RCEKit

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

Version 3.0.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 executed rests on a value RCEKit generated at random for that probe and that reflection cannot produce. It comes back through one of 3 channels: a computed result present in the response and absent from a payload-free control; an out-of-band callback carrying a token only the target ever held; or a value the target stored and RCEKit fetched back in a second request — the token file has it write to a path it serves, the product write's one-liner computes when the target interprets the file it stored. 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 production software — publicly-documented CVEs, and builds that demonstrate a method without reproducing one — with every verdict differenced against a payload-free control:

3 of those columns say how much weight the row carries, and they are the ones worth reading before the rest.

Verdict is what the run reported against that build. Measured, not what the method could reach in principle.

Bench case says whether tests/bench/ reproduces the row — bringing the target up under Docker and checking the verdict and its negative control. All 11 rows do; python tests/bench/runner.py --all was last green at 3.0.0 (2026-09-30), 9/9 cases in 55m50s. That is a point-in-time claim, not a continuous one: the benchmark runs on a cadence, not on every change. A row reading as a control is reproduced by the control half of another row's case, which is the half that describes it.

3.0.0 renamed the verdict every case expects, so every one of the 9 was re-run under the new names and all 9 passed — the Verdict column above is what that run reported, not a rename applied to an older result.

What each run's control half reported is not in this table, and two of them are the reason the run was worth doing. The full 9 rows, controls included, are in tests/bench/README.md; the two rows here reading as a control are the time halves of the Webmin and OpenTSDB cases, so their timing-sink is a control result shown in the Verdict column.

Those two are the ones worth having: on a Webmin 1.910 and an OpenTSDB 2.4.1 that are genuinely vulnerable, time reaches its own proven tier and still does not reach executed. That is the tier ceiling holding against real software rather than against a fixture.

Advisory is empty where the verdict does not depend on the patch. Both HugeGraph rows and the fastjson row are — deliberately: HugeGraph 1.3.0 answers the arithmetic exactly as 1.2.0 does — its Gremlin API evaluates Groovy unauthenticated by design, which was checked by pulling the patched image and running it — and fastjson resolving an Inet4Address is documented autoType behaviour. Those rows prove a method against real software, which is worth recording; calling them CVE reproductions would be the overclaim this table exists to avoid.

Each control is the row's real test. Struts2 probed with reflected comes back negative, because S2-001 re-evaluates OGNL and there is no shell behind it. Webmin's time signal is held at timing-sink on a target where it happens to be right. And Solr probed with oob comes back negative although it is exploitable -- oob builds shell commands and a ${jndi:...} sink runs none of them, which is the gap lookup exists to close, measured rather than asserted.

The Log4Shell row says lookup-sink, not executed: what the callback proves is that the sink resolved a URI RCEKit chose. Reaching RCE needs a server that answers the lookup with a loadable class, and at the default risk tier only jndi:dns:// goes out -- a name lookup, with no connection past it for such a server to answer on.

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 (13 result(s)): executed=4, negative=9

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

From a captured request — the shape most real targets have

A --verify-url carries a URL and nothing else. Most sinks worth testing sit behind a POST with a session cookie, a content type and a body, and RCEKit takes that request whole: save it from your proxy or your browser's devtools and name the field to inject into.

rcekit --acknowledge-consent \
  -r search.req -p q \
  --methods reflected,eval

[detect] sent 4 probes (4 result(s)): executed=3, negative=1

[detect] EXECUTED (3):
  [reflected/unix/raw] ; echo RKHWNHK$((114157+752773))RKXGFIH$(echo RKHSEIF)RKHWNHK
      (target computed 'RKHWNHK866930RKXGFIHRKHSEIFRKHWNHK' — random operands, absent from control)

The method, path, headers, body and cookies are reused as captured, and each value is encoded for the context it lands in — a JSON leaf, a form field and a cookie are not escaped the same way. Drop -p and mark the spot with FUZZ or * instead, if you prefer.

Everything the tool has

Two things are only reachable from a captured request: injection-point enumeration (--auto-params), and any sink that needs a session. So the fullest run RCEKit can make starts from -r, not from a URL — which is worth knowing before concluding a target is clean.

rcekit --acknowledge-consent \
  -r search.req --auto-params all --point-order thorough \
  --methods reflected,eval,time,lookup,deser \
  --oob-host oob.yourdomain.example --listen-dns-port 53 \
  --verify-active-risk stateful --probe-depth full \
  --detect-json findings.json

[verify] loaded request from search.req: enumerating 4 injection point(s)
[detect] enumerating 4 injection point(s) x 3 method(s)
[detect] cost: 4 points x ~1739 probes = at least 6964 requests
[detect]   body param 'q': executed (1544 probes)  <-- EXECUTED
[detect] sent 6371 probes: executed=446, negative=5925

What each flag opens up:

This is a lot of requests. The cost line prints before anything fires, and --max-points / --max-payloads bound it. Run it against an instance you are allowed to break: --verify-active-risk stateful is the tier for a disposable target, not for production.

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 twelve verdicts that are never collapsed into each other. Every one of them is named for what the target did, not for how sure RCEKit is:

The moment executed and maybe blur, executed stops meaning anything — so nothing is ever promoted upward. A timing regression stays timing-sink however clean the slope. A deserialization callback stays deserialization-sink however certain you are that the classpath is exploitable. A response shape that tracks a predicate stays evaluation-sink however cleanly it partitions: measured against a sandboxed eval sink and against a plain SQLite comparison, that oracle produced the same clean differential in 40 runs each, and only one of those two is RCE.

Nothing is rounded down either, which is the half that used to be wrong. Three of the rows above — timing-sink, file-write, evaluation-sink — were reported as needs-review until 3.0.0. Each is a settled measurement, so needs-review was RCEKit declaring itself unsure of something it had proven; a file-write finding printed the words "ARBITRARY FILE WRITE confirmed" under a verdict that said the opposite. A verdict now says what happened and stops there.

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

The last three rows are the ones other tools do not have, and they matter more than they look. A scanner that could not reach the target, that built no probes because your flags excluded every one of them, or whose every payload was refused by a WAF, 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 executed:

• 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, multipart parts, cookies, headers and path segments, each encoded for where it lands, with the probe cost printed before anything fires. A GraphQL body is ordered by what can actually confirm: the variables a resolver reads before the operation document itself.

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 anything it cannot attribute to execution: evidence that showed up in the payload-free control too, and equally a measurement the run never finished gathering:

[detect] methods: reflected, eval
[detect] sent 13 probes (13 result(s)): executed=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 executed.

The same instinct runs the other way. Timing never self-confirms, a deserialization callback is never called RCE, a response shape that tracks a predicate is never called execution — a query engine comparing two numbers produces the same shape — 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

RCEKit exploits, and that is the point. A vulnerability is confirmed by making the target do the thing, because that is the only evidence a signature cannot fake and a patched build cannot produce by accident. What bounds a run is not reluctance to exploit. It is two structural facts and one switch.

It takes no arbitrary payload from you. Probes are built by the engine to serve an oracle — arithmetic on operands random to that probe, a name only this run could have chosen. There is no input that turns detection into something else, because there is no such input to give.

Anything reaching past computing a value declares the tier it needs, so one flag decides how far a run goes: --verify-active-risk safe | intrusive | stateful. A method or a single probe shape above that tier is held back by name, with the flag that would send it — a ladder that shrinks quietly is indistinguishable from a target with nothing to find. Against a disposable instance, raise the tier and get everything the tool has.

• 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. Corpus payloads are filtered by --max-safety; detection methods and their probe shapes declare the same rungs and are filtered by --verify-active-risk, so a method that makes the target reach out or leaves something behind is held to the same ordering as every corpus payload. The pre-flight names the tier each held-back item actually needs. file and write are gated by their own configuration instead: neither does anything until you name a directory to write into and a URL to read it back from.
• 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.