Laboratoire de validation du modèle Nuclei pour CVE-2026-45185

Ce dépôt n'est pas un dépôt de PoC d'exploit à usage général. Il s'agit d'un laboratoire de validation local permettant de reproduire et d'examiner le comportement d'un modèle CVE-2026-45185 destiné à être contribué à projectdiscovery/nuclei-templates.

Le modèle de code nuclei n'est pas un détecteur basé uniquement sur la version.
Il contrôle directement STARTTLS, BDAT, TLS close_notify et un octet
SMTP en texte clair suivant sur la même connexion TCP.

Cette séquence correspond dans le laboratoire local vulnérable Exim 4.99.2 GnuTLS et ne
correspond pas dans le laboratoire corrigé Exim 4.99.3 GnuTLS dans les mêmes conditions.

Le signal de validation actuel est un oracle de réponse SMTP distant, pas une observation directe de l'écriture UAF elle-même. En interne, cette CVE est une use-after-free où des octets de saut de ligne (\r/\n) peuvent être écrits dans un tampon de transfert GnuTLS libéré après l'arrêt TLS. En pratique, un client ne peut pas observer directement cette écriture dans le tampon libéré via les réponses SMTP. Par conséquent, ce README et le modèle ne prétendent pas prouver directement l'écriture UAF bdat_ungetc -> tls_ungetc ou une RCE. À la place, le modèle détecte une différence de récupération de la pile/état de réception qui apparaît pendant le flux de déclenchement.

En traçant le mécanisme de la vulnérabilité, j'ai observé qu'après TLS close_notify pendant la gestion STARTTLS + BDAT, des pointeurs de fonction tls_* obsolètes peuvent rester dans la couche inférieure de la pile de réception BDAT au lieu d'être correctement restaurés en pointeurs de fonction smtp_*. Cet état devient visible dans la façon dont le serveur traite la prochaine commande SMTP. Après que le BDAT fractionné atteint sa première complétion, l'envoi de NOOP sur la même session fait que le laboratoire vulnérable Exim 4.99.2 GnuTLS renvoie 421 lost input connection, tandis que le laboratoire corrigé Exim 4.99.3 GnuTLS le gère normalement avec 250 OK. Cette différence claire de réponse vulnérable/corrigé est utilisée comme correspondance pour le modèle de code nuclei local et autorisé.

Pour une présentation plus détaillée du flux de la vulnérabilité, voir CVE-2026-45185-Technical-Analysis.md.

Matrice de validation

Cible	Version	Backend TLS	STARTTLS	CHUNKING	Port	Résultat nuclei attendu
vulnérable	Exim 4.99.2	GnuTLS	oui	oui	127.0.0.1:2525	correspond
corrigé	Exim 4.99.3	GnuTLS	oui	oui	127.0.0.1:2526	pas de correspondance

Destinataire d'enveloppe SMTP commun (RCPT TO) :

[email protected]

L'ACL lab_rcpt du laboratoire Docker accepte ce destinataire d'enveloppe. Sur une cible SMTP générale, si RCPT TO est rejeté, la séquence peut ne pas atteindre l'analyseur de corps BDAT, donc le modèle a besoin d'un destinataire accepté.

Cette valeur est distincte de l'en-tête To: dans le corps BDAT. Le destinataire RCPT TO est une adresse d'enveloppe SMTP qui doit passer les vérifications de destinataire du serveur. La valeur To: dans le corps BDAT n'est qu'un texte d'en-tête de message ; elle n'a pas besoin d'exister ou d'être acceptée comme boîte aux lettres par le serveur.

Emplacement du modèle

templates/CVE-2026-45185.yaml

Nom du modèle :

Exim 4.97-4.99.2 GnuTLS STARTTLS BDAT - Vérification de réponse sur la même session

Le modèle est écrit avec metadata.verified: true et possède les balises code et intrusive.

Validation rapide

Exécutez les commandes suivantes depuis le répertoire POC_2026_45185/.

docker compose build
docker compose up -d

Validez la syntaxe du modèle :

nuclei -duc -validate -code -t templates/CVE-2026-45185.yaml

Signez le modèle de code local avant de l'exécuter :

nuclei -duc -code -t templates/CVE-2026-45185.yaml -sign

Exécutez contre le laboratoire vulnérable :

nuclei -code \
  -t templates/CVE-2026-45185.yaml \
  -u 127.0.0.1:2525 \
  -var [email protected] \
  -debug

Résultat attendu :

CVE-2026-45185 : oracle de réponse vulnérable correspondant

Exécutez contre le laboratoire corrigé :

nuclei -code \
  -t templates/CVE-2026-45185.yaml \
  -u 127.0.0.1:2526 \
  -var [email protected] \
  -debug

Résultat attendu :

pas de correspondance
NO-MATCH : réponse de type corrigé : NOOP a réussi après le déclenchement fractionné

Notez que le protocole code de nuclei n'est pas exécuté par défaut, donc -code est nécessaire. Nuclei bloque également les modèles code non signés. Si la clé privée locale de nuclei est protégée par une phrase de passe, exécutez la commande de signature dans un terminal interactif et saisissez cette phrase de passe. Re-signez après chaque modification du modèle car le digest couvre le contenu du modèle.

Exemples de résultats Nuclei

Ces captures d'écran montrent le résultat de l'oracle de réponse du laboratoire local après la signature du modèle. Elles constituent une preuve de validation de la différence de réponse sur la même session décrite ci-dessus, et non une preuve directe par débogueur ou ASAN de l'écriture UAF interne.

Laboratoire vulnérable Exim 4.99.2 GnuTLS sur 127.0.0.1:2525 :

Laboratoire corrigé Exim 4.99.3 GnuTLS sur 127.0.0.1:2526 :

Pourquoi le protocole Code ?

Le cœur de cette CVE n'est pas une bannière SMTP ou une vérification de version. Le modèle doit créer la transition d'état de transport suivante sur la même connexion TCP :

SMTP en texte clair EHLO
-> STARTTLS
-> Poignée de main TLS sur la même connexion TCP
-> TLS EHLO / MAIL FROM / RCPT TO / BDAT 70 LAST
-> 69 premiers octets du corps BDAT en tant que données d'application TLS
-> TLS close_notify sans fermer la socket TCP
-> dernier octet du corps en texte clair sur la même connexion TCP
-> vérification de réponse NOOP en texte clair sur la même session

Ce que vérifie le modèle

Le code Python dans le modèle YAML imprime le marqueur fixe uniquement après que toutes les conditions suivantes sont remplies. Le dispositif de correspondance nuclei ne correspond qu'à ce marqueur.

L'identité Exim est trouvée
ET STARTTLS est annoncé dans EHLO en texte clair
ET CHUNKING est annoncé dans EHLO en texte clair
ET STARTTLS est accepté
ET CHUNKING est annoncé dans EHLO TLS
ET MAIL FROM est accepté
ET RCPT TO est accepté
ET le BDAT fractionné close_notify atteint la première complétion
ET la première complétion contient "250 OK id="
ET la réponse NOOP en texte clair sur la même session contient "421"
ET la réponse NOOP en texte clair sur la même session contient "lost input connection"

Le modèle ne correspond sur aucun des signaux suivants seuls :

version uniquement
timeout uniquement
perte de connexion uniquement
réponse vide uniquement
rejet du destinataire
annonce STARTTLS/CHUNKING uniquement

Oracle de réponse

Les deux laboratoires traitent le message BDAT fractionné jusqu'à la première complétion.

250- 70 byte chunk, total 72
250 OK id=...

La différence apparaît lorsque la prochaine commande SMTP en texte clair est envoyée sur la même session SMTP.

Vulnérable 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

Corrigé 4.99.3 :

NOOP -> 250 OK
QUIT -> 221 exim-lab.local closing connection
RSET -> 250 Reset OK