CVE-2026-59251

Denial of service via exponential certificate policy tree growth in path validation

HIGH
7.5
CVSS Score
Published: July 27, 2026 at 03:30 PM UTC
Updated: October 24, 2026 at 01:10 PM UTC
2 products affected across 1 vendorErlang /otpErlang /public Key

Using OTP by Erlang?

Get instant alerts when new vulnerabilities affect OTP - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.5
Exploit prediction
EPSS 0.3%
SSVC
No known exploit

Description

Allocation of resources without limits in Erlang/OTP public_key certificate path validation allows a remote unauthenticated attacker to cause denial of service by sending a crafted X.509 certificate chain during the TLS handshake. During RFC 5280 policy processing in public_key:pkix_path_validation/3, the certificate policy tree maintained by pubkey_policy_tree grows without an upper bound. When a certificate chain contains M policies per certificate and K certificates, the tree grows on the order of M^K nodes because pubkey_policy_tree:add_leaves/2 and pubkey_policy_tree:add_leaf_siblings/2 extend the tree per policy per certificate. A modest chain with many policies per certificate is enough to pin BEAM schedulers and exhaust the node's memory, taking down the entire VM. The attacker only needs to be able to present a certificate chain to the victim, which is the normal precondition for a TLS handshake, so exploitation succeeds against any incoming or outgoing TLS connection that validates the peer's chain (the default for SSL/TLS clients and mutual-TLS servers). This is the same vulnerability class as OpenSSL's X509_verify_cert policy tree DoS. This vulnerability is associated with program files lib/public_key/src/pubkey_policy_tree.erl and program routines pubkey_policy_tree:add_leaves/2 and pubkey_policy_tree:add_leaf_siblings/2. This issue affects OTP from OTP 26.2 before OTP 29.0.4, OTP 28.5.0.4 and OTP 27.3.4.15, corresponding to public_key from 1.15 before 1.21.4, 1.20.3.4 and 1.17.1.5.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

26.2 ≤ v < 27.3.4.1528.0 ≤ v < 28.5.0.429.0 ≤ v < 29.0.41.1526.29d1dda7bad5a64b58c10a1554751689e94131a73
Affected range stops below 27.3.4.15, so it looks safe — our inference, not a vendor statement
Affected range stops below 28.5.0.4, so it looks safe — our inference, not a vendor statement
Affected range stops below 29.0.4, so it looks safe — our inference, not a vendor statement
1.15 ≤ v < 1.17.1.51.18 ≤ v < 1.20.3.41.21 ≤ v < 1.21.4
Affected range stops below 1.17.1.5, so it looks safe — our inference, not a vendor statement
Affected range stops below 1.20.3.4, so it looks safe — our inference, not a vendor statement
Affected range stops below 1.21.4, so it looks safe — our inference, not a vendor statement

SSVC — Action Prioritization

SSVCNo known exploitAutomatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
NETWORK
Complexity
LOW
Privileges
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusANALYZED
CWE
CWE-770

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card