CVE-2026-42790
WysokieCVSS 8.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 27 - wyżej niż 27% wszystkich znanych CVE
Streszczenie
W bibliotece public_key Erlang OTP wykryto podatność polegającą na nieprawidłowej walidacji certyfikatów. Dwa błędy umożliwiają pominięcie ograniczeń DNS nameConstraints poprzez użycie nazwy pospolitej (commonName) w certyfikacie liścia, co pozwala atakującemu na podszycie się pod dowolny host.
Ocena ryzyka
Organizacja narażona jest na ataki typu man-in-the-middle, gdzie atakujący może wykorzystać certyfikat z ograniczonego podrzędnego urzędu certyfikacji do podszycia się pod dowolną domenę, co może prowadzić do przechwycenia poufnych danych.
Rekomendacja
Należy niezwłocznie zaktualizować Erlang OTP do wersji 29.0.1, 28.5.0.1, 27.3.4.12 lub 26.2.5.21 w zależności od używanej gałęzi, a także odpowiednie wersje biblioteki public_key.
Inne podatności w Erlang OTP public_key
Zobacz wszystkie- CVE-2026-59251Wysokie
W bibliotece public_key w Erlang/OTP wykryto podatność polegającą na nieograniczonym przydzielaniu zasobów podczas walidacji ścieżki certyfikatu X.509. Zdalny, nieuwierzytelniony atakujący może wysłać spreparowany łańcuch certyfikatów podczas uzgadniania TLS, co prowadzi do przeciążenia harmonogramów BEAM i wyczerpania pamięci węzła, powodując odmowę usługi (DoS). Problem dotyczy funkcji pubkey_policy_tree:add_leaves/2 i pubkey_policy_tree:add_leaf_siblings/2, które rozwijają drzewo polityki certyfikatów bez ograniczeń.
- CVE-2026-42789Średnie
W bibliotece public_key Erlang OTP wykryto podatność polegającą na nieprawidłowym śledzeniu łańcucha zaufania certyfikatów. Moduł pubkey_cert błędnie akceptuje certyfikat niebędący CA (z basicConstraints cA:false i bez rozszerzenia keyUsage) jako pośredniego wystawcę, co umożliwia fałszowanie łańcucha certyfikatów. Problem dotyczy wersji OTP od 17.0 do 29.0.1, 28.5.0.1, 27.3.4.12 i 26.2.5.21.
Oryginalny opis (angielski, źródło NVD)
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 hostname matcher. This issue affects OTP from OTP 19.3 before OTP 29.0.1, OTP 28.5.0.1, OTP 27.3.4.12 and OTP 26.2.5.21, corresponding to public_key from 1.4 before 1.21.1, 1.20.3.1, 1.17.1.3 and 1.15.1.7.