FR
live
Networking Critical CVSS 9.3

The RebirthDay attack revives 2002-era DNS cache poisoning by abusing ECS

Researchers resurrected the DNS birthday attack, considered dead since 2002, by bypassing query aggregation through ECS; eight vendors acknowledged the issue and 50 CVEs were assigned. Unbound, PowerDNS, and BIND are affected — exposed resolvers should be patched immediately.

A dark telephone switchboard bristling with dozens of identical copper jacks, a single jack glowing amber as a cable plugs into the wrong socket.

2025. Researchers present RebirthDay at CCS, an attack that revives the DNS birthday poisoning thought dead since 2002. 2026. The work is presented again at Black Hat Asia, with a responsible disclosure tally: eight vendors acknowledged the issue and 50 CVEs were assigned. July 22, 2026. Separately, NLnet Labs publishes CVE-2026-50252, a port-entropy flaw in Unbound rated CVSS 9.3. The part that matters: DNS cache poisoning is no longer a history lesson — it is a live attack surface again, and exposed resolvers need patching now.

How RebirthDay bypasses the defense that killed the birthday attack

DNS cache poisoning means tricking a resolver into accepting a forged response that maps a domain name to an attacker-controlled IP. The classic defense rests on two secrets: a random source port and a transaction ID. The birthday attack — flooding guessed responses and betting on a collision — stopped working in 2002, when resolvers began aggregating identical queries: one outgoing query per name, one chance to guess.

RebirthDay breaks exactly that protection. The trick rides on ECS — EDNS Client Subnet — the extension that forwards a prefix of the client’s address to the resolver to guide CDN selection. By sending queries with different ECS prefixes, the attacker forces the resolver to emit multiple outgoing queries for the same name, one per prefix. Aggregation shatters: each prefix offers a fresh collision chance, and the birthday attack becomes statistically viable again.

The targets are recursive resolvers and forwarders that enable ECS without checking its consistency. The blast radius is wide because ECS is common and rarely audited.

The concrete case: Unbound and CVE-2026-50252

Alongside the academic work, CVE-2026-50252 shows the same family of risk from a more mundane angle. It affects Unbound, the validating resolver from NLnet Labs, in versions 1.4.22 through 1.25.1, and only when so-reuseport is enabled — which is the default in those versions.

The mechanism is subtle. Unbound splits the UDP port range across its worker threads. With SO_REUSEPORT, the kernel sends each client port to a fixed thread. An observer on the same network can therefore learn the mapping between an outgoing port and a thread, for a given source address. Once the thread is known, the number of ports to guess collapses, making cache poisoning far cheaper.

The 1.25.2 fix replaces that split with a shared port pool per interface, so the port no longer leaks the thread. The flaw is rated CVSS 9.3 with an adjacent-network vector: the attacker must be able to observe the resolver’s traffic, which limits exploitation to networks where you can listen in — but a shared resolver or an open Wi-Fi changes that calculus.

The scale: eight vendors, fifty CVEs

The responsible disclosure for RebirthDay drew acknowledgments from eight vendors, including BIND (ISC), Unbound (NLnet Labs), PowerDNS, and Quad9. The 50 CVEs assigned signal a cross-cutting problem: this is not one faulty implementation but a class of weakness tied to ECS verification and the DNS extensions that come with it.

The lesson outlives today’s patch. ECS was added for performance and CDN reasons, not as an attack vector. Its interaction with resolver entropy reopened a door people believed closed for a quarter of a century. The researchers are blunt: ECS verification and its implementations deserve far more scrutiny.

What to do, concretely

The remediation steps are precise and verifiable.

Upgrade Unbound to 1.25.2, or install the package your distribution patched for CVE-2026-50252. If you build from source and cannot move to 1.25.2, apply the patch NLnet Labs publishes for 1.25.1.

bash
unbound -V
unbound-checkconf -o so-reuseport

The first command prints the installed version; the second prints the effective value of so-reuseport. If it answers yes, the advisory’s condition is met. A package may report an older base version with fixes backported, so check your distribution’s security tracker.

Disable ECS if you do not need it. An enterprise resolver that serves no CDN has no reason to emit ECS queries. Turning it off removes the surface RebirthDay exploits.

Keep DNSSEC validation on. It protects answers independently of source ports and makes poisoning harmless on signed zones.

Limit who may query the resolver with access-control rules, and restart the service after upgrading to confirm the new version is running.

Verdict

If you run an Unbound resolver exposed to anyone beyond your own clients, move to 1.25.2 immediately and check so-reuseport: it is a one-command fix against a flaw rated 9.3. If you manage a fleet of resolvers or forwarders, add two lines to your standard: disable ECS where it serves no purpose, and keep DNSSEC on. The conclusion of RebirthDay fits in one sentence: an extension added for performance reopened a 2002 attack — the defense only holds if you treat every DNS extension as a surface to audit.

References

cve

Linked vulnerabilities

CVE-2026-50252In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing policies depend on the source port while their outcome is revealed this secrecy is undermined. The vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP port and IP address while heavily depending on the incoming source UDP port as a randomization source. When the SO_REUSEPORT configuration option is enabled ('so-reuseport: yes') in Unbound (by default), it meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size, assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel’s SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a particular thread. All outgoing DNS queries generated during the resolution of that request use source ports selected exclusively from the port subset assigned to the corresponding thread. Since these port subsets are disjoint across threads, the source port observed in a resolver’s outgoing query to an authoritative name server serves as a reliable indicator of the worker thread that processed the original client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks by effectively lowering the random port population per thread.Nlnetlabs Unbound Critical CVSS 9.3 22/07

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

OpenSSL 4.1.0 finally ships DTLS 1.3, four known bugs included

On October 23, 2026, OpenSSL released version 4.1.0, which adds DTLS 1.3 (RFC 9147) support alongside four known bugs in that same code, two of which make a connection’s return codes lie to the application. If you adopt DTLS 1.3 server-side, do not take SSL_ERROR_WANT_READ or SSL_ERROR_SYSCALL at face value.

Tailscale SSH turns one compromised device into root access across the mesh

On October 25, 2026, researcher Erica Windisch published Tailworm, a report showing that Tailscale SSH combined with port forwarding grants root access to every reachable server once a single device on the mesh is compromised. With no patch and no CVE so far, the immediate fix comes down to three settings: pairwise access rules, port forwarding off, and Tailnet Lock.

← Back to the feed

Type at least two characters.

↑ ↓ navigate ↵ open esc dismiss