CVE-2026-107567
El uso de una fuente menos fiable en la firma DKIM de hMailServer 6.0.0 hasta 6.3.6, de Progressive Robot, permite a un atacante remoto sin autenticar que el correo que redacta vaya firmado con la clave DKIM de un dominio alojado en el servidor, de modo que supere DKIM y DMARC para ese dominio en otros receptores.
Leer descripción completaMostrar menos
Con la firma DKIM habilitada para un dominio alojado, el servidor firmaba cada mensaje en su primera pasada de entrega como el dominio indicado en su cabecera From, antes de la entrega local, independientemente del origen del mensaje y sin comprobar que su remitente se hubiera autenticado. Por tanto, cualquier remitente podía enviar al servidor, como correo entrante ordinario, un mensaje cuyo From fuera cualquier dirección de ese dominio, y el servidor lo firmaba con la clave de dicho dominio. Cada copia que el servidor enviaba después a una dirección externa llevaba una firma válida alineada con el From falsificado, con independencia de la política DMARC del dominio: el reenvío de una cuenta, el reenvío o la copia de una regla de correo, una redirección de Sieve, un alias o lista de distribución con un miembro externo, la copia espejo, una copia de una lista gestionada o de journal, o un mensaje liberado de la cuarentena. Una copia firmada también puede reenviarse a otros destinatarios mientras la clave del dominio no cambie. La explotación requiere que la firma DKIM esté habilitada para el dominio alojado (está desactivada hasta su configuración) y, para que la falsificación salga del servidor, un reenvío, alias, lista o regla que dirija el correo del dominio a una dirección externa. El firmante también firmaba un mensaje enviado mediante SMTP autenticado con cualquier dominio alojado que indicara su cabecera From, algo que la autenticación SMTP no vincula a la cuenta remitente, de modo que una cuenta de un dominio alojado podía hacer que se firmara con la clave de otro dominio alojado correo redactado en nombre de este. Esto cobraba importancia cuando el servidor retiene a los remitentes autenticados hacia sus propias direcciones de sobre (SmtpAuthenticatedSenderCheck, desactivada por defecto), ya que la firma era entonces la única vía restante para que dicho correo superara la política DMARC del otro dominio.
Traducción automática del texto original de NVD (en inglés).
CVSS
- Puntuación base
- 7.5
- Versión
- 3.1
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días
- 0.17 %
- Percentil entre todas las CVEs puntuadas
- 5
- Fecha de la puntuación
- 20/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Técnicas ATT&CK
Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.
- Explotación
T1190Exploit Public-Facing Applicationinitial access60 %
Inferido por reglas deterministas a partir del vector CVSS y la CWE. Solo orientativo.
Mitigaciones ATT&CK que cubren estas técnicas
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
CWE
- CWE-348
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-107567",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Secondary",
"source": "cve@gitlab.com",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 7.5,
"attackVector": "NETWORK",
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"integrityImpact": "HIGH",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "NONE",
"privilegesRequired": "NONE",
"confidentialityImpact": "NONE"
},
"impactScore": 3.6,
"exploitabilityScore": 3.9
}
]
},
"affected": [
{
"source": "cve@gitlab.com",
"affectedData": [
{
"repo": "https://gitlab.com/hmailserver/hmailserver",
"vendor": "Progressive Robot Ltd",
"product": "hMailServer",
"versions": [
{
"status": "affected",
"version": "6.0.0",
"versionType": "semver",
"lessThanOrEqual": "6.3.6"
}
],
"defaultStatus": "unaffected"
}
]
}
],
"published": "2026-10-19T16:17:01.587",
"references": [
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.7",
"source": "cve@gitlab.com"
},
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/84",
"source": "cve@gitlab.com"
}
],
"vulnStatus": "Deferred",
"weaknesses": [
{
"type": "Primary",
"source": "cve@gitlab.com",
"description": [
{
"lang": "en",
"value": "CWE-348"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Use of a less trusted source in the DKIM signing of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have mail they write signed with the DKIM key of a domain the server hosts, so that it passes DKIM and DMARC for that domain at other receivers. With DKIM signing enabled for a hosted domain, the server signed every message on its first delivery pass as the domain named in its From header, before local delivery, whatever the message's origin and without checking that its sender had authenticated. A sender anywhere could therefore send the server, as ordinary inbound mail, a message whose From is any address at such a domain, and the server signed it with that domain's key. Every copy the server then sent on to an address outside carried a valid signature aligned with the forged From, whatever the domain's DMARC policy: an account's forward, a mail rule's forward or copy, a Sieve redirect, an alias or distribution list with an outside member, the mirror copy, a managed-list or journal copy, or a message released from quarantine. A signed copy can also be re-sent to other recipients while the domain's key is unchanged. Exploitation needs DKIM signing to be enabled for the hosted domain (it is off until configured) and, for the forgery to leave the server, a forward, alias, list or rule that carries the domain's mail to an outside address. The signer likewise signed a message submitted over authenticated SMTP as whatever hosted domain its From header named, a header authenticated SMTP does not hold to the submitting account, so that an account of one hosted domain could have mail written in the name of another hosted domain signed with that domain's key; this mattered where the server holds signed-in senders to their own envelope addresses (SmtpAuthenticatedSenderCheck, off by default), as the signature was then the remaining way for such mail to pass the other domain's DMARC policy."
}
],
"lastModified": "2026-10-19T21:14:14.150",
"sourceIdentifier": "cve@gitlab.com"
}