Vulnerability analysis · DMARC
A wildcard rule such as *.compute.amazonaws.com promotes each matched tenant name to a public suffix of its own. OpenDMARC's label count lands one short of that, and the gap is enough for a sibling host's DKIM signature to satisfy relaxed alignment against the victim.
| Software | OpenDMARC |
|---|---|
| Vendor | The Trusted Domain Project |
| Source | https://github.com/trusteddomainproject/OpenDMARC |
| Affected | OpenDMARC 1.4.2, built from the upstream tarball rel-opendmarc-1-4-2. The finding was originally isolated on the Debian package 1.4.2-1+deb12u1 and re-confirmed against pristine upstream. Earlier 1.4.x and 1.3.x releases are expected to share the behavior. Newest published release checked on 2026-07-30. |
| Where | DMARC organisational-domain computation from the Public Suffix List, under a wildcard (*) rule |
| Weakness | CWE-346 (Origin Validation Error) leading to CWE-290 (Authentication Bypass by Spoofing) |
| Reachable by | Remote. The attacker must control one host under the same wildcard suffix as the victim, which on shared cloud infrastructure means renting an instance. |
| CVSS v3.1 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N (6.5 (Medium)) |
| Verification | Reproduced on 2026-07-28 against the current release (run 20260728-120957) with a scripted reproducer, negative controls, and a second independent implementation as the differential oracle. The wildcard rule was verified byte-identical in both verifiers' Public Suffix List files, so the divergence is an algorithm defect and not a data difference. |
*.compute.amazonaws.com is a wildcard entry in the Public Suffix List. Any name the wildcard matches becomes a public suffix on its own, so tenanta.compute.amazonaws.com is one. A registrable domain is a public suffix plus a single label, which for x.tenanta.compute.amazonaws.com works out to the entire name.
OpenDMARC's count ends at the name the wildcard matched. It reports the organizational domain as tenanta.compute.amazonaws.com, one label short of the correct answer. Every host beneath that tenant name consequently lands in a single organization. Relaxed alignment then accepts a DKIM signature from any sibling host as aligned with the victim's From: domain.
The test publishes v=DMARC1; p=reject; adkim=r at _dmarc.x.tenanta.compute.amazonaws.com and varies the DKIM d= domain.
DKIM d= | OpenDMARC | Rspamd | Required |
|---|---|---|---|
z.tenanta.compute.amazonaws.com (a sibling host, registrable domain of its own) | pass, a bypass | reject | reject |
z.tenantb.compute.amazonaws.com (control: a second tenant under the wildcard) | fail | fail | fail |
plain.compute.amazonaws.com (control: one label higher) | fail | fail | fail |
The two control rows measure how far the mistake reaches. The collapse stops at tenanta.compute.amazonaws.com and does not continue on to amazonaws.com. One label is the whole size of the error, and the only names wrongly grouped together are siblings that share a tenant name.
Nothing about the list data explains the divergence. The two verifiers read separate files: OpenDMARC uses /usr/share/publicsuffix/public_suffix_list.dat, Rspamd uses /usr/share/rspamd/effective_tld_names.dat. Compared across the two, the *.compute.amazonaws.com entry is byte-identical. Running the publicsuffixlist library against each container's own file yields the canonical registrable domain and matches Rspamd. What differs is how OpenDMARC counts labels.
# zone
_dmarc.x.tenanta.compute.amazonaws.com. IN TXT "v=DMARC1; p=reject; adkim=r"
# attacker publishes a DKIM key for the host they control
sel._domainkey.z.tenanta.compute.amazonaws.com. IN TXT "v=DKIM1; k=rsa; p=..."From: is ceo@x.tenanta.compute.amazonaws.com.d=z.tenanta.compute.amazonaws.com with the attacker's own valid key.Expected: dmarc=fail. The two names are separate registrable domains, and adkim=r does not bridge separate registrable domains.
Observed: OpenDMARC reports dmarc=pass.
One host under the victim's tenant name is all the attacker needs. Where that tenant name belongs to shared cloud infrastructure, acquiring the host means paying for an instance. Wildcard entries of this shape are plentiful in the Public Suffix List: AWS EC2 *.compute.amazonaws.com, *.elasticbeanstalk.com, *.r.appspot.com, and more. Holding such a host, the attacker signs with a key of its own, and OpenDMARC treats the mail as aligned with the neighbor's From: domain in spite of p=reject; adkim=r. The CVSS vector records a privilege requirement; the price of an instance is what that requirement amounts to.
Keeping tenants in separate organizations is the reason those wildcard entries were added to the list. This defect cancels the isolation they were meant to establish.
When the matched rule is a wildcard, the label the wildcard matched belongs to the public suffix. The organizational domain is that suffix plus one further label. Count the wildcard's matched label before taking the registrable domain.
A companion finding, rspamd-psl-rules-ignored, covers Rspamd getting the same class of rules wrong in the opposite direction. Separate again is psl-snapshot-drift, where the two vendored lists carry data of different ages; that is a data-freshness divergence rather than an algorithm defect.
The laboratory keeps a fixture that publishes example.com as a public suffix. This test left it unused, and no example.com name occurs anywhere in the reproduction.