JEDI-SEC | Security Research & Digital Defense

Tag: high

  • GHSA-4vqv-7265-gm2w: pypdf has possible large memory usage for exceptions in strict mode

    • Severity: HIGH
    • CVE: CVE-2026-119207
    • Ecosystems: pip
    • Packages: pypdf

    ### Impact

    An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires loading an invalid dictionary.

    ### Patches

    This has been fixed in [pypdf==6.21.3](https://github.com/py-pdf/pypdf/releases/tag/6.21.3).

    ### Workarounds

    If you cannot upgrade yet, consider applying the changes from PR [#4265](https://github.com/py-pdf/pypdf/pull/4265).

    Source: GitHub Security Advisories · 2026-10-30

  • GHSA-62m5-6wh8-28×7: pypdf has possible long runtimes/large memory usage for encrypted PDF files

    • Severity: HIGH
    • CVE: CVE-2026-119208
    • Ecosystems: pip
    • Packages: pypdf

    ### Impact

    An attacker who uses this vulnerability can craft a PDF which leads to large runtimes/memory usage. This requires accessing the page count of an encrypted PDF file, which itself declares a wrong `/Count` value.

    ### Patches

    This has been fixed in [pypdf==6.21.3](https://github.com/py-pdf/pypdf/releases/tag/6.21.3).

    ### Workarounds

    If you cannot upgrade yet, consider applying the changes from PR [#4270](https://github.com/py-pdf/pypdf/pull/4270).

    Source: GitHub Security Advisories · 2026-10-30

  • GHSA-x3rh-gjgm-fmqc: pypdf has possible large memory usage when parsing cross-reference streams

    • Severity: HIGH
    • CVE: CVE-2026-119209
    • Ecosystems: pip
    • Packages: pypdf

    ### Impact

    An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires opening a file with cross-reference streams.

    ### Patches

    This has been fixed in [pypdf==6.21.3](https://github.com/py-pdf/pypdf/releases/tag/6.21.3).

    ### Workarounds

    If you cannot upgrade yet, consider applying the changes from PR [#4269](https://github.com/py-pdf/pypdf/pull/4269).

    Source: GitHub Security Advisories · 2026-10-30

  • GHSA-2qm8-x737-gmw5: pyasn1 has quadratic CPU consumption in constructed BIT STRING decoding

    • Severity: HIGH
    • CVE: CVE-2026-119196
    • Ecosystems: pip
    • Packages: pyasn1

    ## 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=bitStrin…

    Source: GitHub Security Advisories · 2026-10-30

  • GHSA-mm57-4v3p-rchx: pyasn1 has quadratic-complexity denial of service in binary REAL decoding

    • Severity: HIGH
    • CVE: CVE-2026-119197
    • Ecosystems: pip
    • Packages: pyasn1

    ## 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

    Source: GitHub Security Advisories · 2026-10-30

  • GHSA-9m75-vc3g-4×39: pyasn1 has quadratic-time denial of service in constructed string and indefinite-length ANY decoding

    • Severity: HIGH
    • CVE: CVE-2026-119195
    • Ecosystems: pip
    • Packages: pyasn1

    ## 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:/…

    Source: GitHub Security Advisories · 2026-10-30

  • GHSA-fm9c-5rcf-2q5p: pyasn1 has quadratic CPU use in schemaless BER/CER/DER container decoding

    • Severity: HIGH
    • CVE: CVE-2026-119194
    • Ecosystems: pip
    • Packages: pyasn1

    ### 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))…

    Source: GitHub Security Advisories · 2026-10-30

  • GHSA-7wch-p9px-956x: Forge: Regular expression denial of service in PEM decoding (pem.decode)

    • Severity: HIGH
    • CVE: CVE-2026-118779
    • Ecosystems: npm
    • Packages: node-forge

    ### Summary
    `pem.decode()`, which every node-forge API that parses PEM input uses, split messages with a regular expression that takes polynomial time on input without a matching END line, and parsed encapsulated headers with regular expressions that take quadratic time on long header lines. A remote attacker can block the Node.js event loop for seconds to minutes with a crafted input of a few tens of kilobytes. Fixed in node-forge 1.4.1.

    ### Details
    `pem.decode()` in `lib/pem.js` found PEM messages with this regular expression:

    /\s*—–BEGIN ([A-Z0-9- ]+)—–\r?\n?([\x21-\x7e\s]+?(?:\r?\n\r?\n))?([:A-Za-z0-9+\/=\s]+?)—–END \1—–/g

    The optional headers group and the body group are adjacent, lazy, and share characters (whitespace and the base64 alphabet), and the match must end with an END line whose label equals the BEGIN label (`\1`). When no such END line follows, the engine tries every split of the text between the two groups, for every label split and at every BEGIN line in the input. The work grows polynomially with the input length (roughly cubic for repeated BEGIN/END lines with mismatched labels, quadratic for a BEGIN line followed by many newlines).

    The encapsulated header parsing in the same function had two smaller quadratic cases: trimming each header line with `/\s+$/`, and an unanchored header regex `([\x21-\x7e]+):…` that retries at every position of a long line without a colon. These are reachable when a message does match.

    All PEM entry points…

    Source: GitHub Security Advisories · 2026-10-30

  • GHSA-jc66-7q78-782g: Forge: PKCS#12 MAC forgery and constant-key PBE via zero iteration count

    • Severity: HIGH
    • CVE: CVE-2026-118782
    • Ecosystems: npm
    • Packages: node-forge

    ### Summary

    forge.pkcs12.pkcs12FromAsn1() accepts a PKCS#12 MAC iteration count of zero (or less) from the input, and the PKCS#12 key derivation function then returns a constant key that does not depend on the password or salt. An attacker who does not know the password can modify a PKCS#12/PFX file and compute a MAC that verifies with any password; PKCS#12 PBE-encrypted private keys prepared the same way decrypt with any password. Fixed in node-forge 1.4.1.

    ### Details

    `p12.pkcs12FromAsn1()` in `lib/pkcs12.js` reads the MAC iteration count (`MacData.iterations`) from the input and passes it to the PKCS#12 key derivation function `pki.pbe.generatePkcs12Key()` in `lib/pbe.js` (also exposed as `forge.pkcs12.generateKey()`) without checking that it is at least 1. The key derivation function (RFC 7292 Appendix B.2) runs its hash loop `iter` times. With an iteration count of 0 (or an empty or negative INTEGER), no hashing is done and the function returns the PKCS#12 diversifier ID byte repeated, for example `0x03` repeated 20 times for an HMAC-SHA1 MAC key. The result does not depend on the password or the salt, so anyone can compute a valid MAC over arbitrary PFX contents.

    The same key derivation function is used by `pki.pbe.getCipherForPKCS12PBE()` for the PKCS#12 password-based encryption schemes `pbeWithSHAAnd3-KeyTripleDES-CBC` and `pbewithSHAAnd40BitRC2-CBC`, whose `pkcs-12PbeParams` iteration count is also read from the input. With an iteration count of 0 or less, the e…

    Source: GitHub Security Advisories · 2026-10-30

  • GHSA-8hrf-8g6f-7xwp: Forge: Denial of service in TLS record processing via a record interleaved with a fragmented handshake message

    • Severity: HIGH
    • CVE: CVE-2026-119188
    • Ecosystems: npm
    • Packages: node-forge

    ### Summary

    A connection created with `forge.tls.createConnection()` throws an uncaught `TypeError` from `process()` when it receives a record of another content type while waiting for the rest of a handshake message that was split across records. A peer can trigger this with 18 bytes before the handshake, without authentication, which terminates Node.js processes that use the documented socket wiring. Fixed in node-forge 1.4.1.

    ### Details

    In `lib/tls.js`, `_readRecord()` handles a record that arrives while a handshake message split across records is incomplete. If the record has any other content type (change_cipher_spec, alert, application_data or heartbeat), forge correctly reports “Invalid fragmented record.” through `c.error()` with a fatal `unexpected_message` alert. That fatal error closes and resets the connection, which sets `c.record` to `null`. `_readRecord()` then continues with `c.record.ready = true` and throws `TypeError: Cannot set properties of null (setting ‘ready’)` out of `process()`. The code is unchanged since the first release.

    RFC 5246 section 6.2.1 allows a handshake message to be fragmented across records, and RFC 8446 section 5.1 forbids interleaving handshake messages with other record types. Failing the connection with `unexpected_message` is the intended behavior; the bug is the crash after the error.

    node-forge reports TLS protocol errors through the `error` callback, so applications do not normally wrap `process()` in `try`/`catch`. When…

    Source: GitHub Security Advisories · 2026-10-30