CVE-2026-77972 in safeurl
Summary
by MITRE • 09/15/2026
Time-of-check Time-of-use (TOCTOU) Race Condition in Slab safeurl allows an attacker who controls a hostname's DNS responses to reach internal network destinations that validation rejected.
Validation returns a verdict and not the address it approved, so the HTTP clients the library ships receive the original hostname and resolve it a second time when the request is made. An attacker who controls the authoritative DNS for a name can answer the first lookup with a permitted address and the second with a blocked one, and the request then reaches a destination validation never approved. The same window opens without an attacker whenever a name legitimately resolves to different addresses across lookups, such as short record lifetimes or rotation between several addresses.
This issue affects safeurl: from 0.1.0 onward.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in the Slab safeurl library represents a classic Time-of-Check-Time-of-Use (TOCTOU) race condition that undermines network security controls designed to prevent access to unauthorized internal or malicious destinations. This flaw is rooted in the architectural design of how validation verdicts are handled versus actual address resolution during HTTP request execution. When an application utilizes this library, it typically performs a preliminary check against a hostname to determine if the destination is permitted by policy. The core technical deficiency lies in the fact that the validation mechanism returns only a boolean verdict indicating whether the name is allowed or denied, rather than returning the specific IP address that was evaluated and approved during that initial check. Consequently, when the actual HTTP client proceeds to make the network request, it must resolve the hostname again from scratch using standard DNS resolution mechanisms. This creates a critical temporal gap between the security decision point and the operational execution of the network call.
An attacker who controls or can manipulate the authoritative Domain Name System (DNS) records for a target hostname can exploit this window to bypass validation restrictions. By responding to the initial lookup with an IP address that is explicitly permitted by the safeurl policy, the validator approves the request based on that specific address. However, before the HTTP client completes its second DNS resolution required to establish the actual connection, the attacker modifies the DNS response or relies on a rapid change in records to return a different IP address—one that points to an internal network resource or a malicious server that was not approved by the policy. Because the library does not cache and enforce the specific resolved address from the validation step but instead allows the client to re-resolve the name, the request is successfully routed to the unapproved destination. This effectively nullifies the security boundary intended by the safeurl configuration, allowing unauthorized lateral movement or data exfiltration to restricted network segments.
The impact of this vulnerability extends beyond scenarios involving active attacker manipulation. The race condition can also be triggered legitimately under normal operational conditions where DNS records exhibit high volatility. For instance, if a hostname has very short Time-to-Live (TTL) values configured on its DNS records, or if the service employs round-robin DNS rotation across multiple IP addresses to balance load, there is an inherent risk that the address resolved during validation differs from the address used during connection establishment. In such cases, even without malicious intent, a request might inadvertently reach a backend server instance that was not part of the validated set, potentially exposing internal services or violating compliance requirements regarding network segmentation and access control. This highlights how dynamic DNS behaviors can introduce security gaps in applications relying on hostname-based validation rather than strict IP allowlisting.
From a classification perspective, this vulnerability aligns with CWE-367, which defines Time-of-check Time-of-use (TOCTOU) race conditions as errors that occur when the status of an object is checked and then used without ensuring that it has not changed in between. Furthermore, within the MITRE ATT&CK framework, this behavior facilitates techniques associated with Discovery and Lateral Movement, specifically allowing an adversary to probe internal network structures or access resources outside their intended scope by bypassing perimeter controls. The exploitation of DNS resolution inconsistencies is a known tactic for evading security monitoring and policy enforcement mechanisms in enterprise environments.
To mitigate this vulnerability, the primary remediation strategy involves modifying the validation logic within the safeurl library to enforce strict address binding rather than hostname-based permission checks. Instead of returning a simple verdict based on the initial lookup, the function should resolve the hostname once during the check phase and return both the approval status and the specific IP address that was validated. The HTTP client must then be required to use this pre-resolved IP address for the actual connection attempt, thereby eliminating the possibility of DNS rebinding or race condition exploitation. Alternatively, applications can implement additional safeguards such as disabling automatic hostname resolution in favor of explicit IP configuration where possible, or employing a dedicated proxy layer that performs deep packet inspection and enforces strict source-destination mapping rules independent of application-level validation logic. Updating to a patched version of the library that addresses this architectural flaw is essential for maintaining the integrity of network security policies relying on safeurl functionality.