Exim sigue moviendo buena parte del correo de internet, así que cuando aparece un fallo de ejecución remota de código sin autenticación toca prestar atención. El CVE-2026-45185 es exactamente eso: un use-after-free que afecta a las versiones 4.97 a 4.99.2 y que se arregló en Exim 4.99.3, publicado el 12 de mayo de 2026.
Qué es la vulnerabilidad
El problema vive en el cierre de la conexión TLS mientras Exim procesa tráfico SMTP fragmentado con BDAT (la extensión CHUNKING). Durante ese cierre Exim libera un búfer de transferencia TLS, pero conserva referencias de callback ya obsoletas que siguen apuntando a esa memoria. Cuando esas referencias se usan después, se acaba escribiendo en una región de memoria ya liberada. De ahí a controlar el flujo de ejecución hay un paso, y por eso el fallo permite ejecutar código de forma remota.
El detalle que lo hace serio es la combinación: no hace falta autenticarse. Un atacante que pueda hablar SMTP con el servidor y forzar el camino BDAT + cierre TLS tiene material para intentar la explotación.
A quién afecta
No todas las instalaciones de Exim están expuestas. Para que el fallo sea explotable tienen que darse tres condiciones a la vez:
- Que el binario esté compilado contra GnuTLS (las builds con OpenSSL no se ven afectadas).
- Que el servidor anuncie STARTTLS.
- Que el servidor anuncie CHUNKING.
Esto es relevante porque varias distribuciones empaquetan Exim con GnuTLS. Debian y Ubuntu, por ejemplo, distribuyen builds afectadas, y ambos recibieron aviso el 8 de mayo de 2026 para preparar los parches. Si administras un MTA Exim, lo primero es comprobar contra qué biblioteca TLS está compilado y qué extensiones anuncia en el saludo SMTP.
Gravedad
Estamos ante un RCE remoto y sin autenticación, lo que en la práctica lo coloca en el escalón más alto de riesgo. Un atacante que lo aproveche podría ejecutar comandos en el servidor de correo, leer los datos y mensajes que maneja Exim y usar ese acceso como punto de entrada al resto de la red interna. En el momento de la divulgación no constaba explotación activa y no se había publicado un PoC funcional, aunque sí se discutió el camino para construirlo. Esa ventana sin exploit público no debería tomarse como excusa para retrasar el parche.
La cronología fue rápida: Federico Kirschbaum, investigador de XBOW, lo reportó el 1 de mayo; los mantenedores lo confirmaron el 5; las distribuciones recibieron aviso el 8; y la corrección llegó con Exim 4.99.3 el 12 de mayo de 2026.
Mitigación
La vía directa es actualizar a Exim 4.99.3 o posterior. En Debian y Ubuntu basta con instalar la versión parcheada desde el gestor de paquetes (apt update && apt upgrade) y reiniciar el servicio. Si por lo que sea no puedes parchear de inmediato, reducir la superficie ayuda: deshabilitar CHUNKING quita una de las tres condiciones necesarias, y revisar si realmente necesitas la build con GnuTLS frente a una con OpenSSL es otra opción a medio plazo. Aun así, ninguna mitigación sustituye a aplicar la versión corregida.
Si te interesa el patrón técnico detrás de este tipo de fallos, hemos cubierto otros use-after-free en la pila TLS del kernel en CVE-2026-23240: use-after-free en TLS del kernel Linux.