Índice de contenidos
Claves de la noticia
- Progressive Robot publicó hMailServer 6.3.4 el 27 de septiembre para corregir CVE-2026-100741 en su rama 6.x para Windows.
- La ruta de acceso remoto exige scripts de eventos JScript y un manejador concreto; una contraseña errónea puede bastar si se nombra una cuenta activa.
- El fabricante pide instalar la versión manualmente y preparar una copia de la base de datos y de los mensajes por una migración de 64 pasos.
Un servidor de correo puede procesar una contraseña maliciosa antes de decidir si el usuario entra. Eso es lo que corrige la versión 6.3.4 de hMailServer mantenida por Progressive Robot: bajo una configuración específica de scripts, un cliente remoto podía convertir datos de una petición de acceso en instrucciones JScript ejecutadas dentro del servicio. El aviso oficial identifica el fallo como CVE-2026-100741 y delimita su alcance a las versiones 6.0.0 a 6.3.3 para Windows.
La contraseña se evaluaba antes de autenticar
Según las notas oficiales de la versión 6.3.4, la vía de entrada más directa era un intento de autenticación que nombrase una cuenta existente y activa. La instalación tenía que tener habilitados los scripts de eventos, elegir JScript como lenguaje y definir el manejador OnClientValidatePassword. En esa combinación, un valor de contraseña preparado podía alterar la construcción de la llamada al script y hacer que el servidor ejecutase código antes de comprobar si la clave era correcta. No hacía falta conocer la contraseña válida, pero sí reunir esas condiciones de configuración.
El código se ejecutaría dentro de hMailServer.exe, con los permisos de la cuenta del servicio. El fabricante explica que la configuración suministrada de ScriptAllowedObjects=* permite acceder a objetos capaces de lanzar comandos, siempre dentro de los privilegios de esa cuenta. De ahí la gravedad potencial: un fallo en el tratamiento de texto recibido por red puede convertirse en ejecución de órdenes en el servidor. La nota no afirma que todas las instalaciones permitan ese camino ni comunica una campaña de explotación observada.
La misma familia de error tiene otras dos entradas remotas: el identificador de un mensaje que devuelve un servidor POP3 externo cuando existe OnExternalAccountDownload, y el texto de rechazo de una entrega SMTP cuando existe OnDeliveryFailed. Cada una depende de su propio manejador. La posibilidad de editar una regla con la acción Run function es distinta: exige capacidad para cambiar reglas y puede afectar a cualquiera de los dos lenguajes de scripts. Mezclar todas esas rutas bajo la etiqueta de «cualquier usuario anónimo» ocultaría la comprobación que realmente necesita hacer un administrador.
Una matriz corta para decidir si el servidor está expuesto
El alcance se entiende mejor cruzando plataforma, versión y configuración, en vez de mirar solo el número CVE. La siguiente tabla resume las condiciones descritas por Progressive Robot; se refiere a su rama mantenida 6.x, no a todas las instalaciones históricas de hMailServer 5.x.
| Entorno | Condición decisiva | Lectura operativa |
|---|---|---|
| Windows 6.0.0–6.3.3 | JScript, scripts activos y OnClientValidatePassword |
Un intento de acceso con cuenta activa puede alcanzar la ruta remota sin clave válida. |
| Windows 6.0.0–6.3.3 | OnExternalAccountDownload u OnDeliveryFailed |
Revisar también entradas del POP3 remoto o del rechazo SMTP. |
| Windows con VBScript | Sin la ruta JScript anterior | La contraseña, el UID y el error SMTP no abren esa vía; revisar permisos de edición de reglas. |
| Linux en esta rama | Sin el motor afectado en las versiones previas | El fabricante lo excluye de este CVE concreto. |
La conclusión práctica de esa comparación es precisa: la versión vulnerable no equivale por sí sola a una instalación explotable por contraseña. Para priorizar, hay que verificar si el servicio es Windows, si pertenece a la rama 6.0.0–6.3.3 y qué manejadores están cargados. A la inversa, que no exista el manejador de contraseña tampoco cierra automáticamente los caminos de POP3, SMTP o reglas. Esta separación permite revisar una flota sin atribuir el mismo riesgo a servidores con configuraciones distintas.
Contener ahora, actualizar con copia restaurable
La corrección de fondo es hMailServer 6.3.4. Si no puede instalarse de inmediato en un servidor JScript, el fabricante propone desactivar temporalmente los scripts de eventos. La alternativa más selectiva consiste en retirar los tres manejadores afectados de EventHandlers.js y recargar los scripts. También indica reservar a administradores la edición de reglas con Run function. Esa mitigación puede interrumpir automatizaciones legítimas del correo; conviene inventariar qué procesos dependen de cada manejador antes de quitarlos y verificar después que las funciones esenciales siguen operando.
La actualización requiere una ventana de mantenimiento planificada. Según la nota oficial, 6.3.4 mueve la base de datos del esquema 6040 al 6104 mediante 64 pasos de migración en un solo sentido. Por eso pide respaldar tanto la base como el directorio de datos antes de instalar. En sistemas MySQL o MariaDB incluye una conversión a utf8mb4 que puede tardar en almacenes grandes y detenerse si determinados nombres antes diferenciables colisionan con la nueva comparación. Un respaldo no sirve de mucho si no se sabe restaurarlo; probar esa recuperación antes de tocar producción reduce el riesgo de convertir una corrección urgente en una caída prolongada del correo.
Hay otra particularidad: esta versión se compiló y firmó manualmente tras el traslado del proyecto a GitLab y no lleva el paquete Sigstore que espera el actualizador integrado. El propio fabricante advierte de que el mecanismo automático rechazará 6.3.4 y no descargará el instalador. Esperar una actualización silenciosa dejaría el servidor en la versión anterior. La vía publicada es instalar manualmente el paquete adecuado desde la versión oficial, comprobando plataforma y requisitos antes de empezar.
Cómo comprobar que la corrección funciona
Después de instalar, verificar solo que el servicio arranca sería insuficiente. El orden razonable es confirmar la versión 6.3.4, revisar que la migración de base finalizó, comprobar los scripts y reglas que se conservaron y probar recepción, envío y autenticación con cuentas de prueba autorizadas. Si se usó la mitigación temporal, hay que decidir explícitamente qué manejadores vuelven y bajo qué permisos. Mantenerlos desactivados por accidente puede romper funciones; reactivarlos sin revisar su propósito puede devolver una superficie que nadie pretendía exponer.
Para operadores españoles que alojan su propio correo, la medida urgente es localizar instancias de esta rama y contrastar su configuración, no asumir que todos los servidores de correo o todos los hMailServer comparten el fallo. La combinación de una vía anterior al inicio de sesión y una migración compleja crea dos trabajos distintos: cerrar la exposición inmediata y ejecutar una actualización verificable. El primero depende de unos pocos ajustes concretos; el segundo exige copia restaurable, tiempo y pruebas de funcionamiento.
