# Commix: an automated command injection exploiter for authorised pentests

> Commix is a Python 3.7+ CLI tool that detects and exploits OS command and code injection across four techniques, from classic results-based to out-of-band. Here is how it installs, how the techniques differ, and where it stops being the right tool.

**commixproject/commix** — Automated Αll-in-One OS command injection exploitation tool.

- Repository: https://github.com/commixproject/commix
- Website: https://commixproject.com
- Stars: 5,867 · Forks: 943
- Language: Python
- License: NOASSERTION
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/commixproject-commix

## The gap Commix fills between a scanner and a shell

A generic web scanner will tell you that a parameter looks injectable. It will not tell you which of the four injection techniques actually works against that parameter, and it will not hand you a shell. Commix is built for that second step. The README describes it as an open source penetration testing tool that automates the detection and exploitation of command and code injection vulnerabilities, written by Anastasios Stasinopoulos.

The audience is narrow and worth stating plainly: penetration testers and bug bounty hunters working against systems they own or have explicit authorisation to test. The README repeats that warning twice, once in the feature list and once in an important note that says commix executes operating system commands on the targets it tests. That is not boilerplate. A tool that reaches an os_shell on a production host is a different category of risk from a scanner that only reports.

The supported back ends are broad: PHP, Python, Perl, Ruby, ASP.NET, JSP and CGI, against both Unix-like and Windows targets. The wiki page linked from the README, Windows and Unix-like targets at a glance, is where the payload differences between those two families are documented. If your target is Windows and you assume the Unix payload set applies, that page is the one to read first.

## Four injection techniques and how Commix picks between them

The mechanism is technique selection. Commix supports results-based (classic) injection, time-based (blind), file-based (blind, with a tempfile-based variant for write-restricted targets), and out-of-band over HTTP/S and DNS. You either name the technique with --technique or let the tool report the type it found with --type.

The distinction matters because each technique extracts data through a different channel. Results-based reads the command output straight out of the HTTP response. Time-based infers execution from response delay when nothing is echoed back. File-based writes to the target filesystem and reads the result back, and the tempfile variant exists for targets where the obvious write locations are closed. Out-of-band sends the proof of execution to a listener you control, which is the only option when the response carries nothing back at all.

Injection surface is wider than query strings: GET and POST parameters, HTTP headers, cookies, JSON and XML request bodies, plus a shellshock module for CGI targets. The same four techniques also drive --eval, which tests the string a target evaluates as code, in PHP or Python. Targeting is equally flexible: a single URL, a crawl, HTML forms, a sitemap, a proxy log, a bulk file, a raw HTTP request file, or piped stdin. Results are stored per target in a session file so a scan can be resumed, and exported to JSON.

## Installing Commix and running a first out-of-band check

Commix has no package manager step. The README says to clone the official Git repository, and notes that Python 3.7 or later is required while all other dependencies are bundled, so no additional installation step is needed. The clone command from the README is:

```bash
git clone https://github.com/commixproject/commix.git commix
```

After that, change into the commix directory and list the options. The README gives this as the way to see all switches:

```bash
python3 commix.py -h
```

The first real use in the README is a single injectable parameter followed by an interactive shell on the target:

```bash
python3 commix.py --url="http://www.target.com/vuln.php?addr=127.0.0.1" --os-shell
```

Where the response carries nothing back, the README shows an out-of-band run against a POST parameter instead:

```bash
python3 commix.py --url="http://www.target.com/vuln.php" --data="addr=127.0.0.1" --oob
```

One caveat belongs with that second command, and the README states it directly: out-of-band detection with --oob uses the public oast.fun interactsh server by default, so interaction metadata for your target leaves your network. Point --oob-server at a self-hosted instance to keep it in-house. For unattended runs across a list, the README shows bulk mode with batch answers and a JSON report:

```bash
python3 commix.py -m targets.txt --batch --report-json=results.json
```

## Where Commix is the wrong tool

The README is honest about the sharpest limitation, and it is worth taking at face value: commix is primarily built to be used as a standalone CLI tool, and running it as a service may pose security risks. If your architecture assumes a scanning component you can wrap in an API and call from a scheduler, that is not the shape this project is documented to have. The README describes a CLI, a session file per target, and JSON export. It does not describe a server mode, a daemon, or an authentication layer around one.

The second limitation is authorisation. Nothing in the tool prevents you from pointing it at a host you do not control, and the README's warning is the only guardrail it offers. That is a policy problem a command-line flag cannot solve, but it does mean Commix belongs in a scoped engagement, not in an always-on internet scanner.

The third is the out-of-band default. Using the public oast.fun interactsh server means interaction metadata for your target leaves your network. For engagements with data handling rules, that default is not acceptable and --oob-server is not optional. Teams that skip that step are, in effect, sending target interaction data to a third party.

Finally, the project warns that it is in active development and to expect breaking changes between revisions, with a pointer to the changelog before updating. The repository's own setup.py carries version 4.2.dev, which is a development version rather than a released tag. If you pin Commix in a repeatable test harness, pin it to a release such as 4.1-stable from 2025-12-20 rather than tracking master.

## Commix against a general web scanner: different starting point

The natural comparison is a general-purpose web vulnerability scanner. The difference is the starting point, not the coverage list. A general scanner begins from a crawl and enumerates many vulnerability classes, then reports findings for a human to triage. Commix begins from the assumption that you already suspect a command injection point, and spends its effort proving which technique reaches it and then giving you an interactive shell.

That shows up in the interface. Commix accepts a single URL, a raw HTTP request file, a proxy log, or piped stdin, which are all ways of handing it a specific request you already care about rather than a site to explore. It also has an os_shell on the target, reverse_tcp and bind_tcp modes, and file download and upload over the established shell, plus enumeration of current user, hostname, privileges, system information, users and password hashes. A reporting scanner stops at the finding. Commix continues into post-exploitation, which is exactly why the authorisation warning is repeated.

The practical division of labour: use a general scanner to find candidates across an application, then use Commix on the specific parameter to determine whether it is genuinely injectable and to demonstrate impact. Running Commix as a broad discovery pass is possible given the crawl, sitemap and bulk-file inputs, but that is not where its documented strengths sit.

## Licence, maintenance and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-22. The README carries an important note stating the project is in active development and that breaking changes between revisions should be expected, with the changelog as the reference before updating. Releases are roughly annual: v3.9 on 2024-01-19, v4.0 on 2024-12-20, and v4.1 on 2025-12-20. Between those tags, master moves.

Licensing is GPLv3. The README badge says GPLv3, setup.py declares the same and classifies it as GNU General Public License v3, and the repository root contains LICENSE.txt. The GitHub API reports the licence as NOASSERTION, which is a metadata mismatch rather than a different licence, but it is the kind of thing that trips automated compliance tooling. If your organisation gates dependencies on machine-readable licence metadata, that mismatch is worth resolving before Commix enters a build.

GPLv3 is a copyleft licence. This is not legal advice, but the practical implication for most users is limited: Commix is a tool you run, not a library you link, and the README describes it as a standalone CLI. The upgrade cost is the real ongoing expense. Because the project warns of breaking changes between revisions and because the development version is 4.2.dev, a pinned release is the safer default for any scripted or repeatable test, and the changelog is the document to read before moving the pin.

## Conclusion

Adopt Commix if you run authorised web application tests and need repeatable detection plus an interactive shell on the target, especially where the response carries nothing back and out-of-band detection is the only option. Do not adopt it if you cannot point to written authorisation for every host you test, or if you need a library to embed in a pipeline: the README describes a standalone CLI, and it states that running commix as a service may pose security risks. Before your first real engagement, verify three things: that Python 3.7 or later is on the machine, that you are willing to route OAST traffic through a self-hosted instance via --oob-server rather than the default public oast.fun interactsh server, and that you have read the changelog, because the project warns of breaking changes between revisions.

## FAQ

### What does Commix mean?

The README states that Commix is short for command injection exploiter, taking comm from command, i from injection and x from exploiter.

### How do I install Commix?

Clone the official Git repository with git clone https://github.com/commixproject/commix.git commix. Python 3.7 or later is required, and the README notes that all other dependencies are bundled, so no additional installation step is needed.

### Does Commix need a package manager or extra dependencies?

No. The README says Python 3.7 or later is required for running commix and that all other dependencies are bundled, so the clone is the whole installation.

### What techniques does Commix support for command injection?

Four: results-based (classic), time-based (blind), file-based (blind, with a tempfile-based variant for write-restricted targets), and out-of-band over HTTP/S and DNS. They are selected with --technique or reported by type with --type.

### Does Commix send data to a third party when using out-of-band detection?

By default, yes. The README states that out-of-band detection with --oob uses the public oast.fun interactsh server, so interaction metadata for your target leaves your network, and that pointing --oob-server at a self-hosted instance keeps it in-house.

## Sources

- [commixproject/commix on GitHub](https://github.com/commixproject/commix)
- [Issues](https://github.com/commixproject/commix/issues)
- [Project website](https://commixproject.com)
- [README](https://github.com/commixproject/commix/blob/master/README.md)
- [Releases](https://github.com/commixproject/commix/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/commixproject-commix