mj-bin/poc_cve-2026-45185POC_CVE-2026-45185 für nuclei-templates
Dieses Repository ist kein Allzweck-Exploit-PoC-Repository. Es ist ein lokales Validierungslabor zur Reproduktion und Überprüfung des Verhaltens einer CVE-2026-45185-Vorlage, die für einen Beitrag zu projectdiscovery/nuclei-templates vorgesehen ist.
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.
Das aktuelle Validierungssignal ist ein entfernter SMTP-Antwort-Orakel, keine direkte Beobachtung des UAF-Schreibens selbst. Intern handelt es sich bei dieser CVE um einen Use-After-Free, bei dem Newline-Bytes (\r/\n) nach dem TLS-Shutdown in einen freigegebenen GnuTLS-Transfer-Puffer geschrieben werden können. In der Praxis kann ein Client dieses Schreiben in den freigegebenen Puffer nicht realistisch direkt über SMTP-Antworten beobachten. Daher beanspruchen dieses README und die Vorlage nicht, den UAF-Schreibvorgang bdat_ungetc -> tls_ungetc oder RCE direkt zu beweisen. Stattdessen erkennt die Vorlage einen Unterschied in der Empfangsstapel-/Zustandswiederherstellung, der während des Triggerablaufs auftritt.
Während der Nachverfolgung des Schwachstellenmechanismus habe ich beobachtet, dass nach TLS close_notify während der STARTTLS+BDAT-Verarbeitung veraltete tls_*-Funktionszeiger in der unteren Schicht des BDAT-Empfangsstapels verbleiben können, anstatt ordnungsgemäß auf smtp_*-Funktionszeiger zurückgesetzt zu werden. Dieser Zustand wird sichtbar, wie der Server den nächsten SMTP-Befehl behandelt. Nachdem das geteilte BDAT den ersten Abschluss erreicht hat, führt das Senden von NOOP in derselben Sitzung dazu, dass das anfällige Exim 4.99.2 GnuTLS-Labor 421 lost input connection zurückgibt, während das gepatchte Exim 4.99.3 GnuTLS-Labor es normal mit 250 OK behandelt. Dieser deutliche Unterschied zwischen anfälliger und gepatchter Antwort wird als Matcher für die lokale, autorisierte Nuclei-Code-Vorlage verwendet.
Für eine detailliertere Schritt-für-Schritt-Erklärung des Schwachstellenablaufs siehe CVE-2026-45185-Technical-Analysis.md.
| Ziel | Version | TLS-Backend | STARTTLS | CHUNKING | Port | Erwartetes Nuclei-Ergebnis |
|---|---|---|---|---|---|---|
| anfällig | Exim 4.99.2 | GnuTLS | ja | ja | 127.0.0.1:2525 | Treffer |
| gepatcht | Exim 4.99.3 | GnuTLS | ja | ja | 127.0.0.1:2526 | kein Treffer |
Allgemeiner SMTP-Umschlagempfänger (RCPT TO):
Die lab_rcpt-ACL des Docker-Labors akzeptiert diesen Umschlagempfänger. Bei einem allgemeinen SMTP-Ziel, wenn RCPT TO abgelehnt wird, erreicht die Sequenz möglicherweise nicht den BDAT-Body-Parser, daher benötigt die Vorlage einen akzeptierten Empfänger.
Dieser Wert unterscheidet sich vom To:-Header innerhalb des BDAT-Bodys. Der RCPT TO-Empfänger ist eine SMTP-Umschlagadresse, die die Empfängerprüfungen des Servers bestehen muss. Der To:-Wert im BDAT-Body ist nur Nachrichtenkopftext; er muss nicht existieren oder vom Server als Mailbox akzeptiert werden.
templates/CVE-2026-45185.yaml
Vorlagenname:
Exim 4.97-4.99.2 GnuTLS STARTTLS BDAT - Same-Session Response Check
Die Vorlage ist mit metadata.verified: true geschrieben und hat die Tags code und intrusive.
Führen Sie die folgenden Befehle aus dem Verzeichnis POC_2026_45185/ aus.
docker compose build
docker compose up -d
Validieren Sie die Vorlagensyntax:
nuclei -duc -validate -code -t templates/CVE-2026-45185.yaml
Signieren Sie die lokale Code-Vorlage vor dem Ausführen:
nuclei -duc -code -t templates/CVE-2026-45185.yaml -sign
Ausführen gegen das anfällige Labor:
nuclei -code \
-t templates/CVE-2026-45185.yaml \
-u 127.0.0.1:2525 \
-var [email protected] \
-debug
Erwartetes Ergebnis:
CVE-2026-45185: vulnerable response oracle matched
Ausführen gegen das gepatchte Labor:
nuclei -code \
-t templates/CVE-2026-45185.yaml \
-u 127.0.0.1:2526 \
-var [email protected] \
-debug
Erwartetes Ergebnis:
no match
NO-MATCH: patched-like response: NOOP succeeded after split trigger
Beachten Sie, dass das code-Protokoll von Nuclei standardmäßig nicht ausgeführt wird, daher ist -code erforderlich. Nuclei blockiert auch unsignierte code-Vorlagen. Wenn der lokale private Nuclei-Schlüssel mit einer Passphrase geschützt ist, führen Sie den Signierbefehl in einem interaktiven Terminal aus und geben Sie diese Passphrase ein. Signieren Sie nach jeder Vorlagenänderung neu, da der Digest den Vorlageninhalt abdeckt.
Diese Screenshots zeigen das lokale Labor-Antwort-Orakel-Ergebnis, nachdem die Vorlage signiert wurde. Sie sind Validierungsnachweise für den oben beschriebenen Unterschied in der Antwort derselben Sitzung, kein direkter Debugger- oder ASAN-Nachweis des internen UAF-Schreibvorgangs.
Anfälliges Exim 4.99.2 GnuTLS-Labor auf 127.0.0.1:2525:
Gepatchtes Exim 4.99.3 GnuTLS-Labor auf 127.0.0.1:2526:
Der Kern dieser CVE ist kein SMTP-Banner- oder Versionscheck. Die Vorlage muss den folgenden Transportzustandsübergang auf derselben TCP-Verbindung erzeugen:
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
Der Python-Code innerhalb der YAML-Vorlage gibt den festgelegten Marker nur aus, wenn alle folgenden Bedingungen erfüllt sind. Der Nuclei-Matcher erkennt nur diesen Marker.
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"
Die Vorlage erkennt nicht auf eines der folgenden Signale allein:
version-only
timeout-only
connection-drop-only
empty-response-only
recipient rejection
STARTTLS/CHUNKING advertisement only
Beide Labore verarbeiten die geteilte BDAT-Nachricht bis zum ersten Abschluss.
250- 70 byte chunk, total 72
250 OK id=...
Der Unterschied tritt auf, wenn der nächste SMTP-Klartextbefehl in derselben SMTP-Sitzung gesendet wird.
Anfälliges 4.99.2:
NOOP -> 421 exim-lab.local lost input connection
QUIT -> 421 exim-lab.local lost input connection
RSET -> 421 exim-lab.local lost input connection
Gepatchtes 4.99.3:
NOOP -> 250 OK
QUIT -> 221 exim-lab.local closing connection
RSET -> 250 Reset OK
Interpretation:
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.
Die Vorlage verwendet die folgende 70-Byte-Nachricht als BDAT-Body.
From: [email protected]\r\n
To: [email protected]\r\n
Subject: poc\r\n
\r\n
body
Der SMTP-Umschlagempfänger wird separat über die Vorlagenvariable recipient übergeben. Der To:-Header im Body ist Text und hat nichts damit zu tun, ob SMTP RCPT TO akzeptiert wird, daher muss er nicht existieren oder vom Server akzeptiert werden.
Geteilte Form:
BDAT 70 LAST
TLS body: first 69 bytes, ending with "bod"
TLS event: close_notify
Plaintext: final byte "y"
Follow-up: NOOP
Sie können manuell überprüfen, dass beide Labore Exim, STARTTLS und CHUNKING anzeigen.
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
Erwartete Signale:
Exim
STARTTLS
CHUNKING
Sie können auch den normalen STARTTLS-Pfad prüfen:
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/ und notes/source-walkthrough-progress.md verfolgt.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