CVE-2026-42304

What it actually does

CVE-2026-42304 is a remote unauthenticated denial-of-service flaw in Twisted's twisted.names DNS handling. A crafted DNS packet sent over TCP can contain deeply chained name-compression pointers that bypass prior loop-prevention logic. While decompressing the DNS name, Twisted performs excessive recursive pointer resolution, consuming the single-threaded reactor's execution time and causing the application to stop processing other events. The impact is availability loss only; the vulnerability does not directly provide code execution, data disclosure, or data modification.

Why it matters to the business

Services that rely on Twisted's DNS functionality can be made unresponsive by a remote attacker without authentication. Because Twisted is commonly embedded in Python network services and applications, the operational impact may appear as application freezes, failed DNS responses, timeouts, health-check failures, or service restarts. The CVSS score is high for availability impact, but current EPSS is low and stable, it is not listed in CISA KEV, and no mature public exploitation is indicated, so remediation should be prioritized for internet-exposed or DNS-processing services rather than treated as active widespread exploitation.

How an attack unfolds

An attacker identifies a service using Twisted's twisted.names DNS implementation that accepts DNS traffic over TCP. The attacker establishes a TCP DNS connection and sends a malformed DNS message where name fields use a long chain of compression pointers. When Twisted parses the message, the decompression routine follows the chained pointers through millions of lookups rather than rejecting the input quickly. Because the Twisted reactor is single-threaded, this parsing work monopolizes the event loop and prevents the server from handling normal requests. Repeating the request or maintaining several connections can keep the affected service frozen or repeatedly unavailable until the process is restarted or patched.

How to fix it

Upgrade Twisted to version 26.4.0rc2 or later, where DNS name decompression handling has been corrected. If a stable release newer than 26.4.0rc2 is available from the project's normal package channel, prefer that version. Rebuild and redeploy any applications, containers, virtual environments, or bundled Python packages that vendor Twisted. If immediate upgrade is not possible, restrict access to Twisted-based DNS services to trusted networks, block or rate-limit TCP DNS traffic from untrusted sources where operationally feasible, place affected services behind protective DNS-aware filtering, and configure process supervision to restart hung services. Mitigations should be treated as temporary because malformed input can still reach any exposed vulnerable parser.

How to confirm the fix worked

Confirm installed Twisted versions across source repositories, virtual environments, container images, hosts, and packaged applications. Use package inventory tooling or commands such as `python -m pip show Twisted` and verify the version is 26.4.0rc2 or later. Where applications vendor dependencies, inspect lockfiles such as requirements.txt, requirements.lock, Pipfile.lock, poetry.lock, uv.lock, or SBOM output for Twisted versions. Validate that deployed artifacts were rebuilt after the dependency update, not only source manifests. For exposure validation, confirm whether applications import or enable twisted.names and whether DNS over TCP is reachable from untrusted networks. Functional validation can include sending benign DNS queries after the upgrade and confirming the service remains responsive under malformed-input testing in a controlled environment.

Typical attack path

1. Identify an application or service using Twisted's twisted.names DNS parser.
2. Confirm that the service accepts DNS messages over TCP from the attacker's network location.
3. Craft a DNS packet containing deeply chained compression pointers in a compressed domain name field.
4. Send the crafted TCP DNS packet to the target service.
5. Trigger excessive recursive decompression inside the Twisted reactor.
6. Cause the event loop to hang, resulting in service timeouts or unresponsiveness.
7. Repeat the traffic as needed to sustain denial of service.

How to detect it

Evidence of exploitation is most likely to appear as availability symptoms rather than explicit error messages, because the vulnerable behavior can hang the Twisted reactor instead of producing a clean exception. Review network telemetry for unusual DNS-over-TCP traffic to services using Twisted, especially small numbers of malformed queries followed by immediate service unresponsiveness. Inspect application, supervisor, and platform logs for health-check failures, request timeouts, watchdog restarts, or lack of normal Twisted activity after receiving DNS TCP connections. Packet captures, DNS firewall logs, IDS telemetry, or load balancer logs may show TCP/53 or application-specific DNS traffic containing abnormal compression-pointer chains. Correlate suspected traffic with process CPU spikes, event-loop stalls, increased latency, or service restarts. No named threat actors or active exploitation campaigns are currently associated with this vulnerability in the supplied intelligence.

What your security team should do

• Inventory all applications, containers, and Python environments that include Twisted, with priority on internet-facing services and anything handling DNS traffic.
• Upgrade Twisted to 26.4.0rc2 or later and redeploy affected workloads.
• If upgrade cannot be completed immediately, restrict untrusted access to TCP DNS endpoints and apply rate limits or upstream filtering for malformed DNS traffic.
• Add monitoring for application hangs, event-loop stalls, health-check failures, sudden TCP DNS connection spikes, and unexplained restarts in Twisted-based services.
• Review dependency lockfiles and SBOMs to identify transitive or vendored Twisted usage in internally developed and third-party applications.
• Because this is not currently KEV-listed and EPSS is low and stable, prioritize based on exposure and service criticality rather than emergency enterprise-wide shutdown procedures.