CyberSecBulletin
CVE-2026-42790NVD status: Modified

OTP: Improper Certificate Validation

Published Updated By the CyberSecBulletin desk

CVE-2026-42790 is a high-severity improper certificate validation vulnerability in OTP from Erlang, with a CVSS 3.1 base score of 8.1 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, but only if a user takes part, for example by opening a link or file. Affected OTP versions: 19.3 and later; 1.4 and later; b0c245e8132bb13171e277b1af59c0cec00c9459 and later. The record does not name a fixed version, so check the vendor advisory. There is no confirmed exploitation so far. EPSS estimates a 0.36% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Erlang/otp to 26.2.5.21 or 27.3.4.12 or 28.5.0.1 or 29.0.1, whichever matches your release line, or a later version.
  2. Read the advisory on github.com for workarounds and exact fixed builds.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
  4. Because the attack needs a user to take part, warn users about unexpected links and files related to this product until it is patched.

Affected products and versions

VendorProductAffected versionsFixed in
ErlangOTP19.3 and later; 1.4 and later; b0c245e8132bb13171e277b1af59c0cec00c9459 and laterNot stated
Red HatRed Hat OpenStack Platform 16.2Not specified in the recordNot stated
Red HatRed Hat OpenStack Services on OpenShift 18.0Not specified in the recordNot stated
Red HatRed Hat Hardened ImagesNot specified in the recordNot stated
Red HatRed Hat OpenStack Platform 17.1Not specified in the recordNot stated
ErlangErlang/otp19.3 up to, but not including, 26.2.5.21; 27.0 up to, but not including, 27.3.4.12; 28.0 up to, but not including, 28.5.0.1; 29.0 up to, but not including, 29.0.126.2.5.21, 27.3.4.12, 28.5.0.1, 29.0.1

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
RequiredA user must take an action such as opening a file or link.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
NoneAvailability is not affected.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N. Scored by NVD.

Scoring systemScoreSeverityScored by
CVSS 4.07.6HighCNA
CVSS 3.18.1HighNVD
CVSS 3.17.4HighCNA

Official description

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, OTP 27.3.4.12, OTP 28.5.0.1, and OTP 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.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Improper Certificate Validation

The product does not validate, or incorrectly validates, a certificate.

How developers prevent this class of flaw

  • Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
  • If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

More Improper Certificate Validation vulnerabilities (CWE-295)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Third-party and government advisories

Other vulnerabilities in OTP

All OTP vulnerabilities

Recent Improper Certificate Validation vulnerabilities

Spotted an error? Tell us.