MVEL Script Injection RCE in Elasticsearch _search

This is a deliberately vulnerable training environment with a documented exploit, rather than a standalone automated exploit tool. The two app READMEs contain equivalent English and Chinese HTTP walkthroughs: create an indexed document, then POST to /_search?pretty with an MVEL script in script_fields. Java Runtime.exec runs the hardcoded command id, and Scanner returns stdout in the search result. No reverse shell, persistence, credential theft, or container escape payload is supplied, despite the CTF metadata describing a shell as the challenge objective. The documented command-execution payload supports the OPERATIONAL classification, but it was not executed or independently validated here. The 33 files comprise CTF metadata; publishing and validation workflows; root documentation and licensing; the vendored app walkthrough and minimal Compose configuration; an Elasticsearch image Dockerfile, Bash entrypoint, and logging configuration under base/; a version-check script; the authoritative isoloom.yml; and generated deployment artifacts under .isoloom/. These artifacts support Docker, Kubernetes, Docker-hosting Vagrant and Proxmox VMs, and six cloud providers: AWS, Azure, DigitalOcean, GCP, Linode, and OCI. The code-file count of 15 includes seven Terraform files, one Ruby Vagrantfile, six shell scripts, and one Dockerfile; declarative YAML/JSON files and README-embedded payloads are excluded from that count. MVEL is present only in documentation. Isoloom is deployment tooling, not an exploit framework. Checks verify HTTP availability, the reported Elasticsearch version, and blocked internet access; they do not exercise the RCE or prove exploitability. Docker uses a route-removal sidecar, while Kubernetes uses egress NetworkPolicies whose enforcement depends on the cluster networking implementation. Local generated deployment defaults to loopback publishing, cloud firewalls restrict SSH and ports 9200/9300 to an operator-supplied CIDR, and Kubernetes creates a LoadBalancer with ingress allowed to those ports from any IPv4 source. The minimal vendored app Compose file lacks the generated isolation controls. Command execution occurs inside the vulnerable Elasticsearch container, not inherently on its host. Network observables are target API paths, private lab addresses, isolation probes, and software/provisioning download endpoints; no hardcoded attacker callback is present. Provisioning contains legitimate cleanup commands and Docker installer execution, which are not evidence of a fake exploit. The upstream Vulhub source is documented at commit 8fd63916f7a8711e2e01dda0d27237e4d6175d38, but the original analyzed repository URL, its analyzed Git reference, and archive byte size were not supplied; empty strings and zero represent unavailable repository metadata.

This repository contains a single Metasploit module (script_mvel_rce.rb) that exploits CVE-2014-3120, a remote code execution vulnerability in ElasticSearch versions prior to 1.2.0. The exploit leverages the REST API's dynamic scripting feature, which allows unauthenticated attackers to execute arbitrary Java code via specially crafted search requests. The module determines the target's OS, identifies a writable directory, uploads a Java JAR payload (containing a Metasploit shell or similar), and executes it using Java reflection. The exploit is weaponized, allowing for customizable payloads and full remote code execution. The main network endpoint targeted is the ElasticSearch REST API (default port 9200, path /_search). The module is written in Ruby and is designed to be used within the Metasploit framework.