CVE-2026-34475 is a medium severity (CVSS 5.4) URL handling flaw in Varnish Cache and Varnish Enterprise, which can lead to cache poisoning or authentication bypass. Fixed releases are Varnish Cache 8.0.1, 6.0.17 and Enterprise 6.0.16r12. A VCL snippet mitigates it.
What's affected
The project's advisory VSV00018 lists as affected all Varnish Cache releases up to and including 8.0.0, the 6.0 LTS series up to and including 6.0.16, and Varnish Enterprise 6.0.x up to and including 6.0.16r11.
Not affected: Vinyl Cache 9.0 (released 2026-03-16), Varnish Cache 8.0.1 (2026-03-16), Varnish Cache 6.0 LTS version 6.0.17 (2026-03-16), and Varnish Enterprise 6.0.16r12 or later.
The advisory title calls it an absolute form parsing deficiency. The record describes URLs with a path of / for HTTP/1.1 being mishandled in certain cases where req.url is unchecked.
How to check if you're exposed
varnishd -V
Compare the output with the lists above. Then read your VCL for places that use req.url for routing, caching or access decisions without checking its form. Those are the setups where mishandling matters.
If Varnish sits behind a CDN or load balancer, check whether that layer normalizes request URLs before they reach Varnish. A front layer that rejects absolute-form targets lowers your exposure, though you should still update.
What to do now
- Check each Varnish instance's version.
- Upgrade to 8.0.1, 6.0.17, Enterprise 6.0.16r12, or Vinyl Cache 9.0 or later.
- If you cannot upgrade, add the advisory's VCL mitigation at the top of your VCL.
- Purge caches after the change if you suspect poisoned entries.
- Review VCL logic that makes access decisions based on the URL.
Why it matters
The weakness is CWE-180, validation before canonicalization. When the cache and the origin disagree on what a URL means, a request can be cached under one meaning and served under another.
The advisory's mitigation, to be placed at the top of the VCL, lets only an OPTIONS request with * and CONNECT through with a non-slash URL start, and rejects other requests whose URL does not begin with a slash using a 400 response:
sub vsv18 {
if (req.url == "*" && req.method == "OPTIONS") { return; }
if (req.url !~ "^/" && req.method != "CONNECT") { return (synth(400)); }
}
sub vcl_recv { call vsv18; }
The advisory says the same check is now in the built-in VCL. The record does not mark this CVE as exploited, and it is not on the CISA KEV list.
The CVSS vector has high attack complexity and changed scope, which fits the pattern: the weakness needs particular VCL and request shapes, but the effect crosses from the cache to users of the origin. For a cache that fronts logins or personalized pages, the impact is larger than the medium score suggests.
Cache poisoning is hard to see from the outside, so check what your cache holds as well as what it accepts. Look at the hit rates and the objects for the root path, and purge them after the upgrade. If you run several tiers, update the edge first, since it is the layer that sees raw client requests, then move inward. Test with a staging instance before you change production VCL.
Quick check
Do I have to upgrade if I add the VCL snippet?
The advisory offers it as a mitigation when upgrading is not possible. Upgrading is still the lasting fix.
Sources
Last reviewed: 19 October 2026.
