Source: caddy Version: 2.6.2-14 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for caddy. CVE-2026-27585[0]: | Caddy is an extensible server platform that uses TLS by default. Prior | to version 2.11.1, the path sanitization routine in file matcher | doesn't sanitize backslashes which can lead to bypassing path related | security protections. It affects users with specific Caddy and | environment configurations. Version 2.11.1 fixes the issue. CVE-2026-27586[1]: | Caddy is an extensible server platform that uses TLS by default. | Prior to version 2.11.1, two swallowed errors in | `ClientAuthentication.provision()` cause mTLS client certificate | authentication to silently fail open when a CA certificate file is | missing, unreadable, or malformed. The server starts without error | but accepts any client certificate signed by any system-trusted CA, | completely bypassing the intended private CA trust boundary. Any | deployment using `trusted_ca_cert_file` or | `trusted_ca_certs_pem_files` for mTLS will silently degrade to | accepting any system-trusted client certificate if the CA file | becomes unavailable. This can happen due to a typo in the path, file | rotation, corruption, or permission changes. The server gives no | indication that mTLS is misconfigured. Version 2.11.1 fixes the | vulnerability. CVE-2026-27587[2]: | Caddy is an extensible server platform that uses TLS by default. | Prior to version 2.11.1, 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. Version 2.11.1 contains a fix for | the issue. CVE-2026-27588[3]: | Caddy is an extensible server platform that uses TLS by default. | Prior to version 2.11.1, Caddy's HTTP `host` request matcher is | documented as case-insensitive, but when configured with a large | host list (>100 entries) it becomes case-sensitive due to an | optimized matching path. An attacker can bypass host-based routing | and any access controls attached to that route by changing the | casing of the `Host` header. Version 2.11.1 contains a fix for the | issue. CVE-2026-27589[4]: | Caddy is an extensible server platform that uses TLS by default. | Prior to version 2.11.1, the local caddy admin API (default listen | `127.0.0.1:2019`) exposes a state-changing `POST /load` endpoint | that replaces the entire running configuration. When origin | enforcement is not enabled (`enforce_origin` not configured), the | admin endpoint accepts cross-origin requests (e.g., from attacker- | controlled web content in a victim browser) and applies an attacker- | supplied JSON config. This can change the admin listener settings | and alter HTTP server behavior without user intent. Version 2.11.1 | contains a fix for the issue. CVE-2026-27590[5]: | Caddy is an extensible server platform that uses TLS by default. | Prior to version 2.11.1, Caddy's FastCGI path splitting logic | computes the split index on a lowercased copy of the request path | and then uses that byte index to slice the original path. This is | unsafe for Unicode because `strings.ToLower()` can change UTF-8 byte | length for some characters. As a result, Caddy can derive an | incorrect `SCRIPT_NAME`/`SCRIPT_FILENAME` and `PATH_INFO`, | potentially causing a request that contains `.php` to execute a | different on-disk file than intended (path confusion). In setups | where an attacker can control file contents (e.g., upload features), | this can lead to unintended PHP execution of non-.php files | (potential RCE depending on deployment). Version 2.11.1 fixes the | issue. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-27585 https://www.cve.org/CVERecord?id=CVE-2026-27585 [1] https://security-tracker.debian.org/tracker/CVE-2026-27586 https://www.cve.org/CVERecord?id=CVE-2026-27586 [2] https://security-tracker.debian.org/tracker/CVE-2026-27587 https://www.cve.org/CVERecord?id=CVE-2026-27587 [3] https://security-tracker.debian.org/tracker/CVE-2026-27588 https://www.cve.org/CVERecord?id=CVE-2026-27588 [4] https://security-tracker.debian.org/tracker/CVE-2026-27589 https://www.cve.org/CVERecord?id=CVE-2026-27589 [5] https://security-tracker.debian.org/tracker/CVE-2026-27590 https://www.cve.org/CVERecord?id=CVE-2026-27590 Regards, Salvatore
