How severe is CVE-2026-33489?

No CVSS score has been assigned to CVE-2026-33489 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by CVE-2026-33489?

CVE-2026-33489 affects the following packages: github.com/coredns/coredns (Go). Ecosystems affected: Go.

How do I fix CVE-2026-33489?

Update github.com/coredns/coredns to 1.14.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-33489 is resolved across your whole dependency graph.

How do I detect CVE-2026-33489 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/coredns/coredns, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2026-33489 if there is no patch (or I can't update yet)?

Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Is CVE-2026-33489 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-33489 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2026-33489?

CVE-2026-33489 has an EPSS (Exploit Prediction Scoring System) score of 0.4%, placing it in the 35th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2026-33489?

CVE-2026-33489 is classified as CWE-863 (CWE-863). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2026-33489 published, and has it been updated?

CVE-2026-33489 was published on May 5, 2026 and was last updated on October 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

Not in CISA KEV

CVE-2026-33489 — coredns

CVE-2026-33489 is a CWE-863 vulnerability in github.com/coredns/coredns. A fix is available for github.com/coredns/coredns — see the affected versions and patch details below.

CoreDNS transfer plugin subzone ACL bypass via lexicographic zone comparison

Also known asGHSA-h8mm-c463-wjq3GO-2026-5417

Published

May 5, 2026

Updated

Oct 28, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Nov 3, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-33489.

EPSS Exploitation Probability

via FIRST.org ↗

0.4%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs35th percentile — riskier than 35% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

🐹github.com/coredns/coredns

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

CoreDNS' transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. A permissive parent-zone transfer rule can override a restrictive subzone rule (name-dependent), allowing an unauthorized client to perform AXFR/IXFR for the subzone and retrieve its zone contents.

Details

In plugin/transfer/transfer.go, stanza selection is implemented by longestMatch(), which is documented as "longest zone match wins", but it actually chooses the winner via a lexicographic string comparison:

zone := "" // longest zone match wins (plugin/transfer/transfer.go)
if z > zone { zone = z; x = xfr } (plugin/transfer/transfer.go)

So, a parent zone like example.org. can beat a child zone like a.example.org. purely due to lexicographic ordering ("example.org." > "a.example.org."), even though the child zone is the longer/more specific suffix match. The bypass is data-dependent (some child labels will win, some will lose), making it operationally non-intuitive.

PoC

Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)
Run python3 ./acl-repro.py
Expected output: *** Baseline (only subzone transfer rule) *** axfr a.example.org.: rcode=5 ancount=0 (expected REFUSED=5)

*** Candidate (add permissive parent transfer rule) *** axfr a.example.org.: rcode=0 ancount=5 (expected NOERROR=0 with ancount>0)

*** OK *** Subzone transfer ACL bypass reproduced: adding a permissive parent-zone stanza can override a stricter child-zone stanza due to lexicographic zone selection.

Impact

Unauthorized zone transfer can expose full zone contents to a remote network client that was intended to be denied by a subzone-specific transfer policy.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/coredns/coredns`	all versions	1.14.3`go get github.com/coredns/coredns@v1.14.3`

Affected Products

1 product · 1 configurations

Application

corednscoredns.io

< 1.14.3

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/coredns/coredns, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/coredns/coredns to 1.14.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-33489 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

Workaround published by Red Hat

To mitigate this vulnerability, ensure that the CoreDNS `transfer` plugin is configured with explicit and precise Access Control List (ACL) rules for all zones and subzones. Avoid broad parent-zone transfer rules that could inadvertently override more restrictive subzone configurations. If zone transfers are not required, disable the `transfer` plugin or restrict its access to only trusted internal networks using firewall rules or CoreDNS configuration directives. Always review and validate `transfer` plugin configurations to prevent unintended information disclosure.

Source: Red Hat security advisory for CVE-2026-33489 (CC BY 4.0)

Frequently Asked Questions

### Summary CoreDNS' transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. A permissive parent-zone transfer rule can override a restrictive subzone rule (name-dependent), allowing an unauthorized client to perform AXFR/IXFR for the subzone and retrieve its zone contents. ### Details In plugin/transfer/transfer.go, stanza selection is implemented by longestMatch(), which is documented as "longest zone match wins", but it actually chooses the winner via a lexicographic string comparison: - zone := "" // longest zone match wins (plug