Improper Validation of Certificate with Host Mismatch in the C++ and D libraries of Apache Thrift. Both libraries install a default access manager for client sockets — TSSLSocketFactory does so in C++, and the accessManager property does so in D — which compares the peer certificate against the host name that was connected to. That comparison walks the subjectAltName dNSName entries first and consults the certificate Common Name afterwards. A name that does not match yields a "skip" result rather than a rejection, so a certificate whose subjectAltName entries are all present and all non-matching falls through to the Common Name, which can then satisfy the check. RFC 6125 section 6.4.4, and RFC 9525 section 2, require that the Common Name is not consulted when a dNSName subjectAltName is present. A certificate carrying subjectAltName entries for one name and a Common Name for another is therefore accepted for a connection to the second name. Exploitation requires an attacker positioned on the network path who holds a certificate that chains to a certificate authority in the client's trust store and whose Common Name matches the connected host name. Public certificate authorities have not issued on Common Name alone for many years, so this is principally a concern for deployments using a private or enterprise public-key infrastructure. This issue affects the C++ library of Apache Thrift from 0.7.0 through 0.24.0 and the D library from 0.9.0 through 0.24.0. Users should upgrade to 0.25.0.

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

  - Improper Validation of Certificate with Host Mismatch in the C++ and D libraries of Apache Thrift. Both
    libraries install a default access manager for client sockets — TSSLSocketFactory does so in C++, and the
    accessManager property does so in D — which compares the peer certificate against the host name that was
    connected to. That comparison walks the subjectAltName dNSName entries first and consults the certificate
    Common Name afterwards. A name that does not match yields a "skip" result rather than a rejection, so a
    certificate whose subjectAltName entries are all present and all non-matching falls through to the Common
    Name, which can then satisfy the check. RFC 6125 section 6.4.4, and RFC 9525 section 2, require that the
    Common Name is not consulted when a dNSName subjectAltName is present. A certificate carrying
    subjectAltName entries for one name and a Common Name for another is therefore accepted for a connection
    to the second name. Exploitation requires an attacker positioned on the network path who holds a
    certificate that chains to a certificate authority in the client's trust store and whose Common Name
    matches the connected host name. Public certificate authorities have not issued on Common Name alone for
    many years, so this is principally a concern for deployments using a private or enterprise public-key
    infrastructure. This issue affects the C++ library of Apache Thrift from 0.7.0 through 0.24.0 and the D
    library from 0.9.0 through 0.24.0. Users should upgrade to 0.25.0. (CVE-2026-85088)

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

  - Improper Validation of Certificate with Host Mismatch in the C++ and D libraries of Apache Thrift. Both     libraries install a default access manager for client sockets  TSSLSocketFactory does so in C++, and the     accessManager property does so in D  which compares the peer certificate against the host name that was     connected to. That comparison walks the subjectAltName dNSName entries first and consults the certificate     Common Name afterwards. A name that does not match yields a skip result rather than a rejection, so a     certificate whose subjectAltName entries are all present and all non-matching falls through to the Common     Name, which can then satisfy the check. RFC 6125 section 6.4.4, and RFC 9525 section 2, require that the     Common Name is not consulted when a dNSName subjectAltName is present. A certificate carrying     subjectAltName entries for one name and a Common Name for another is therefore accepted for a connection     to the second name. Exploitation requires an attacker positioned on the network path who holds a     certificate that chains to a certificate authority in the client's trust store and whose Common Name     matches the connected host name. Public certificate authorities have not issued on Common Name alone for     many years, so this is principally a concern for deployments using a private or enterprise public-key     infrastructure. This issue affects the C++ library of Apache Thrift from 0.7.0 through 0.24.0 and the D     library from 0.9.0 through 0.24.0. Users should upgrade to 0.25.0. (CVE-2026-85088)

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

ID	Name	Product	Family	Type	Severity
472899	Echo: thrift: security update to 0.19.0-4+e3	Tenable Cloud Security	Echo Local Security Checks	Local	critical
472899	Echo: thrift: security update to 0.19.0-4+e3	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	critical
362720	Linux Distros Unpatched Vulnerability : CVE-2026-85088	Nessus	Misc.	Local	critical

Detections

Analytics

CVE-2026-85088

critical

Tenable Plugins

critical

critical

critical