CVE-2026-27586
Caddyserver Caddy ≤ 2.11.1
Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-27586 is a high-severity Improper Handling of Exceptional Conditions (CWE-755) vulnerability in Caddyserver Caddy. Its CVSS base score is 8.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Client Execution (T1203); ranked at the 19th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SC-24 (Fail in Known State) and SI-17 (Fail-safe Procedures) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-27586 affects Caddy, an extensible server platform that uses TLS by default, in versions prior to 2.11.1. The vulnerability stems from two swallowed errors in the `ClientAuthentication.provision()` function, causing mutual TLS (mTLS) client certificate authentication to silently fail open. This occurs when a specified CA certificate file—configured via `trusted_ca_cert_file` or `trusted_ca_certs_pem_files`—is missing, unreadable, or malformed. As a result, the server starts without any error indication but accepts any client certificate signed by a system-trusted CA, completely bypassing the intended private CA trust boundary. The issue aligns with CWE-755 (Improper Handling of Exceptional Conditions) and carries a CVSS v3.1 base score of 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).
Remote attackers can exploit this vulnerability without privileges or user interaction by connecting to a vulnerable Caddy server instance configured for mTLS authentication. Exploitation requires the CA certificate file to become unavailable due to factors such as a path typo, file rotation, corruption, or permission changes, which triggers the silent fail-open behavior. A successful attack allows the attacker to present any client certificate signed by a system-trusted CA, granting unauthorized access to resources protected by the mTLS boundary and potentially leading to high confidentiality and integrity impacts, such as data exfiltration or modification.
The Caddy security advisory (GHSA-hffm-g8v7-wrv7) and release notes for version 2.11.1 detail the fix, which addresses the swallowed errors to ensure proper error handling and prevent silent degradation of mTLS authentication. Security practitioners should upgrade to Caddy 2.11.1 or later and verify CA file configurations, including paths, permissions, and integrity, to mitigate the risk. Additional technical details are available in the referenced GitHub gist.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-8541
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 1 hardening rule · 1 OS baseline
—
Mitigating Controls (NIST 800-53 r5) AI
Requires the system to fail to a known safe state on specified failures, limiting the impact of unhandled exceptional conditions.
Mandates explicit fail-safe procedures triggered by indicated failures, structurally preventing unhandled or mishandled exceptional conditions.
Requires generation of appropriate error messages on exceptional conditions, directly enforcing correct handling rather than silent or incorrect behavior.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices explicitly require proper exception and error handling during design and coding.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development and acceptance verifies correct handling of exceptional conditions.
Documented operating procedures may specify exception handling but do not guarantee implementation.
Logging captures unhandled exceptions, aiding detection but not preventing the weakness.
Monitoring can surface unhandled exceptions but does not enforce proper handling.
Secure SDLC mandates exception-handling requirements and testing that directly prevent improper handling of exceptional conditions.
Application security requirements explicitly include handling of error and exceptional conditions.