VulnFeed.org: pyasn1

CVE-2026-119196: pyasn1 has quadratic CPU consumption in constructed BIT STRING decoding

Fri, 30 Oct 2026 23:07:04 +0000

## Summary In pyasn1 through 0.6.4, decoding a constructed BIT STRING with many fragments repeatedly shifts and copies the entire value accumulated so far. For fixed-size fragments, CPU time grows quadratically with the encoded input size. An application that passes sufficiently large, attacker-controlled ASN.1 data to an affected decoder can suffer CPU exhaustion during `decode()`; no conversion or formatting of the decoded value is required. The BER and CER decoders reach this path for constructed BIT STRING values, with or without an `asn1Spec`. The DER decoder rejects constructed BIT STRING in schema-less decoding, but its schema-driven path accepts a **definite-length** constructed BIT STRING when given a matching `asn1Spec` and reaches the same vulnerable code. Constructed BIT STRING is not valid DER; this DER exposure is due to decoder permissiveness. DER rejects the indefinite-length form. This is a separate decoder path from the OBJECT IDENTIFIER accumulation fixed in [CVE-2026-59885](https://github.com/advisories/GHSA-8ppf-4f7h-5ppj). ## Technical details In the 0.6.4 [`BitStringPayloadDecoder`](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/ber/decoder.py#L173-L301), both the [definite-length](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/ber/decoder.py#L237-L255) and [indefinite-length](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/ber/decoder.py#L275-L301) fragment loops call `BitString.fromOctetString(..., prepend=bitString)` for every fragment. [`fromOctetString`](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/type/univ.py#L614-L627) shifts the growing `SizedInteger` left by the fragment's bit length and ORs in the fragment. Shifting an ever-larger Python integer for each fixed-size fragment makes total work O(n²) for n fragments. The fragments are siblings, so the decoder's nesting-depth limit does not constrain their count; its limit on the number of length octets does not prevent the demonstrated inputs. In…

CVE-2026-119197: pyasn1 has quadratic-complexity denial of service in binary REAL decoding

Fri, 30 Oct 2026 23:06:46 +0000

## Summary In pyasn1 0.6.4 and earlier, decoding a binary-encoded ASN.1 REAL with a large mantissa can consume CPU time quadratic in the mantissa length. The BER, CER, and DER decoders all use the affected `RealPayloadDecoder`. An application is exposed when it passes attacker-controlled ASN.1 containing a REAL value to one of these decoders, either without an `asn1Spec` or with a schema that includes REAL. The work occurs inside `decode()`; the application does not need to convert, print, or otherwise use the resulting REAL object. This is distinct from [CVE-2026-59886](https://github.com/advisories/GHSA-hm4w-wwcw-mr6r), which concerns converting an already-decoded REAL to a Python float. That issue was fixed in 0.6.4 and its advisory states that decoding alone does not trigger it. ## Root cause and affected components For binary REAL values, [`RealPayloadDecoder.valueDecoder` in v0.6.4](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/ber/decoder.py#L535-L603) builds the mantissa one octet at a time: ```python p = 0 while chunk: p <<= 8 p |= chunk[0] chunk = chunk[1:] ``` Each shift processes an integer that grows with the mantissa; with byte strings, each slice also copies the remaining suffix. Repeating both operations for every octet makes decoding quadratic in mantissa size. The decoder's [eight-octet length-field limit](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/ber/decoder.py#L1704-L1717) does not impose a practical mantissa-size limit for the inputs demonstrated below. [CER](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/cer/decoder.py#L51-L62) and [DER](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/der/decoder.py#L23-L31) reuse the BER REAL payload decoder, so all three paths reach this loop. The vulnerable loop is present in every available repository release tag inspected, from v0.2.1 through v0.6.4. Runtime measurements below were made on v0.6.4; older releases were checked for the loop, not benchmarked in…

CVE-2026-119195: pyasn1 has quadratic-time denial of service in constructed string and indefinite-length ANY decoding

Fri, 30 Oct 2026 23:03:51 +0000

## Summary In pyasn1 0.6.4 and earlier, decoding a constructed OCTET STRING or character string made of many fragments can spend disproportionate CPU time repeatedly copying the accumulated value. A separate indefinite-length `ANY` path has the same problem while collecting the encoded components. The work grows roughly quadratically with the number of fixed-size fragments, although the input and decoded value grow linearly. An application that lets an attacker supply such ASN.1 input to an affected decoder can suffer CPU exhaustion. The affected string paths are available in BER and CER. The DER decoder also accepts certain *non-DER* constructed strings: a definite-length constructed OCTET STRING when an `asn1Spec` selects `univ.OctetString`, and constructed character strings such as UTF8String even without a schema. Indefinite-length `ANY` is affected in BER and CER when an `asn1Spec` selects `univ.Any`; DER rejects indefinite lengths. This is a distinct decoder path from the OBJECT IDENTIFIER/RELATIVE-OID accumulation addressed by [CVE-2026-59885](https://github.com/advisories/GHSA-8ppf-4f7h-5ppj). It has the same complexity class, but the OID fix in 0.6.4 did not change these string or `ANY` loops. ## Technical details In the [v0.6.4 BER decoder](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/ber/decoder.py), `OctetStringPayloadDecoder` appends each decoded fragment to a growing `bytes` value with `header += component` in both its [definite-length](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/ber/decoder.py#L338-L351) and [indefinite-length](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/ber/decoder.py#L368-L387) constructed forms. [`AnyPayloadDecoder.indefLenValueDecoder`](https://github.com/pyasn1/pyasn1/blob/v0.6.4/pyasn1/codec/ber/decoder.py#L1403-L1430) similarly uses `chunk += component`. In the exercised paths, each concatenation copies an increasingly large prefix. For `N` fixed-size fragments, the total copied data gr…

CVE-2026-119194: pyasn1 has quadratic CPU use in schemaless BER/CER/DER container decoding

Fri, 30 Oct 2026 23:03:37 +0000

### 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 enc_tag(tag_id): groups = [tag_id & 0x7f] tag_id >>= 7 while tag_id: groups.append((tag_id & 0x7f) | 0x80) tag_id >>= 7 return b'\xbf' + bytes(reversed(groups)) def payload(tag_ids): body = b''.join(enc_tag(tag_id) + b'\x03\x04\x01A' for tag_id in tag_ids) length = len(body).to_bytes((len(body).bit_length() + 7) // 8, 'big') return b'\x30' + bytes([0x80 | len(length)]) + length + body for count in (3200, 6400): cases = ( ("collision", [32 + i * sys.hash_info.modulus for i in range(count)]), ("control", [(1 << 70) + i for i in range(count)]), ) for name, tag_ids in cases: wire = payload(tag_ids) start = time.process_time() value, remainder = decoder.decode(wire) cpu_s…