CVE-2026-27586: 
NixOS vulnerability analysis and mitigation

CVE-2026-27586 is an mTLS authentication bypass vulnerability in the Caddy web server that causes client certificate authentication to silently fail open when a CA certificate file is missing, unreadable, or malformed. It affects all versions of Caddy prior to 2.11.1 (specifically confirmed in v2.10.2 and earlier). The vulnerability was discovered by researcher moscowchill, published to the GitHub Advisory Database on February 23, 2026, and publicly disclosed via NVD on February 24, 2026. It carries a CVSS v3.1 base score of 9.1 (Critical) and a CVSS v4.0 base score of 8.8 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is improper handling of exceptional conditions (CWE-755) combined with improper verification of cryptographic signatures (CWE-347) in modules/caddytls/connpolicy.go. Specifically, the ClientAuthentication.provision() method contains two return nil statements (at lines 787 and 800) that should be return err — effectively swallowing errors when convertPEMFilesToDER() fails or when caPool.Provision() fails. When these errors are swallowed, TrustedCACerts remains empty, clientauth.ca is never set, and cfg.ClientCAs is left nil in ConfigureTLSConfig(). Because Go's crypto/tls with RequireAndVerifyClientCert and a nil ClientCAs falls back to verifying against the system root pool, any client certificate signed by a system-trusted CA is accepted instead of the intended private CA. No authentication credentials or special privileges are required — an attacker only needs a certificate signed by any system-trusted CA (GitHub Advisory, PoC Gist).

Successful exploitation allows an attacker to completely bypass the intended private CA trust boundary for mTLS-protected Caddy deployments, gaining unauthorized access to resources that should only be accessible to clients with private CA-signed certificates. The impact is high on both confidentiality and integrity — an attacker can access sensitive data and perform unauthorized actions on the server — while availability is unaffected. The failure is entirely silent: the server starts and operates normally with no error or warning, meaning administrators have no indication that mTLS protection has been compromised, making detection and incident response significantly harder (GitHub Advisory, Red Hat Bugzilla).

A proof-of-concept exploit (a Go test file demonstrating the full mTLS fail-open behavior including a successful TLS handshake with a self-signed client certificate) is publicly available on GitHub Gist (PoC Gist). The CVSS v4.0 exploit maturity is rated PROOF_OF_CONCEPT. As of the time of disclosure, there is no evidence of in-the-wild exploitation or threat actor attribution. The EPSS score is approximately 0.057% (0.127% per GitHub Advisory), placing it in the 32nd percentile for exploitation probability. The vulnerability is not listed in the CISA KEV catalog. It is detectable by Qualys (detection ID 5007940) and Nessus (detection ID 300012) (GitHub Advisory, Feedly).

1. Identify a vulnerable target: Locate a Caddy server (version < 2.11.1) configured with trusted_ca_cert_file or trusted_ca_certs_pem_files for mTLS client authentication. This can be identified via service banners, configuration leaks, or network scanning.
2. Trigger or confirm the misconfiguration: The vulnerability activates when the specified CA certificate file is missing, unreadable, or malformed — conditions that may already exist due to a typo in the path, file rotation, permission changes, or corruption. No attacker action is needed to trigger this state.
3. Obtain or generate a client certificate: Obtain any client certificate signed by a system-trusted CA (e.g., a publicly trusted CA, or a self-signed certificate that chains to a system root on the target). A self-signed certificate may suffice on some systems.
4. Connect to the mTLS-protected endpoint: Use a TLS client (e.g., openssl s_client) to connect, presenting the non-intended client certificate:

   openssl s_client -connect <target>:443 -cert client.pem -key client-key.pem

5. Achieve authentication bypass: The TLS handshake succeeds because Caddy's cfg.ClientCAs is nil, causing Go's crypto/tls to fall back to system root verification. The attacker gains access to the mTLS-protected resource as if they held a valid private CA-signed certificate (GitHub Advisory, PoC Gist).

• Logs: Caddy access logs showing successful TLS handshakes from clients presenting certificates not issued by the intended private CA; absence of any startup error or warning related to CA file loading despite trusted_ca_cert_file or trusted_ca_certs_pem_files being configured.
• File System: Missing, zero-byte, permission-restricted, or malformed CA certificate PEM files at paths specified in trusted_ca_cert_file or trusted_ca_certs_pem_files configuration directives.
• Network: Successful mTLS connections from unexpected client certificate issuers (i.e., certificates signed by public/system CAs rather than the expected private CA); TLS session metadata showing client certificates with unexpected issuer Distinguished Names (DNs).
• Configuration: Caddy JSON or Caddyfile configurations referencing CA certificate file paths that do not exist or are inaccessible at runtime (GitHub Advisory).

Upgrade Caddy to version 2.11.1 or later, which fixes the vulnerability by changing the two erroneous return nil statements to return err in ClientAuthentication.provision() (Caddy Release). For deployments unable to upgrade immediately: (1) verify that all CA certificate files specified in trusted_ca_cert_file or trusted_ca_certs_pem_files exist, are readable, and contain valid PEM-formatted data; (2) implement file monitoring/alerting to detect when CA certificate files become unavailable or inaccessible; (3) test mTLS authentication after any configuration or file system changes to confirm only intended CA-signed certificates are accepted; (4) consider adding network-level access controls as a defense-in-depth measure until patching is complete (GitHub Advisory, Red Hat Bugzilla).

The vulnerability was published by Caddy maintainer mholt on February 23, 2026, as part of the v2.11.1 release which addressed six CVEs simultaneously, indicating a coordinated security release (Caddy Release). The issue was reported by researcher moscowchill, who also provided the fix (PR #7464) and a detailed PoC. Social media coverage appeared on Bluesky and Mastodon via security news accounts (e.g., @thehackerwire), and the vulnerability was covered by security aggregators including InfinitSec and CVEReports. Red Hat tracked the issue via Bugzilla and assigned it high severity (Red Hat Bugzilla). SUSE also issued a govulncheck advisory referencing the vulnerability.