Durante tres décadas la seguridad de qmail fue considerada un referente; un simple vistazo de una red neuronal bastó para desmontar esa creencia.

A veces para comprometer un servidor no hace falta un comando, sino una sola frase. Expertos mostraron cómo un sistema basado en inteligencia artificial en hora y media encontró una vulnerabilidad en un servidor de correo y preparó de inmediato un método de ataque funcional.

La tarea parecía extremadamente simple: comprobar la versión más reciente del proyecto qmail de sagredo en busca de vulnerabilidades que permitieran ejecutar código de forma remota. En 101 minutos el sistema ya desplegó un entorno de prueba, analizó el código, encontró el problema, escribió un exploit funcional, propuso una corrección y elaboró un informe técnico detallado. No intervino ninguna persona en el proceso.

Se trata de una versión modificada de qmail, un popular servidor de correo creado en 1995 por Daniel Bernstein. El proyecto se consideró durante mucho tiempo un ejemplo de arquitectura segura. El desarrollador incluso ofreció una recompensa por las vulnerabilidades encontradas, y durante muchos años nadie pudo obtenerla. Sin embargo, desde finales de los años 90 el código original apenas se actualizó, y la comunidad fue añadiendo nuevas funciones mediante parches de terceros.

Con el tiempo se acumularon docenas de esos cambios. Las compilaciones modernas, incluida la versión de Roberto Puzzangerry, incorporan soporte para cifrado, autenticación y otras funciones necesarias. El problema es que la seguridad del qmail original no se extiende a las modificaciones de terceros. Precisamente en una de esas adiciones se encontró la vulnerabilidad. Se trata de la función notlshosts_auto, añadida en octubre de 2024. El mecanismo debe recordar los servidores con cifrado configurado incorrectamente para no intentar establecer una conexión segura cada vez.

El error resultó banal pero peligroso. El código formaba un comando de shell con el nombre del servidor remoto y lo ejecutaba mediante popen(). El nombre se encerraba entre comillas simples, esperando protegerse de las sustituciones. La protección fallaba si en el nombre aparecía la misma comilla. Formalmente, en los nombres de host habituales esos símbolos están prohibidos. Pero en el sistema de nombres de dominio las restricciones son más laxas: etiquetas individuales pueden contener casi cualquier byte. Un atacante puede registrar un dominio con un nombre "no estándar", configurar los registros de correo y provocar que el servidor víctima se conecte.

La cadena es sencilla. El servidor de correo intenta entregar un mensaje, se encuentra con un error de cifrado y llama a la función vulnerable. En ese momento el comando integrado ya no solo crea un archivo, sino que ejecuta código arbitrario insertado en el nombre de dominio. En la demostración el sistema ejecutó el comando id y escribió el resultado en un archivo.

La vulnerabilidad recibió el identificador CVE-2026-41113. Roberto Puzzangerry cerró el problema en abril de 2026; la actualización ya está disponible. Los propietarios de servidores con la función notlshosts_auto activada deberían instalar la corrección lo antes posible.

La historia es ilustrativa no por el error en sí. Inyecciones similares se han encontrado antes. Lo nuevo aquí es la velocidad y la autonomía. Lo que antes requería días o semanas de análisis manual ahora ocupa poco más de una hora y no requiere la participación de una persona. De hecho, la misma herramienta que ayuda a buscar errores en el propio código es capaz de hacer lo mismo en manos de atacantes. Y cuanto más rápido estas comprobaciones se conviertan en práctica estándar, menos posibilidades habrá de que otra persona encuentre la vulnerabilidad primero.