Case Sensitive Chaos: Bypassing Caddy Authentication with a Shift Key

In the world of software engineering, there is an old adage: "Premature optimization is the root of all evil." In the world of exploit development, we call it "job security." Caddy, the darling of modern web servers known for its automatic HTTPS and ease of use, recently fell victim to this exact trap. It wasn't a memory corruption bug, a buffer overflow, or some complex race condition. It was a simple attempt to make the server go vroom when handling large lists of domains.

The vulnerability, tracked as CVE-2026-27588, is a classic logic flaw hidden inside a performance optimization. Web standards (RFC 4343) dictate that domain names are case-insensitive. example.com, Example.Com, and ExAmPlE.cOm are all the same place. Caddy knows this. Caddy respects this. Usually.

However, someone decided that when a single matcher block contains more than 100 hostnames—a common scenario for SaaS providers or multi-tenant architectures—a linear scan was too slow. They implemented a binary search optimization. The problem? Computers are pedantic. While a linear scan using strings.EqualFold knows that 'A' equals 'a', a binary search relying on standard string sorting and equality checks does not. This created a split-brain scenario where the server's security posture depended entirely on how many domains you shoved into your config file.

Let's dig into the root cause. Caddy's MatchHost module is responsible for looking at an incoming HTTP request, grabbing the Host header, and deciding if it matches a rule. If you have a rule saying "Require Basic Auth for admin.corp.com," Caddy checks the header. If the header matches, the middleware chain executes, and the user is prompted for a password.

Here is where the logic splits. If you have 100 or fewer hosts defined, Caddy iterates through them one by one, performing a case-insensitive comparison. This is safe. However, if you add that 101st host, Caddy switches to an "optimized" path. This path sorts the list of hosts and uses sort.Search to find the target.

The fatal flaw was in the comparison logic used during this binary search. The code compared the incoming Host header directly against the stored configuration using Go's == operator. In Go, "example.com" == "EXAMPLE.COM" evaluates to false.

This means if an attacker sends a request to ADMIN.CORP.COM, the optimized matcher looks at its sorted list of lowercase domains, sees admin.corp.com, compares it to ADMIN.CORP.COM, determines they are different, and returns false. The matcher fails. The request is not considered a match for that block.

The vulnerability lived in modules/caddyhttp/matchers.go. It’s a perfect example of how a subtle assumption can break security boundaries. Here is the vulnerable logic from versions prior to 2.11.1:

// VULNERABLE CODE
if m.large() {
    // fast path: locate exact match using binary search
    pos := sort.Search(len(m), func(i int) bool {
        // comparison is case-SENSITIVE
        return m[i] >= reqHost 
    })
    // equality check is case-SENSITIVE
    if pos < len(m) && m[pos] == reqHost { 
        return true, nil
    }
}

The fix was embarrassingly simple: normalize everything to lowercase before comparing. The patch ensures that no matter how the user types the domain, the binary search sees a lowercase string, matching the normalized configuration.

// PATCHED CODE (v2.11.1)
if m.large() {
    // Normalize the input before search
    reqHostLower := strings.ToLower(reqHost)
    pos := sort.Search(len(m), func(i int) bool {
        return m[i] >= reqHostLower
    })
    if pos < len(m) && m[pos] == reqHostLower {
        return true, nil
    }
}

This change restores the RFC-compliant behavior even when the optimization path is triggered.

So, how do we weaponize this? The impact depends entirely on what the matcher is guarding. In Caddy, matchers are often used as gates for middleware. A common pattern is to apply authentication only to specific internal subdomains.

The Setup: Imagine a SaaS platform using Caddy with 150 customer domains configured. One of them is internal-admin.saas.com, protected by basicauth.

The Attack:

1. Standard Request: GET / HTTP/1.1 | Host: internal-admin.saas.com.

   • Caddy's binary search matches the host.
   • The basicauth middleware is triggered.
   • Result: 401 Unauthorized.

2. Bypass Request: GET / HTTP/1.1 | Host: INTERNAL-ADMIN.SAAS.COM.

   • Caddy's binary search fails to match because of the case mismatch.
   • The matcher returns false.
   • The basicauth middleware is skipped because the matcher didn't trigger.
   • The request proceeds down the chain. If there is a catch-all route (e.g., *) or if the backend simply serves the app based on the Host header regardless of Caddy's routing logic, the attacker gains access.

This effectively turns a "secure" internal admin panel into a public-facing page, provided the backend application itself doesn't enforce a secondary layer of host validation (spoiler: they rarely do).

The mitigation is straightforward: Upgrade to Caddy v2.11.1. The Caddy team responded quickly once the issue was identified, patching the binary search logic to normalize the request host before lookup.

If you are stuck in a change-freeze or cannot upgrade immediately, there is a configuration workaround, though it is tedious. You need to ensure that no single host matcher block contains more than 100 entries.

For example, instead of:

@myhosts host a.com b.com ... (101 domains) ...

You would split it:

@group1 host a.com ... (50 domains)
@group2 host ... (51 domains)

This forces Caddy to use the unoptimized, linear scan path, which correctly uses strings.EqualFold and is not vulnerable to this casing bypass. But seriously, just upgrade the binary. It's a single file.