Prefect CVE-2026-7724

Exploitation requires an authenticated user (PR:L) with the ability to configure webhooks or notifications in Prefect. The attacker must control a DNS domain and be able to manipulate DNS responses with sub-second timing precision. The Prefect instance must have allow_private_urls set to False (the default secure configuration) or the webhook/notification must target a URL that validate_restricted_url would ordinarily restrict. Non-default configurations where allow_private_urls is True eliminate this vulnerability's impact, as they intentionally permit private address targets. Exploitation does not require user interaction (UI:N) beyond initial webhook/notification configuration, and can be triggered automatically when Prefect processes events.

Despite the low CVSS score of 1.3, this vulnerability presents a moderate real-world risk. The CVSS vector (AV:N/AC:H/AT:N/PR:L/UI:N) correctly reflects that exploitation requires network access, high complexity, and low privileges, yet the technical impact is limited to information disclosure (VC:L/VI:L/VA:L). However, multiple risk signals indicate tangible exploitability: publicly available proof-of-concept code exists, the attack methodology (DNS rebinding) is well-established, and the fix explicitly addresses a known TOCTOU window. The attack complexity is high because it requires precise timing and DNS control, and the tag indicates information disclosure rather than remote code execution. The vulnerability is NOT actively exploited in the wild (no KEV status), but the combination of public POC and low authentication requirement (PR:L) warrants expedited patching for internet-facing Prefect instances. Organizations with Prefect deployments exposed to untrusted users should prioritize this upgrade, particularly if webhooks or notifications route to sensitive internal services. The limited scope (information disclosure, no integrity or availability impact) and requirement for authenticated attackers reduce criticality compared to network-accessible RCE, but the TOCTOU nature makes it a teaching example for why static URL validation is insufficient for SSRF protection.

An authenticated user (satisfying PR:L requirement) configures a webhook notification URL pointing to a hostname under attacker control. The attacker's DNS server initially returns a public IP address when Prefect's validate_restricted_url function performs its pre-connection check, allowing the URL to pass validation. When Prefect's HTTP client actually establishes the connection moments later, the attacker's DNS server returns a private IP address (e.g., 127.0.0.1) via DNS rebinding. The unprotected HTTP transport connects to the private address and inadvertently exfiltrates webhook data or notification content that should have been restricted.