CVE-2026-7724
Received Received - Intake
Time-of-Check Time-of-Use in PrefectHQ

Publication date: 2026-05-04

Last updated on: 2026-05-04

Assigner: VulDB

Description
A vulnerability has been found in PrefectHQ prefect up to 3.6.28.dev1. Affected by this vulnerability is the function validate_restricted_url of the component Webhook/Notification. The manipulation leads to time-of-check time-of-use. It is possible to initiate the attack remotely. The attack is considered to have high complexity. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 3.6.28.dev2 addresses this issue. The identifier of the patch is 7c70ac54a5e101431d83b9f2681ec88d5e0021ed. Upgrading the affected component is advised. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-04
Last Modified
2026-05-04
Generated
2026-05-27
AI Q&A
2026-05-04
EPSS Evaluated
2026-05-25
NVD
EUVD
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
prefecthq prefect to 3.6.28.dev2 (exc)
prefecthq prefect 3.6.28.dev2
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
CWE-367 The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-7724 is a DNS rebinding Time-of-Check Time-of-Use (TOCTOU) vulnerability in the validate_restricted_url function of the PrefectHQ prefect project. The vulnerability arises because the function initially resolves a hostname to an IP address and checks if it is private, but then passes the original hostname to the HTTP client, which re-resolves the DNS at connection time. This gap allows an attacker-controlled DNS server to return a public IP during validation and a private IP during the actual connection, bypassing Server-Side Request Forgery (SSRF) protections.

Additionally, the original function only checked the first DNS A record, allowing mixed public and private DNS responses to bypass validation. The vulnerability can be exploited remotely but requires high complexity and is considered difficult to exploit.

The fix involves hardening the validation function to check all resolved addresses, introducing protected HTTP transports that prevent DNS re-resolution by connecting directly to validated IPs, and updating webhook components to use these protections.


How can this vulnerability impact me? :

This vulnerability can allow an attacker to bypass SSRF protections and potentially make the application send requests to internal or private network resources that should be inaccessible. This could lead to unauthorized access to internal services, data leakage, or other security breaches within the network.

Because the attack exploits DNS rebinding and TOCTOU timing issues, it can be used to manipulate the target system into connecting to unintended internal IP addresses, which might expose sensitive information or allow further exploitation.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves a DNS rebinding Time-of-Check Time-of-Use (TOCTOU) bypass in the validate_restricted_url function, which is difficult to detect directly on a network or system due to its high complexity and the nature of DNS resolution timing.

Detection would involve monitoring for unusual DNS resolution patterns or unexpected DNS responses that switch between public and private IP addresses for the same hostname.

Since the vulnerability exploits DNS rebinding, you can use network tools to monitor DNS queries and responses, for example:

  • Use tcpdump or Wireshark to capture DNS traffic and look for multiple IP addresses returned for the same hostname within a short time frame.
  • Example tcpdump command: tcpdump -i any port 53 -w dns_capture.pcap
  • Use dig or nslookup repeatedly to query the hostname used by the Prefect webhook to see if DNS responses vary between public and private IPs.
  • Example dig command: dig example-hostname.com +short

However, no specific detection commands or tools are provided in the available resources or CVE description.


What immediate steps should I take to mitigate this vulnerability?

The primary and recommended mitigation step is to upgrade Prefect to version 3.6.28.dev2 or later, which includes the fix for this vulnerability.

The fix hardens the validate_restricted_url function to validate all resolved IP addresses and introduces protected HTTP transports that prevent DNS rebinding attacks by connecting directly to pre-validated IP addresses.

Upgrading ensures that the vulnerability is addressed by eliminating the time-of-check time-of-use window exploited by attackers.

No other immediate mitigation steps such as configuration changes or workarounds are mentioned in the provided resources.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided information does not include any details on how the CVE-2026-7724 vulnerability affects compliance with common standards and regulations such as GDPR or HIPAA.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart