Vulnerabilities

Vulnerability · GHSA-f278-mgc7-46j3

php_fastcgi authorization bypass via dot-segments in the request path

Published Nov 4, 2026 · catalog updated Nov 4, 2026 · php_fastcgi authorization bypass via

Last checked Nov 4, 2026. A connected source was read within the last 7 days.

Open the advisory

Exploitation likelihood is not on this record for GHSA-f278-mgc7-46j3. A missing EPSS score is not a low risk. Compare php_fastcgi authorization bypass via with the linked advisory before you change production.

Severity

Medium5.9

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Awaiting synchronization with FIRST

Remediation

Version ranges on file

Affected products

go github.com/caddyserver/caddy/v2

### Summary An unauthenticated attacker can execute a PHP script that a Caddyfile access-control rule was protecting. > Disclosure note: This finding was identified and validated by Bynario AI, an automated pipeline. The technical claims and supporting evidence were manually reviewed before submission. The technical report was partly written using AI and re-written by me. Caddy's route matchers evaluate the cleaned request path, while the FastCGI transport derives from the raw path. The two therefore disagree about which file a request names: the access-control decision is made about one file, and a different file is executed. **If there is no index.php file**, or is judged by every matcher as a request for . A or gate on , , or never fires while php-fpm is told to execute . No access-control configuration prevents this. The matcher only ever sees a string the attacker chooses fresh on every request, so no path rule can cover it. Where the attacker also controls a file on disk (e.g. an upload directory the operator deliberately excluded from PHP execution), this escalates from authorization bypass to remote code execution as the php-fpm user. ### Details expands to three routes ( output abbreviated): **Caddy never rewrites itself.** is applied only to matcher-local copies for their own yes/no decisions ( , ). The rewrite in route 2 is therefore the *only* step in the entire chain that normalizes the path the transport will later read. But as said, that part never happens, so transport will receive the entire raw path. **Bug 1: the transport splits an un-normalized path** fpath := r.URL.Path // raw; contains ".." as sent by the client ... if splitPos := t.splitPos(fpath); splitPos > -1 { docURI = fpath[:splitPos] pathInfo = fpath[splitPos:] scriptName = strings.TrimSuffix(scriptName, pathInfo) } scriptFilename := caddyhttp.SanitizedPathJoin(root, scriptName) returns the index past the end of the *first* token, so for is and pathInfo becomes . Both get sanitized, but