GHSA-wwhq-w58m-w29c

# ## TL;DR CVE-2026-30852 fixed double expansion in `vars_regexp` when the variable key is a placeholder (e.g. `{http.vars.x}`). The fix does NOT protect literal key names (e.g. `tenant_id`). An attacker injects `{env.AWS_SECRET_ACCESS_KEY}` or `{file./etc/passwd}` via a request header → Caddy expands it on the second pass → secrets leaked in response headers. **Affected:** Caddy v2.11.0 through v2.11.2 (latest). All versions since the CVE-2026-30852 fix. ## Root Cause `modules/caddyhttp/vars.go`, lines 215-217: ```go valExpanded = varStr if !fromPlaceholder { valExpanded = repl.ReplaceAll(varStr, "") // ← SECOND EXPANSION } ``` Same issue at line 358-360 in `MatchVarsRE`. `fromPlaceholder` is `false` when the variable key is a literal string (not wrapped in `{}`). The fix only protects `fromPlaceholder=true`. ### Expansion chain: 1. Config: `vars tenant_id {http.request.header.X-Tenant-ID}` 2. Request header: `X-Tenant-ID: {env.SECRET}` 3. **Pass 1** (`VarsMiddleware.ServeHTTP`, line 63): `repl.ReplaceAll("{http.request.header.X-Tenant-ID}", "")` → resolves to literal string `{env.SECRET}`. Stored in vars map. 4. **Pass 2** (`VarsMatcher.MatchWithError`, line 217): `repl.ReplaceAll("{env.SECRET}", "")` → resolves to the actual secret value. 5. Leaked value reflected in response header `X-Tenant-ID` or forwarded to backend via `reverse_proxy`. ## Impact - **Environment variable disclosure:** `{env.AWS_SECRET_ACCESS_KEY}`, `{env.DATABASE_URL}`, etc. - **Arbitrary file read (up to 1MB):** `{file./etc/passwd}`, `{file./proc/self/environ}` - **System info:** `{system.hostname}`, `{system.os}` - **Full env dump in one request:** `{file./proc/self/environ}` ## Realistic Attack Scenario API gateway pattern - Caddy captures a tenant ID header, validates it with `vars_regexp`, and reflects it in response headers or forwards to a backend. This is a common production pattern for multi-tenant routing. ``` # Caddyfile :8080 { vars tenant_id {http.request