rcekit

Toolkit per il rilevamento e la conferma di RCE che verifica URL o richieste HTTP catturate per command injection, SSTI, percorsi blind e OOB, restituendo verdetti a livelli con prova.

Ogni riga è riprodotta da tests/bench/, che esegue RCEKit contro queste build sotto Docker e verifica il verdetto e il suo controllo negativo. Ultima esecuzione verde alla 2.36.0 (2026-09-20): 3/3 casi. Questa è una affermazione puntuale, non continua -- il benchmark viene eseguito con una cadenza, non a ogni modifica.

Ogni controllo è il vero test della riga. Struts2 sondato con reflected torna negative, perché S2-001 rivaluta OGNL e non c'è una shell dietro di esso. Il segnale time di Webmin è mantenuto a needs-review su un target dove capita di essere corretto. E Solr sondato con oob torna negative sebbene sia sfruttabile -- oob costruisce comandi shell e un sink ${jndi:...} non ne esegue nessuno, che è il divario che lookup esiste per colmare, misurato piuttosto che asserito.

La riga Log4Shell dice lookup-sink, non confirmed: ciò che il callback prova è che il sink ha risolto un URI scelto da RCEKit. Raggiungere RCE richiede un server che risponda alla lookup con una classe caricabile, e al livello di rischio predefinito solo jndi:dns:// esce -- una name lookup, senza alcuna connessione oltre essa per un tale server a cui rispondere.

Avvio rapido

RCEKit ha due forme supportate, e nessuna è un fallback per l'altra.

Installalo — pipx mantiene la CLI nel proprio ambiente, che è ciò che vuoi per uno strumento piuttosto che una libreria:```bash pipx install rcekit # or: pip install rcekit rcekit --doctor # confirms the corpus it will run with

Entrambi eseguono lo stesso codice e riportano gli stessi verdetti. Lavorare da un checkout è il terzo modo, e non richiede alcuna installazione:```bash git clone https://github.com/kabiri-labs/rcekit.git cd rcekit # Python 3.8+, standard library only

| -s | --server | SERVER | http://localhost:8080 | URL del server MCP | | -t | --token | TOKEN | null | Token di autenticazione | | -c | --config | CONFIG | null | File di configurazione | | -v | --verbose | VERBOSE | false | Abilita output dettagliato | | -h | --help | HELP | false | Mostra il messaggio di aiuto |

Esempi di utilizzo

Integrazione

Integrazione con Claude Desktop

Aggiungi quanto segue al file di configurazione di Claude Desktop:

Integrazione con VS Code

Installa l'estensione MCP per VS Code e configura il server:

Sviluppo

Prerequisiti

• Node.js >= 18.0.0
• npm >= 9.0.0

Configurazione

Test

Build

Contribuire

I contributi sono benvenuti! Segui questi passaggi:

1. Fai il fork del repository
2. Crea un branch per la funzionalità (git checkout -b feature/amazing-feature)
3. Esegui il commit delle modifiche (git commit -m 'Add some amazing feature')
4. Esegui il push del branch (git push origin feature/amazing-feature)
5. Apri una Pull Request

Licenza

Questo progetto è distribuito sotto licenza MIT. Consulta il file LICENSE per i dettagli.

Ringraziamenti

• Model Context Protocol
• Anthropic
• Kitploit

Supporto

• 📧 Email: [email protected]
• 🐛 Issues: GitHub Issues
• 💬 Discussions: GitHub Discussions

Nota: Questo progetto è fornito solo a scopo educativo e di ricerca. Gli autori non sono responsabili per qualsiasi uso improprio.``` [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)

Utilizzo

Opzioni

Esempi

Come funziona

Lo script invia una richiesta POST appositamente predisposta all'endpoint /api/upload con un payload multipart che sfrutta la vulnerabilità di path traversal. La risposta viene analizzata per determinare se il target è vulnerabile.

Payload

Rilevamento

Lo script controlla la risposta alla ricerca di indicatori di sfruttamento riuscito:

• Codice di stato HTTP 200
• Presenza di stringhe specifiche nella risposta
• Tempo di risposta

Limitazioni

• Lo script è progettato solo per test autorizzati
• Potrebbe non funzionare su tutte le configurazioni
• Richiede accesso di rete al target

Riferimenti

• CVE-2025-55182
• Documentazione OWASP

Licenza

Questo progetto è rilasciato sotto la licenza MIT.``` [detect] sent 4 probes: confirmed=3, negative=1

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

Utilizzo

Esempi

Come funziona

Lo script sfrutta la vulnerabilità CVE-2025-55182 inviando una richiesta POST appositamente predisposta all'endpoint di destinazione. La richiesta contiene un payload progettato per attivare l'esecuzione di codice in remoto (RCE) sul server.

Requisiti

• Python 3.x
• Libreria requests

Installazione

Esclusione di responsabilità

Questo strumento è fornito solo a scopo didattico e di ricerca sulla sicurezza. Gli autori non sono responsabili per qualsiasi uso improprio o danno causato da questo software. Usalo in modo responsabile e solo su sistemi che possiedi o per cui hai ricevuto autorizzazione esplicita.

Riferimenti

• CVE-2025-55182
• Analisi della vulnerabilità

Licenza

Questo progetto è rilasciato sotto la Licenza MIT.``` [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': confirmed (1544 probes) <-- CONFIRMED [detect] sent 6371 probes: confirmed=446, negative=5925

Colpisce ovunque una run possa silenziosamente diventare vuota: un metodo che non si applica agli ambienti selezionati, un gradino --sink-shape per cui la shell scelta non ha sintassi, una selezione --bridges interamente trattenuta dal tetto di sicurezza, un corpo di richiesta che ha interrotto la consegna prima di arrivare.

Una run che è stata solo parzialmente accecata riceve lo stesso trattamento un livello più in basso. Se hai richiesto un oracolo di secondo ordine e l'endpoint osservato non ha mai risposto, i verdetti delle sonde restano validi — ma la run ti dice che sono stati decisi senza mai leggere il canale verso cui l'hai puntato, invece di lasciarli passare per un negativo di secondo ordine.

Cosa conferma

Una CLI, un flag --methods, che copre i principali percorsi verso l'RCE:

Tre cose ampliano dove quei metodi possono arrivare, senza cambiare ciò che ciascuno di essi chiamerà confirmed:

• Esecuzione di secondo ordine (--observe-url) — quando il payload atterra su una richiesta e viene eseguito su un'altra: SSTI memorizzato renderizzato su una pagina profilo, un payload scritto in un log che un template engine renderizza in seguito, un job in coda. L'endpoint osservato viene differenziato rispetto a uno snapshot preso prima che qualsiasi sonda fosse inviata.
• Bridge verso linguaggi di query (--bridges) — COPY … FROM PROGRAM, xp_cmdshell, expect://. Un bridge è un vettore, non un oracolo: avvolge il comando che i metodi già costruiscono, quindi gli stessi livelli si applicano attraverso di esso.
• Enumerazione dei punti di iniezione (-p all) — query, foglie JSON, campi form, parti multipart, cookie, header e segmenti di path, ciascuno codificato per dove atterra, con il costo della sonda stampato prima che qualsiasi cosa parta. Un body GraphQL è ordinato per ciò che può effettivamente confermare: le variables che un resolver legge prima del documento dell'operazione stesso.

Mescola i metodi liberamente: --methods reflected,eval,time esegue tutti e tre e riporta ciascun livello separatamente.

Ambito onesto. RCEKit conferma l'RCE che è raggiungibile iniettando in una richiesta e interpretato da una shell o da un valutatore. Non copre bug di corruzione della memoria (buffer overflow, UAF) o injection di argomenti in un array argv senza shell — quelli sono problemi diversi. Anche le gadget chain di deserializzazione restano fuori ambito: --methods deser dimostra che un endpoint deserializza dati dell'attaccante e lo dice nel proprio livello, ma quale gadget (se esiste) lo trasforma in esecuzione dipende dal classpath del target, e RCEKit non pretende di saperlo. Mira a essere eccellente nelle classi di RCE guidate da injection sopra elencate piuttosto che mediocre in tutto.

Come si confronta RCEKit

Gli altri strumenti in questo spazio sono costruiti per farti entrare. RCEKit è costruito perché il finding sopravviva allo scrutinio di qualcun altro — il retest del cliente, la coda di triage, la revisione del report. Questa differenza si manifesta tre volte.

1. Un punto di iniezione, ogni classe, una run

Raramente conosci la classe prima di testare. Coprire un sink sconosciuto con strumenti a classe singola significa eseguirli uno per uno e ricostruire la richiesta per ciascuno:

_{Copertura secondo la lista di tecniche documentate di ciascun progetto. SSTImap è il successore mantenuto di tplmap, che il suo autore ha contrassegnato come non mantenuto.}```bash

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

Sarebbero state scoperte di qualcun altro. Cinque meccanismi producono quel verdetto, e vengono eseguiti a ogni conferma:

• Una richiesta di controllo senza payload. L'evidenza deve essere presente con il payload e assente senza di esso. Qualsiasi cosa presente in entrambi è inconclusive, non una scoperta.
• Un controllo inerte con lo stesso token. Una seconda richiesta porta l'identico token casuale in una forma non eseguibile. Un target che si limita a riflettere l'input fallisce qui — ed è così che una riflessione viene separata da un'esecuzione.
• Operandi casuali, mai stringhe fisse. L'oracolo è una somma racchiusa tra tag o un prodotto delimitato da confini calcolato ex novo a ogni esecuzione. Riflettere il payload restituisce il letterale $((a+b)); solo l'esecuzione restituisce il valore.
• Ricerca dell'evidenza consapevole della codifica. Un sink che applica base64, hex, URL, HTML o unicode-escape al proprio output conferma comunque — il corpo grezzo viene controllato per primo, quindi la decodifica può solo trasformare un riscontro mancato in un riscontro, mai il contrario.
• Ricerca dell'evidenza sull'intera risposta. Il valore calcolato viene cercato in ogni canale della risposta — corpo, header dell'applicazione, valori dei cookie, il target di redirect, la reason phrase HTTP, e ogni foglia di un envelope JSON di errore — e la scoperta nomina il canale che lo ha trasportato. Il differenziale di controllo viene applicato a ogni canale, quindi ampliare dove RCEKit guarda non amplia ciò che chiamerà confirmed.

Lo stesso istinto vale nella direzione opposta. Il timing non si auto-conferma mai, una callback di deserializzazione non viene mai chiamata RCE, e un'esecuzione che non ha costruito alcuna sonda non viene mai chiamata negativa.

3. È costruito per un ingaggio autorizzato, non per un laboratorio

I controlli su cui le rules of engagement di un cliente chiedono effettivamente conto, nello strumento piuttosto che nelle tue note:

Quando rivolgerti a qualcos'altro

Vuoi una shell invece di un verdetto? commix e SSTImap proseguono nella post-exploitation; RCEKit si ferma alla prova per design. Scansionare migliaia di host alla ricerca di CVE note? È il lavoro di Nuclei — e RCEKit scrive template Nuclei (--output-format nuclei), quindi alimenta il tuo scanner invece di competere con esso. Sai già che l'iniezione è SQL e vuoi il database stesso? sqlmap possiede quel terreno — i bridge di RCEKit esistono per provare che il OS è raggiungibile da un parametro testuale, non per sfruttare il database.

Trova la tua situazione

Ogni riga è un esempio pratico nella field guide — il comando, cosa invia, e come leggere ciò che ritorna.

Documentazione

Sicurezza & etica

RCEKit sfrutta, e questo è il punto. Una vulnerabilità viene confermata facendo fare al target la cosa, perché è l'unica evidenza che una firma non può falsificare e una build corretta non può produrre per caso. Ciò che delimita un'esecuzione non è la riluttanza a sfruttare. Sono due fatti strutturali e un interruttore.

Non accetta alcun payload arbitrario da te. Le sonde sono costruite dal motore per servire un oracolo — aritmetica su operandi casuali per quella sonda, un nome che solo questa esecuzione avrebbe potuto scegliere. Non esiste un input che trasformi il rilevamento in qualcos'altro, perché non esiste un tale input da fornire.

Qualsiasi cosa che vada oltre il calcolo di un valore dichiara il tier di cui ha bisogno, così un flag decide fin dove arriva un'esecuzione: --verify-active-risk safe | intrusive | stateful. Un metodo o una singola forma di sonda al di sopra di quel tier viene trattenuto per nome, con il flag che lo invierebbe — una scala che si accorcia silenziosamente è indistinguibile da un target senza nulla da trovare. Contro un'istanza usa e getta, alza il tier e ottieni tutto ciò che lo strumento ha.

• Consent gate — la generazione e la verifica di exploit richiedono --acknowledge-consent; --detection-only è benigno e non lo richiede.
• Safe by default — la verifica lancia solo prove a basso impatto; reverse shell, download-execute, accesso a credenziali, movimento laterale, container escape, cloud-metadata e payload OOB sono trattenuti finché non alzi --verify-active-risk. I payload distruttivi (persistenza, backdoor) non vengono mai lanciati senza --verify-allow-destructive. Un execution plan stampa esattamente cosa verrà inviato prima che qualsiasi cosa parta.
• Safety tiers — safe / intrusive / stateful. I payload del corpus sono filtrati da --max-safety; i metodi di rilevamento e le loro forme di sonda dichiarano gli stessi gradini e sono filtrati da --verify-active-risk, quindi un metodo che fa contattare l'esterno al target o lascia qualcosa dietro è soggetto allo stesso ordinamento di ogni payload del corpus. Il pre-flight nomina il tier di cui ogni elemento trattenuto ha effettivamente bisogno. file e write sono invece regolati dalla loro stessa configurazione: nessuno dei due fa nulla finché non indichi una directory in cui scrivere e un URL da cui rileggere.
• Audit & logging — ogni esecuzione di exploitation/verification è registrata in exploit_audit.log; --watermark incorpora un token tracciabile; i log di esecuzione vanno in rcekit.log.
• Corpus integrity — un corpus corrotto, o un esplicito --template-file mancante, fa sì che RCEKit rifiuti di eseguire e esca con codice diverso da zero invece di generare silenziosamente nulla (--doctor lo verifica). Solo un file di corpus predefinito assente ricade sulla copia integrata, e lo dichiara quando lo fa.

Questo toolkit è destinato esclusivamente a penetration testing autorizzato, ricerca sulla sicurezza, formazione e addestramento difensivo. Non usarlo mai contro sistemi senza esplicito permesso — i test non autorizzati sono illegali.

Sviluppo```bash

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

La suite di test fallisce se i due divergono. Vedi CONTRIBUTING.md.

Licenza

MIT — vedi LICENSE.