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.

The remote Fedora 44 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2026-950cac64f2 advisory.

    Security update resolving 17 CVEs across both caddy itself and its vendored libraries.

Tenable has extracted the preceding description block directly from the Fedora security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 43 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2026-3dc324bd9a advisory.

    Security update resolving 22 CVEs across both caddy itself and its vendored libraries.

Tenable has extracted the preceding description block directly from the Fedora security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - 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. (CVE-2026-27590)

  - 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-27585)

  - 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-27586)

  - 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-27587)

  - 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-27588)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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-27586)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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-27586)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
324621	Fedora 44 : caddy (2026-950cac64f2)	Nessus	Fedora Local Security Checks	critical
324614	Fedora 43 : caddy (2026-3dc324bd9a)	Nessus	Fedora Local Security Checks	critical
439411	Alpine: caddy: security update to 2.11.2-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	critical
439411	Alpine: caddy: security update to 2.11.2-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	critical
438003	SCA: security update for github.com/caddyserver/caddy/v2 (GHSA-hffm-g8v7-wrv7)	Tenable Cloud Security	SCA Checks	critical
438003	SCA: security update for github.com/caddyserver/caddy/v2 (GHSA-hffm-g8v7-wrv7)	Tenable Self-Hosted Container Security	SCA Checks	critical
300012	Linux Distros Unpatched Vulnerability : CVE-2026-27586	Nessus	Misc.	critical

Detections

Analytics

CVE-2026-27586

critical

Tenable Plugins

critical

critical

critical

critical

critical

critical

critical