mj-bin/poc_cve-2026-45185POC_CVE-2026-45185 per nuclei-templates
Questo repository non è un repository PoC (proof-of-concept) di exploit generici. È un laboratorio di validazione locale per riprodurre e verificare il comportamento di un template CVE-2026-45185 pensato per essere contribuito a projectdiscovery/nuclei-templates.
The nuclei code template is not a version-only detector.
It directly controls STARTTLS, BDAT, TLS close_notify, and a following
SMTP plaintext byte on the same TCP connection.
This sequence matches in the local vulnerable Exim 4.99.2 GnuTLS lab and does
not match in the patched Exim 4.99.3 GnuTLS lab under the same conditions.
Il segnale di validazione attuale è un oracolo di risposta SMTP remota, non un'osservazione diretta della scrittura UAF stessa. Internamente, questa CVE è una use-after-free in cui i byte di newline (\r/\n) possono essere scritti in un buffer di trasferimento GnuTLS liberato dopo l'arresto di TLS. In pratica, un client non può osservare realisticamente quella scrittura su buffer liberato direttamente attraverso le risposte SMTP. Pertanto, questo README e il template non affermano di provare direttamente la scrittura UAF bdat_ungetc -> tls_ungetc o la RCE. Invece, il template rileva una differenza di ripristino dello stato/dello stack di ricezione che emerge durante il flusso di trigger.
Durante l'analisi del meccanismo della vulnerabilità, ho osservato che dopo close_notify TLS durante la gestione di STARTTLS + BDAT, puntatori a funzione tls_* obsoleti possono rimanere nel livello inferiore dello stack di ricezione BDAT invece di essere correttamente ripristinati ai puntatori a funzione smtp_*. Questo stato diventa visibile nel modo in cui il server gestisce il comando SMTP successivo. Dopo che il BDAT diviso raggiunge il primo completamento, l'invio di NOOP sulla stessa sessione fa sì che il laboratorio vulnerabile Exim 4.99.2 GnuTLS restituisca 421 lost input connection, mentre il laboratorio corretto Exim 4.99.3 GnuTLS lo gestisce normalmente con 250 OK. Questa chiara differenza di risposta vulnerabile/corretto viene usata come matcher per il template nuclei code locale e autorizzato.
Per un'analisi più approfondita del flusso della vulnerabilità, consulta CVE-2026-45185-Technical-Analysis.md.
| Target | Versione | Backend TLS | STARTTLS | CHUNKING | Porta | Risultato nuclei atteso |
|---|---|---|---|---|---|---|
| vulnerabile | Exim 4.99.2 | GnuTLS | sì | sì | 127.0.0.1:2525 | match |
| corretto | Exim 4.99.3 | GnuTLS | sì | sì | 127.0.0.1:2526 | no match |
Destinatario comune dell'inviluppo SMTP (RCPT TO):
L'ACL lab_rcpt del laboratorio Docker accetta questo destinatario dell'inviluppo. Su un target SMTP generico, se RCPT TO viene rifiutato, la sequenza potrebbe non raggiungere il parser del corpo BDAT, quindi il template richiede un destinatario accettato.
Questo valore è distinto dall'intestazione To: nel corpo BDAT. Il destinatario RCPT TO è un indirizzo dell'inviluppo SMTP che deve superare i controlli sui destinatari del server. Il valore To: nel corpo BDAT è solo testo dell'intestazione del messaggio; non deve esistere né essere accettato come casella di posta dal server.
templates/CVE-2026-45185.yaml
Nome del template:
Exim 4.97-4.99.2 GnuTLS STARTTLS BDAT - Same-Session Response Check
Il template è scritto con metadata.verified: true e ha i tag code e intrusive.
Esegui i seguenti comandi dalla directory POC_2026_45185/.
docker compose build
docker compose up -d
Valida la sintassi del template:
nuclei -duc -validate -code -t templates/CVE-2026-45185.yaml
Firma il template code locale prima di eseguirlo:
nuclei -duc -code -t templates/CVE-2026-45185.yaml -sign
Esegui contro il laboratorio vulnerabile:
nuclei -code \
-t templates/CVE-2026-45185.yaml \
-u 127.0.0.1:2525 \
-var [email protected] \
-debug
Risultato atteso:
CVE-2026-45185: vulnerable response oracle matched
Esegui contro il laboratorio corretto:
nuclei -code \
-t templates/CVE-2026-45185.yaml \
-u 127.0.0.1:2526 \
-var [email protected] \
-debug
Risultato atteso:
no match
NO-MATCH: patched-like response: NOOP succeeded after split trigger
Nota che il protocollo nuclei code non viene eseguito di default, quindi -code è obbligatorio. Nuclei blocca anche i template code non firmati. Se la chiave privata nuclei locale è protetta da una passphrase, esegui il comando di firma in un terminale interattivo e inserisci la passphrase. Ripeti la firma dopo ogni modifica al template perché il digest copre il contenuto del template.
Questi screenshot mostrano il risultato dell'oracolo di risposta del laboratorio locale dopo la firma del template. Sono una prova di validazione della differenza di risposta nella stessa sessione descritta sopra, non una dimostrazione diretta tramite debugger o ASAN della scrittura UAF interna.
Laboratorio vulnerabile Exim 4.99.2 GnuTLS su 127.0.0.1:2525:
Laboratorio corretto Exim 4.99.3 GnuTLS su 127.0.0.1:2526:
Il cuore di questa CVE non è un banner SMTP o un controllo di versione. Il template deve creare la seguente transizione di stato del trasporto sulla stessa connessione TCP:
plaintext SMTP EHLO
-> STARTTLS
-> TLS handshake on the same TCP connection
-> TLS EHLO / MAIL FROM / RCPT TO / BDAT 70 LAST
-> first 69 bytes of the BDAT body as TLS application data
-> TLS close_notify without closing the TCP socket
-> final body byte as plaintext on the same TCP connection
-> same-session plaintext NOOP response check
Il codice Python all'interno del template YAML stampa il marcatore fisso solo dopo che tutte le seguenti condizioni sono soddisfatte. Il matcher nuclei corrisponde solo a quel marcatore.
Exim identity is found
AND STARTTLS is advertised in plaintext EHLO
AND CHUNKING is advertised in plaintext EHLO
AND STARTTLS is accepted
AND CHUNKING is advertised in TLS EHLO
AND MAIL FROM is accepted
AND RCPT TO is accepted
AND the split close_notify BDAT reaches first completion
AND first completion contains "250 OK id="
AND the same-session plaintext NOOP response contains "421"
AND the same-session plaintext NOOP response contains "lost input connection"
Il template non corrisponde su nessuno dei seguenti segnali da soli:
version-only
timeout-only
connection-drop-only
empty-response-only
recipient rejection
STARTTLS/CHUNKING advertisement only
Entrambi i laboratori elaborano il messaggio BDAT diviso fino al primo completamento.
250- 70 byte chunk, total 72
250 OK id=...
La differenza appare quando il comando SMTP in chiaro successivo viene inviato sulla stessa sessione SMTP.
4.99.2 vulnerabile:
NOOP -> 421 exim-lab.local lost input connection
QUIT -> 421 exim-lab.local lost input connection
RSET -> 421 exim-lab.local lost input connection
4.99.3 corretto:
NOOP -> 250 OK
QUIT -> 221 exim-lab.local closing connection
RSET -> 250 Reset OK
Interpretazione:
Observation:
Both labs reach split BDAT message completion.
Only the vulnerable lab fails to return cleanly to the next plaintext SMTP
command loop in the same session.
Evidence:
The vulnerable follow-up response is 421 lost input connection.
The patched follow-up response is 250 OK or 221 closing connection.
Inference:
This difference is consistent with the receive stack/state recovery difference
after STARTTLS close_notify.
Il template usa il seguente messaggio di 70 byte come corpo BDAT.
From: [email protected]\r\n
To: [email protected]\r\n
Subject: poc\r\n
\r\n
body
Il destinatario dell'inviluppo SMTP viene passato separatamente tramite la variabile recipient del template. L'intestazione To: nel corpo è testo e non è correlata all'accettazione di RCPT TO da parte di SMTP, quindi non deve esistere né essere accettata dal server.
Struttura divisa:
BDAT 70 LAST
TLS body: first 69 bytes, ending with "bod"
TLS event: close_notify
Plaintext: final byte "y"
Follow-up: NOOP
Puoi verificare manualmente che entrambi i laboratori pubblicizzino Exim, STARTTLS e CHUNKING.
printf 'EHLO lab-client.local\r\nQUIT\r\n' | nc -w 3 127.0.0.1 2525
printf 'EHLO lab-client.local\r\nQUIT\r\n' | nc -w 3 127.0.0.1 2526
Segnali attesi:
Exim
STARTTLS
CHUNKING
Puoi anche verificare il percorso STARTTLS normale:
openssl s_client -starttls smtp -connect 127.0.0.1:2525 -crlf
openssl s_client -starttls smtp -connect 127.0.0.1:2526 -crlf
debugging/ e notes/source-walkthrough-progress.md.POC_2026_45185/
compose.yaml
images/ local nuclei validation screenshots
vulnerable/ Exim 4.99.2 + GnuTLS debug build
patched/ Exim 4.99.3 + GnuTLS debug build
nuclei-templates/ submodule: local nuclei template workspace