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):
[email protected]
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.