<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-06T15:06:37.336836+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2026-27145</id>
    <title>CVE-2026-27145 — Inefficient candidate hostname parsing in crypto/x509</title>
    <updated>2026-10-06T15:06:37.361836+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go standard library crypto/x509, Red Hat Ansible Automation Platform 2.5 for RHEL 8, Red Hat Ansible Automation Platform 2.5 for RHEL 9, Red Hat Ansible Automation Platform 2.6 for RHEL 10, Red Hat Ansible Automation Platform 2.6 for RHEL 9, Red Hat Ansible Automation Platform 2.7 for RHEL 10, Red Hat Ansible Automation Platform 2.7 for RHEL 9, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 7 Extended Lifecycle Support and 121 more</p>
<p>(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop over all DNS Subject Alternative Name (SAN) entries. This caused strings.Split(host, ".") to execute repeatedly on the same input hostname. With a large DNS SAN list, verification costs scaled quadratically based on the number of SAN entries multiplied by the hostname's label count. Because x509.Verify validates hostnames before building the certificate chain, this overhead occurred even for untrusted certificates.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-27145"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-mpwr-8vm7-h73f</id>
    <title>GHSA-mpwr-8vm7-h73f — package pkcs12: Authentication bypass in Decode functions</title>
    <updated>2026-10-06T15:06:37.362194+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: software.sslmate.com/src/go-pkcs12</p>
<p>`Decode`, `DecodeChain`, `DecodeTrustStore`, and `ToPEM` can incorrectly accept PKCS#12 files which were encoded with the wrong password, due to a failure to reject excessively-short PBMAC1 keys. Users who decode PKCS#12 files from untrusted sources and rely on the password for authentication can be tricked into accepting malicious PKCS#12 files. Users who only decode PKCS#12 files from trusted sources are not affected.</p>
<p>Thanks to Pavol Žáčik (Red Hat) and Alex Gaynor (Anthropic) for finding and reporting the same issue in OpenSSL ([CVE-2026-34181](https://openssl-library.org/news/vulnerabilities/#CVE-2026-34181)).</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-mpwr-8vm7-h73f"/>
  </entry>
</feed>
