CVE-2026-107567 (GCVE-0-2026-107567)
Vulnerability from cvelistv5 – Published: 2026-10-19 15:34 – Updated: 2026-10-20 19:26
VLAI
EPSS
VEX
Title
Use of Less Trusted Source in hMailServer
Summary
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.
Severity
7.5 (High)
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-20 19:26 UTC
CWE
- CWE-348 - Use of Less Trusted Source
Assigner
References
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Progressive Robot Ltd | hMailServer |
Affected:
6.0.0 , ≤ 6.3.6
(semver)
|
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-107567",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-20T19:26:11.680731Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-20T19:26:19.977Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "hMailServer",
"repo": "https://gitlab.com/hmailserver/hmailserver",
"vendor": "Progressive Robot Ltd",
"versions": [
{
"lessThanOrEqual": "6.3.6",
"status": "affected",
"version": "6.0.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Found in the hMailServer project\u0027s own security review (Progressive Robot Ltd)"
}
],
"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\u0027s 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\u0027s key. Every copy the server then sent on to an address outside carried a valid signature aligned with the forged From, whatever the domain\u0027s DMARC policy: an account\u0027s forward, a mail rule\u0027s 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\u0027s 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\u0027s 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\u0027s 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\u0027s DMARC policy."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-348",
"description": "CWE-348: Use of Less Trusted Source",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T15:34:17.494Z",
"orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
"shortName": "GitLab"
},
"references": [
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/84"
},
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.7"
}
],
"solutions": [
{
"lang": "en",
"value": "Upgrade to hMailServer 6.3.7. It records on each message, and on every copy of it, whether the message came from outside: an SMTP session that did not authenticate and was not a submission the server\u0027s IP ranges allow without authentication, a download from an external account, or an imported file. It signs a message as its From domain only when an authenticated user submitted it (as another domain the server hosts only when the account may send as the address its From names), the server made it, or an IP range let it in as one of the server\u0027s own domains, so mail from outside and its forwards keep only the signatures they arrived with, and a signed-in account\u0027s message from an address at another hosted domain that the account may not send as is sent unsigned as that domain. Until then, do one of the following: publish a DMARC policy of quarantine or reject for each hosted domain the server signs for and set the server\u0027s DMARC failure score (DMARCFailureScore) at or above the spam delete threshold (SpamDeleteThreshold), so that such a message is refused on arrival; refuse it in an OnAcceptMessage event script when the client has not authenticated and the From header names a domain the server signs for; remove the forwards, rule forwards, Sieve redirects, alias and list members and mirror addresses that carry mail to outside addresses; or disable DKIM signing for the hosted domains, which alone of these also covers a signed-in account\u0027s submission. Rotate the DKIM key of any domain whose key may have signed forged mail."
}
],
"title": "Use of Less Trusted Source in hMailServer"
}
},
"cveMetadata": {
"assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
"assignerShortName": "GitLab",
"cveId": "CVE-2026-107567",
"datePublished": "2026-10-19T15:34:17.494Z",
"dateReserved": "2026-10-08T10:51:00.638Z",
"dateUpdated": "2026-10-20T19:26:19.977Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-107567",
"date": "2026-10-21",
"epss": "0.00166",
"percentile": "0.05531"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "hMailServer",
"repo": "https://gitlab.com/hmailserver/hmailserver",
"vendor": "Progressive Robot Ltd",
"versions": [
{
"lessThanOrEqual": "6.3.6",
"status": "affected",
"version": "6.0.0",
"versionType": "semver"
}
]
}
],
"source": "cve@gitlab.com"
}
],
"cveTags": [],
"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\u0027s 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\u0027s key. Every copy the server then sent on to an address outside carried a valid signature aligned with the forged From, whatever the domain\u0027s DMARC policy: an account\u0027s forward, a mail rule\u0027s 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\u0027s 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\u0027s 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\u0027s 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\u0027s DMARC policy."
}
],
"id": "CVE-2026-107567",
"lastModified": "2026-10-20T20:17:13.707",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6,
"source": "cve@gitlab.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-107567",
"options": [
{
"exploitation": "none"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-20T19:26:11.680731Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-10-19T16:17:01.587",
"references": [
{
"source": "cve@gitlab.com",
"url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.7"
},
{
"source": "cve@gitlab.com",
"url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/84"
}
],
"sourceIdentifier": "cve@gitlab.com",
"vulnStatus": "Deferred",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-348"
}
],
"source": "cve@gitlab.com",
"type": "Secondary"
}
]
}
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.