mj-bin/poc_cve-2026-45185POC_CVE-2026-45185 para nuclei-templates
Este repositorio no es un repositorio de PoC de exploits de propósito general. Es un
laboratorio de validación local para reproducir y revisar el comportamiento de una
plantilla CVE-2026-45185 destinada a ser contribuida a
projectdiscovery/nuclei-templates.
La plantilla de código nuclei no es un detector solo de versión.
Controla directamente STARTTLS, BDAT, close_notify de TLS y un siguiente
byte SMTP en texto plano en la misma conexión TCP.
Esta secuencia coincide en el laboratorio local vulnerable Exim 4.99.2 GnuTLS y no
coincide en el laboratorio parcheado Exim 4.99.3 GnuTLS bajo las mismas condiciones.
La señal de validación actual es un oráculo de respuesta SMTP remoto, no una observación
directa de la escritura UAF en sí. Internamente, este CVE es un use-after-free
donde bytes de nueva línea (\r/\n) pueden escribirse en un búfer de transferencia
GnuTLS liberado después del apagado de TLS. En la práctica, un cliente no puede observar
realistamente esa escritura en búfer liberado directamente a través de respuestas SMTP.
Por lo tanto, este README y la plantilla no afirman probar directamente la
escritura UAF de bdat_ungetc -> tls_ungetc o RCE. En cambio, la plantilla detecta una
diferencia de recuperación de estado/pila de recepción que aparece durante el flujo de activación.
Al rastrear el mecanismo de la vulnerabilidad, observé que después de TLS
close_notify durante el manejo de STARTTLS + BDAT, punteros a función tls_* obsoletos
pueden permanecer en la capa inferior de la pila de recepción BDAT en lugar de ser
restaurados correctamente a punteros a función smtp_*. Ese estado se vuelve visible en
cómo el servidor maneja el siguiente comando SMTP. Después de que el BDAT dividido alcanza la
primera finalización, enviar NOOP en la misma sesión hace que el laboratorio vulnerable
Exim 4.99.2 GnuTLS devuelva 421 lost input connection, mientras que el laboratorio parcheado
Exim 4.99.3 GnuTLS lo maneja normalmente con 250 OK. Esta clara diferencia de respuesta
vulnerable/parcheado se utiliza como el comparador para la plantilla de código nuclei local y autorizada.
Para un recorrido más profundo del flujo de la vulnerabilidad, consulte
CVE-2026-45185-Technical-Analysis.md.
| Destino | Versión | Backend TLS | STARTTLS | CHUNKING | Puerto | Resultado esperado de nuclei |
|---|---|---|---|---|---|---|
| vulnerable | Exim 4.99.2 | GnuTLS | sí | sí | 127.0.0.1:2525 | coincidencia |
| parcheado | Exim 4.99.3 | GnuTLS | sí | sí | 127.0.0.1:2526 | sin coincidencia |
Destinatario común del sobre SMTP (RCPT TO):
La ACL lab_rcpt del laboratorio Docker acepta este destinatario de sobre. En un
objetivo SMTP general, si RCPT TO es rechazado, la secuencia puede no alcanzar el analizador
del cuerpo BDAT, por lo que la plantilla necesita un destinatario aceptado.
Este valor es distinto del encabezado To: dentro del cuerpo BDAT. El
destinatario RCPT TO es una dirección de sobre SMTP que debe pasar las comprobaciones
de destinatario del servidor. El valor To: en el cuerpo BDAT es solo texto de encabezado
del mensaje; no necesita existir ni ser aceptado como buzón por el servidor.
templates/CVE-2026-45185.yaml
Nombre de la plantilla:
Exim 4.97-4.99.2 GnuTLS STARTTLS BDAT - Same-Session Response Check
La plantilla está escrita con metadata.verified: true y tiene las etiquetas code e
intrusive.
Ejecute los siguientes comandos desde el directorio POC_2026_45185/.
docker compose build
docker compose up -d
Valide la sintaxis de la plantilla:
nuclei -duc -validate -code -t templates/CVE-2026-45185.yaml
Firme la plantilla de código local antes de ejecutarla:
nuclei -duc -code -t templates/CVE-2026-45185.yaml -sign
Ejecute contra el laboratorio vulnerable:
nuclei -code \
-t templates/CVE-2026-45185.yaml \
-u 127.0.0.1:2525 \
-var [email protected] \
-debug
Resultado esperado:
CVE-2026-45185: vulnerable response oracle matched
Ejecute contra el laboratorio parcheado:
nuclei -code \
-t templates/CVE-2026-45185.yaml \
-u 127.0.0.1:2526 \
-var [email protected] \
-debug
Resultado esperado:
no match
NO-MATCH: patched-like response: NOOP succeeded after split trigger
Tenga en cuenta que el protocolo code de nuclei no se ejecuta por defecto, por lo que -code es
necesario. Nuclei también bloquea plantillas code sin firmar. Si la clave privada local de nuclei
está protegida con una frase de contraseña, ejecute el comando de firma en una
terminal interactiva e introduzca esa frase de contraseña. Vuelva a firmar después de cada
cambio en la plantilla porque el resumen cubre el contenido de la plantilla.
Estas capturas de pantalla muestran el resultado del oráculo de respuesta del laboratorio local después de que la plantilla haya sido firmada. Son evidencia de validación de la diferencia de respuesta en la misma sesión descrita anteriormente, no una prueba directa con depurador o ASAN de la escritura UAF interna.
Laboratorio vulnerable Exim 4.99.2 GnuTLS en 127.0.0.1:2525:
Laboratorio parcheado Exim 4.99.3 GnuTLS en 127.0.0.1:2526:
El núcleo de este CVE no es un banner SMTP o una comprobación de versión. La plantilla necesita crear la siguiente transición de estado de transporte en la misma conexión TCP:
SMTP EHLO en texto plano
-> STARTTLS
-> handshake TLS en la misma conexión TCP
-> TLS EHLO / MAIL FROM / RCPT TO / BDAT 70 LAST
-> primeros 69 bytes del cuerpo BDAT como datos de aplicación TLS
-> close_notify de TLS sin cerrar el socket TCP
-> byte final del cuerpo en texto plano en la misma conexión TCP
-> comprobación de respuesta NOOP en texto plano en la misma sesión
El código Python dentro de la plantilla YAML imprime el marcador fijo solo después de que todas las siguientes condiciones se cumplan. El comparador de nuclei solo coincide con ese marcador.
Se encuentra la identidad Exim
Y STARTTLS se anuncia en EHLO en texto plano
Y CHUNKING se anuncia en EHLO en texto plano
Y STARTTLS es aceptado
Y CHUNKING se anuncia en TLS EHLO
Y MAIL FROM es aceptado
Y RCPT TO es aceptado
Y el BDAT dividido con close_notify alcanza la primera finalización
Y la primera finalización contiene "250 OK id="
Y la respuesta NOOP en texto plano en la misma sesión contiene "421"
Y la respuesta NOOP en texto plano en la misma sesión contiene "lost input connection"
La plantilla no coincide con ninguna de las siguientes señales por sí solas:
solo versión
solo tiempo de espera
solo caída de conexión
solo respuesta vacía
rechazo de destinatario
solo anuncio de STARTTLS/CHUNKING
Ambos laboratorios procesan el mensaje BDAT dividido hasta la primera finalización.
250- 70 byte chunk, total 72
250 OK id=...
La diferencia aparece cuando se envía el siguiente comando SMTP en texto plano en la misma sesión SMTP.
Vulnerable 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
Parcheado 4.99.3:
NOOP -> 250 OK
QUIT -> 221 exim-lab.local closing connection
RSET -> 250 Reset OK
Interpretación:
Observación:
Ambos laboratorios alcanzan la finalización del mensaje BDAT dividido.
Solo el laboratorio vulnerable no logra volver limpiamente al bucle del siguiente comando
SMTP en texto plano en la misma sesión.
Evidencia:
La respuesta de seguimiento vulnerable es 421 lost input connection.
La respuesta de seguimiento parcheada es 250 OK o 221 closing connection.
Inferencia:
Esta diferencia es consistente con la diferencia de recuperación de estado/pila de recepción
después de close_notify de STARTTLS.
La plantilla utiliza el siguiente mensaje de 70 bytes como cuerpo BDAT.
From: [email protected]\r\n
To: [email protected]\r\n
Subject: poc\r\n
\r\n
body
El destinatario del sobre SMTP se pasa por separado a través de la variable de plantilla
recipient. El encabezado To: en el cuerpo es texto y no está relacionado con si
el SMTP RCPT TO es aceptado, por lo que no necesita existir ni ser aceptado por el
servidor.
Forma dividida:
BDAT 70 LAST
Cuerpo TLS: primeros 69 bytes, terminando con "bod"
Evento TLS: close_notify
Texto plano: byte final "y"
Seguimiento: NOOP
Puede verificar manualmente que ambos laboratorios anuncian Exim, STARTTLS y 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
Señales esperadas:
Exim
STARTTLS
CHUNKING
También puede verificar la ruta normal de STARTTLS:
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/ y notes/source-walkthrough-progress.md.POC_2026_45185/
compose.yaml
images/ capturas de pantalla de validación local de nuclei
vulnerable/ Exim 4.99.2 + compilación de depuración GnuTLS
patched/ Exim 4.99.3 + compilación de depuración GnuTLS
nuclei-templates/ submódulo: espacio de trabajo local de plantillas nuclei