CVE-2026-67201 in vlang
Summary
by MITRE • 07/29/2026
V through 0.5.2, fixed in commit 85859f0, contains a server-side request forgery (SSRF) bypass vulnerability that allows attackers to circumvent host-based allowlists by exploiting a parser differential between net.urllib and net.http. Attackers can craft a URL containing a backslash in the authority section such that net.urllib.parse() extracts the trusted host for allowlist validation while net.http.get() normalizes the backslash and connects to the internal host, enabling access to internal network services that the allowlist was intended to block.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/29/2026
This vulnerability exists within versions 0.5.2 and earlier of a software component where a server-side request forgery flaw allows attackers to bypass host-based allowlists through a parser differential between net.urllib and net.http modules. The issue stems from inconsistent URL parsing behavior where net.urllib.parse() correctly identifies the trusted host for validation purposes while net.http.get() normalizes backslash characters in the authority section, ultimately connecting to an internal host that would otherwise be blocked by the allowlist. The vulnerability specifically exploits the backslash character within the URL authority section to create a discrepancy between parsing and connection behavior.
The technical implementation of this flaw relies on crafting malicious URLs containing backslashes in the host portion that appear legitimate to the validation logic but are processed differently during actual network operations. When net.urllib.parse() processes the URL, it extracts what appears to be a trusted domain for allowlist verification, but the subsequent net.http.get() operation normalizes the backslash character and establishes a connection to an internal service that was not intended to be accessible through the allowlist mechanism. This differential parsing creates a pathway for attackers to access internal network resources that should remain protected behind the host-based restrictions.
From an operational perspective, this vulnerability enables attackers to bypass security controls designed to restrict outbound connections to specific hosts or networks. The impact extends beyond simple information disclosure as it allows for potential exploitation of internal services that may contain sensitive data, administrative interfaces, or systems with elevated privileges. Attackers can leverage this bypass to enumerate internal network topology, access restricted APIs, or potentially escalate privileges through exploitation of vulnerable internal services that would normally be blocked by the allowlist protections.
The vulnerability aligns with CWE-918 Server-Side Request Forgery and maps to ATT&CK technique T1071.004 Application Layer Protocol: DNS where attackers manipulate URL parsing to bypass network restrictions. Organizations implementing host-based allowlists using this vulnerable software component face significant risk as the bypass mechanism allows attackers to access internal services without proper authorization, potentially leading to full network compromise. The attack vector requires careful URL construction but can be automated once the vulnerability is understood, making it particularly dangerous in environments where such allowlists are critical security controls.
Recommended mitigations include upgrading to version containing commit 85859f0 which addresses the parser differential, implementing additional validation layers beyond simple host-based allowlists, and employing more robust URL parsing that normalizes all characters consistently across different modules. Organizations should also consider implementing network segmentation, using dedicated proxy servers with proper URL validation, and monitoring for anomalous outbound connection patterns that may indicate exploitation attempts. Additional controls such as request/response inspection at the application level and implementation of more comprehensive security policies beyond simple host allowlists would provide layered protection against similar vulnerabilities in the future.