A deliberately vulnerable, multi-language collection of web pages built to exercise commix detection techniques and teach how command and code injection bugs actually manifest in code, for authorized training and research.
| Tool | commixproject/commix-testbed — a collection of deliberately vulnerable web pages for exercising command and code injection detection |
| Category | Vulnerable application / security training lab |
| Primary Use | Testing and learning commix injection techniques against known-flawed PHP, Python, Ruby, Perl, Lua, JavaScript and Java scenarios in a local lab |
| Safe Use | Run strictly locally in isolated labs or authorized training environments; the README itself warns the pages execute whatever input they receive and must stay off networks you do not control |
| Telemetry Note | Every scenario shells out or evaluates input on the host running it; defenders observing this traffic would see structured injection probes against ping, eval()-style sinks and out-of-band callbacks — useful signatures for recognizing scanner activity in authorized assessments |
commix-testbed is the companion target range for commix, the well-known open-source command injection tool from the same project. Written by Anastasios Stasinopoulos (@ancst), it is a curated collection of deliberately vulnerable web pages whose single purpose is to exercise commix's detection and exploitation techniques and to teach what OWASP-class command and code injection actually looks like in source. The design philosophy is elegant in its restraint: every page contains the same underlying bug — a request value reaching a shell or an evaluated string — while everything around it varies. That variation, where the value lands, what the application does to it first, and how much output returns, is precisely what separates an injection point found in seconds from one that is nearly invisible, and it is why a scanner needs more than one technique.
The collection is organised into scenario families that map cleanly onto real-world bug patterns. The regular set covers GET, POST and PUT bodies, JSON, GraphQL and SOAP/XML documents, Base64 and hex encodings, single and double quoting, HTTP Basic and Digest authentication, and a page where only two of three parameters are validated — a subtle partial-validation case that trips naive fuzzers. The eval() code-sink family exercises eval(), assert(), preg_replace() with attacker-controlled patterns, create_function(), and str_replace() sanitising into an evaluated string, giving students a tour of PHP's historical code-evaluation surface.
What makes the testbed genuinely valuable for training is the filter-bypass section. Each weak filter is wrong in a different way: denylisted metacharacters, whitespace rejection, anchored patterns constraining only one end of input, lax domain validation, a command-name blocklist, a function-name blocklist that inspects only the query string, and a check on the first of two same-named parameters while the application reads the last. These mirror real developer mistakes almost one-to-one, and each scenario carries an explanation of what the code gets wrong, so the collection reads as a structured tour of the bug class rather than a pile of targets.
Beyond single-request injection, the stateful and multi-step scenarios are where the testbed distinguishes itself from older projects like DVWA. Pages require login sessions, anti-CSRF tokens and single-use nonces, second-order sinks that answer on a different page, account lockout, held-open connections, endpoints that fail at random, chunked request bodies, non-standard parameter and cookie delimiters, out-of-band-only sinks, and output deferred until the next request. There is even a branch reachable only from a phone user-agent and a Set-Cookie header that breaks the session if stored. These are the conditions under which automated scanners fail in the field, reproduced deliberately.
Discovery is treated as its own challenge class: one page's injectable parameter is never named in the markup, routes exist only inside a script a page loads, and an API publishes an OpenAPI description of endpoints nothing links to. This reflects a mature understanding that finding the injection surface is often harder than exploiting it, and it forces users of commix to engage with crawling and parameter-discovery behaviour rather than pointing at a known URL.
Language diversity is a headline feature. The same classic, blind and code-injection bugs are reimplemented in Python, Ruby, Perl, Lua and JavaScript CGI/server variants, plus a Java scenario evaluated through the Nashorn engine — matching commix's own --eval=perl, --eval=lua and --eval=javascript options, and giving the javascript grammar a second engine to run against. The Ruby and Perl pages correspond to genuine CTF recreations rather than PHP stand-ins, which matters for anyone studying engine-specific quirks.
The CTF section recreates real, named challenges faithfully, filters and languages included: YesWeHack Dojo challenges #30, #36, #41 and #46, a Root-Me filter bypass, OverTheWire Natas Level 16, DVWA's Command Injection at high, ImaginaryCTF 2025's Perl open() pipe-quirk challenge, and DeadSec CTF 2024's Bing2. For bug-bounty trainees, this turns the testbed into a replayable archive of published challenge knowledge.
Deployment is refreshingly simple. The published Docker image carries PHP, Python, Ruby, Perl and Lua, so a single docker run --rm -p 8080:80 commixproject/commix-testbed brings up most of the collection; docker compose up -d adds the Node and Nashorn servers on ports 8087 and 8088. The base image is Ubuntu 14.04, a deliberate choice so older PHP scenarios — those depending on create_function(), the e regex modifier, or string-evaluating assert() — remain exploitable, since those features were removed in PHP 7 and 8.
A hand-rolled install is equally viable but demands attention. The README is unusually honest about the operational prerequisites: php -S will not execute the CGI pages (Python, Ruby, Perl and Lua get served as text), so a real web server with mod_cgid and per-extension handlers is needed for those. Most pages shell out to ping, the file-based technique needs a writable web root, and the out-of-band technique needs outbound network access — a hand-rolled install missing any of these produces scans that look like passes while never exercising the corresponding techniques.
Several environment details are engineered into the image rather than documented as afterthoughts. hidden/blind.php is served from outside the document root through an alias so its path cannot be guessed from the URL; the kid scenario resolves filenames against a key directory at /var/www/keys; and because one scenario filters - from input, the image ships a dash-free symlink at /var/www/html so --web-root=/var/www/html covers every scenario. Scenarios are labelled with the technique type commix reports and each page states which option reaches it — several exist to exercise one specific option and cannot be found without it.
From a defensive perspective, the testbed is equally useful in reverse. Engineers writing WAF rules, code reviewers learning to recognise dangerous sinks, and SAST tool developers benchmarking detection coverage against eval(), shell-outs and filter logic all benefit from a corpus where every flaw is documented and intentionally varied. The README's own warning deserves repeating: these pages execute whatever they are given, so the testbed must stay on isolated, authorized networks — it is a target, not a demo left running. With 186 stars, GPLv3 licensing, active maintenance at version 2.0, and a scenario catalogue this thorough, commix-testbed is arguably the most complete dedicated injection training range available in open source.
commixproject/commix-testbed.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.