CVE WatchSep 22, 2026

CVE-2026-65634

Inefficient algorithmic complexity in the Erlang/OTP asn1 OBJECT IDENTIFIER decoder allows a remote unauthenticated attacker to cause denial

CVSS

—

No CVSS

EPSS

—

KEV

—

Exploit Today

—

0-100

Published: Sep 22, 2026 · Last modified: Sep 22, 2026 · CWE-407

EPSS · 30d

Not enough EPSS history yet.

Technical description

Inefficient algorithmic complexity in the Erlang/OTP asn1 OBJECT IDENTIFIER decoder allows a remote unauthenticated attacker to cause denial of service by sending a crafted OID during the TLS handshake. The BER OID decoder asn1rtt_ber:dec_subidentifiers/3 in lib/asn1/src/asn1rtt_ber.erl and the equivalent PER helper asn1rtt_per_common:dec_subidentifiers/3 in lib/asn1/src/asn1rtt_per_common.erl accumulate a base-128 subidentifier into an unbounded integer using (Av bsl 7) + H per continuation byte. Each shift and addition on the growing accumulator is linear in the number of bits already accumulated, giving quadratic total work in the size of a single subidentifier. The JER helper asn1rtt_jer:json2oid/1 in lib/asn1/src/asn1rtt_jer.erl exhibits the same class of unbounded-integer parsing when decoding a dot-separated OID from JSON. A DER-encoded OBJECT IDENTIFIER with one very large arc (approximately 262 KB of continuation bytes) consumes roughly 13 seconds of CPU on typical hardware. The vulnerable decoder is generated into every ASN.1 module that contains an OBJECT IDENTIFIER, including OTP-PUB-KEY which is reached during X.509 certificate parsing via public_key:pkix_decode_cert/2. This decoder runs before any signature or trust chain verification, so any Erlang service that parses peer TLS certificates is exposed: the default for TLS clients (which always parse the server certificate) and for mutual-TLS servers (which parse client certificates). This vulnerability is associated with program files lib/asn1/src/asn1rtt_ber.erl, lib/asn1/src/asn1rtt_per_common.erl and lib/asn1/src/asn1rtt_jer.erl and program routines asn1rtt_ber:dec_subidentifiers/3, asn1rtt_per_common:dec_subidentifiers/3 and asn1rtt_jer:json2oid/1. This issue affects OTP from OTP 17.0 before OTP 27.3.4.18, OTP 28.5.0.7, and OTP 29.1.1, corresponding to asn1 from 3.0 before 5.3.4.3, 5.4.3.1, and 5.5.2. Whether OTP before OTP 17.0, corresponding to asn1 before 3.0, is affected is unknown.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-87081—

—

———Net::IDN::UTS46 versions before 2.590 for Perl allow CPU exhaustion via quadratic punycode encoding of an overlong label before the length check in to_ascii. to_ascii punycode encodes each label and only then applies the 63-byte DNS limit. encode_punycode in both backends follows the sample implementation in RFC 3492, whose outer loop runs once per distinct non-ASCII code point and scans the whole input each round, so a label of distinct non-ASCII characters costs the square of its length before the limit rejects it. Every ASCII conversion in the distribution, including domain_to_ascii and email_to_ascii, goes through to_ascii.12h CVE-2026-870797.5 HIG

—

———Net::IDN::Punycode versions before 2.590 for Perl allow CPU exhaustion via quadratic insertion cost when decoding a long label in decode_punycode. The XS backend inserts each decoded code point into a UTF-8 buffer and finds the insertion point by scanning that buffer from the start, one character at a time. The scan runs once per code point over the output built so far, so the cost is quadratic in the label length. The pure-Perl backend downgrades its input to bytes so that substr can index it directly, but takes its working copy before the downgrade, so when the input carries the UTF-8 flag every substr on the copy scans from the start, with the same quadratic cost. Nothing bounds the label length in the to-Unicode direction. The 63-byte DNS limit is checked only when converting to ASCII, so domain_to_unicode and uts46_to_unicode pass an attacker-supplied label of any length to the decoder.7h CVE-2026-714187.5 HIG

28.6%

——9Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. From 8.0.0 until 8.0.6, DNS-over-HTTP/2 processing in rust/src/http2/http2.rs retains previously processed HTTP/2 DATA frame contents instead of clearing the internal buffer. Multiple DATA frames with the EndOfStream flag set can grow the buffer to its 65 KiB limit while causing all prior contents to be processed again, producing quadratic CPU complexity, degraded packet processing, loss of monitoring visibility, or denial of service. This issue is fixed in version 8.0.6.23h CVE-2026-634485.9 MED

37.5%

——11Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to 7.0.17 and 8.0.6, the SMB parser can retain force-completed transactions on flows where Suricata sees payload in only one direction, including async-oneside flows, because cleanup waits for inspection in the unseen direction. The transaction creation paths in rust/src/smb can exceed the intended SMB_MAX_TX bound, and cleanup repeatedly scans the growing list. Sustained one-directional SMB traffic can therefore cause unbounded per-flow state and CPU and memory exhaustion. This issue is fixed in versions 8.0.6 and 7.0.17.4d CVE-2026-634477.5 HIG

29.8%

——9Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. From 8.0.5 until 8.0.6, the FTP parser in src/app-layer-ftp.c can continue allocating transactions after app-layer.protocols.ftp.max-tx is reached while processing one large chunk of FTP command data. The oversized transaction list is repeatedly processed with quadratic complexity after the too_many_transactions event, allowing crafted FTP traffic to degrade packet processing, reduce monitoring visibility, or cause denial of service. This issue is fixed in version 8.0.6.1d CVE-2026-634467.5 HIG

32.6%

——10Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. From 8.0.0 until 8.0.6, AppLayerParserSetTransactionInspectId() in src/app-layer-parser.c uses an inverted guard and marks only already-inspected transactions as inspected. On flows passed by a pass rule or pass-the-flow exception policy, detection is skipped, so completed transactions remain unmarked, are never freed, and are repeatedly rescanned. The per-flow list can grow without bound with quadratic cleanup cost, causing CPU and memory exhaustion. This issue is fixed in version 8.0.6.1d