CVE-2026-77281: Rewrite Placeholder Re-expansion Vulnerability in Caddy Web Server

Caddy is an extensible web server written in Go that relies on a structured modular architecture to process incoming HTTP traffic. A core mechanism within this architecture is the Replacer, which dynamically evaluates variable placeholders wrapped in curly braces. This mechanism is frequently used in routing configurations, reverse proxy operations, and rewrite directives to interpolate properties such as request headers, client IP addresses, or environment variables. This dynamic substitution provides administrators with configuration flexibility but also expands the attack surface if user-controlled input flows into the evaluation context.

The vulnerability classified as CVE-2026-77281 resides specifically within the request rewrite processing logic, implemented in modules/caddyhttp/rewrite/rewrite.go. Under typical operations, a rewrite directive modifies the URI of an active request before sending it to downstream handlers. When the rewrite rules utilize client-controlled variables, such as values parsed directly from incoming HTTP headers, Caddy is designed to perform a single substitution pass. However, a structural logic error allows an attacker to bypass this boundary.

By manipulating input headers and exploiting specific rewrite configurations that terminate with a literal question mark, an attacker can coerce the rewrite engine into performing a secondary evaluation pass. This secondary pass treats the resolved string as executable placeholder syntax rather than safe, static text. Consequently, any nested template token injected by the client is processed by the internal evaluation system. The primary impact of this flaw is unauthorized information disclosure, enabling attackers to leak cryptographic secrets, environment variables, or local files.

The root cause of CVE-2026-77281 is a double-evaluation flaw inside the query parameter separation logic of Caddy's rewrite module. When Caddy processes a rewrite directive, it initializes the Replacer engine to evaluate all defined placeholders. This step converts configuration parameters like {http.request.header.X-Fwd} into their literal string representations. If the rewrite path template terminates with a literal question mark, Caddy's parser performs a string-split operation to isolate the path from the query string.

The split mechanism is designed to handle rewrites where query parameters must be appended or overwritten. When a literal question mark is found, the parser divides the intermediate, post-evaluation URI into two distinct string variables: newPath and injectedQuery. If the configuration did not explicitly define an independent query string, the handler assigns the extracted injectedQuery to the request's internal query variable. This state transition is critical because the newly isolated query string contains raw, un-sanitized client input that has already undergone the first phase of template resolution.

Because of this architectural routing, the extracted query variable is subsequently passed to the buildQueryString function. The primary implementation defect exists here: buildQueryString executes a secondary ReplaceAll call on the query parameters. This secondary evaluation pass operates under the assumption that the input contains un-evaluated configuration-level placeholders. In reality, because of the split operation, the input now contains string content originating from the client, including any curly brace delimiters. Consequently, the Replacer parses these delimiters and evaluates the contained instructions.

To understand the technical flow, it is helpful to analyze the structural changes applied to modules/caddyhttp/rewrite/rewrite.go. In the vulnerable implementation, the split output was directly assigned to the query variable without modification. The following code comparison highlights the vulnerability and the subsequent sanitation logic introduced in the fix.

// Vulnerable Implementation
newPath, injectedQuery = before, after
if query == "" {
    query = injectedQuery
}

In this state, any opening and closing curly braces present within injectedQuery remained unchanged. When query was evaluated in the downstream function, these characters triggered the Replacer's parser, which extracted the inner key and looked it up against registered system providers. The patched version mitigates this behavior by performing a global string replacement on the extracted substring before assigning it to the query variable.

// Patched Implementation (Caddy v2.11.4)
newPath, injectedQuery = before, after
if query == "" {
    // The injected query came from the first-pass placeholder
    // expansion above, which means any '{' or '}' bytes in it
    // must have come from replacement values (e.g. a request
    // header), not from operator-written placeholder syntax.
    // Escape them so buildQueryString does not re-expand them.
    injectedQuery = strings.ReplaceAll(injectedQuery, "{", "%7B")
    injectedQuery = strings.ReplaceAll(injectedQuery, "}", "%7D")
    query = injectedQuery
}

By replacing the literal curly braces with their percent-encoded representations (%7B and %7D), the patch ensures that the downstream evaluation pass is unable to recognize the character sequence as placeholder delimiters. The Replacer treats the percent-encoded values as safe, static string literals, preventing secondary execution. The following diagram illustrates this data flow during an exploitation attempt:

Exploitation of CVE-2026-77281 requires an attacker to satisfy two primary conditions. First, the target Caddy server must be configured with a rewrite rule that ends in a literal question mark and references a client-controlled variable. A common example is a reverse proxy or path router that utilizes incoming request headers to determine backend paths. Second, the attacker must have network access to transmit HTTP requests containing specifically formatted headers to the exposed Caddy listener.

The exploitation technique involves sending an HTTP request where the target header contains a nested placeholder string positioned immediately after a query delimiter. For example, an attacker targeting a header named X-Fwd would construct a payload value such as ok?key={env.CADDY_REWRITE_TEST_SECRET}. When the first-pass expansion occurs, this entire string is resolved as a path element. The split logic then extracts key={env.CADDY_REWRITE_TEST_SECRET} and treats it as a query parameter.

During the second evaluation pass within buildQueryString, Caddy's engine identifies the {env.CADDY_REWRITE_TEST_SECRET} syntax. It queries the system environment variables and replaces the token with the corresponding plaintext secret. If the rewritten request is subsequently forwarded to an upstream server controlled by the attacker, or if the server returns detailed error logs, the sensitive credentials are leaked. This allows unauthenticated, remote attackers to retrieve critical environmental configuration data without authorization.

The security impact of this vulnerability is primarily classified as low-to-medium-severity information disclosure, reflecting its CVSS score of 6.5. Although the flaw does not directly permit arbitrary code execution on the underlying operating system, the capability to leak environment variables significantly undermines system security. In modern cloud-native deployments, environment variables are frequently used to store sensitive configurations, including database connection strings, third-party API keys, and cryptographic secret keys.

Furthermore, the impact is compounded if specific optional modules are enabled on the Caddy server. For instance, if the local file provider is registered within Caddy's template engine, an attacker can use placeholders such as {file./etc/passwd} to read arbitrary local files. This escalates the vulnerability from basic environment variable disclosure to local file inclusion, potentially exposing sensitive system configuration files, private keys, or application source code.

The CVSS vector for this vulnerability (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L) underscores that the exploit is highly accessible. It requires no privileges, no user interaction, and has low technical complexity. While the integrity impact is rated as none, the availability impact is rated as low due to potential overhead or crash vectors associated with malformed placeholder parsing inside the core web server loop.

The definitive resolution for CVE-2026-77281 is upgrading Caddy to version v2.11.4 or later. The patch introduces robust sanitization of the injected query string, preventing any secondary placeholder evaluation. Security administrators should prioritize updating their binary installations using official Caddy distribution channels to ensure all active rewrite loops are secured.

In scenarios where immediate patching is not technically feasible due to production change freezes or compatibility validations, administrative workarounds can be applied. Administrators should inspect their active Caddyfiles to locate rewrite directives that end with a literal question mark and rely on request variables. Modifying these rules to avoid passing client-supplied headers directly into the rewrite path terminates the attack vector.

Additionally, defense-in-depth measures can be deployed at the network layer. Web Application Firewalls (WAFs) should be configured to detect and block incoming HTTP requests containing curly braces inside common headers. A regular expression match targeting patterns like \{[a-zA-Z0-9_\.]+\} in request headers such as User-Agent, Referer, and custom routing headers can effectively neutralize incoming exploitation payloads before they reach the Caddy web server handler.