CVE-2026-27586
Received Received - Intake
Silent mTLS Authentication Bypass in Caddy Server Before

Publication date: 2026-02-24

Last updated on: 2026-02-25

Assigner: GitHub, Inc.

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-24
Last Modified
2026-02-25
Generated
2026-05-27
AI Q&A
2026-02-24
EPSS Evaluated
2026-05-25
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
caddyserver caddy to 2.11.1 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-755 The product does not handle or incorrectly handles an exceptional condition.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

[{'type': 'paragraph', 'content': "CVE-2026-27586 is a vulnerability in the Caddy server's mutual TLS (mTLS) client authentication implementation. Specifically, in versions prior to 2.11.1, two errors in the ClientAuthentication.provision() method are silently ignored when the CA certificate file is missing, unreadable, or malformed. Instead of reporting these errors, the server proceeds without properly loading the intended private CA certificates."}, {'type': 'paragraph', 'content': 'As a result, the server starts normally but accepts any client certificate signed by any system-trusted Certificate Authority (CA), bypassing the intended private CA trust boundary. This means that deployments using custom trusted CA files for mTLS will unintentionally accept client certificates validated against the broader system root CA pool if the CA file is unavailable or corrupted.'}, {'type': 'paragraph', 'content': 'The server gives no indication that mTLS is misconfigured, causing a silent security degradation. This fail-open behavior undermines the security guarantees of mTLS by allowing unauthorized clients to authenticate successfully.'}] [1, 2]


How can this vulnerability impact me? :

[{'type': 'paragraph', 'content': "This vulnerability can critically impact the security of any system using Caddy's mTLS with custom trusted CA certificate files. If the CA certificate file is missing, unreadable, or malformed due to reasons such as typos, file rotation, corruption, or permission changes, the server will silently accept any client certificate signed by any system-trusted CA."}, {'type': 'paragraph', 'content': 'This effectively widens the trust boundary beyond the intended private CA, allowing unauthorized clients to authenticate and potentially gain access to protected resources.'}, {'type': 'paragraph', 'content': 'Because the server does not report any error or warning, administrators may be unaware that the mTLS configuration has degraded, leading to a critical security bypass.'}] [1, 2]


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by verifying whether the Caddy server is silently failing open in its mTLS client certificate authentication due to missing, unreadable, or malformed CA certificate files. Specifically, if the server is configured with trusted_ca_cert_file or trusted_ca_certs_pem_files but the CA file is missing or invalid, the server will accept any client certificate signed by any system-trusted CA instead of the intended private CA.

A practical detection method involves attempting a TLS handshake with a client certificate that is not signed by the intended private CA but is trusted by the system root CA pool. If the handshake succeeds, it indicates the vulnerability is present.

While no explicit commands are provided in the resources, the proof-of-concept test demonstrates using Go code to configure a TLS listener with the faulty ClientAuthentication and then performing a TLS handshake with a self-signed client certificate. This approach can be adapted to test your environment.


What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation step is to upgrade Caddy to version 2.11.1 or later, where the vulnerability is fixed by correcting the error handling in the ClientAuthentication.provision() method.

Until the upgrade is applied, ensure that the CA certificate files referenced by trusted_ca_cert_file or trusted_ca_certs_pem_files exist, are readable, correctly formatted, and have proper permissions to prevent the server from silently failing open.

Additionally, monitor the server logs and configuration to detect any changes or issues with the CA files, such as file rotations, typos in paths, or corruption, which could trigger the vulnerability.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart