CVE-2026-107568

Estado: AplazadaMedia (6.5)—
Gravedad6.5Media · CVSS 3.1
Probabilidad de explotación0.24 %mayor que el 15 % de las CVE
Explotación activaNono figura en el catálogo de CISA
Exploit públicoNo conocidosin código público localizado

Autorización ausente en la acción de notificación de Sieve (desde 6.2.22 hasta 6.3.6) y en la acción Responder de las reglas de correo (desde 6.0.0 hasta 6.3.6) de Progressive Robot hMailServer permite a un usuario autenticado enviar correo a través del servidor como cualquier dirección.

Leer descripción completaMostrar menos

Una notificación de Sieve envía un mensaje de notificación, y su etiqueta :from indica el remitente; el servidor establecía la cabecera From de la notificación con ese valor de :from tal como lo había escrito el script, sin comprobar que la dirección perteneciera a la cuenta; comprobación que sí aplica la acción de vacaciones de Sieve a su propio :from, y que el servidor aplica al remitente del correo puesto en cola mediante COM o enviado desde el correo web. Por tanto, una cuenta que pueda almacenar un script de Sieve (mediante ManageSieve, el filtro de autoservicio de la API REST o la interfaz de administración) podría hacer que el servidor envíe una notificación desde cualquier dirección, en este servidor o en cualquier otro; y, cuando la dirección indicada pertenece a un dominio alojado en el servidor con firma DKIM habilitada, el servidor firmaba la notificación con la clave DKIM de ese dominio, ya que firma según el dominio de la cabecera From, produciendo correo falsificado alineado para superar la política DMARC del dominio. La acción de notificación y este comportamiento se introdujeron en la versión 6.2.22. En el motor de reglas de correo, la respuesta de una regla también se enviaba desde la dirección que indicara la acción, independientemente de a quién perteneciera la regla; de modo que una cuenta que actúa sobre sus propias reglas mediante COM, un administrador de dominio o una clave de API restringida a un dominio (mediante la API REST desde la versión 6.3.4) podrían hacer que la respuesta de una regla de un dominio o de una cuenta se enviase desde cualquier dirección, firmada, cuando esa dirección pertenece a un dominio alojado en el servidor con firma DKIM habilitada, usando la clave de ese dominio.

Traducción automática del texto original de NVD (en inglés).

CVSS

Puntuación base
6.5
Versión
3.1
Vector
CVSS:3.1/AV:N/AC:L/PR:L/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.24 %
Percentil entre todas las CVEs puntuadas
15
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.

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

Referencias

Mostrar las 2 referencias

JSON original (NVD)

Mostrar
{
  "id": "CVE-2026-107568",
  "cveTags": [],
  "metrics": {
    "cvssMetricV31": [
      {
        "type": "Secondary",
        "source": "cve@gitlab.com",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 6.5,
          "attackVector": "NETWORK",
          "baseSeverity": "MEDIUM",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
          "integrityImpact": "HIGH",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "NONE",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "NONE"
        },
        "impactScore": 3.6,
        "exploitabilityScore": 2.8
      }
    ]
  },
  "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.717",
  "references": [
    {
      "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.7",
      "source": "cve@gitlab.com"
    },
    {
      "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/82",
      "source": "cve@gitlab.com"
    }
  ],
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "type": "Primary",
      "source": "cve@gitlab.com",
      "description": [
        {
          "lang": "en",
          "value": "CWE-862"
        }
      ]
    }
  ],
  "descriptions": [
    {
      "lang": "en",
      "value": "Missing authorization in the Sieve notify action (6.2.22 through 6.3.6) and in the mail-rule Reply action (6.0.0 through 6.3.6) of Progressive Robot hMailServer allows an authenticated user to send mail through the server as any address. A Sieve notify sends a notification message, and its :from tag names the sender; the server set the notification's From header to that :from as the script wrote it, without checking that the address belongs to the account - the check that the Sieve vacation action applies to its own :from, and that the server applies to the sender of mail queued over COM or sent from the webmail. An account that can store a Sieve script (over ManageSieve, the REST API's self-service filter, or the administration interface) could therefore have the server send a notification from any address, on this server or anywhere; and where the claimed address is at a domain the server hosts with DKIM signing enabled, the server signed the notification with that domain's DKIM key, because it signs by the From header's domain, producing forged mail aligned to pass the domain's DMARC policy. The notify action and this behaviour were introduced in 6.2.22. In the mail-rule engine, a rule's Reply was likewise sent from whatever address the action named, whoever the rule belonged to, so that an account acting on its own rules over COM, a domain administrator, or an API key confined to a domain (over the REST API from 6.3.4) could have a domain's or an account's rule reply from any address, signed, where that address is at a domain the server hosts with DKIM signing enabled, with that domain's key."
    }
  ],
  "lastModified": "2026-10-19T21:14:14.150",
  "sourceIdentifier": "cve@gitlab.com"
}