caddyserver Caddy FastCGI path-splitting flaw enables execution of non-PHP files

Caddy is an extensible server platform that uses TLS by default. From 2.7.0 until 2.11.3, the FastCGI transport's splitPos() in modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go misuses golang.org/x/text/search with search.IgnoreCase when the request path contains a non-ASCII byte. Two distinct flaws in that fallback let an attacker mislead Caddy's FastCGI splitting into treating a non-.php (or other configured split_path extension) file as a script. In any deployment where the attacker can place content into a file served via FastCGI (uploads, file storage, etc.), this can be escalated to remote code execution by crafting a URL whose path triggers either flaw. This vulnerability is fixed in 2.11.3.

• The normalized record identifies caddyserver Caddy >= 2.7.0, < 2.11.3 as affected.
• The vendor advisory instead lists >= 2.7.0, <= 2.10.2 as affected and identifies v2.11.3 as patched.
• These sources conflict about the status of 2.11.0 through 2.11.2; it is not safe to infer that this interval is unaffected from only one source. Deployments within the normalized range should be reviewed and handled until caddyserver clarifies the discrepancy.

Caddy's FastCGI transport uses golang.org/x/text/search with search.IgnoreCase in splitPos() when a request path contains a non-ASCII byte. The fallback has two flaws: one path can retain a stale successful-match state after encountering a non-ASCII byte, while Unicode case folding can treat ASCII lookalikes as a valid configured extension. Caddy can therefore calculate the FastCGI split position incorrectly and treat a file without .php, or without another configured split_path extension, as a script. The key precondition is that an attacker can place content in a file served through FastCGI, such as through an upload feature or user-content store, and then send a network request with a path that triggers the flaw. The vendor states that valid SplitPath entries are ASCII-only and lower-cased, but the Unicode fallback bypassed that constraint. The specific FastCGI application, process privileges and file-storage layout remain deployment-dependent.

The flaw is remotely reachable over the network when Caddy handles a route using FastCGI and split_path. The supplied data indicates that authentication is not required and no user interaction is needed, but the need to place content in a file and construct a matching path makes exploitation high complexity. The vendor advisory includes a public reproducer for both flaws, so technical exploitation details are publicly available. The supplied record does not establish whether exploitation has occurred in real-world deployments.

The flaw can make Caddy route a non-script file to the FastCGI upstream as a script, potentially resulting in arbitrary code execution in the upstream process. Technical consequences may include reading data, modifying data or disrupting services within that process's privileges. Code execution does not by itself prove full host compromise; process privileges, sandboxing, container boundaries and file-system permissions remain important limits. The risk requires both the ability to place content in a file served through FastCGI and the ability to send a path that triggers the parsing flaw.

If an upload endpoint, file store or user-content store permits files to be written into a location served through FastCGI, attacker-controlled content may be converted into server-side code execution. Possible consequences include loss of confidentiality for data accessible to the FastCGI process, modification of application content or configuration, and service disruption. The actual business exposure depends on the FastCGI account's privileges, the data reachable by the upstream and the isolation of upload directories. The record provides no evidence naming a victim, campaign or specific breach.

1. Upgrade Caddy to the vendor's patched release 2.11.3. Do not treat this statement as verification that every later or parallel release branch has been assessed in this record.
2. Because the normalized affected range and the vendor advisory differ, reconcile the installed version with caddyserver release information before closing an exposure, especially for 2.11.x releases before 2.11.3.
3. Until patched, prevent untrusted users from writing files into directories served through FastCGI and separate upload or file-storage areas from locations that can be resolved as scripts.
4. Review routes using split_path and, where the architecture permits, disable or remove FastCGI handling for content that does not need it.
5. After updating, verify that every Caddy node, container and binary serving the application runs the patched release. Updating only one reverse proxy in a cluster is not sufficient if other nodes remain exposed.

1. Inventory systems running Caddy and compare deployed versions with the affected branches recorded for the deployment.
2. Identify configurations using FastCGI, especially routes with split_path and backends such as PHP-FPM or comparable FastCGI applications.
3. Determine whether untrusted users or services can write files into directories that FastCGI may process as scripts, including upload directories, file stores and user-content stores.
4. Review access logs and upstream logs, where available, for requests containing non-ASCII bytes in paths reaching FastCGI or requests that cause unusually named files to be processed as scripts. This is precautionary monitoring, not a vendor-confirmed indicator.
5. Correlate file-system changes and upload activity with unexpected FastCGI execution. The absence of suspicious events does not prove that a system is safe.