In Vinyl Cache before 9

Varnish Cache before 9.0.3 (and the Vinyl Cache fork before 9.0.1) mis-parses certain HTTP/2 request framings in a way that lets an attacker desync the backend connection. The classic CWE-444 outcome follows: a smuggled request rides a pooled backend connection, poisons the shared cache, bypasses VCL-enforced authorization, or captures another user's response. Affected: Varnish Cache 6.x–9.0.2 and Vinyl Cache <9.0.1, only when HTTP/2 is explicitly enabled via feature=+http2. Default builds ship with HTTP/2 disabled.

There is no NVD CVSS on this record yet; the vendor advisory (VSV00019) rates it CVSS 4.0 = 2.3 LOW. That is too generous. Cache poisoning and auth-bypass on an internet-facing edge cache is not a 2.3 event — a single poisoned response can burn every downstream user until TTL expires. But Varnish's vendor rating isn't crazy either: HTTP/2 is opt-in, and most Varnish deployments don't terminate TLS/H2 directly (a fronting NGINX/HAProxy/ATS usually does). MEDIUM is the honest floor.

Why this verdict

• HTTP/2 opt-in gate: exploitation requires feature=+http2, off by default; fleet-wide this eliminates 70–90% of Varnish installs from the attack surface.
• Fronted-edge topology: in production, Varnish typically sits behind Hitch/NGINX/HAProxy that terminate H2 and re-emit H1, sanitizing the smuggling primitive before it reaches Varnish.
• Role multiplier — caching tier: Varnish is (b) a typical application-tier component, not an identity or trust root. Worst realistic outcome is cache poisoning + VCL auth bypass on the affected vhost. No fleet compromise, no domain takeover, no supply-chain pivot — the HIGH floor does not trigger.
• No KEV, no PoC, EPSS 0.00317: background-level probability, no active campaigns.
• Impact is non-trivial when it lands: cache poisoning against a public edge can affect thousands of users per poisoned key until TTL expiry, and VCL-enforced auth bypass is a real chain step — this floors the verdict at MEDIUM, not LOW.

Why not higher?

HIGH would require either broad exposed population or a role-multiplier (identity, hypervisor, kernel-mode). Neither applies: H2 is off by default, most edges front-terminate H2 outside Varnish, and the blast radius is bounded to one caching layer. No KEV, no in-the-wild activity, no released PoC.

Why not lower?

LOW / IGNORE would misprice the impact: request smuggling against a public edge cache is a documented pathway to mass cache poisoning and auth bypass, and Varnish is widely deployed as an internet-facing accelerator. The vendor's 2.3 LOW rating undersells the outcome when H2 *is* turned on.

1. Disable HTTP/2 on Varnish until patched — Remove +http2 from the feature parameter (varnishd -p feature=-http2 ... or update your systemd/init unit and restart). This kills the vulnerable code path outright. If HTTP/2 is required end-to-end, terminate H2 at a fronting NGINX/Hitch and re-emit HTTP/1.1 to Varnish. Deploy within the noisgate MEDIUM window — no mitigation SLA, but treat as same-week hygiene if H2 is on and internet-facing.
2. Disable backend connection reuse — Set backend.between_bytes_timeout low and Connection: close on backend responses via VCL (set beresp.http.Connection = "close"; in vcl_backend_response). Breaks the pooled-connection primitive smuggling depends on. Ship in the same change window as the H2 disable.
3. Add H2 downgrade normalization at the WAF/edge — Cloudflare, Akamai, F5 ASM 17+, and Imperva have H2-smuggling rules that reject malformed header frames before they reach Varnish. Enable strict H2 validation mode on your WAF. Cheap insurance while you schedule the vendor patch.
4. Move VCL-enforced auth to the backend — Any authorization decision made in vcl_recv is bypassable by a smuggled request. If you use VCL for auth, replicate the check at the backend app tier immediately — this is durable defense against this bug class, not just this CVE.

Run this on each Varnish host as root (needs to read varnishadm state). Invoke as sudo ./check-cve-2026-50052.sh. It checks the installed Varnish version and whether +http2 is active in the running feature set. Exit 2 = VULNERABLE, 0 = PATCHED, 1 = UNKNOWN.

#!/usr/bin/env bash
# noisgate check for CVE-2026-50052 (Varnish HTTP/2 request smuggling, VSV00019)
# Usage: sudo ./check-cve-2026-50052.sh
set -u

FIXED_VARNISH="9.0.3"
FIXED_VINYL="9.0.1"

ver_lt() {
  # returns 0 if $1 < $2 using sort -V
  [ "$1" = "$2" ] && return 1
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

if ! command -v varnishd >/dev/null 2>&1; then
  echo "UNKNOWN: varnishd not found on PATH"
  exit 1
fi

RAW=$(varnishd -V 2>&1 | head -n1)
# Examples: "varnishd (varnish-8.0.1 revision ...)" or "varnishd (vinyl-9.0.0 ...)"
PRODUCT="varnish"
if echo "$RAW" | grep -qi vinyl; then PRODUCT="vinyl"; fi
VER=$(echo "$RAW" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)

if [ -z "$VER" ]; then
  echo "UNKNOWN: could not parse version from: $RAW"
  exit 1
fi

FIXED=$FIXED_VARNISH
[ "$PRODUCT" = "vinyl" ] && FIXED=$FIXED_VINYL

VERSION_VULN=0
if ver_lt "$VER" "$FIXED"; then VERSION_VULN=1; fi

# Check if HTTP/2 is enabled in the running feature set
H2_ON=0
if command -v varnishadm >/dev/null 2>&1; then
  FEAT=$(varnishadm param.show feature 2>/dev/null | tr -d ' ')
  if echo "$FEAT" | grep -q 'http2'; then H2_ON=1; fi
else
  # fall back to the service unit / config
  if pgrep -af varnishd | grep -qE 'feature=[^ ]*\+http2'; then H2_ON=1; fi
fi

if [ "$VERSION_VULN" -eq 1 ] && [ "$H2_ON" -eq 1 ]; then
  echo "VULNERABLE: $PRODUCT $VER < $FIXED AND +http2 is enabled"
  exit 2
elif [ "$VERSION_VULN" -eq 1 ] && [ "$H2_ON" -eq 0 ]; then
  echo "PATCHED (mitigated): $PRODUCT $VER < $FIXED but +http2 disabled — still upgrade"
  exit 0
else
  echo "PATCHED: $PRODUCT $VER >= $FIXED"
  exit 0
fi

Sources

1. Varnish Software advisory VSV00019
2. Varnish Cache upstream security page
3. SUSE CVE-2026-50052 record
4. CIRCL Vulnerability-Lookup CVE-2026-50052
5. THREATINT CVE-2026-50052
6. detectify/Varnish-H2-Request-Smuggling (prior-art tooling)
7. Historical VSV00007 Varnish HTTP/2 smuggling
8. CWE-444 Inconsistent Interpretation of HTTP Requests