CVE-2026-42790: nameConstraints DNS bypass via subject CommonName fallback in public_key hostname verification

Synopsis

An improper certificate validation vulnerability in Erlang OTP's public_key module allows a DNS nameConstraints bypass via subject CommonName fallback during TLS hostname verification. An unauthenticated remote attacker who can perform a man-in-the-middle interception and meet specific preconditions can present a crafted leaf certificate with no subjectAltName, causing a TLS client running Erlang OTP to accept it as valid for a hostname outside the subordinate CA's permitted DNS scope. Successful exploitation enables the attacker to intercept and tamper with traffic the client believes is protected by a trusted TLS connection. A patched-image rebuild is available on HarborGuard for environments running an affected version of Erlang OTP.

HarborGuard Coverage

Exploit Conditions

• Network reachabilityRequired

  The attacker must be positioned to intercept or inject traffic over the network between the Erlang OTP TLS client and the server it is connecting to.

• AuthenticationNot required

  No credentials or account are required; the attack is reachable from an unauthenticated network position.

• Victim interactionRequired

  A victim TLS client must initiate a connection that the attacker can intercept, requiring the target application or user to trigger outbound TLS traffic toward the spoofed host.

• Attack complexityDetail

  Exploitation requires specific preconditions: the attacker must control or compromise a subordinate CA with restricted DNS nameConstraints and be positioned to perform a man-in-the-middle interception, making reliable exploitation dependent on environmental factors.

Blast Radius

• The attacker can impersonate a TLS server for a hostname outside the subordinate CA's permitted DNS scope, causing the Erlang OTP client to treat the connection as trusted.
• All data sent over the intercepted TLS session is readable by the attacker, including session tokens, credentials, API keys, or any application-layer content.
• The attacker can modify data in transit between the client and the spoofed server, injecting or altering requests and responses without the client detecting tampering.