CVE-2026-52845

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

No known exploitation. EPSS puts it in the 38th percentile. Fixed in 2.11.4.

CVSS 3.18.1High EPSS percentile38th0.4% chance in 30 days CISA KEVNot listedNo confirmed exploitation
No public exploit known Fix2.11.4Upgrade to this build

Published 2026-06-23Updated 2026-07-15Sources: CVE.org, NVD

NVD CVE.org

What to do

Find your product and version, then upgrade to the build on the right.

Caddyserver CaddyAffected: < 2.11.4Upgrade to: 2.11.4Stated by: NVD

Versions as the sources state them. Full version matrix after sign-in

Steps

Written by AI from the record

Check your Caddy version and whether you use forward_auth with copy_headers alongside a FastCGI backend (for example, PHP-FPM).
If you are on Caddy before 2.11.4 and the setup matches, plan an upgrade to Caddy 2.11.4.
If upgrading is delayed, remove or disable forward_auth copy_headers for identity/group header forwarding until you can upgrade.

May need vendor or contractor work

Check it yourselfA free OpenVAS check exists for this CVE. Run it against your hosts.Is your organisation exposed?Request an assessment to establish which checks fit your systems.

What it is

From the CVE record

Caddy is an extensible server platform that uses TLS by default. Prior to 2.11.4, forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _. This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable. Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy. This vulnerability is fixed in 2.11.4.

In plain language

Written by AI from the record

Caddy versions before 2.11.4 can let a visitor smuggle fake identity or group information to backend FastCGI apps (like PHP-FPM); if you use forward_auth with copy_headers, you should act now.

In Caddy (pre-2.11.4), `forward_auth` `copy_headers` can be bypassed via FastCGI header normalization (underscore handling), allowing a remote client to inject/override identity/group headers that the FastCGI application trusts.

If you're affected

User identity spoofing
Unauthorized account access
Sensitive user data exposure
Privilege escalation risk

What is it

Caddy can use an authentication step and then “forward” specific identity details to your backend app. This bug is like having a doorman who checks a badge in one hallway, but later an attacker finds a shortcut that turns a fake label into something the backend treats as real—so the backend may believe the wrong user or group.

Who is affected

This matters if you run Caddy and configure forward_auth with copy_headers, and your backend is a FastCGI application (commonly PHP-FPM). If all three are true and your Caddy is older than 2.11.4, a remote visitor can potentially inject or override identity/group headers that the backend trusts. This is only a risk when the vulnerable functionality is reachable over the network (and the setup routes requests through forward_auth to the FastCGI backend).

How urgent is it

This is an Amber issue because it can lead to identity and group header injection into backend FastCGI apps, which can directly enable unauthorized access. While no public exploit is on record and it’s not listed in CISA KEV, the vulnerability is reachable remotely and does not require user interaction, so you should prioritize upgrading.

What to do — in detail

Confirm exposure
- Identify your Caddy version.
  - If it is earlier than 2.11.4, you meet the version condition.
- Review your Caddy configuration for forward_auth.
  - Confirm copy_headers is enabled under forward_auth.
- Confirm your backend chain includes FastCGI.
  - Look for FastCGI routing to something like PHP-FPM.
- If all of the above are true, treat your setup as exposed.
Apply the fix
- Upgrade Caddy to 2.11.4.
- If you have multiple Caddy instances, upgrade them all (including any behind load balancers).
If you can’t upgrade immediately (workaround)
- Temporarily disable or remove forward_auth copy_headers so Caddy does not forward identity/group headers from the auth flow via this mechanism.
- Keep forward_auth itself only if your backend still receives trusted identity details through a safer path.
Validate after change
- Re-check that requests still authenticate correctly.
- Confirm that identity/group information used by your FastCGI app comes only from the trusted auth gateway (and not from client-controlled headers).
Monitor
- Watch for authentication anomalies (unexpected logins, users appearing in wrong groups) and errors related to auth header parsing in your FastCGI app after deployment.

Technical context

Severity is High (CVSS 8.1) and the vulnerability is in Caddy’s forward_auth copy_headers behavior before 2.11.4. Mechanism: a remote client can send HTTP headers using underscore variants that survive Caddy’s forward_auth filtering/deletion and later normalize into the same CGI/FastCGI environment variables (where headers are mapped by converting - to _). Weaknesses map to CWE-287 (improper authentication/authorization handling), CWE-290 (improper integrity of client-controlled inputs), and CWE-444 (unverified data leading to security issues). Preconditions from the findings: Caddy < 2.11.4; forward_auth configured with copy_headers; and a FastCGI backend (e.g., PHP-FPM). Exploitation status: no KEV entry and no public exploit code on record; exploitation likelihood is predicted low (EPSS is noted as low in the findings) and the traffic light verdict is AMBER. Patch info: fixed in 2.11.4, and the findings also state no separate patch/package instructions beyond upgrading the Caddy version.

This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS38th

CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.4% chance of exploitation activity in the next 30 days, which ranks it in the 38th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

6 events over 22 days, from the signal feeds we watch.

2026-07-15Record updated
2026-07-01OpenVAS check added
2026-06-30Record updated
2026-06-23Publishedweakness classified, att&ck mapped

Affected products

caddyserveross-projectaka caddy
- caddyOn-premNetworking Infrastructure / load-balancer-proxy

Technical detail

CVSS 3.1 vector

Open in the CVSS calculator

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

Scored 8.1 by NVD.

How it is reached

Attack Vector NetworkExploitable remotely over the network without any special conditions
Attack Complexity LowNo special conditions — the attack can be reliably reproduced
Privileges Required LowRequires basic user-level privileges
User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

Confidentiality HighTotal information disclosure — all data in the component is compromised
Integrity HighTotal loss of integrity — attacker can modify any data in the component
Availability NoneNo availability impact