<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T20:21:57.358641+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-91769</id>
    <title>CVE-2026-91769 — TLS Hostname Verification Falls Back to CN After SAN Mismatch</title>
    <updated>2026-09-28T20:21:57.360247+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PHP Group PHP</p>
<p>PHP's OpenSSL stream peer verification checks the certificate's subjectAltName entries first and, whenever no entry matches, falls back to the Common Name. RFC 6125 requires the CN to be ignored once the certificate presents any service identity, so a certificate carrying a non-matching DNS SAN was still accepted when its CN matched the requested peer_name. A certificate trusted by the client for one name can therefore be used to impersonate another.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-91769"/>
  </entry>
</feed>
