pyasn1 EUVD-2026-113353

The application must pass attacker-controlled ASN.1 to pyasn1's BER, CER, or DER decode(), either with no asn1Spec or with a schema that includes REAL; the input must contain a binary-encoded REAL (tag 0x09, binary/base flag set) with a large mantissa. The expensive work occurs entirely inside decode() - the application does NOT need to convert the REAL to float, print, or otherwise use it (this distinguishes it from CVE-2026-59886, which required float() conversion). Limiting factors that reduce real-world risk: exploitation requires that untrusted ASN.1 actually reaches an affected decoder, and any application-level input size limit on the REAL/mantissa directly caps the achievable CPU cost; the advisory does not assert network reachability or unauthenticated access on its own, so exposure is deployment-dependent. The only complete fix stated by the vendor is upgrading to 0.6.5; until then the stated workaround is to reject or strictly size-limit attacker-controlled ASN.1 that may contain REAL values before decoding.

This is a CWE-407 quadratic-complexity denial-of-service in pyasn1's binary REAL decoder, scored CVSS 7.5 with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - a pure availability impact (C:N/I:N) with no confidentiality or integrity consequence. The vendor priority label is 'this_week', not act_now or emergency, which is consistent with a resource-exhaustion bug rather than code execution. No EPSS score and no CISA KEV entry are present in the input, and there is no indication of active exploitation, so by the precision rules this is 'no public exploit identified' in the KEV sense; however, the GHSA advisory itself publishes working reproduction code and reporter CPU-time measurements, so a public proof-of-concept clearly exists. The CVSS network vector and PR:N should be read with caution: the vendor advisory explicitly states it 'does not assert a network endpoint, unauthenticated access, or an affected downstream application by itself' - exposure depends entirely on whether a given application feeds attacker-controlled ASN.1 to BER/CER/DER decode(). Net assessment: a credible, easy-to-trigger single-core CPU-exhaustion issue affecting a very widely used library, but the real-world severity is bounded by application-level input limits and by whether the decoder is actually reachable with untrusted input. Prioritize patching where pyasn1 parses external ASN.1, but this is not a critical RCE-class emergency.

An attacker submits a small ASN.1 message containing a binary-encoded REAL value with a large mantissa (e.g., a few hundred thousand octets) to any application that passes untrusted input to pyasn1's BER, CER, or DER decode(). Decoding alone - no float conversion, printing, or use of the result - consumes CPU time quadratic in mantissa length, pinning one worker on one CPU core for seconds or longer per request and causing availability loss. Working reproduction code and timing measurements (e.g., ~6 s for a 200,000-octet mantissa, ~24 s for 400,000) are published in the GHSA advisory.