https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 11:04:19 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-15308 bdu:2026-15308 https://cve.radiocsirt.org/vuln/bdu:2026-15308 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0731 certfr-2026-avi-0731 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0731 https://cve.radiocsirt.org/vuln/euvd-2026-371799 EUVD-2026-371799 https://cve.radiocsirt.org/vuln/euvd-2026-371799 https://cve.radiocsirt.org/vuln/fkie_cve-2026-42790 <p>Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_cert and public_key modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification.</p> <p>Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com):</p> <p>First, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName.</p> <p>Second, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this fallback.</p> <p>The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verify_peer, a trusted CA, SNI, and the canonical strict https…</p> <p>Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_cert and public_key modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification.</p> <p>Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com):</p> <p>First, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName.</p> <p>Second, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this fallback.</p> <p>The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verify_peer, a trusted CA, SNI, and the canonical strict https…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-42790 https://cve.radiocsirt.org/vuln/msrc_cve-2026-42790 msrc_CVE-2026-42790 https://cve.radiocsirt.org/vuln/msrc_cve-2026-42790 https://cve.radiocsirt.org/vuln/opensuse-su-2026:10947-1 <p>erlang27-27.1.3-2.1 on GA media</p> <p>erlang27-27.1.3-2.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:10947-1 https://cve.radiocsirt.org/vuln/rhsa-2026:39809 <p>erlang: Erlang OTP public_key: Certificate chain forgery via improper trust chain validation erlang: Erlang OTP public_key: Certificate validation bypass allows hostname spoofing</p> <p>erlang: Erlang OTP public_key: Certificate chain forgery via improper trust chain validation erlang: Erlang OTP public_key: Certificate validation bypass allows hostname spoofing</p> https://cve.radiocsirt.org/vuln/rhsa-2026:39809 https://cve.radiocsirt.org/vuln/suse-su-2026:22082-1 <p>Security update for erlang</p> <p>Security update for erlang</p> https://cve.radiocsirt.org/vuln/suse-su-2026:22082-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-42790 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: erlang, Ubuntu:Pro:16.04:LTS: erlang, Ubuntu:Pro:18.04:LTS: erlang, Ubuntu:Pro:20.04:LTS: erlang, Ubuntu:22.04:LTS: erlang, Ubuntu:24.04:LTS: erlang, Ubuntu:25.10: erlang, Ubuntu:26.04:LTS: erlang</p> <p>Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_cert and public_key modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification. Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com): First, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName. Second, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this fallback. The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verify_peer, a trusted CA, SNI, and the canonical strict https hos…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: erlang, Ubuntu:Pro:16.04:LTS: erlang, Ubuntu:Pro:18.04:LTS: erlang, Ubuntu:Pro:20.04:LTS: erlang, Ubuntu:22.04:LTS: erlang, Ubuntu:24.04:LTS: erlang, Ubuntu:25.10: erlang, Ubuntu:26.04:LTS: erlang</p> <p>Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_cert and public_key modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification. Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com): First, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName. Second, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this fallback. The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verify_peer, a trusted CA, SNI, and the canonical strict https hos…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-42790 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1719 <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Erlang/OTP ausnutzen, um Sicherheitsvorkehrungen zu umgehen.</p> <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Erlang/OTP ausnutzen, um Sicherheitsvorkehrungen zu umgehen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1719