RCEKit

confirmed means the target executed the input. negative means the probes reached it.

Version 2.35.0 · MIT · Python 3.8+ · zero third-party dependencies

RCEKit is an RCE detection & confirmation toolkit for authorised penetration testing, red teaming and security research. Point it at a target you are allowed to test — a URL or a captured HTTP request — and every finding comes back with the tier it earned.

Every confirmed rests on a value RCEKit generated at random for that probe and that reflection cannot produce: a computed result present in the response and absent from a payload-free control, or an out-of-band callback carrying a token only the target ever held. Weaker signals keep their own tiers and are never promoted into it. And a run that could not test something never reports it as clean.

Proof, not "maybe"

RCEKit confirms RCE through multiple methods under one CLI. Below it is pointed at real, publicly-documented CVEs in production software — each verdict differenced against a payload-free control:

Quick start

RCEKit has two supported shapes, and neither is a fallback for the other.

Install it — pipx keeps the CLI in its own environment, which is what you want for a tool rather than a library:

pipx install rcekit          # or: pip install rcekit
rcekit --doctor              # confirms the corpus it will run with

Or take just the one file. The payload corpus is built into the module, so rcekit.py runs on its own with nothing beside it — no install step, no site-packages, nothing to leave behind. On a client jump box, an air-gapped host, or anywhere pip install is not an option:

curl -O https://raw.githubusercontent.com/kabiri-labs/rcekit/main/rcekit.py
python rcekit.py --doctor    # same corpus, same check, zero installation

Both run the same code and report the same verdicts. Working from a checkout is the third way, and needs no install either:

git clone https://github.com/kabiri-labs/rcekit.git
cd rcekit                    # Python 3.8+, standard library only

Put a FUZZ marker where your input lands (or select a parameter with -p when using a captured request), and ask RCEKit to prove RCE:

rcekit --acknowledge-consent \
  --verify-url "https://target.example/lookup?host=FUZZ" \
  --methods reflected,eval

[detect] methods: reflected, eval
[detect] sent 13 probes: confirmed=4, negative=9

[detect] CONFIRMED execution (4):
  [reflected/unix/raw] ; echo RKYZRIP$((540141+314681))RKFWVFS$(echo RKBWOOC)RKYZRIP
      (target computed 'RKYZRIP854822RKFWVFSRKBWOOCRKYZRIP' — random operands, absent from control)

No external infrastructure, no config file.

Don't take the GIFs on trust — reproduce them yourself against dockerised Webmin and Struts2 targets in about five minutes.

Next: the field guide walks the real situations — captured requests, WAFs, filtered separators, quoted sinks, blind and no-egress targets — one worked example each.

What a verdict means

Finding an RCE candidate is easy. Reporting one that survives someone else's retest is the hard part, and it fails in two directions: a "possibly vulnerable" that turns out to be reflection, and a "not vulnerable" from a run that never actually tested anything.

RCEKit answers with seven verdicts that are never collapsed into each other:

The moment confirmed and maybe blur, confirmed stops meaning anything — so nothing is ever promoted upward. A timing regression stays needs-review however clean the slope. A deserialization callback stays deserialization-sink however certain you are that the classpath is exploitable.

The other half: a run that tested nothing is never clean

The last two rows are the ones other tools do not have, and they matter more than they look. A scanner that could not reach the target, or built no probes because your flags excluded every one of them, has learned nothing about the target — and printing negative there is a lie that reads exactly like safety.

So error and nothing-tested are first-class verdicts, the run exits non-zero, and RCEKit says which of them happened and why:

[!] No probes were built, so NOTHING WAS TESTED — this is not a negative result.
[!] None of the selected methods (reflected, file) apply to environment(s): sql.

It fires wherever a run can quietly become empty: a method that does not apply to the selected environments, a --sink-shape rung the chosen shell has no syntax for, a --bridges selection entirely held back by the safety ceiling, a request body that broke delivery before it arrived.

A run that was only partly blinded gets the same treatment one level down. If you asked for a second-order oracle and the observed endpoint never answered, the probe verdicts still stand — but the run tells you they were decided without ever reading the channel you pointed it at, rather than letting them pass for a second-order negative.

What it confirms

One CLI, one --methods flag, covering the main paths to RCE:

Three things widen where those methods can reach, without changing what any of them will call confirmed:

• Second-order execution (--observe-url) — when the payload lands on one request and runs on another: stored SSTI rendered on a profile page, a payload written to a log a template engine later renders, a queued job. The observed endpoint is differenced against a snapshot taken before any probe was sent.
• Query-language bridges (--bridges) — COPY … FROM PROGRAM, xp_cmdshell, expect://. A bridge is a carrier, not an oracle: it wraps the command the methods already build, so the same tiers apply through it.
• Injection-point enumeration (-p all) — query, JSON leaves, form fields, cookies, headers and path segments, each encoded for where it lands, with the probe cost printed before anything fires.

Mix methods freely: --methods reflected,eval,time runs all three and reports each tier separately.

Honest scope. RCEKit confirms RCE that is reachable by injecting into a request and interpreted by a shell or an evaluator. It does not cover memory-corruption bugs (buffer overflow, UAF) or argument injection into a no-shell argv array — those are different problems. Deserialization gadget chains stay out of scope too: --methods deser proves an endpoint deserializes attacker data and says so in its own tier, but which gadget (if any) turns that into execution depends on the target's classpath, and RCEKit does not claim to know. It aims to be excellent at the injection-driven RCE classes above rather than mediocre at everything.

How RCEKit compares

The other tools in this space are built to get you in. RCEKit is built so the finding survives someone else's scrutiny — the client's retest, the triage queue, the report review. That difference shows up three times.

1. One injection point, every class, one run

You rarely know the class before you test. Covering an unknown sink with single-class tools means running each in turn and rebuilding the request for each one:

_{Coverage per each project's own documented technique list. SSTImap is the maintained successor to tplmap, which its author has marked unmaintained.}

# Command injection, expression injection and blind timing against the same
# parameter, in one pass, with zero infrastructure
python rcekit.py --acknowledge-consent -r request.txt -p host --methods reflected,eval,time

2. It argues with its own results

A tool reports what it found. RCEKit also reports what it refused to believe — inconclusive is a verdict of its own, for evidence that showed up but could not be attributed to execution:

[detect] methods: reflected, eval
[detect] sent 13 probes: confirmed=0, inconclusive=2, negative=11

Those two would have been someone else's finding. Five mechanisms produce that verdict, and they run on every confirmation:

• A payload-free control request. Evidence must be present with the payload and absent without it. Anything in both is inconclusive, not a finding.
• A same-token inert control. A second request carries the identical random token in a non-executing form. A target that merely echoes input fails here — which is how a reflection is separated from an execution.
• Random operands, never fixed strings. The oracle is a tag-wrapped sum or a boundary-fenced product computed fresh each run. Echoing the payload returns the literal $((a+b)); only execution returns the value.
• Encoding-aware evidence search. A sink that base64-, hex-, URL-, HTML- or unicode-escapes its output still confirms — the raw body is checked first, so decoding only ever turns a missed hit into a hit, never the reverse.
• Whole-response evidence search. The computed value is looked for in every channel of the response — body, application headers, cookie values, the redirect target, the HTTP reason phrase, and each leaf of a JSON error envelope — and the finding names the channel that carried it. The control differential is applied to every channel too, so widening where RCEKit looks does not widen what it will call confirmed.

The same instinct runs the other way. Timing never self-confirms, a deserialization callback is never called RCE, and a run that built no probes is never called negative.

3. It is built for an authorised engagement, not a lab

The controls a client's rules of engagement actually ask about, in the tool rather than in your notes:

When to reach for something else

Want a shell rather than a verdict? commix and SSTImap continue into post-exploitation; RCEKit stops at proof by design. Sweeping thousands of hosts for known CVEs? That is Nuclei's job — and RCEKit writes Nuclei templates (--output-format nuclei), so it feeds your scanner instead of competing with it. Already know the injection is SQL and want the database itself? sqlmap owns that ground — RCEKit's bridges exist to prove the OS is reachable from a text parameter, not to exploit the database.

Find your situation

Each row is a worked example in the field guide — the command, what it sends, and how to read what comes back.

Documentation

Safety & ethics

• Consent gate — exploitation generation and verification require --acknowledge-consent; --detection-only is benign and does not.
• Safe by default — verification fires only low-impact proofs; reverse shells, download-execute, credential access, lateral movement, container escape, cloud-metadata and OOB payloads are held back until you raise --verify-active-risk. Destructive payloads (persistence, backdoors) are never fired without --verify-allow-destructive. An execution plan prints exactly what will be sent before anything fires.
• Safety tiers — safe / intrusive / stateful, filtered by --max-safety. A method or bridge that leaves something behind is held to the same ordering as every corpus payload, and the pre-flight names the tier each held-back item actually needs.
• Audit & logging — every exploitation/verification run is recorded in exploit_audit.log; --watermark embeds a traceable token; execution logs go to rcekit.log.
• Corpus integrity — a corpus that is corrupt, or an explicit --template-file that is missing, makes RCEKit refuse to run and exit non-zero rather than silently generate nothing (--doctor checks it). Only an absent default corpus file falls back to the built-in copy, and it says so when it does.

This toolkit is intended for authorised penetration testing, security research, education, and defensive training only. Never use it against systems without explicit permission — unauthorized testing is illegal.

Development

python -m unittest discover -s tests   # dependency-free test suite

Contributions welcome — new sinks/categories, encodings, environments, detection methods, bug fixes, and docs. Payload bases live in editable JSON templates (templates/payloads.json), so most coverage extends without touching the Python source. After changing the corpus, refresh the built-in copy that ships inside rcekit.py:

python tools/embed_corpus.py    # --check verifies it is current

The test suite fails if the two ever drift. See CONTRIBUTING.md.

License

MIT — see LICENSE.