RCEKit

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

Version 3.0.1 · 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:

Target	Advisory	RCE class	`--methods`	Verdict	Bench case	Recording
Webmin 1.910	CVE-2019-15107	OS command injection (results-based)	`reflected`	`executed`	yes	GIF
Apache Struts2	S2-001	Expression injection (OGNL)	`eval`	`executed`	yes	GIF
Apache Solr 8.11.0 (Log4j 2.14.1)	CVE-2021-44228	Expression-lookup (Log4Shell/JNDI)	`lookup`	`lookup-sink`	yes	GIF
Webmin 1.910	CVE-2019-15107	Blind command injection (no output)	`time`	`timing-sink`	as a control	GIF
Webmin 1.910	CVE-2019-15107	OS command injection (self-OOB read-back)	`file`	`executed`	yes	—
OpenTSDB 2.4.1	CVE-2023-25826	Blind command injection (gnuplot)	`oob`	`executed`	yes	—
OpenTSDB 2.4.1	CVE-2023-25826	Blind command injection (gnuplot)	`time`	`timing-sink`	as a control	—
Apache HugeGraph 1.2.0	—	Expression injection (Gremlin/Groovy)	`eval`	`executed`	yes	—
Apache HugeGraph 1.2.0	—	OS command injection	`reflected`	`executed`	yes	—
Spring Boot on fastjson 1.2.83	—	Deserialization sink	`deser`	`deserialization-sink`	yes	—
Apache Tomcat 8.5.19	CVE-2017-12615	Write primitive (PUT a JSP)	`write`	`executed`	yes	—

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.1 (2026-10-01), 10/10 cases in 55m48s. That is a point-in-time claim: the benchmark runs on a cadence, not on every change.

The controls are not in this table and two of them are the point. 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 — a ceiling holding against real software rather than against a fixture. Those two are the rows reading as a control above. The full 10, controls included, are in tests/bench/README.md.

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.

reflected — OS command injection, Webmin CVE-2019-15107 → executed

RCEKit confirming OS command injection on Webmin 1.910 (CVE-2019-15107): the shell computes arithmetic on random operands, the result is reflected in the response and absent from a payload-free control

eval — OGNL expression injection, Apache Struts2 S2-001 → executed

RCEKit confirming OGNL expression injection on Apache Struts2 (S2-001): the payload %{ab} evaluates to the product in the response while the literal ab does not

out-of-band — blind Log4Shell (CVE-2021-44228) via a DNS callback → lookup-sink

RCEKit correlating a blind Log4Shell (CVE-2021-44228) DNS callback back to the exact payload that produced it: the token in the queried name is one only the target could have learned by resolving the URI it was handed

time — blind command injection, Webmin CVE-2019-15107 → timing-sink

RCEKit measuring a linear timing response on Webmin 1.910 (CVE-2019-15107): response time tracks a controlled 0/N/2N delay series — a proven timing-sink, never executed on its own

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

rcekit

最受欢迎

RCEKit

Proof, not "maybe"

Quick start