Lack of data validation - Type confusion In caddy

Description

Caddy: MatchPath %xx (escaped-path) branch skips case normalization, enabling path-based route/auth bypass

Summary

Caddy's HTTP path request matcher is intended to be case-insensitive, but when the match pattern contains percent-escape sequences (%xx) it compares against the request's escaped path without lowercasing. An attacker can bypass path-based routing and any access controls attached to that route by changing the casing of the request path.

Details

In Caddy v2.10.2, MatchPath is explicitly designed to be case-insensitive and lowercases match patterns during provisioning:

    modules/caddyhttp/matchers.go: rationale captured in the MatchPath comment.

    MatchPath.Provision lowercases configured patterns via strings.ToLower.

    MatchPath.MatchWithError lowercases the request path for the normal matching path: reqPath := strings.ToLower(r.URL.Path).

But when a match pattern contains a percent sign (%), MatchPath.MatchWithError switches to "escaped space" matching and builds the comparison string from r.URL.EscapedPath():

    reqPathForPattern := CleanPath(r.URL.EscapedPath(), mergeSlashes)

    If it doesn't match, it continues (skipping the remaining matching logic for that pattern).

Because r.URL.EscapedPath() is not lowercased, case differences in the request path can cause the escaped-space match to fail even though MatchPath is meant to be case-insensitive. For example, with a pattern of /admin%2Fpanel:

    Requesting /admin%2Fpanel matches and can be denied as intended.

    Requesting /ADMIN%2Fpanel does not match and falls through to other routes/handlers.

Suggested fix

    In the %-pattern matching path, ensure the effective string passed to path.Match is lowercased (same as the normal branch).

      Simplest seems to lowercase the constructed string in matchPatternWithEscapeSequence right before path.Match.

Reproduced on:

    Stable release: v2.10.2 -- this is the release referenced in the reproduction below.

    Dev build: v2.11.0-beta.2.

    Master tip: commit 58968b3fd38cacbf4b5e07cc8c8be27696dce60f.

PoC

Prereqs:

    bash, curl

    A pre-built Caddy binary available at /opt/caddy-2.10.2/caddy (edit CADDY_BIN in the script if needed)

Script (Click to expand)
#!/usr/bin/env bash
set -euo pipefail

CADDY_BIN="/opt/caddy-2.10.2/caddy"
HOST="127.0.0.1"
PORT="8080"

TMPDIR="$(mktemp -d)"...
Expected output (Click to expand)
== Caddy version ==
v2.10.2 h1:g/gTYjGMD0dec+UgMw8SnfmJ3I9+M2TdvoRL/Ovu6U8=

== Caddyfile ==
{
    debug
}
...

Impact

This is a route/auth bypass in Caddy's path-matching logic for patterns that include escape sequences. Deployments that use path matchers with %xx patterns to block or protect sensitive endpoints (including encoded-path variants such as encoded slashes) can be bypassed by changing the casing of the request path, allowing unauthorized access to sensitive endpoints behind Caddy depending on upstream configuration.

The reproduction is minimal per the reporting guidance. In a realistic "full" scenario, a deployment may block %xx variants like path /admin%2Fpanel, otherwise proxying. If the backend is case-insensitive/normalizing, /ADMIN%2Fpanel maps to the same handler; Caddy’s %-pattern match misses due to case, so the block is skipped and the request falls through.

AI Use Disclosure

A custom AI agent pipeline was used to discover the vulnerability, after which was manually reproduced and validated each step. The entire report was ran through an LLM to make sure nothing obvious was missed.

Disclosure/crediting

Asim Viladi Oglu Manizada

Mitigation

Update Impact

Minimal update. May introduce new vulnerabilities or breaking changes.

Ecosystem
Package
Affected version
Patched versions