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 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to public_key from 1.4 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.
CVE-2026-42790 is an improper certificate validation vulnerability in Erlang OTP that allows DNS nameConstraints bypass through subject CommonName fallback in TLS hostname verification. A subordinate CA with restricted DNS nameConstraints can issue leaf certificates accepted as valid for out-of-scope hostnames due to incomplete SAN and CommonName validation.
يتعلق هذا الضعف بوحدتي pubkey_cert و public_key في Erlang OTP حيث لا يتم التحقق من قيود DNS nameConstraints بشكل صحيح. يسمح الضعف لسلطة تصديق فرعية بإصدار شهادات أوراق تقبلها عملاء TLS كهويات صحيحة لأسماء مضيفين خارج النطاق المسموح به.
This vulnerability affects Erlang OTP's public_key module, allowing attackers to bypass DNS nameConstraints restrictions through improper certificate validation. Organizations using Erlang-based TLS implementations in Saudi Arabia may be vulnerable to man-in-the-middle attacks if they rely on nameConstraints for certificate scope restriction.
Update Erlang OTP to the latest patched version that properly validates both SAN and CommonName against nameConstraints. Implement additional certificate validation checks at the application level. Review and strengthen CA policies to enforce SAN usage. Monitor certificate issuance logs for suspicious certificates lacking SAN entries.
قم بتحديث Erlang OTP إلى أحدث إصدار مصحح يتحقق بشكل صحيح من SAN و CommonName مقابل nameConstraints. قم بتنفيذ فحوصات التحقق من الشهادات الإضافية على مستوى التطبيق. راجع وقوي سياسات CA لفرض استخدام SAN. راقب سجلات إصدار الشهادات للشهادات المريبة التي تفتقد إدخالات SAN.