Twisted EUVD-2026-109152

No authentication is required (PR:N), but exploitation is constrained by network position and a guessing race, not by any product configuration toggle. The flaw is inherent to twisted.names.dns.DNSDatagramProtocol.datagramReceived, which accepts a UDP DNS response on transaction-ID match alone and never validates the datagram source address - affecting every consumer of the standard twisted.names.client.Resolver and createResolver, including twisted.mail MX resolution. Limiting factors per the advisory: against the standard client.Resolver, each query uses a fresh random source port, so an off-path attacker must guess ~32 bits (ephemeral port + transaction ID) within the query timeout window; an on-path attacker or one sharing a broadcast domain/NAT with the resolver or real server faces no barrier beyond the transaction ID. The single-barrier case is applications that directly construct and reuse one DNSDatagramProtocol instance across multiple queries (a supported pattern): after the first query the source port is fixed, so only the 16-bit transaction ID must be guessed. Affects Twisted <= 26.4.0; fixed in 26.10.0rc1.

This is a genuine but low-urgency defense-in-depth gap, not a high-priority emergency. The input CVSS 3.1 vector (AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N, base 3.1 Low) and the vuln.today Decision label 'monitor' are consistent: realistic exploitation requires a privileged network position and winning a probabilistic guessing race. The advisory itself quantifies the difficulty - against the standard twisted.names.client.Resolver, an off-path attacker must guess roughly 32 bits (a fresh random ephemeral source port plus the 16-bit transaction ID) within the query timeout, because the client cycles a new random source port per query; against code that reuses a single DNSDatagramProtocol instance across multiple queries, only the 16-bit transaction ID must be guessed after the first query. The AV:A (Adjacent) choice is well-supported because the advisory stresses that the real risk is for an on-path attacker or one sharing a broadcast domain or NAT, for whom source-address validation would be the stopping check and it is absent. No EPSS score was provided, so statistical exploitation-likelihood cannot be compared here. The vulnerability is NOT in CISA KEV (status not asserted in input) and there is no indication of active exploitation. A complete, demonstrated proof-of-concept is embedded in the vendor GHSA advisory (shown accepting a forged response), though the structured signals do not flag it as confirmed working exploit code. Net: a real correctness/best-practice flaw (missing RFC 5452 source-address validation) worth patching on a routine cycle, but the AC:H race condition and network-adjacency requirement keep real-world mass-exploitation risk low.

An attacker on the same LAN, broadcast domain, or NAT as a host running a Twisted-based application delivers a forged UDP DNS response to the resolver's listening port with a matching 16-bit transaction ID (and, for the standard client, the correct ephemeral source port), before the legitimate server replies. Because twisted.names never checks the response's source address, the forged A/MX record is accepted, redirecting resolution to attacker-controlled infrastructure for mail interception, SSRF, or MITM. A working proof-of-concept demonstrating acceptance of a forged response from an unrelated local socket is published in the vendor's GHSA advisory.