https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 10:10:22 +0000 https://db.gcve.eu/vuln/cve-2026-85088 <p><strong>Affected:</strong> Apache Software Foundation Apache Thrift</p> <p>Improper Validation of Certificate with Host Mismatch in the C++ and D libraries of Apache Thrift.</p> <p>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</p> <p>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 &#34;skip&#34; result rather than</p> <p>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.</p> <p>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</p> <p>Common Name for another is therefore accepted for a connection to the second name.</p> <p>Exploitation requires an attacker positioned on the network path who holds a certificate that chains to a certificate authority in the client&#39;s trust store and whose Common Name matches the connected host</p> <p>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.</p> <p>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. User…</p> <p><strong>Affected:</strong> Apache Software Foundation Apache Thrift</p> <p>Improper Validation of Certificate with Host Mismatch in the C++ and D libraries of Apache Thrift.</p> <p>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</p> <p>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 &#34;skip&#34; result rather than</p> <p>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.</p> <p>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</p> <p>Common Name for another is therefore accepted for a connection to the second name.</p> <p>Exploitation requires an attacker positioned on the network path who holds a certificate that chains to a certificate authority in the client&#39;s trust store and whose Common Name matches the connected host</p> <p>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.</p> <p>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. User…</p> https://db.gcve.eu/vuln/cve-2026-85088