CVE-2026-65634: 
Erlang OTP Analyse et atténuation des vulnérabilités

CVE-2026-65634 is a superlinear CPU Denial-of-Service vulnerability in the Erlang/OTP ASN.1 OBJECT IDENTIFIER (OID) decoder, caused by inefficient algorithmic complexity when processing large base-128 subidentifiers. A remote unauthenticated attacker can send a crafted OID during a TLS handshake to trigger quadratic CPU consumption, resulting in service disruption. Affected software includes Erlang/OTP versions ≥ 17.0 and the asn1 library versions ≥ 3.0; patched versions are OTP 27.3.4.18, 28.5.0.7, and 29.1.1 (asn1 5.3.4.3, 5.4.3.1, and 5.5.2). The vulnerability was published on September 22, 2026, with a CVSS v4 base score of 8.2 (High) (GitHub Advisory).

The root cause is CWE-407 (Inefficient Algorithmic Complexity) in three OID decoder functions: asn1rtt_ber:dec_subidentifiers/3 (BER), asn1rtt_per_common:dec_subidentifiers/3 (PER), and asn1rtt_jer:json2oid/1 (JER). Each continuation byte of a base-128 subidentifier is accumulated into an unbounded Erlang integer via (Av bsl 7) + H; because each shift-and-add operation is linear in the number of bits already accumulated, a single very large arc produces quadratic total CPU work. A DER-encoded OID with approximately 262 KB of continuation bytes consumes roughly 13 seconds of CPU on typical hardware. The vulnerable decoder is embedded in every compiled ASN.1 module containing an OBJECT IDENTIFIER, including OTP-PUB-KEY, which is invoked via public_key:pkix_decode_cert/2 during X.509 certificate parsing — before any signature or trust-chain verification occurs (GitHub Advisory, Fix Commit).

Successful exploitation causes excessive CPU consumption on the affected Erlang service, leading to denial of service for all clients during and after the malicious TLS handshake. Because the vulnerable code path runs before signature or trust-chain verification, any Erlang service that parses peer TLS certificates is exposed — including TLS clients (which always parse server certificates) and TLS servers configured with verify_peer. Notably affected ecosystem applications include RabbitMQ, EMQX, and ejabberd/MongooseIM. There is no confidentiality or integrity impact; the attack is purely an availability concern (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been observed as of the disclosure date (Feedly). The EPSS score is approximately 0.25%, reflecting low current exploitation probability. The vulnerability is rated automatable by NVD SSVC analysis, meaning an attacker can reliably trigger it without user interaction by initiating a TLS handshake with a crafted certificate. No threat actor attribution or CISA KEV catalog listing has been reported (GitHub Advisory).

1. Reconnaissance: Identify internet-facing services running Erlang/OTP (e.g., RabbitMQ on port 5671, EMQX on port 8883, ejabberd on port 5222/5223) using tools like Shodan or Censys, targeting versions prior to OTP 27.3.4.18, 28.5.0.7, or 29.1.1.
2. Craft malicious certificate: Generate a self-signed X.509 certificate containing an AlgorithmIdentifier or SubjectPublicKeyInfo field with a DER-encoded OBJECT IDENTIFIER that includes a single arc encoded with approximately 262 KB of base-128 continuation bytes (each byte with the high bit set).
3. Initiate TLS handshake: Connect to the target service and present the crafted certificate during the TLS handshake. For servers using verify_peer, the attacker acts as a client presenting the malicious certificate; for TLS clients, the attacker operates a malicious server.
4. Trigger quadratic CPU consumption: The target's dec_subidentifiers function processes the oversized OID arc, consuming approximately 13 seconds of CPU per connection on typical hardware before any signature verification occurs.
5. Sustain denial of service: Repeat connections in parallel or sequence to keep the target's CPU saturated, preventing legitimate clients from completing handshakes (GitHub Advisory, Fix Commit).

• Network: Repeated inbound TLS connections from the same or rotating source IPs that do not complete the handshake successfully; unusually large TLS ClientHello or Certificate messages (~262 KB or larger).
• Process: Sustained high CPU utilization on the Erlang VM (beam.smp) process without a corresponding increase in legitimate traffic or application load; CPU spikes correlated with new TLS connection attempts.
• Logs: Erlang/OTP SSL application logs showing repeated handshake failures or timeouts from the same source; application-level logs (e.g., RabbitMQ, EMQX) recording connection errors or authentication failures at an abnormal rate.
• System: Load average spikes on the host coinciding with TLS connection bursts; watchdog or health-check failures for Erlang-based services during periods of normal network traffic volume (GitHub Advisory).

Upgrade to one of the patched Erlang/OTP releases: 27.3.4.18, 28.5.0.7, or 29.1.1 (corresponding asn1 library versions 5.3.4.3, 5.4.3.1, and 5.5.2). The fix limits OID subidentifier length to 16 continuation bytes (112 bits), rejecting overlong components and eliminating the quadratic work. No configuration-based workaround exists; however, the advisory notes that TLS servers not configured with verify_peer are not exposed via the server-side path, so disabling peer certificate verification can reduce (but not eliminate) attack surface for server deployments. Implementing rate limiting on TLS connection attempts from untrusted sources and network segmentation can reduce exposure until patching is complete (GitHub Advisory, Fix Commit).

The advisory was published by Erlang/OTP maintainer IngelaAndin on September 22, 2026, with credits to reporter tynus2 and remediation developer jhogberg. The fix was noted to align with Go's approach of limiting OID arc size to 30 bits per component, suggesting cross-ecosystem awareness of this class of vulnerability. No significant broader media coverage or notable public researcher commentary beyond the official advisory has been identified at this time (GitHub Advisory).