Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 0.6.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, 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 builds the…
Recommended action: Upgrade to 0.6.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.6.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.6.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The univ.Real type converted its (mantissa, base, exponent) value to a Python float using exact big-integer exponentiation. A BER/CER/DER-encoded REAL value only a few bytes long can carry a very large exponent, causing this computation to attempt to materialize an astronomically large integer. Any operation that triggers float conversion on such a decoded value — prettyPrint(), str(), comparison, arithmetic, or an explicit float() call — consumes excessive CPU and memory, hanging the process. Applications that decode untrusted ASN.1 data and then print, log, or compare the decoded objects are vulnerable to denial of service. Decoding alone does not trigger the issue. Affected components - pyasn1.type.univ.Real — float conversion (float() and everything built on it: prettyPrint(), str(), comparisons, arithmetic, int()) - Reachable through the pyasn1.codec.ber, cer, and der decoders, which produce Real objects from untrusted input; also via directly constructed Real values The…
Recommended action: Upgrade to 0.6.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The BER/CER/DER decoders process OBJECT IDENTIFIER and RELATIVE-OID values in quadratic time relative to the number of arcs. A small crafted payload (tens of kilobytes) containing an OID with many arcs consumes seconds of CPU per decode() call, allowing denial of service in any application that decodes untrusted ASN.1 data (certificates, LDAP, SNMP, Kerberos, etc.). The corresponding encoders have the same quadratic behavior, reachable when an application re-encodes previously decoded attacker-supplied values. The arc-size limit introduced for CVE-2026-23490 bounds the byte length of an individual arc but not the number of arcs, so it does not mitigate this issue. Affected components ObjectIdentifierPayloadDecoder and RelativeOIDPayloadDecoder in pyasn1/codec/ber/decoder.py; ObjectIdentifierEncoder and RelativeOIDEncoder in pyasn1/codec/ber/encoder.py. The CER and DER codecs inherit these and are equally affected. Patches Fixed in pyasn1 0.6.4: arc accumulation in both…
Recommended action: Upgrade to 0.6.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The BER decoder (shared by the CER and DER codecs) parses long-form tags by accumulating continuation octets in a loop with no upper bound on the size of the tag ID. A crafted input can force the decoder to build an arbitrarily large integer, with CPU cost growing quadratically in input size — a ~1 MB input consumes over a minute of CPU. On Python 3.11+, the oversized tag ID can also trigger an unhandled ValueError (integer string conversion limit) while the decoder formats error messages, violating the documented PyAsn1Error contract and potentially bypassing caller error handling. Any application decoding untrusted BER/CER/DER input is affected. Affected components - pyasn1.codec.ber.decoder — decode() and StreamingDecoder - pyasn1.codec.cer.decoder and pyasn1.codec.der.decoder, which inherit the same tag parsing - pyasn1.type.tag — Tag/TagSet reprs could raise ValueError when rendering oversized tag IDs (reachable through decoder error paths) The encoders and the…
Recommended action: Upgrade to 0.6.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The pyasn1 library is vulnerable to a Denial of Service (DoS) attack caused by uncontrolled recursion when decoding ASN.1 data with deeply nested structures. An attacker can supply a crafted payload containing nested SEQUENCE (0x30) or SET (0x31) tags with Indefinite Length (0x80) markers. This forces the decoder to recursively call itself until the Python interpreter crashes with a RecursionError or consumes all available memory (OOM), crashing the host application. Details The vulnerability exists because the decoder iterates through the input stream and recursively calls decodeFun (the decoding callback) for every nested component found, without tracking or limiting the recursion depth. Vulnerable Code Locations: 1. indefLenValueDecoder (Line 998): This method handles indefinite-length constructed types. It sits inside a while True loop and recursively calls the decoder for every nested tag. 2. valueDecoder (Lines 786 and 907): This method handles standard decoding when a…
Recommended action: Upgrade to 0.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
After reviewing pyasn1 v0.6.1 a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets. Details The integer issue can be found in the decoder as reloid += ((subId << 7) + nextSubId,): https://github.com/pyasn1/pyasn1/blob/main/pyasn1/codec/ber/decoder.py#L496 PoC For the DoS: Screenshots with the results: DoS <img width="944" height="207" alt="Screenshot20251219160840" src="https://github.com/user-attachments/assets/68b9566b-5ee1-47b0-a269-605b037dfc4f" / <img width="931" height="231" alt="Screenshot20251219152815" src="https://github.com/user-attachments/assets/62eacf4f-eb31-4fba-b7a8-e8151484a9fa" / Leak analysis A potential heap leak was investigated but came back clean: Scenario 1. An attacker creates a malicious X.509 certificate. 2. The application validates certificates. 3. The application accepts the malicious certificate and tries decoding resulting in the issues mentioned above. Impact…
Recommended action: Upgrade to 0.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.