Alerta crítica: Exim con GnuTLS expone a ejecución remota por fallo use-after-free en BDAT (CVE-2026-45185)

Exim ha publicado una actualización crítica que corrige una vulnerabilidad de uso posterior a liberación de memoria (use-after-free) en el análisis del cuerpo de mensajes BDAT cuando la pila TLS está implementada con GnuTLS. Identificada como CVE-2026-45185 (Dead.Letter), la falla permite que un cliente que pueda establecer una conexión TLS provoque corrupción del heap y, potencialmente, ejecución de código remoto sin autenticación, aprovechando la extensión CHUNKING (BDAT) del protocolo SMTP.

Desde el punto de vista técnico, el error aparece durante la secuencia de cierre TLS: si un cliente envía un alert de close_notify antes de completar la transferencia BDAT y luego inyecta un byte final en texto claro en la misma conexión TCP, Exim puede acabar escribiendo en un búfer ya liberado. Ese único byte sobrescribe metadatos del asignador de memoria, lo que abre el camino a técnicas de explotación que escalan la corrupción en primitivas útiles para un atacante. El descubrimiento fue reportado por Federico Kirschbaum de XBOW el 1 de mayo de 2026 y la corrección se ha incluido en la versión 4.99.3.

La vulnerabilidad afecta a las series de Exim desde la 4.97 hasta la 4.99.2, pero con una salvedad importante: solo impacta a los binarios compilados con USE_GNUTLS=yes. Los despliegues que usan otras bibliotecas TLS como OpenSSL no están afectados por este fallo en particular. Esto obliga a los administradores a verificar no solo la versión del paquete, sino también cómo fue compilado su Exim.

La explotación del fallo no requiere privilegios previos ni autenticación, y se basa únicamente en la capacidad de negociar una sesión TLS y usar BDAT. En la práctica esto significa que servidores de correo expuestos que anuncien CHUNKING en su respuesta EHLO y que hayan sido compilados con GnuTLS pueden ser atacables desde la red. Dado que la secuencia necesaria es relativamente sencilla y que la falla altera estructuras internas del allocator, los investigadores la califican como de muy alto riesgo.

Las recomendaciones inmediatas son claras: actualizar Exim a la versión 4.99.3 cuanto antes. No existen mitigaciones completas que sustituyan al parche según el aviso del proyecto, por lo que permanecer en versiones anteriores deja la infraestructura en riesgo. Si no puede aplicar la actualización de forma inmediata, considere medidas de mitigación temporales hasta que sea posible parchear: restringir el acceso de clientes no confiables al servicio SMTP mediante listas de control y firewalls, retirar temporalmente soporte TLS basado en GnuTLS o recompilar Exim usando otra biblioteca TLS (por ejemplo, OpenSSL) si eso es viable en su entorno.

Para comprobar rápidamente la versión y la configuración de TLS de su instalación puede ejecutar comandos de Exim para ver la versión instalada y, en muchos sistemas, revisar si Exim fue compilado con GnuTLS. Un enfoque práctico es consultar la salida de exim -bV o la documentación de empaquetado del sistema, y verificar si su servidor anuncia CHUNKING en la negociación EHLO. Además, monitorice logs por reinicios inesperados, core dumps o patrones de BDAT combinados con cierres TLS, ya que intentos de explotación podrían dejar trazas en registros de conexión y fallos de proceso.

En el plano operativo a medio plazo conviene incorporar estas acciones: implementar gestión de inventario que distinga no solo versiones de software sino opciones de compilación, automatizar pruebas en entornos de staging antes de desplegar actualizaciones críticas, y revisar la superficie de exposición del servicio SMTP (qué puertos y qué clientes están autorizados). También es recomendable disponer de detección basada en firmas y análisis del tráfico TLS/SMTP para identificar secuencias inusuales relacionadas con BDAT y close_notify.

Este episodio recuerda precedentes peligrosos: Exim ya había parcheado un use-after-free sobremanera crítico en 2017 (CVE-2017-16943), que permitió explotación remota mediante BDAT. La recurrencia de fallos en el manejo de BDAT subraya la complejidad de implementar extensiones de protocolo que interactúan con cierres de sesión TLS y gestión de búferes. Mantener las bibliotecas TLS y el propio MTA actualizados es una medida preventiva esencial.

Puede encontrar el comunicado y recursos del proyecto Exim en su web oficial https://www.exim.org/, y consultar el registro de la vulnerabilidad en la base de datos nacional de vulnerabilidades en https://nvd.nist.gov/vuln/detail/CVE-2026-45185. Para información sobre las bibliotecas TLS mencionadas, véase https://www.gnutls.org/ y https://www.openssl.org/.

En resumen: identifique qué hosts ejecutan Exim compilado con GnuTLS, priorice la actualización a Exim 4.99.3, vigile indicios de explotación en los registros y, si no puede parchear de inmediato, aplique controles de acceso y considere alternativas temporales de compilación para reducir la exposición. La gravedad y la simplicidad de la secuencia explotable hacen de esta vulnerabilidad una prioridad para administradores de correo en producción.