CVE-2026-85088: CWE-295 Improper certificate validation in Apache Software Foundation Apache Thrift
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.
AI Analysis
Technical Summary
The vulnerability in Apache Thrift's C++ and D libraries involves improper validation of TLS certificates during hostname verification. The libraries' default access managers check the peer certificate's subjectAltName dNSName entries first and then fall back to the Common Name if no dNSName matches. According to RFC 6125 section 6.4.4 and RFC 9525 section 2, the Common Name must not be consulted if subjectAltName dNSName entries are present. This flaw allows acceptance of certificates where subjectAltName entries do not match the connected hostname but the Common Name does, violating RFC requirements. Exploitation requires an attacker on the network path with a certificate chaining to a trusted CA and a Common Name matching the target hostname. Public CAs no longer issue certificates based solely on Common Name, so the risk is mainly for private or enterprise PKI deployments. The affected versions are Apache Thrift C++ 0.7.0 through 0.24.0 and D 0.9.0 through 0.24.0, with a fix available in 0.25.0.
Potential Impact
An attacker positioned on the network path could present a certificate with subjectAltName entries that do not match the hostname but with a Common Name that does, bypassing hostname verification. This could allow man-in-the-middle attacks in environments using private or enterprise certificate authorities. Public certificate authorities are unlikely to issue such certificates, reducing risk in public deployments.
Mitigation Recommendations
Users should upgrade Apache Thrift C++ and D libraries to version 0.25.0 or later, where this certificate validation issue has been fixed. No other mitigations are specified. Patch status is confirmed by the vendor advisory recommending upgrade to 0.25.0.
CVE-2026-85088: CWE-295 Improper certificate validation in Apache Software Foundation Apache Thrift
Description
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.
CVSS v4.0
Score 6.9medium
Affected software
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in Apache Thrift's C++ and D libraries involves improper validation of TLS certificates during hostname verification. The libraries' default access managers check the peer certificate's subjectAltName dNSName entries first and then fall back to the Common Name if no dNSName matches. According to RFC 6125 section 6.4.4 and RFC 9525 section 2, the Common Name must not be consulted if subjectAltName dNSName entries are present. This flaw allows acceptance of certificates where subjectAltName entries do not match the connected hostname but the Common Name does, violating RFC requirements. Exploitation requires an attacker on the network path with a certificate chaining to a trusted CA and a Common Name matching the target hostname. Public CAs no longer issue certificates based solely on Common Name, so the risk is mainly for private or enterprise PKI deployments. The affected versions are Apache Thrift C++ 0.7.0 through 0.24.0 and D 0.9.0 through 0.24.0, with a fix available in 0.25.0.
Potential Impact
An attacker positioned on the network path could present a certificate with subjectAltName entries that do not match the hostname but with a Common Name that does, bypassing hostname verification. This could allow man-in-the-middle attacks in environments using private or enterprise certificate authorities. Public certificate authorities are unlikely to issue such certificates, reducing risk in public deployments.
Mitigation Recommendations
Users should upgrade Apache Thrift C++ and D libraries to version 0.25.0 or later, where this certificate validation issue has been fixed. No other mitigations are specified. Patch status is confirmed by the vendor advisory recommending upgrade to 0.25.0.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-4xmj-xwhr-jcj2
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-85088"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6abfee87a43b0b3b89e54bc2
Added to database: 10/02/2026, 17:48:55 UTC
Last enriched: 10/02/2026, 17:56:58 UTC
Last updated: 10/02/2026, 19:59:20 UTC
Views: 1
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.