Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires opening an incomplete file without a trailer.
Patches
This has been fixed in pypdf==6.21.4.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #4289.
@hapi/content provides HTTP Content- header parsing. From 3.0.6 until 6.0.3, Content.disposition() uses an unanchored parameter-name expression in a global regular-expression scan, causing repeated failed matching over the remaining input when a Content-Disposition parameter contains a long token without an equals sign. The resulting quadratic processing can block the Node.js event loop before route handlers or validation when @hapi/pez parses multipart/form-data headers, including unauthenticated hapi routes with payload.multipart enabled, and also affects applications that pass untrusted headers directly to Content.disposition(). This issue is fixed in @hapi/content version 6.0.3.
Impact
When no appSecret is configured (via NUXTAPPSECRET, NITROAPPSECRET or runtimeConfig.appSecret), nuxt dev generates a development secret and stores it in <buildDir>/app-secret (by default .nuxt/app-secret). The build directory is inside the directories that Nuxt passes to Vite's server.fs.allow, so the file can be fetched from the dev server:
bash curl http://<dev-server>/nuxt/@fs/<absolute-path-to-project>/.nuxt/app-secret
Anyone who can read it can compute every secret derived from it with deriveSecret(), including the default password used by useSession, and so can forge session cookies accepted by that dev server.
Exploitation requires direct HTTP access to the dev server. nuxt dev listens on localhost by default, so this mainly affects dev servers that are exposed to a network (for example with --host, a published container port or a tunnel). A malicious website cannot read the file through a developer's browser: Vite's CORS and host checks prevent pages on other origins from reading the response.
Production builds never generate an appSecret and are not affected. Dev servers with an explicitly configured appSecret do not use the generated file.
Patches
Fixed in @nuxt/vite-builder 4.6.3, which nuxt 4.6.3 depends on. The dev server now adds app-secret to Vite's server.fs.deny, keeping Vite's default deny list.
Workarounds
Set NUXTAPPSECRET in .env to a random value of at least 32 characters (for example the output of openssl rand -base64 32), or avoid exposing the dev server to untrusted networks.
If a dev server using a generated secret has been reachable by untrusted clients, delete .nuxt/app-secret (a new secret is generated on the next nuxt dev) or set NUXTAPPSECRET. Either invalidates existing dev sessions.
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Summary
Since 4.6.0, Nuxt resolves . and .. segments in the request path, including percent-encoded forms such as %2e, before rendering a page. Nitro's routing, Nitro's route rules and server/middleware see the path with those segments still in place. A request for /%2e/admin therefore renders the page at /admin, while server-side checks keyed on /admin do not apply.
Impact
An unauthenticated attacker can bypass server-side controls that match on the request path of a page route.
server/middleware that checks event.path (or event.node.req.url) is skipped:
ts export default defineEventHandler((event) => { if (event.path.startsWith('/admin') && !isAuthenticated(event)) { throw createError({ statusCode: 401 }) } })
With this middleware, /admin returns 401, but /%2e/admin, /.%2e/admin and /x/%2e%2e/admin reach the middleware with event.path set to /./admin, /../admin and /x/../admin, and render app/pages/admin.vue along with the data it fetches during server rendering.
Server-side redirect and headers route rules are skipped in the same way, so '/admin/': { redirect: '/login' } does not redirect /%2e/admin/secret, and per-route security headers such as Content-Security-Policy are not sent.
Not affected:
- API handlers in server/api and server/routes. Nitro's router does not resolve dot segments, so these requests do not reach the handler. - appMiddleware route rules and middleware declared with definePageMeta, which are matched against the resolved route. - Nuxt 3.x and 4.0.0 to 4.5.x, which pass the path to the page router unchanged, so these requests 404.
Browsers resolve dot segments before sending a request, so exploitation requires a client that sends the path as written.
Patches
Fixed in nuxt@4.6.3 and @nuxt/nitro-server@4.6.3. A page request whose path contains . or .. segments now receives a 404 instead of rendering the page the path resolves to, and route-rule keys and lookup paths have their dot segments resolved, including percent-encoded spellings, before they are compared.
Workarounds
Reject dot segments in a server middleware that runs before your other middleware (middleware runs in file name order):
ts // server/middleware/0.dot-segments.ts export default defineEventHandler((event) => { if (/(?:^|\/)\.{1,2}(?:\/|$)/.test(event.path.split('?')[0])) { throw createError({ statusCode: 404 }) } })
Checking getRequestURL(event).pathname instead of event.path is not a sufficient workaround: it resolves dot segments, but keeps percent-encoding such as %61 that the page router decodes. Path checks in server middleware should also account for the page router matching paths case-insensitively unless router.options.sensitive is set.
A reverse proxy or CDN that normalises the request path before forwarding it also removes the mismatch.
Credits
Thanks to @vinzabe, @nikhilagrawalsf (Nikhil Agrawal, Mettle Labs), @0xjunwei and @kq5y, who reported this issue independently.
Summary
With Nitro 2 (the default server engine in Nuxt 3 and Nuxt 4), the Nitro development server bundle written by nuxt dev can be fetched through the Vite dev server. Nitro inlines the resolved runtimeConfig into that bundle, so private runtime config values that were resolved at build time can be read by anyone with HTTP access to the dev server.
Impact
nuxt dev writes the Nitro development server bundle to <buildDir>/dev/index.mjs (by default .nuxt/dev/index.mjs). The build directory is inside the directories Nuxt passes to Vite's server.fs.allow, so the bundle is served by the dev server:
bash curl http://<dev-server>/nuxt/@fs/<absolute-path-to-project>/.nuxt/dev/index.mjs
The response contains every private (non-public) runtime config value that was resolved at build time. That includes values set in nuxt.config, such as a secret read from .env:
ts export default defineNuxtConfig({ runtimeConfig: { apiSecret: process.env.APISECRET, }, })
From Nuxt 4.6.0, it also includes the generated development appSecret. Vite's default deny list blocks .env itself, but not the bundle containing values read from it.
Exploitation requires direct HTTP access to the dev server. nuxt dev listens on localhost by default, so this mainly affects dev servers that are exposed to a network (for example with --host, a published container port or a tunnel). As far as we can tell, a malicious website cannot read the file through a developer's browser: Vite's CORS and host checks prevent pages on other origins from reading the response.
Production builds are not affected, because the Vite dev server is not used and the server bundle is not served. Nuxt projects using Nitro 3 do not write the server bundle to disk in development and are not affected. Private runtime config values that are left empty in nuxt.config and supplied through NUXT environment variables are applied when the server starts, are not inlined into the bundle, and are not exposed.
Patches
Fixed in @nuxt/vite-builder 4.6.3, which nuxt 4.6.3 depends on. The dev server now adds Nitro's development output directory to Vite's server.fs.deny, keeping Vite's default deny list.
Nuxt 3 has reached end of life and will not receive a fix.
Workarounds
Avoid exposing the dev server to untrusted networks. Alternatively, set private runtime config keys to an empty default in nuxt.config and provide their values with the matching NUXT environment variables (for example runtimeConfig: { apiSecret: '' } with NUXTAPISECRET in .env).
If a dev server has been reachable by untrusted clients, rotate any credentials that were set through runtimeConfig in nuxt.config.
Summary
A client that can connect to the dev server's HMR socket can send a nuxt:dev:client-error event whose message ends in an absolute file path. The dev server reads that file while building the error report, and its contents are returned in the error overlay, on the dev error channel, and in the report shown in the terminal.
Impact
This affects the development server only; production builds contain none of this code. Affected versions are 4.6.0 to 4.6.2.
Reading the file requires TCP access to the dev server, so the default localhost bind limits this to local processes, which can usually read the same files directly. With the dev server exposed to a network (nuxt dev --host, nuxt dev --tunnel, or a proxy onto the dev port), anyone who can reach the port can read any file the dev process can read: SSH keys, .env files, cloud credentials and other files outside the project. The same path is refused by Vite's server.fs allow list over /nuxt/@fs/; the client error channel bypasses that check.
No user interaction is needed and no browser is involved: a plain WebSocket client is enough, as long as it does not send Sec-Fetch-Site: cross-site. A web page on another origin cannot retrieve the report: the overlay and channel endpoints reject browser requests from other origins.
Nuxt 3 is not affected.
Patches
Fixed in @nuxt/vite-builder 4.6.3, which nuxt 4.6.3 depends on. A client-reported error is no longer turned into a compile report, and report building for it no longer reads from the filesystem; file content now comes only from the dev server's module graph.
Workarounds
Do not expose the dev server to untrusted networks: keep the default localhost bind, and avoid nuxt dev --host, nuxt dev --tunnel and proxies onto the dev port. If the dev port was reachable from an untrusted network while a vulnerable version was running, treat any file readable by the dev process on that machine as exposed, and rotate credentials such as SSH keys and .env secrets.
Credits
Thanks to @samsulselfut for the report.
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:
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 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.
python 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 realvalue(mantissaoctets): content = b"\x80\x00" + b"\xff" mantissaoctets length = len(content).tobytes(3, "big") return b"\x09\x83" + length + content
for codec in (ber, cer, der): for size in (50000, 100000, 200000): substrate = realvalue(size) started = time.processtime() value, rest = codec.decode(substrate) print(codec.name, size, time.processtime() - 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.frombytes(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.
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.
python import time
from pyasn1.codec.ber import decoder as berdecoder from pyasn1.codec.cer import decoder as cerdecoder from pyasn1.codec.der import decoder as derdecoder from pyasn1.error import PyAsn1Error from pyasn1.type import univ
def encodelength(size): octets = size.tobytes((size.bitlength() + 7) // 8, "big") return bytes((0x80 | len(octets),)) + octets
def definitefragments(count): body = b"\x03\x02\x00\xa5" count # one data octet per BIT STRING fragment return b"\x23" + encodelength(len(body)) + body
def cerfragments(count): # Each primitive fragment has 1000 contents octets: one unused-bits # octet (zero) followed by 999 data octets. fragment = b"\x03" + encodelength(1000) + b"\x00" + b"\xa5" 999 return b"\x23\x80" + fragment count + b"\x00\x00"
def measure(label, decode, payload, options): start = time.processtime() value, remainder = decode(payload, options) print(label, len(payload), f"{time.processtime() - start:.3f}s CPU") assert not remainder and len(value) > 0
for count in (50000, 100000, 200000): measure(f"BER {count} fragments", berdecoder.decode, definitefragments(count))
for count in (1000, 2000, 4000): measure(f"CER {count} fragments", cerdecoder.decode, cerfragments(count))
sample = definitefragments(1000) measure("DER with BIT STRING schema", derdecoder.decode, sample, asn1Spec=univ.BitString()) try: derdecoder.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.processtime(). 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.
Important: java-21-openjdk security update for RHEL 8 and 9
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used asn1.fromDer(), BIT STRING decoding, maxDepth to process the relevant input or security decision. node-forge decoded ASN.1 stored inside BIT STRING values without consistently applying the configured maxDepth limit and recursively retained copies at each nesting level. Crafted DER containing nested BIT STRINGs could cause excessive recursion, CPU use, and quadratic memory consumption during asn1.fromDer(). This issue is fixed in version 1.4.1.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge parsed deprecated extension OIDs 2.5.29.10 and 2.5.29.13 as basicConstraints, and pki.verifyCertificateChain() used the first extension with that name. Exploitation requires a CA trusted by the application to issue a certificate carrying an attacker-supplied deprecated-OID extension, commonly because the CA copies extensions from a certificate signing request. By placing a permissive deprecated extension before the genuine 2.5.29.19 basicConstraints extension, the certificate holder could have the certificate accepted as a CA and issue certificates for arbitrary names, enabling server or client impersonation. If the issuing CA adds a keyUsage extension without keyCertSign, node-forge rejects the chain. This issue is fixed in version 1.4.1.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used forge.tls.createConnection(), TLS record processing, process() to process the relevant input or security decision. node-forge processed received TLS records recursively, consuming one JavaScript stack frame per record in a single input chunk. A remote peer could send thousands of small records together and exhaust the call stack, causing an uncaught exception and denial of service. This issue is fixed in version 1.4.1.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge did not validate the AES-GCM tagLength option passed to start() during decryption through forge.cipher.createDecipher(). When an application derived tagLength from received data or used an unset or zero-like configuration value, a value that converted to zero together with an empty or missing authentication tag caused the calculated and supplied tags to compare as empty, so decipher.finish() accepted unauthenticated ciphertext. Applications that omit tagLength to use the 128-bit default or pass a fixed valid tag length are unaffected. This issue is fixed in version 1.4.1.
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
ServiceNow has remediated a sandbox escape security issue that was identified in the ServiceNow AI Platform. This vulnerability could enable an authenticated user with the admin role to bypass Rhino sandbox restrictions and execute arbitrary code on the underlying host operating system, potentially enabling further unintended access.
ServiceNow deployed an update to hosted instances, and ServiceNow provided the update to our partners and self-hosted customers. We are not currently aware of malicious exploitation against ServiceNow instances. We recommend customers promptly apply appropriate updates or upgrade to a patched release if they have not already done so.
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 encryption key and IV are constants (0x01 and 0x02 repeated). This is reached from shrouded key bags and encrypted SafeContents in pkcs12FromAsn1(), and from forge.pki.decryptPrivateKeyInfo() (for example for ENCRYPTED PRIVATE KEY PEM input).
RFC 7292 defines MacData with iterations INTEGER DEFAULT 1; an iteration count only makes sense as 1 or more (RFC 8018 uses INTEGER (1..MAX) for the same concept). PBES2 (PBKDF2) encrypted content is not affected.
The fix rejects iteration counts less than 1 when verifying a PKCS#12 MAC in pkcs12FromAsn1() ("PKCS#12 MAC iteration count must be >= 1.") and at the entry of pki.pbe.generatePkcs12Key() ("PKCS#12 key derivation iteration count must be >= 1."), which covers the MAC, both PKCS#12 PBE schemes and direct forge.pkcs12.generateKey() callers.
Patches Fixed in node-forge 1.4.1. Iteration counts less than 1 are now rejected when verifying a PKCS#12 MAC and in the PKCS#12 key derivation function.
Workarounds Before calling forge.pkcs12.pkcs12FromAsn1(), reject inputs whose MacData.iterations is present and less than 1. For encrypted private keys using the PKCS#12 PBE schemes, there is no simple workaround other than checking the pkcs-12PbeParams iteration count before decryption, or upgrading.
Credits Reported by Thai, Calif.io in collaboration with Claude and Anthropic Research.
Proof of concept
Take any PKCS#12/PFX file, replace its AuthenticatedSafe with attacker-chosen content (for example the attacker's certificate and an unencrypted private key), set MacData.iterations to 0 (DER 02 01 00), and compute the HMAC-SHA1 over the new content with the key 0x03 repeated 20 times. On node-forge <= 1.4.0, forge.pkcs12.pkcs12FromAsn1(asn1, password) reports successful MAC verification for whatever password the application supplies and returns the attacker's certificate and key. An empty or negative iteration count behaves the same way. Likewise, a shrouded key bag or ENCRYPTED PRIVATE KEY using pbeWithSHAAnd3-KeyTripleDES-CBC with iteration count 0 decrypts with any password.
The constant key is visible directly:
js var salt = new forge.util.ByteBuffer('anysalt'); forge.pkcs12.generateKey('any password', salt, 3, 0, 20).toHex(); // <= 1.4.0: '0303030303030303030303030303030303030303' // 1.4.1: throws "PKCS#12 key derivation iteration count must be >= 1."
The fix adds regression tests in tests/unit/pkcs12.js and the reporter's PoC in tests/pocs/.
Impact
Applications that import PKCS#12/PFX files or PKCS#8 encrypted private keys from untrusted sources with forge.pkcs12.pkcs12FromAsn1() or forge.pki.decryptPrivateKeyInfo(), and rely on the password-based MAC or on successful decryption to establish that the file was produced by someone who knows the password. The default API and call pattern are affected; no password, oracle or user interaction is needed, only one offline HMAC.
An attacker can supply a PKCS#12 file with certificates and private keys of their choice (for example, replaced certificates or an unencrypted private key) that node-forge reports as verified under the application's password. The attacker does not learn the password or the original private key. PBES2 (PBKDF2) encrypted content is not affected.
ServiceNow has addressed a domain separation bypass security issue that was identified in the ServiceNow SR – CSM – Task Plan Templates Store application. This vulnerability could enable an authenticated user with a specific role to create records in domains they do not have access to, potentially leading to unauthorized data creation across domain boundaries.
We are not currently aware of malicious exploitation against ServiceNow instances. We recommend customers promptly apply appropriate updates or upgrade to a patched release if they have not already done so.
Summary
BigInteger.prototype.modInverse() in node-forge's bundled jsbn library enters an infinite loop when the value or the modulus is negative, for example when a negative public exponent is passed to forge.pki.rsa.generateKeyPair(). This is an incomplete fix of CVE-2026-33891 (GHSA-5m6q-g25r-mvwx), which handled only a zero value. Fixed in node-forge 1.4.1.
Details
bnModInverse() (lib/jsbn.js, exposed as forge.jsbn.BigInteger.prototype.modInverse) implements the binary extended Euclidean algorithm (Handbook of Applied Cryptography, Algorithm 14.61), which is defined for positive integers. With a negative operand the loop cannot terminate: rShiftTo is an arithmetic shift, so a negative value never moves towards zero, and the loop's exit condition (u reaching zero) is never met. The calling thread spins at 100% CPU indefinitely; in Node.js this blocks the event loop. Memory does not grow.
node-forge 1.4.0 fixed CVE-2026-33891 (GHSA-5m6q-g25r-mvwx) by returning zero early when this.signum() == 0, although its changelog describes the check as "<= 0". Negative values were not covered, and a negative modulus was never handled. Every negative input that did terminate already returned zero.
Within node-forge, RSA key generation is the only path to a negative operand: the caller's public exponent e becomes BigInteger.fromInt(e), and state.e.modInverse(state.phi) is called with it. gcd() works on absolute values, so the coprimality checks pass and the loop is reached. Any exponent other than 3 or 65537 uses the pure JavaScript implementation, even when forge.options.usePureJavaScript is not set. RFC 8017, Section 3.1 requires the RSA public exponent to be at least 3.
Values that node-forge parses (DER, PEM, JWK, PKCS#12, X.509, TLS) are always read as unsigned integers and cannot produce a negative operand.
The fix makes modInverse() return zero when the value or the modulus is zero or negative, as it already does when no inverse exists. Results for positive inputs are unchanged.
This issue was reported by wzc.
Patches Fixed in node-forge 1.4.1. modInverse() now returns zero when the value or the modulus is zero or negative.
Workarounds - Pass only fixed, valid RSA public exponents (e.g. 65537) to key generation, or validate caller-supplied exponents first: an odd integer >= 3. - Do not call BigInteger#modInverse() with negative operands. Reduce the value modulo a positive modulus first (x.mod(m).modInverse(m)).
Proof of concept
A negative public exponent passed to RSA key generation never returns (also with the callback form and with createKeyPairGenerationState() / stepKeyPairGenerationState()):
var forge = require('node-forge'); forge.pki.rsa.generateKeyPair({bits: 256, e: -1}); // hangs at 100% CPU
Calling modInverse() directly with a negative value or modulus hangs the same way:
var BigInteger = forge.jsbn.BigInteger; new BigInteger('-1').modInverse(new BigInteger('7')); // hangs new BigInteger('3').modInverse(new BigInteger('-7')); // hangs
With the fix, these calls return zero. The regression tests are in tests/unit/jsbn.js.
Impact
Applications are affected only if they: - pass an untrusted value as the RSA public exponent e to forge.pki.rsa.generateKeyPair(), forge.pki.rsa.createKeyPairGenerationState() or forge.pki.rsa.stepKeyPairGenerationState(), or - call forge.jsbn.BigInteger#modInverse() directly with negative values derived from untrusted input.
An attacker who can supply such a value makes the call hang indefinitely at 100% CPU, which blocks the Node.js event loop (denial of service). Keys and other data parsed by node-forge (DER, PEM, JWK, PKCS#12, X.509, TLS) cannot trigger this issue, and the documented usage of key generation passes a constant exponent (65537). There is no effect on confidentiality or integrity.
Summary
When a CA store created by pki.createCaStore() holds two or more certificates with the same subject name, pki.verifyCertificateChain() permanently removes those certificates from the store while trying each one as the issuer. A peer can send any certificate that names that subject as its issuer to make all later verifications against those CA certificates fail. Fixed in node-forge 1.4.1.
Details
pki.verifyCertificateChain() (lib/x509.js) asks the CA store for the issuer of each certificate with caStore.getIssuer(). When the store holds several certificates with the same subject, caStore.getIssuer() returns the store's own internal array of those certificates (caStore.certs[hash], built by addCertificate()). verifyCertificateChain() used that array directly as its list of candidate parents and called parents.shift() on it while trying each candidate. Every candidate it tried, including the one that finally verified the certificate, was removed from the store.
Once the array is empty, getIssuer() returns an empty list, no candidate is tried, and verification fails with "Certificate signature is invalid." hasCertificate() and listAllCertificates() no longer see the removed certificates. The store stays in this state for as long as the object is used.
The attacker's certificate only needs an issuer name equal to the shared subject name, which is public. Its signature and key can be arbitrary: every candidate is tried and shifted out because none verifies, and errors from parent.verify() are caught by the loop. Verification of the attacker's chain fails as expected. Verifying valid chains has a similar effect: the CA certificate that verified the chain and any tried before it are removed.
No chain is accepted that should be rejected. Removing candidates can only turn a success into a failure.
RFC 5280, Section 6.1.1(d) treats trust anchor information as an input to path validation. Validation should not consume it.
The fix copies the array returned by getIssuer() before iterating over it, so the CA store is no longer modified. getIssuer() itself is unchanged.
Patches Fixed in node-forge 1.4.1. pki.verifyCertificateChain() now works on a copy of the candidate issuer list instead of shifting entries out of the CA store.
Workarounds - Pass a fresh CA store to each pki.verifyCertificateChain() call (for example pki.createCaStore(trustedCerts)), or pass caStore to forge.tls.createConnection() as an array of certificates instead of a store object, so that forge creates a new store per connection. - Or wrap the store so that getIssuer() returns a copy:
var getIssuer = caStore.getIssuer; caStore.getIssuer = function(cert) { var r = getIssuer(cert); return Array.isArray(r) ? r.slice() : r; };
Proof of concept
Two trusted self-signed CA certificates, rootA and rootB, share the subject CN=Root. bogus is any certificate whose issuer is CN=Root, signed with an unrelated key. leafA is a valid certificate issued by rootA.
var caStore = forge.pki.createCaStore([rootA, rootB]); caStore.listAllCertificates().length; // 2 try { forge.pki.verifyCertificateChain(caStore, [bogus]); } catch(e) {} // rejected as expected ("Certificate signature is invalid.") caStore.listAllCertificates().length; // 0: both CA certificates are gone forge.pki.verifyCertificateChain(caStore, [leafA]); // throws "Certificate signature is invalid." (valid chain now rejected)
Without the attacker certificate, verifying leafA twice against a fresh store gives the same result: the first call succeeds and removes rootA, the second fails. With the fix, the store keeps both certificates and every valid chain verifies. The regression tests are in tests/unit/x509.js ("CA store" section).
Impact
Applications that keep a long-lived CA store holding several trusted certificates with the same subject name, and that verify certificate chains received from other parties with pki.verifyCertificateChain(). This includes forge.tls clients that pass the same caStore object to several connections. Duplicate subject names occur with re-keyed or renewed CAs that kept their name, or a CA next to a cross-signed version of itself, mostly in private PKIs.
A remote, unauthenticated peer (for example a malicious TLS server or a party submitting a signed document) can send a certificate naming the shared subject as its issuer. This removes every certificate with that subject from the store, so later verifications of valid chains issued by those CA certificates fail until the store is recreated. This is a persistent denial of service for certificate verification against those CA certificates. Verification against other trusted CAs keeps working, no invalid chain is accepted, and stores without duplicate subject names are not affected.
--- -= Per source details. Do not edit below this line.=-
Source: amazon-inspector (85ba686d403966bfe8a9b5e8103e620c506d7e9d2823f6896b6be87409f9cc06) Package orderbook-volt-plugin@0.0.2 was examined and no indicators of installer-side harm were identified. No lifecycle scripts fetching or executing remote content, no credential or environment scraping, no silent relay of caller data to third-party endpoints, no backdoor or persistence mechanisms, and no shipped third-party credentials were observed in the package's files.
Source: ghsa-malware (0c5e43ffd87e59e00afe190ca8f2a09ac3afaa366f19506c570b8ace7dec0c5f) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.
--- -= Per source details. Do not edit below this line.=-
Source: amazon-inspector (85ba686d403966bfe8a9b5e8103e620c506d7e9d2823f6896b6be87409f9cc06) Package orderbook-volt-plugin@0.0.2 was examined and no indicators of installer-side harm were identified. No lifecycle scripts fetching or executing remote content, no credential or environment scraping, no silent relay of caller data to third-party endpoints, no backdoor or persistence mechanisms, and no shipped third-party credentials were observed in the package's files.
Source: ghsa-malware (0c5e43ffd87e59e00afe190ca8f2a09ac3afaa366f19506c570b8ace7dec0c5f) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.
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 call pem.decode(), including pki.certificateFromPem(), pki.privateKeyFromPem(), pki.publicKeyFromPem(), pki.certificationRequestFromPem(), pki.encryptedPrivateKeyFromPem(), pki.decryptRsaPrivateKey() and pkcs7.messageFromPem().
The fix replaces the message regular expression with a scanner that indexes the END lines once and matches each BEGIN line in linear time, finding the same messages as before. The one difference: a label containing ----- (-----BEGIN A-----B-----) was matched as A-----B if possible; now only the shortest label, A, is used. RFC 7468 labels can't contain --. Header parsing now trims lines with a loop and only starts a header match at the beginning of a run of printable characters, which gives the same result.
Patches Fixed in node-forge 1.4.1. PEM messages and encapsulated headers are now parsed in linear time.
Workarounds Rejecting untrusted PEM input larger than a few kilobytes before passing it to node-forge limits the delay but doesn't remove it: on 1.4.0, about 7 KB of crafted input blocked for 0.4 s, and 29 KB for 24 s.
Credits Reported by Ahmed Mokhtari (@AhmedMokhtari), @mwlik and @imenyoo2, and independently by @offset, @bibu123456 (coordinated by @Kayiz-PT), and @Mucahic.
Proof of concept var forge = require('node-forge'); var pem = ' -----BEGIN I-----G-----END B'.repeat(1000) + '\x00'; // 29 KB try { forge.pki.certificateFromPem(pem); } catch(e) {}
On 1.4.0 (Node.js 24) this call blocks for about 24 seconds before throwing "Invalid PEM formatted message."; 14 KB takes about 3 seconds. A BEGIN line followed by 32 KB of newlines and no END line takes about 1.5 seconds, and the time grows quadratically from there. On 1.4.1 each of these inputs is rejected in a few milliseconds, and 1 MB inputs of any of these shapes take under 100 ms.
The PoC is in tests/pocs/ghsa-7wch-p9px-956x.js. Regression tests are in tests/unit/pem.js ("GHSA-7wch-p9px-956x ReDoS checks").
Impact Any application that passes untrusted PEM text to node-forge is affected: for example, services that accept uploaded certificates, keys or certificate signing requests, or that parse certificates from configuration, SAML metadata or other user-supplied documents. A remote, unauthenticated attacker can send a small crafted input that blocks the Node.js event loop for seconds to minutes per request, so the process stops serving other requests. Repeated requests keep it unavailable. There is no confidentiality or integrity impact.
Summary The forge TLS client's check for a missing server certificate read the wrong property and never ran. A malicious TLS server, or an on-path attacker who removes the server's Certificate message, can make connection.process() throw a TypeError, which crashes applications that use the forge TLS client. Fixed in node-forge 1.4.1.
Details After ServerHelloDone, tls.handleServerHelloDone() in lib/tls.js is meant to reject a server that sent no certificate with a fatal insufficientsecurity alert, after consulting the application's verify callback. The check tested c.serverCertificate, which is never set (the certificate is stored as c.session.serverCertificate), so it never ran. The client state machine allows ServerHelloDone directly after ServerHello, so the handshake continued to tls.createClientKeyExchange(), which reads c.session.serverCertificate.publicKey and throws a TypeError on the null certificate. The exception propagates out of connection.process() without calling the verify or error callbacks.
There is no authentication bypass: without a server certificate the client cannot build its RSA key exchange, so the handshake cannot complete.
The fix reads c.session.serverCertificate and always fails the handshake in that case, still calling verify so the application can customize the alert. Failing even when verify returns true is needed because the key exchange requires the certificate.
Patches Fixed in node-forge 1.4.1. The TLS client fails the handshake with an insufficientsecurity alert when the server sends no certificate.
Workarounds Catch exceptions thrown by connection.process() in the code that feeds it network data, and close the connection when one occurs.
Credits Reported by @arpitjain099.
Proof of concept Connect a forge TLS client (forge.tls.createConnection({server: false, ...})) to a server whose first flight contains ServerHello and ServerHelloDone but no Certificate message. For example, run a forge TLS server and remove the Certificate handshake message (type 11) from its first flight before passing it to the client's process().
On 1.4.0 the client's process() throws "TypeError: Cannot read properties of null (reading 'publicKey')", and the verify and error callbacks are not called. On 1.4.1 the client calls verify with insufficientsecurity and no certificates, calls error with "No server certificate provided. Not enough security.", sends a fatal alert and closes the connection.
Regression tests are in tests/unit/tls.js ("missing server certificate").
Impact Applications that use the forge TLS client (forge.tls.createConnection with server: false) are affected. A malicious server the application connects to, or an on-path attacker who can modify the unauthenticated handshake, can make the client throw from connection.process(). Since process() is normally called from a socket data handler, the uncaught exception terminates a Node.js process. There is no confidentiality or integrity impact. Applications using Node.js's own TLS implementation are not affected.
Red Hat Hardened Images RPMs bug fix and enhancement update
Summary The forge.http client stored cookies from Set-Cookie response headers in a plain object keyed by cookie name and path. A malicious server could use the cookie name proto to add properties to Object.prototype, use inherited names such as constructor to add properties to Object, and send an empty cookie value to delete Object.prototype properties. Fixed in node-forge 1.4.1.
Details client.setCookie() in lib/http.js stored a cookie with client.cookies[cookie.name][cookie.path] = cookie, creating client.cookies[cookie.name] only when !(cookie.name in client.cookies). Both values come from the server's Set-Cookie header via response.getCookies(). Because in also sees inherited properties:
- a cookie named proto skipped the initialization, client.cookies['proto'] returned Object.prototype, and the cookie path was written as a new Object.prototype property, visible on every object; - a cookie named constructor wrote onto the global Object function the same way; - a cookie with an empty value calls client.removeCookie(name, path), which used the same in checks and then delete client.cookies[name][path], so Set-Cookie: proto=; path=toString deleted Object.prototype.toString. This path skipped the cookie's secure-flag and domain checks, so it also worked for http:// clients.
forge.http is not loaded by require('node-forge'). It is included in the forge.all browser bundle and is used with a socket pool, for example by forge.xhr.
The fix uses own-property checks for the cookie store and ignores cookies named proto or with the path proto.
Patches Fixed in node-forge 1.4.1. Cookies from a server can no longer add or remove properties of Object.prototype or Object.
Workarounds Don't use forge.http or forge.xhr with servers that aren't trusted, or filter Set-Cookie headers named proto, constructor or other Object.prototype property names before they reach the client.
Credits Reported by @arunmozhivarman-dtx and @Dremig.
Proof of concept A server response for a forge.http client (http.createClient({url: 'https://...', socketPool: ...})) containing:
Set-Cookie: proto=evil; path=polluted
On 1.4.0, after the client processes the response, ({}).polluted is the cookie object. With Set-Cookie: proto=; path=toLocaleString, Object.prototype.toLocaleString is deleted (for http:// and https:// clients). On 1.4.1 these cookies are ignored and Object.prototype is unchanged.
Regression tests are in tests/security/ghsa-6wvx-3r32-xmcg.js.
Impact Applications that use the forge.http client (directly, or through forge.xhr in the forge.all browser bundle) against a server that can be malicious are affected. The server can add properties to Object.prototype and Object for the whole JavaScript realm, which can change application logic that reads properties from plain objects, and can delete built-in Object.prototype methods, breaking the page or process. Applications that don't use forge.http are not affected.