chore(deps): update dependency pyasn1 to v0.6.5 [security] by renovate[bot] · Pull Request #1044 · RonaldHensbergen/composable-data-stack

renovate · 2026-10-31T09:38:13Z

This PR contains the following updates:

Package	Change	Age	Confidence
pyasn1 (changelog)	`0.6.4` → `0.6.5`

pyasn1 has quadratic CPU use in schemaless BER/CER/DER container decoding

CVE-2026-119194 / GHSA-fm9c-5rcf-2q5p

More information

Details

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:

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_seconds = time.process_time() - start

        assert type(value) is univ.Sequence
        assert len(value) == count and remainder == b''
        for position, tag_id in enumerate(tag_ids):
            component = value.getComponentByPosition(position)
            assert component.asOctets() == b'A'
            assert component.tagSet[-1].tagId == tag_id

        print(count, name, len(wire), round(cpu_seconds, 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.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

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

CVE-2026-119195 / GHSA-9m75-vc3g-4x39

More information

Details

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. 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, OctetStringPayloadDecoder appends each decoded fragment to a growing bytes value with header += component in both its definite-length and indefinite-length constructed forms. AnyPayloadDecoder.indefLenValueDecoder similarly uses chunk += component. In the exercised paths, each concatenation copies an increasingly large prefix. For N fixed-size fragments, the total copied data grows with 1 + 2 + ... + N, or O(N²).

The OCTET STRING decoder is also the base class of the decoders for UTF8String, NumericString, PrintableString, TeletexString, VideotexString, IA5String, GraphicString, VisibleString, GeneralString, UniversalString, BMPString, ObjectDescriptor, GeneralizedTime, and UTCTime. These types inherit the same constructed-string reassembly path.

The DER decoder's OCTET STRING restriction replaces the tag-driven decoder, but its schema-driven TYPE_MAP retains the BER-derived decoder. Thus der.decode(data) rejects a constructed OCTET STRING, while der.decode(data, asn1Spec=univ.OctetString()) accepts its definite-length form and reaches the accumulation loop. DER does not replace the inherited character-string decoders, so a constructed UTF8String is also accepted without asn1Spec. These inputs violate X.690's DER string-encoding rule and should not be described as valid DER encodings.

The original short-fragment, definite-length OCTET STRING reproducer is valid BER. The CER decoder accepts it, but it is not a conforming CER string encoding: X.690 requires an indefinite-length outer constructed string and 1,000 contents octets per fragment except possibly the last. A conforming CER-shaped constructed OCTET STRING with those fragment sizes also reaches the loop and shows quadratic growth. The indefinite-length ANY reproducer below can represent a CER SEQUENCE OF OCTET STRING and reaches the separate ANY loop when decoded with an ANY schema.

The decoder's eight-octet length-field limit and nesting-depth limit do not bound the number of sibling fragments in these examples. The BER reproducer below uses only a three-octet outer length field; all fragments have shallow nesting. There is no per-message fragment-count cap in v0.6.4.

Impact

If an application passes attacker-controlled ASN.1 to the affected decode() or StreamingDecoder path without an adequate input or resource limit, a megabyte-scale value can occupy a decoding worker for seconds. Repeated inputs can exhaust available CPU. Whether this is reachable before authentication, or through a particular protocol, depends on the application; the library finding alone does not establish those conditions. No confidentiality or integrity impact is claimed.

Severity assessment (CVSS v3.1)

The 7.5 Base score assumes a reasonable application that automatically decodes attacker-supplied ASN.1 from unauthenticated network input. Valid BER and conforming CER inputs trigger the string-reassembly issue without special conditions, privileges, or user interaction. Repeated crafted inputs could occupy all available decoder workers and deny service while the attack continues. No confidentiality or integrity impact is demonstrated. This library-level score does not assert that every adopter has such an endpoint or loses all service; deployment-specific input limits and architecture may change the score. See FIRST's library-scoring guidance.

On the official v0.6.4 tag, local CPU-time measurements with CPython 3.14.8 on macOS arm64 gave the following results. Times vary by machine and Python runtime; the input-size scaling is the relevant observation. “Fixed” means the local 0.6.5 decoder fix applied to the same inputs.

Decoder path and input	Fragments	v0.6.4 CPU	Fixed CPU
BER constructed OCTET STRING, 0.40 MB	100,000 × 2 payload bytes	0.340 s	0.160 s
BER constructed OCTET STRING, 0.80 MB	200,000 × 2 payload bytes	0.886 s	0.312 s
BER constructed OCTET STRING, 1.60 MB	400,000 × 2 payload bytes	2.738 s	0.623 s
BER indefinite `ANY`, 0.30 MB	100,000 × 1 payload byte	0.459 s	0.206 s
BER indefinite `ANY`, 0.60 MB	200,000 × 1 payload byte	1.245 s	0.412 s
BER indefinite `ANY`, 1.20 MB	400,000 × 1 payload byte	3.980 s	0.826 s
CER constructed OCTET STRING, 1.00 MB, conforming fragment layout	1,000 × 1,000 payload bytes	0.0089 s	0.0022 s
CER constructed OCTET STRING, 2.01 MB, conforming fragment layout	2,000 × 1,000 payload bytes	0.0311 s	0.0044 s
CER constructed OCTET STRING, 4.02 MB, conforming fragment layout	4,000 × 1,000 payload bytes	0.1379 s	0.0090 s

For the same short-fragment layout, the original report measured up to 16.05 seconds for a 3.2 MB BER constructed OCTET STRING. An independent report on CPython 3.11.16/Linux measured 5.76 seconds for a 2.4 MB constructed OCTET STRING, versus about 0.005 seconds for a primitive OCTET STRING of comparable size. These are reporter measurements on different systems, not fixed performance guarantees.

Reproduction

This example uses public decoder APIs. Run it with pyasn1 0.6.4 and increase n to observe the scaling. The final two calls show the DER paths accepted by v0.6.4; their constructed encodings are not valid DER.

import time

from pyasn1.codec.ber import decoder as ber
from pyasn1.codec.cer import decoder as cer
from pyasn1.codec.der import decoder as der
from pyasn1.type import univ

def tlv(identifier, contents):
    length = len(contents)
    if length < 128:
        return bytes((identifier, length)) + contents
    encoded = length.to_bytes((length.bit_length() + 7) // 8, "big")
    return bytes((identifier, 0x80 | len(encoded))) + encoded + contents

def measure(label, decode, substrate, asn1Spec=None):
    start = time.process_time()
    _, rest = decode(substrate, asn1Spec=asn1Spec)
    assert not rest
    print(f"{label}: {len(substrate)} input bytes, "
          f"{time.process_time() - start:.3f} CPU seconds")

n = 100_000
octet_fragments = b"\x04\x02AA" * n
utf8_fragments = b"\x0c\x02AA" * n

measure("BER constructed OCTET STRING", ber.decode,
        tlv(0x24, octet_fragments))
measure("BER indefinite ANY", ber.decode,
        b"\x30\x80" + b"\x04\x01A" * n + b"\x00\x00",
        univ.Any())

##### CER uses indefinite length and 1,000-content-octet primitive fragments.
cer_fragment = tlv(0x04, b"A" * 1000)
measure("CER constructed OCTET STRING", cer.decode,
        b"\x24\x80" + cer_fragment * 1000 + b"\x00\x00")

##### These constructed encodings are accepted by pyasn1 but are invalid DER.
measure("DER OCTET STRING with schema", der.decode,
        tlv(0x24, octet_fragments), univ.OctetString())
measure("DER UTF8String without schema", der.decode,
        tlv(0x2c, utf8_fragments))

Patch

pyasn1 0.6.5 replaces the growing bytes accumulator with a list of fragments and joins them once after decoding in all three affected loops. The OCTET STRING base-class change also covers the inheriting character-string decoders. This removes the repeated copying while preserving the assembled decoded value.

Workaround

Until upgrading, enforce application-appropriate limits on the size of untrusted ASN.1 input before passing it to pyasn1, and limit the CPU resources available to decoding workers. Applications that require DER can also reject constructed string encodings before invoking the decoder. The appropriate byte limit depends on the protocol and expected valid values.

Credits and references

Reported by alimony. Independently reported by manus-pi, whose report identified the schema-driven DER route, inherited character-string decoders, and additional performance evidence.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

pyasn1 has quadratic-complexity denial of service in binary REAL decoding

CVE-2026-119197 / GHSA-mm57-4v3p-rchx

More information

Details

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, 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 mantissa one octet at a time:

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 does not impose a practical mantissa-size limit for the inputs demonstrated below. CER and DER 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 individually.

Impact

A comparatively small REAL value can hold a decoder worker on one CPU core for seconds or longer. The attacker must be able to supply data that the application sends to an affected decoder, and application-level input limits may reduce exposure. The demonstrated effect is CPU exhaustion during decoding; this advisory does not assert a network endpoint, unauthenticated access, or an affected downstream application by itself.

Reproduction and evidence

The following example uses pyasn1 0.6.4. The 0x09 tag identifies REAL; 0x80 0x00 selects a positive, base-2 binary value with a one-octet zero exponent, followed by a large mantissa. It exercises decode() only.

import time

from pyasn1.codec.ber import decoder as ber
from pyasn1.codec.cer import decoder as cer
from pyasn1.codec.der import decoder as der

def real_value(mantissa_octets):
    content = b"\x80\x00" + b"\xff" * mantissa_octets
    length = len(content).to_bytes(3, "big")
    return b"\x09\x83" + length + content

for codec in (ber, cer, der):
    for size in (50_000, 100_000, 200_000):
        substrate = real_value(size)
        started = time.process_time()
        value, rest = codec.decode(substrate)
        print(codec.__name__, size, time.process_time() - started)
        assert not rest
        assert tuple(value)[1:] == (2, 0)

The original report measured the following BER CPU times on repository commit aa05757. That commit is later than the official v0.6.4 tag; the vulnerable loop is identical in the tagged release.

Mantissa size	Reporter's BER CPU time
50,000 octets	0.328 s
100,000 octets	1.299 s
200,000 octets	6.043 s
400,000 octets	24.095 s

The same report measured 5.645 s for a 200,000-octet mantissa through DER.

A separate local reproduction on the official v0.6.4 tag (d43496f, CPython 3.14.8, macOS arm64) measured BER at 0.209 s, 0.884 s, and 3.451 s for 50,000, 100,000, and 200,000 mantissa octets respectively. CER and DER each took about 0.89 s at 100,000 octets. These are machine-specific measurements; the repeated near-fourfold cost for doubled input is the relevant result. Neither reproduction calls float(), str(), or prettyPrint().

Fix

pyasn1 0.6.5 replaces the per-octet shift and slice loop with one int.from_bytes(bytes(chunk), "big") conversion. Sign, scale, exponent, and the decoded REAL tuple are preserved. The fix is in the shared BER payload decoder and therefore covers BER, CER, and DER. A local check of the 0.6.5 candidate decoded a 200,000-octet mantissa correctly through all three codecs; the check does not establish behavior for every application using REAL.

Workarounds

Upgrade to pyasn1 0.6.5. Until then, reject or strictly limit attacker-controlled ASN.1 input that may contain REAL values before passing it to pyasn1. The appropriate size limit depends on the application's available CPU time and request volume.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

pyasn1 has quadratic CPU consumption in constructed BIT STRING decoding

CVE-2026-119196 / GHSA-2qm8-x737-gmw5

More information

Details

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.

Technical details

In the 0.6.4 BitStringPayloadDecoder, both the definite-length and indefinite-length fragment loops call BitString.fromOctetString(..., prepend=bitString) for every fragment. fromOctetString 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 0.6.4, DER's tag-driven map disables constructed BIT STRING, while its schema-driven type map retains the inherited decoder that permits it. This explains why a schema-less DER rejection is not a negative result for all DER decoding.

Under X.690, a conforming CER constructed BIT STRING uses an indefinite-length outer encoding and primitive fragments with 1000 contents octets except possibly the last. That form reaches the affected indefinite-length loop. DER requires primitive string encoding, although the schema-driven pyasn1 decoder accepts the definite-length constructed example below.

Impact

An application is exposed when untrusted input can reach one of the affected decoder paths and its input limits admit enough fragments. The work occupies the decoding thread or worker and may cause denial of service. Whether the input is network-accessible or unauthenticated depends on the calling application. This advisory makes no claim that every application using pyasn1, or any particular protocol implementation, accepts such input.

Severity assessment (CVSS v3.1)

The 7.5 Base score assumes a reasonable application that automatically decodes attacker-supplied ASN.1 from unauthenticated network input. Valid BER and conforming CER values trigger the issue without special conditions, privileges, or user interaction. Repeated crafted values could occupy a finite decoder-worker pool and deny service while the attack continues. No confidentiality or integrity impact is demonstrated. This library-level score does not claim that every application is network-exposed or fully unavailable; deployment-specific input limits and architecture may change the score. See FIRST's library-scoring guidance.

Reproducer

The definite-length example below is valid BER. It is deliberately not a conforming CER or DER encoding. The second constructor uses conforming CER fragment sizing and framing. CPU times are machine-dependent; run the larger cases only in a local test environment.

import time

from pyasn1.codec.ber import decoder as ber_decoder
from pyasn1.codec.cer import decoder as cer_decoder
from pyasn1.codec.der import decoder as der_decoder
from pyasn1.error import PyAsn1Error
from pyasn1.type import univ

def encode_length(size):
    octets = size.to_bytes((size.bit_length() + 7) // 8, "big")
    return bytes((0x80 | len(octets),)) + octets

def definite_fragments(count):
    body = b"\x03\x02\x00\xa5" * count  # one data octet per BIT STRING fragment
    return b"\x23" + encode_length(len(body)) + body

def cer_fragments(count):
    # Each primitive fragment has 1000 contents octets: one unused-bits
    # octet (zero) followed by 999 data octets.
    fragment = b"\x03" + encode_length(1000) + b"\x00" + b"\xa5" * 999
    return b"\x23\x80" + fragment * count + b"\x00\x00"

def measure(label, decode, payload, **options):
    start = time.process_time()
    value, remainder = decode(payload, **options)
    print(label, len(payload), f"{time.process_time() - start:.3f}s CPU")
    assert not remainder and len(value) > 0

for count in (50_000, 100_000, 200_000):
    measure(f"BER {count} fragments", ber_decoder.decode,
            definite_fragments(count))

for count in (1_000, 2_000, 4_000):
    measure(f"CER {count} fragments", cer_decoder.decode,
            cer_fragments(count))

sample = definite_fragments(1_000)
measure("DER with BIT STRING schema", der_decoder.decode, sample,
        asn1Spec=univ.BitString())
try:
    der_decoder.decode(sample)
except PyAsn1Error:
    print("DER without schema rejects the constructed value")
else:
    raise AssertionError("DER unexpectedly accepted schema-less input")

Verification

Local measurements of the official v0.6.4 tag on CPython 3.14.8 used time.process_time(). A local 0.6.5 candidate containing the fix was timed on the same machine. Times are illustrative, not a guaranteed cost on other systems.

Input	Size	v0.6.4 CPU	0.6.5 candidate CPU
BER definite, 50,000 fragments	0.20 MB	0.530 s	0.084 s
BER definite, 100,000 fragments	0.40 MB	1.915 s	0.170 s
BER definite, 200,000 fragments	0.80 MB	7.392 s	0.344 s
Conforming CER, 1,000 fragments	1.004 MB	0.163 s	0.0035 s
Conforming CER, 2,000 fragments	2.008 MB	0.657 s	0.0070 s
Conforming CER, 4,000 fragments	4.016 MB	2.582 s	0.0144 s

The definite BER input with 100,000 fragments also decoded through DER with asn1Spec=univ.BitString() in 1.949 s on v0.6.4, versus 0.172 s with the 0.6.5 candidate. Schema-less DER rejected the same input. Independent reports reproduced the old behavior on v0.6.4: one measured 21.1 s for a 1.28 MB definite-length value; another measured 7.25 s for a 0.8 MB value versus 2.8 ms for a primitive BIT STRING carrying the same data volume. These measurements were taken on different systems and should not be compared as a single benchmark series.

Resolution

Upgrade to pyasn1 0.6.5. The decoder assembles fragment bits in a bytearray, preserves decoded bit values including intermediate-fragment padding, and converts the complete payload to a BIT STRING once. This removes the repeated shift of the growing integer in both constructed decoding loops.

For applications that cannot upgrade immediately, enforce an application-appropriate limit on untrusted ASN.1 input size before passing it to pyasn1. Such a limit bounds exposure but does not change the quadratic behavior of 0.6.4. Where a protocol forbids constructed BIT STRING, rejecting that encoding before decoding also prevents this path.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

pyasn1/pyasn1 (pyasn1)

`v0.6.5`

Compare Source

GHSA-mm57-4v3p-rchx: Decoded binary REAL mantissas in linear time
instead of repeatedly shifting a growing integer and slicing the
remaining bytes (thanks for reporting, manus-use, manus-pi, ucsurf,
adriank31)
GHSA-2qm8-x737-gmw5: Reassembled constructed BIT STRING fragments
in linear time while preserving their decoded bit values, including
intermediate fragment padding (thanks for reporting, manus-use)
GHSA-9m75-vc3g-4x39: Reassembled constructed OCTET STRING and
character-string fragments and indefinite-length ANY content in
linear time. Nested constructed OCTET STRING fragments now contribute
their decoded octets (thanks for reporting, alimony, manus-pi, adriank31)
GHSA-fm9c-5rcf-2q5p: Bounded schemaless container type tracking
after two distinct tag sets to prevent quadratic CPU use from
colliding long tag IDs (thanks for reporting, droideck)

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

sonarqubecloud · 2026-10-31T09:40:31Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

chore(deps): update dependency pyasn1 to v0.6.5 [security]

4626fe9

renovate Bot requested review from RonaldHensbergen and SemTiOne as code owners October 31, 2026 09:38

RonaldHensbergen approved these changes Oct 31, 2026

View reviewed changes

RonaldHensbergen merged commit 6402eba into main Oct 31, 2026
24 checks passed

RonaldHensbergen deleted the renovate/pypi-pyasn1-vulnerability branch October 31, 2026 11:22

Navigation Menu

Repository navigation

chore(deps): update dependency pyasn1 to v0.6.5 [security] - #1044

chore(deps): update dependency pyasn1 to v0.6.5 [security]#1044
RonaldHensbergen merged 1 commit into
mainfrom
renovate/pypi-pyasn1-vulnerability

renovate Bot commented Oct 31, 2026

Uh oh!

sonarqubecloud Bot commented Oct 31, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

renovate Bot commented Oct 31, 2026

pyasn1 has quadratic CPU use in schemaless BER/CER/DER container decoding

Details

Summary

Details

Proof of concept

Impact

Severity

References

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

Details

Summary

Technical details

Impact

Severity assessment (CVSS v3.1)

Reproduction

Patch

Workaround

Credits and references

Severity

References

pyasn1 has quadratic-complexity denial of service in binary REAL decoding

Details

Summary

Root cause and affected components

Impact

Reproduction and evidence

Fix

Workarounds

Severity

References

pyasn1 has quadratic CPU consumption in constructed BIT STRING decoding

Details

Summary

Technical details

Impact

Severity assessment (CVSS v3.1)

Reproducer

Verification

Resolution

Severity

References

Release Notes

v0.6.5

Configuration

Uh oh!

sonarqubecloud Bot commented Oct 31, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

`v0.6.5`