Tutorial

Exim y Dovecot: comprobar que su paquete está corregido

Correo profesional9 min de lectura7 pasos

El aviso de Ubuntu del 28 de septiembre de 2026 y el aviso de Debian correspondiente sobre Exim, y la falla de Dovecot de mayo de 2026, citan números de versión que sus comandos no reproducen. `exim4 -bV` muestra la versión original, mientras que la distribución corrige y conserva un número más antiguo: un Exim 4.97 puede estar protegido y otro no. Esta guía da el método para leer el changelog del paquete, probar la exposición real, reiniciar el proceso correcto y decidir si este servidor de correo merece que lo mantenga usted.

Contenido· Por qué el número de versión no responde a la pregunta1/12
  1. 01Por qué el número de versión no responde a la pregunta
  2. 02Paquetes Exim corregidos por distribución (consultado el 28 de octubre de 2026)
  3. 03Qué corrige el aviso de Ubuntu USN-8834-1
  4. 04Comprobar un paquete Exim, comando por comando
  5. 05Comprobar y corregir según el entorno
  6. 06Actualizar no reemplaza el proceso en ejecución
  7. 07¿Está expuesto?: la prueba de Proxy-Protocol
  8. 08Si su distribución aún no tiene un paquete corregido
  9. 09Dovecot: CVE-2026-42006 y fuentes que no coinciden
  10. 10Revisar los registros tras la corrección
  11. 11¿Quién mantiene al día un servidor de correo?
  12. 12La documentación oficial

Por qué el número de versión no responde a la pregunta

El arreglo original de Exim lleva el número 4.100.1: la ficha de Ubuntu de CVE-2026-94054 describe una falla presente en "Exim before 4.100.1". Sin embargo, Ubuntu 24.04 entrega un paquete corregido en 4.97-4ubuntu4.8, y Ubuntu 22.04 uno corregido en 4.95-4ubuntu2.12. Ambos están muy por debajo de 4.100.1 y, aun así, están corregidos.

La razón es mecánica. Una distribución porta el arreglo a la rama antigua que mantiene: el número original no cambia, solo cambia la revisión del paquete, después del guion. Comparar la salida de exim4 -bV con 4.100.1 provoca entonces una falsa alarma en un servidor sano. Existe también lo contrario: un Exim compilado a mano, fuera del gestor de paquetes, no tiene revisión de distribución y solo cuenta su número original. La pregunta correcta no es "¿mi versión es suficientemente alta?", sino "¿mi paquete contiene la revisión corregida y su changelog cita la CVE?".

Paquetes Exim corregidos por distribución (consultado el 28 de octubre de 2026)

Desplace la tabla

DistribuciónPaquete exim4 corregidoEstado registrado
Ubuntu 26.04 LTS4.99.1-1ubuntu1.5Corregido (USN-8834-1)
Ubuntu 24.04 LTS4.97-4ubuntu4.8Corregido (USN-8834-1)
Ubuntu 22.04 LTS4.95-4ubuntu2.12Corregido (USN-8834-1)
Ubuntu 26.10No aplicaNo afectada según Ubuntu
Debian 13 (trixie), repositorio de seguridad4.98.2-1+deb13u5Corregido (DSA-6522-1)
Debian 12 (bookworm)4.96-15+deb12u10Marcado como vulnerable el 28 de octubre de 2026: releer el seguimiento antes de actuar
Debian forky y sid4.100.1-4Corregido
AlmaLinux, RockySegún el repositorio que ofrezca EximLeer el changelog del paquete

Qué corrige el aviso de Ubuntu USN-8834-1

  • CVE-2026-94054 — escritura fuera de límites cuando se usa Proxy-Protocol con un proxy controlado por el atacante. Ubuntu la puntúa con 7.0 en CVSS 3, prioridad Medium.
  • CVE-2026-94056 — lectura de pila sin inicializar en el mismo contexto de Proxy-Protocol, con posible fuga de información.
  • CVE-2026-94057 — SMTP smuggling: datos enviados tras un rechazo durante el comando DATA permiten inyectar mensajes. No hace falta ningún proxy.
  • CVE-2026-94055 — use-after-free con GnuTLS y ajustes TLS no predeterminados. Solo afectaba a Ubuntu 26.04.
  • Una prioridad no es su riesgo — la prioridad Medium juzga la falla en general. No dice si su servidor acepta conexiones a través de un proxy: las pruebas siguientes sí lo dicen.

Comprobar un paquete Exim, comando por comando

  1. Leer la versión en bruto

    exim4 -bV muestra la versión original de Exim (en otros sistemas el binario se llama exim). Anótela, pero no concluya nada: es el número que no se compara con 4.100.1.

  2. Leer la revisión del paquete

    dpkg -s exim4-daemon-light | grep Version da la revisión instalada. Cambie el nombre por exim4-daemon-heavy si es su variante, y lístelas con dpkg -l 'exim4*'. Compare con la tabla de referencia.

  3. Buscar la CVE en el changelog

    apt changelog exim4 | grep -n CVE-2026-94054. Una línea encontrada significa que el arreglo está en el paquete. Ninguna línea: actualice y repita el comando.

  4. En AlmaLinux o Rocky

    rpm -q --changelog exim | grep CVE hace el mismo trabajo, siempre que el paquete venga de un repositorio que lo publique. Misma lógica para Dovecot con rpm -q --changelog dovecot | grep CVE-2026-42006.

  5. Preguntar a la distribución

    En Debian, debsecan lista las CVE conocidas de los paquetes instalados. En Ubuntu, ubuntu-security-status resume qué paquetes siguen recibiendo correcciones de seguridad; no apunta a una CVE concreta.

  6. Actualizar

    sudo apt update && sudo apt install --only-upgrade 'exim4*', y después el mismo comando con 'dovecot*' si Dovecot corre en la máquina.

  7. Comprobar el proceso cargado

    ls -l /proc/$(pgrep -o exim4)/exe. La mención (deleted) indica que el binario se reemplazó en disco pero el antiguo sigue en memoria. Reinicie con sudo systemctl restart exim4.

Comprobar y corregir según el entorno

Desplace la tabla

EntornoComprobarCorregir
Debian, Ubuntu`dpkg -s exim4-daemon-light | grep Version``sudo apt update && sudo apt install --only-upgrade 'exim4*' 'dovecot*'`
AlmaLinux, Rocky (Dovecot)`rpm -q --changelog dovecot | grep CVE-2026-42006``sudo dnf upgrade dovecot`
AlmaLinux, Rocky (Exim fuera de los repositorios base)`rpm -q --changelog exim | grep CVE-2026-94054`Actualizar desde el repositorio que lo ofrezca, o esperar su corrección
Docker (imagen de Exim o Dovecot)`docker exec <container> exim -bV``docker pull <image>` y recrear el contenedor
Mailcow`docker compose exec dovecot-mailcow dovecot --version``./update.sh` en la carpeta de Mailcow
Compilado a mano`exim -bV`Recompilar desde una versión original corregida, o pasar al paquete de la distribución

Actualizar no reemplaza el proceso en ejecución

Tras la actualización, un demonio que ya estaba en marcha sigue ejecutando el binario antiguo. Reinicie con sudo systemctl restart exim4 y sudo systemctl restart dovecot, o deje que needrestart lo proponga. Para Ubuntu 20.04 y anteriores, la ficha de Ubuntu indica el estado "needs evaluation": sin paquete corregido, planifique una migración de sistema en lugar de esperar.

¿Está expuesto?: la prueba de Proxy-Protocol

Dos de las cuatro CVE exigen Proxy-Protocol. En Exim se activa con la opción principal hosts_proxy. Sin ella, ningún cliente ordinario llega al código afectado por CVE-2026-94054 y CVE-2026-94056. Pruebe con exim4 -bP hosts_proxy.

Un valor vacío indica que ningún host está declarado como proxy; un mensaje de opción desconocida puede venir de una compilación sin este soporte: compruébelo en la documentación de su compilación. Una lista de direcciones significa que esos hosts hablan Proxy-Protocol: el riesgo depende entonces de cuánto confía en ellos, porque la falla supone un proxy controlado por el atacante. Esta prueba no cubre CVE-2026-94057, el SMTP smuggling, que se aplica sin proxy, ni CVE-2026-94055, ligada a GnuTLS y a ajustes TLS no predeterminados en Ubuntu 26.04. Para esas, la actualización es la única defensa.

Si su distribución aún no tiene un paquete corregido

La tabla lo muestra: el 28 de octubre de 2026, Debian 12 seguía marcado como vulnerable para Exim. Esperar sin hacer nada no es la única opción. Empiece por reducir lo que es alcanzable: si exim4 -bP hosts_proxy devuelve un valor vacío, las dos fallas ligadas a Proxy-Protocol no son accesibles para un cliente ordinario, y gana tiempo con ellas. Para el resto, limite los orígenes permitidos en el puerto 25 cuando su uso lo permita, y vigile el seguimiento de su distribución hasta que se publique el paquete.

Recompilar Exim desde las fuentes originales es posible, pero entonces usted se convierte en el único mantenedor de ese binario: ningún apt upgrade volverá a corregirlo. Reserve esta opción para un equipo que acepte ese seguimiento. Si la distribución ya no tiene soporte, la salida duradera es migrar a una versión mantenida, algo que conviene planificar en lugar de sufrir.

Dovecot: CVE-2026-42006 y fuentes que no coinciden

CVE-2026-42006 describe un consumo de memoria sin límite cuando un cliente IMAP envía llaves de apertura en exceso. Elude el arreglo de CVE-2026-27857; según el seguimiento de Debian, ese arreglo solo bloqueaba las llaves de cierre. Dovecot.org la publicó el 12 de mayo de 2026 con severidad Moderate, pero no lista versiones afectadas ni corregidas: el sitio remite al aviso de Open-Xchange.

Debian da paquetes precisos: 1:2.3.19.1+dfsg1-2.1+deb12u6 para bookworm y 1:2.4.1+dfsg1-6+deb13u7 para trixie en el repositorio de seguridad. El seguimiento lista otra revisión de trixie fuera del repositorio de seguridad: cuando conviven dos revisiones, compruebe la que instala su apt con apt-get changelog dovecot-core | grep CVE-2026-42006. No deduzca nada de dovecot --version por sí solo. Si la actualización debe esperar, la mitigación documentada es un valor bajo de vsz_limit para el proceso imap: limita la memoria que un cliente puede consumir.

Dos fuentes callan o se contradicen, y conviene saberlo. Dovecot.org no publica versiones corregidas, mientras que Debian las da por distribución. Y la página de seguridad de exim.org no indexaba estas CVE cuando la consultamos el 28 de octubre de 2026: por eso no citamos ninguna fecha original para Exim. Los avisos de las distribuciones, Ubuntu y Debian, son los que deciden sobre su paquete.

Revisar los registros tras la corrección

Corregir no dice si alguien pasó antes. Busque paradas anormales desde el aviso: journalctl -u exim4 --since "2026-09-28" | grep -i -E 'segfault|signal|core dumped', y después journalctl -k --since "2026-09-28" | grep -i -E 'segfault|out of memory'. Del lado de Dovecot, journalctl -u dovecot --since "2026-09-28" | grep -i -E 'out of memory|killed' detecta un proceso imap eliminado por falta de memoria.

Revise también el registro de Exim (/var/log/exim4/mainlog en Debian y Ubuntu) por mensajes emitidos desde remitentes que no conoce. La ausencia de rastro no prueba nada: una fuga de memoria no deja ninguna línea. Conserve estos comandos como control de rutina tras cada aviso, no como prueba de inocencia.

¿Quién mantiene al día un servidor de correo?

Corregir un MTA expuesto parece reservado a un administrador de sistemas. El procedimiento anterior cabe en unos pocos comandos y se repite en cada aviso: leer el changelog, actualizar, reiniciar, comprobar el proceso. El coste real es la vigilancia, es decir, seguir los avisos USN y DSA, probar y no dejar nunca una máquina de lado.

En un VPS de ServOrbit dispone de acceso root y de la elección del sistema (Ubuntu, Debian, AlmaLinux, Rocky). Si no quiere mantener usted mismo estas correcciones, existe la opción de administración VPS, que se contrata aparte. Esta guía se ofrece tal cual, sin soporte para su configuración. Y si solo desea direcciones profesionales, el correo profesional le evita operar un MTA.

La documentación oficial

Aviso de Ubuntu USN-8834-1 (Exim): https://ubuntu.com/security/notices/USN-8834-1

Ficha de Ubuntu de CVE-2026-94054: https://ubuntu.com/security/CVE-2026-94054

Seguimiento de Debian de CVE-2026-94054: https://security-tracker.debian.org/tracker/CVE-2026-94054

Seguimiento de Debian de CVE-2026-42006: https://security-tracker.debian.org/tracker/CVE-2026-42006

Página de seguridad de Dovecot: https://dovecot.org/security

Aviso de Open-Xchange oxdc-adv-2026-0002: https://documentation.open-xchange.com/dovecot/security/advisories/html/2026/oxdc-adv-2026-0002.html

Compatibilidad de Exim con proxys (hosts_proxy): https://www.exim.org/exim-html-current/doc/html/spec_html/ch-proxies.html

Página de seguridad de Exim: https://www.exim.org/static/doc/security/

Un VPS propio, con root y elección del sistema

Un VPS de ServOrbit ofrece acceso root, una IPv4 dedicada y la elección del sistema (Ubuntu, Debian, AlmaLinux, Rocky). Si no quiere mantener usted mismo las correcciones de un servidor de correo expuesto, existe la opción de administración VPS; si no, el correo profesional evita operar un MTA.

¿Necesita ayuda?

Consulte nuestro centro de ayuda y nuestra FAQ, o contacte con nuestro equipo: llamada, WhatsApp o correo electrónico. Soporte en francés, inglés y árabe.

Escribir por WhatsAppse abre en una pestaña nueva