CVE-2026-27586 is a critical flaw (CVSS 9.1) in Caddy. If the CA file used for mutual TLS is missing, unreadable or malformed, Caddy starts without error and accepts client certificates from any system-trusted CA. Upgrade to Caddy 2.11.1 or later.
What's affected
Caddy versions before 2.11.1. The setting matters only if you use mutual TLS with a private CA, configured through trusted_ca_cert_file or trusted_ca_certs_pem_files. Servers that do not use client certificate authentication are unaffected by this flaw.
GitHub advisories for these Caddy issues list v2.11.0 as the patched version, but the release notes say the first 2.11 release was published as v2.11.1, with no code changes from v2.11.0 other than a CI job. Plan on v2.11.1 or later.
The record flags KEV as false and describes no exploitation.
How to check if you're exposed
Check the Caddy version first, then look for the mTLS directives in your configuration.
caddy version
# Docker
docker run --rm caddy:2 caddy version
# Find mTLS CA settings in config
grep -rn "trusted_ca_cert" /etc/caddy/
For every CA path you find, confirm the file exists, is readable by the Caddy user, and parses as valid PEM. A typo, a rotated file or a permission change is all it takes to trigger the failure, as the advisory notes.
What to do now
- Upgrade to Caddy 2.11.1 or later.
- Verify that every CA file referenced by
trusted_ca_cert_fileortrusted_ca_certs_pem_filesexists and is valid today. - If a CA file was ever missing or broken while a vulnerable version ran, assume any certificate from a public CA could have been accepted, and review access logs for client certificates you do not expect.
- Do not rely on mTLS alone for sensitive routes. Pass the client certificate identity to the application and check it there as well.
- Add a startup test to your deployment pipeline that fails if the Caddy config cannot load its CA files.
Why it matters
This is the CWE-755 class, improper handling of exceptional conditions. The advisory points to two places in the provisioning code where an error was swallowed and the function returned success anyway. With no CA pool created, the TLS layer still demanded and verified a client certificate, but against the system trust roots instead of your private CA.
The nasty part is the silence. The server starts, health checks pass, and the only change is that a boundary you thought was narrow quietly widens to every certificate any public CA has ever issued. Fail open on a security control is worse than a crash, because nobody notices.
The fix turns the swallowed errors into real startup failures. That is the behaviour you want from any security configuration: refuse to run rather than run weaker than intended.
Why a missing file is such a good failure to test
The advisory lists ordinary events that trigger this: a typo in a path, a certificate file replaced during rotation, a corrupted file, or a permissions change. None of these is an attack. They are the daily reality of running certificates. That is why this class of bug is worth a deliberate test in your own pipeline.
A simple regression test is to start a staging Caddy with a CA path that does not exist and confirm it refuses to start. On a fixed build it should. If your staging copy still starts and serves traffic, you have found the problem on the fixed version too, or you are not running the version you think you are.
Layering your client authentication
Mutual TLS tells you a certificate was valid under some trust root. It does not tell you the certificate belongs to a person or service you expected. Where the application can read the subject or a fingerprint of the client certificate, check it against an allow list. That way, even if a trust store is wider than intended for a moment, a certificate from some unrelated public CA does not open the door.
Finally, think about monitoring. Log the client certificate subject on protected routes, and alert on subjects you have never seen. A fail open event then shows up as a new name in the logs instead of staying invisible for months.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect Caddy servers that do not use mTLS?
No. It applies to deployments that use trusted_ca_cert_file or trusted_ca_certs_pem_files for client certificate authentication.
Sources
Last reviewed: 19 October 2026.
