CVE-2008-1447: DNS resolvers allow cache poisoning via insufficient transaction ID and source port entropy

Automated analysis

Generated by VULONE's analysis model from the NVD record, CISA KEV and EPSS data on 18 September 2026. Confidence: high.

high priorityThe flaw enables remote cache poisoning of recursive resolvers with no authentication or user interaction, and EPSS is extremely high, though the CVSS score is medium and KEV listing is absent.

What it is

The DNS protocol as implemented in BIND 8 and 9 (before 9.5.0-P1, 9.4.2-P1, 9.3.5-P1), Microsoft DNS on Windows 2000 SP4, XP SP2/SP3 and Server 2003 SP1/SP2, and other implementations uses insufficient randomness in DNS transaction IDs and source ports. A remote attacker can use a birthday attack with in-bailiwick referrals to spoof DNS responses and poison the cache of a recursive resolver. This is the well-known Kaminsky bug, and successful poisoning lets an attacker redirect name resolution for many users.

Impact

An attacker who poisons a recursive resolver's cache can return forged answers for arbitrary domains, redirecting victims to attacker-controlled hosts for further credential theft, malware delivery or traffic interception. The CVSS vector shows high integrity impact with no confidentiality or availability impact.

Attack surface

Reachable over the network by sending spoofed DNS responses to a recursive resolver; no authentication and no user interaction are required. The attacker must race the legitimate response and predict transaction IDs and source ports.

Exploitation

The record is not listed in CISA KEV and has no exploit-tagged references, but EPSS is very high (0.95182 probability, 99.861 percentile), indicating strong likelihood of exploitation activity. The references are advisories and technical descriptions rather than exploit code.

What to do

• Patch BIND to 9.5.0-P1, 9.4.2-P1 or 9.3.5-P1, and apply the corresponding Microsoft DNS and other vendor updates for the affected Windows versions.
• Where patching is not immediately possible, restrict recursive resolution to trusted clients and disable open recursion.
• Enable source port randomization and, where supported, DNSSEC validation to detect forged answers.
• Segment or firewall recursive resolvers so they are not reachable from untrusted networks.
• Monitor vendor advisories for the affected platforms and apply follow-up fixes.

Detection

• Monitor resolver logs for a high volume of unexpected or mismatched DNS responses and cache changes for domains the resolver did not query.
• Alert on sudden changes in resolution results for high-value domains, such as internal or authentication-related names.
• Use DNSSEC validation failures or anomalies as an indicator of forged responses.
• Baseline normal query and response patterns per resolver and flag deviations consistent with spoofing attempts.

This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.