CVE-2024-25638

What it actually does

The library accepts DNS resource records in replies without verifying they match the original query's name, type, or class, enabling injection of records from unrelated zones into resolver responses.

Why it matters to the business

Applications relying on this DNS library can be tricked into using attacker-supplied addresses or data, leading to traffic redirection, service disruption, or exposure of internal systems; the issue affects many Java projects that depend on dnsjava, increasing the scope of potential impact across the ecosystem.

How an attack unfolds

An attacker positioned to observe or influence DNS traffic sends a crafted reply containing resource records from a different zone; because the library performs no relevance validation, these extraneous records are processed and cached or returned to the calling application, allowing subsequent queries to resolve to attacker-controlled endpoints.

How to fix it

Upgrade dnsjava to version 3.6.0 or later (commit fd1d7c9280986ebb219c421695a902559aaeda22). For the affected Ubuntu package, apply the listed fixed versions. Validate that all direct and transitive dependencies are updated and test DNS resolution behavior after deployment.

How to confirm the fix worked

Confirm the dnsjava version in use matches or exceeds 3.6.0, review application dependency manifests, and perform controlled DNS queries to verify that only relevant records from the queried zone are accepted.

Typical attack path

1. Identify an application using the vulnerable dnsjava library for DNS resolution
2. Observe or trigger a DNS query from the target
3. Craft and transmit a UDP or TCP DNS response containing resource records from an unrelated zone
4. Have the library accept and use the injected records for subsequent operations
5. Redirect application traffic or obtain unauthorized data via the poisoned responses

How to detect it

Examine DNS resolver logs and application debug output for responses containing resource records whose names or zones do not match the original query; correlate with network captures showing unsolicited or out-of-zone records accepted by the resolver.

What your security team should do

• Immediately inventory all Java applications and services that depend on dnsjava and prioritize upgrades to 3.6.0
• Implement network-level DNS query monitoring to detect anomalous responses during the remediation window
• Add dependency scanning to CI/CD pipelines to prevent reintroduction of vulnerable versions
• Review logging configurations to ensure DNS response details are captured for future incident response