caddyserver Caddy file_server case-sensitivity bypass exposes hidden files

Caddy is an extensible server platform that uses TLS by default. In version 2.11.3 and earlier, in modules/caddyhttp/fileserver/staticfiles.go, fileHidden() uses case-sensitive filepath.Match checks, so case variants can bypass hide rules on case-insensitive filesystems or when mixed-case paths coexist and expose files intended to be hidden.

• Affected product: caddyserver Caddy, specifically deployments using HTTP file_server with hide rules.
• Affected release: <= 2.11.3.
• Deployment conditions: exposure depends on a case-insensitive filesystem, a filesystem with case folding enabled, or the coexistence of paths that differ only by case.
• Vendor-listed patched release: v2.11.4.
• The available evidence does not confirm the status of parallel branches or releases outside the boundaries stated above.

In caddyserver Caddy, the HTTP file server uses fileHidden() to test paths against hide patterns with filepath.Match. That matching is case-sensitive, while a case-insensitive filesystem can treat variants such as .git and .GIT as the same resource. On a case-sensitive filesystem, the issue can also occur when paths that differ only by case coexist, because only the exact-case variant matching the hide pattern is blocked. Exploitation requires an exposed file_server route, a deployment that relies on hide, and a target resource within the served directory. The record establishes network reachability without authentication or user interaction; the exact implementation of the fix is not established by the available evidence.

The flaw is remotely reachable over HTTP when Caddy exposes a file_server with hide rules and the corresponding resource remains under the served root. The record describes network access without authentication, privileges, or user interaction, with low attack complexity. An attacker can try case variants of a hidden path or access a differently cased path when corresponding directories coexist. The record marks a public exploit, and the vendor advisory documents an end-to-end reproduction. The available evidence does not establish exploitation in real-world environments.

The flaw weakens Caddy's path-name-based access control for the HTTP file server. The technical result is that a file or directory intended to be blocked by hide may be returned when the URL uses casing that matches the filesystem's name resolution but not the hide pattern's exact casing. The primary impact is loss of confidentiality for resources reachable through the affected file_server route; there is no evidence that the flaw permits file writes, configuration changes, or availability loss. Organizational consequences may include disclosure of source code, configuration, or secrets when those data types are present in an exposed resource. Exploitability and damage depend on the hide configuration, directory contents, and filesystem case behavior.

• Data may be disclosed because files believed to be hidden remain reachable through case variants.
• If hide patterns protect .git, .env, or secrets, exposed data may include source code, configuration, credentials, API keys, or database connection strings. This is conditional on those files existing under the served directory, not a claim that every deployment contains them.
• Exposure of credentials or keys may require the organization to assess access scope and rotate secrets if review shows that the data was accessed.
• The flaw does not establish file modification or service disruption; the confirmed consequence is primarily loss of confidentiality.

1. Upgrade caddyserver Caddy to v2.11.4, which the vendor advisory lists as patched for this issue.
2. Until upgrading, do not treat hide as sufficient protection for sensitive data. Remove confidential files from served directories or apply an independent access-control layer.
3. Review each file_server configuration for hide patterns, the actual filesystem, and directories with differing case. Prioritize directories containing source code, environment files, credentials, or keys.
4. After upgrading, test case variants in a controlled environment and verify that protected resources are no longer served. Do not assume that a fix listed for one release applies to every other branch without branch-specific evidence.
5. If logs or served content indicate that secrets may have been exposed, handle the event as potential data disclosure, including scope assessment and rotation of affected secrets.

1. Inventory caddyserver Caddy instances and identify those using HTTP file_server to serve directories that may contain sensitive data.
2. Review Caddyfile or equivalent configuration for file_server directives and hide patterns, especially .git, .env, secrets, or other internal file names.
3. Determine the filesystem behavior for the served directory. The advisory identifies macOS APFS and Windows NTFS as commonly case-insensitive, and notes that Linux can be affected when ext4 uses casefold or when differently cased directories coexist.
4. In a controlled test environment, check case variants of each hide pattern using a non-sensitive canary file. A single blocked path does not prove that all case variants or subdirectories are protected.
5. Review access logs for requests whose casing differs from configured hidden names. Treat this as precautionary monitoring, not as a confirmed indicator of compromise.