Which versions of V (vlang) are affected by CVE-2026-67201?

The V programming language standard library (versions through 0.5.2) contains an allowlist bypass vulnerability enabling unauthenticated remote attackers to access internal network services that…. A patch is available.

Is there a public PoC exploit available for CVE-2026-67201?

Yes, a public proof-of-concept exploit is available for CVE-2026-67201. Prioritise patching immediately. EPSS: 0.4%.

How to fix or mitigate CVE-2026-67201?

Within 24 hours, identify and document all systems and applications deployed with V programming language version 0.5.2 or earlier. Within 7 days, apply the vendor patch by upgrading V to a patched version and redeploy all affected applications, prioritizing internet-facing services. Within 30 days, conduct a comprehensive review of internal service access logs during the vulnerability window to determine if exploitation occurred, validate that URL parsing and allowlist enforcement are functioning correctly post-patch, and reassess internal network segmentation controls.

V (vlang) CVE-2026-67201

Q: What is the CVSS score of CVE-2026-67201?

CVE-2026-67201 has a CVSS 4.0 base score of 7.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

EUVD-2026-50446 HIGH

Interpretation Conflict (CWE-436)

2026-07-29 VulnCheck

GHSA-mvrj-5wv7-cfg9

SSRF Red Hat Suse

7.7

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

7.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.6 HIGH

Remote, unauthenticated, low-complexity SSRF bypass with no direct impact on the app but scope change (S:C) granting high confidentiality access to internal systems; no integrity/availability impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N

SUSE

HIGH

qualitative

Red Hat

8.6 HIGH

qualitative

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 29, 2026 - 18:51 vuln.today

Analysis Generated

Jul 29, 2026 - 18:51 vuln.today

CVE Published

Jul 29, 2026 - 18:12 cve.org

HIGH 7.7

DescriptionCVE.org

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.

AnalysisAI

Server-side request forgery allowlist bypass in the V programming language standard library (net.urllib / net.http) through version 0.5.2 lets remote unauthenticated attackers reach internal network services that a host-based allowlist was meant to block. The flaw stems from a parser differential: net.urllib.parse() and net.http.get() disagree on how a backslash in a URL's authority is handled, so validation and connection resolve to different hosts. Publicly available exploit code exists and the issue was reported by VulnCheck, though it is not listed in CISA KEV (no public evidence of active exploitation at time of analysis).

Technical ContextAI

The vulnerability lives in V's built-in networking modules - net.urllib (URL parsing/validation) and net.http (HTTP client). Applications commonly parse an attacker-supplied URL, extract the host with urllib.parse(), check it against an allowlist, then fetch it with http.get(). The root cause is CWE-436 (Interpretation Conflict / parser differential): a URL such as http://trusted.host\@internal.target/ is interpreted by urllib.parse() as having authority 'trusted.host' (treating the backslash as part of/terminating the host so the allowlist sees the trusted value), while net.http normalizes the backslash to a forward slash per browser-style WHATWG behavior and instead connects to 'internal.target'. The two components thus resolve different destinations from the same input string. The upstream fix (commit 85859f0, PR #27947) makes urllib treat backslash as an invalid character in the authority - should_escape and valid_userinfo no longer whitelist '\\', and the parser now rejects backslashes in the host (regression tests test_parse_rejects_backslash_in_authority) - so parsing fails rather than silently disagreeing with net.http.

RemediationAI

Upstream fix available (commit 85859f0 / PR #27947); a released, tagged patched version is not independently confirmed from the provided data, so update V to a build that includes commit 85859f0f3498d4091b38009c45ed390a97eeedc2 (verify against the vlang release notes) - see https://github.com/vlang/v/commit/85859f0f3498d4091b38009c45ed390a97eeedc2. Until you can rebuild against a patched compiler/stdlib, defend at the application layer: reject any URL whose authority contains a backslash before validation, and - more robustly - resolve the destination host once and pass that exact resolved value to net.http rather than re-deriving it, so the same host is used for both allowlist checks and the connection (eliminating the parser differential). As network-side compensating controls, enforce egress filtering from the V service so it cannot reach internal/link-local ranges (e.g. block 169.254.0.0/16, 127.0.0.0/8, RFC1918) at the firewall, and route outbound fetches through a forward proxy that independently enforces the allowlist; note these controls add latency and operational overhead and do not fix the underlying library disagreement.