A denial of service vulnerability exists in @hapi/content versions prior to 6.0.3 due to quadratic-time parsing of Content-Disposition parameters. An unauthenticated attacker can send a multipart/form-data request with a long token lacking an '=' character, causing the Node.js event loop to block for several seconds to minutes. This affects hapi servers with multipart payload routes and applications using Content.disposition() on untrusted headers. The issue is fixed in version 6.0.3.
minimatch versions prior to 11.0.1 contain a denial of service vulnerability caused by an attacker-controlled pattern amplification during glob pattern preprocessing. This leads to exponential growth in internal data structures and quadratic processing time, resulting in excessive CPU and memory consumption. The issue is fixed in version 11.0.1.
A vulnerability in glob versions 9.0.0 through 14.0.1 allows asynchronous directory traversal operations to continue consuming CPU and filesystem I/O after an abort signal or timeout has been triggered. This occurs because abort branches in the code call callbacks without returning, causing continued recursive directory reads even after cancellation. The issue impacts availability by allowing excessive resource consumption, potentially degrading service performance. The flaw is fixed in glob version 14.0.2.
The node-forge library's function asn1.oidToDer() improperly encoded Object Identifier (OID) strings with out-of-range first arcs, causing them to be encoded as different, trusted OIDs. This flaw was an incomplete fix of a previous vulnerability and affected versions prior to 1.4.1. The issue was fixed in version 1.4.1 by rejecting out-of-range first arcs and correctly encoding the first subidentifier. The vulnerability allows an attacker to cause applications that accept untrusted OID strings and encode them with node-forge to emit a different OID than intended, potentially bypassing string-based OID checks. There is no impact on confidentiality or availability, and DER parsing is unaffected.
A prototype pollution vulnerability exists in the forge.http client of node-forge before version 1.4.1. The client improperly stores cookies from Set-Cookie headers in a plain object keyed by cookie name and path, allowing a malicious server to use cookie names like '__proto__' or 'constructor' to modify Object.prototype or Object. This can lead to adding or deleting properties on Object.prototype, potentially altering application logic or breaking functionality. The issue is fixed in node-forge 1.4.1 by ignoring such dangerous cookie names and paths.
A vulnerability in the node-forge TLS client causes a crash when the server sends no certificate during the TLS handshake. The client incorrectly checks for the server certificate, leading to a TypeError exception that terminates the Node.js process using the client. This issue is fixed in node-forge version 1.4.1.
A Regular Expression Denial of Service (ReDoS) vulnerability exists in node-forge's pem.decode() function prior to version 1.4.1. The vulnerability arises from inefficient regular expressions used to parse PEM-encoded data, causing the Node.js event loop to block for seconds to minutes when processing crafted inputs. This affects any application that parses untrusted PEM text using node-forge, such as services handling uploaded certificates or keys. The issue is fixed in node-forge version 1.4.1.
node-forge versions prior to 1.4.1 contain a denial of service vulnerability in the BigInteger.modInverse() function due to an infinite loop triggered by negative input values. This occurs when a negative value or modulus is passed, causing the function to spin indefinitely at 100% CPU and block the Node.js event loop. The issue is an incomplete fix of a previous vulnerability and affects RSA key generation when using negative public exponents. The vulnerability does not affect key parsing or standard usage with typical exponents like 65537. It was fixed in node-forge 1.4.1 by returning zero for zero or negative inputs.
A vulnerability in node-forge versions prior to 1.4.1 causes the CA store to lose trusted CA certificates with duplicate subject names during certificate chain verification. When verifying a chain, the function removes certificates from the CA store's internal list, leading to persistent denial of service for subsequent verifications involving those certificates. This affects applications that reuse a CA store containing multiple certificates sharing the same subject name. The issue is fixed in node-forge 1.4.1.
A vulnerability in node-forge's AES-GCM implementation allows authentication bypass when the tagLength option passed to the cipher start() method is zero or converts to zero. This causes the authentication tag to be empty, making decipher.finish() return true for any ciphertext and additional data if the supplied tag is empty or missing. The issue is fixed in node-forge version 1.4.1 by validating the tagLength against allowed NIST values.
A vulnerability in node-forge versions prior to 1.4.1 allows an attacker to forge PKCS#12 MACs and decrypt PKCS#12 PBE-encrypted private keys without knowing the password by exploiting a zero or negative iteration count in the key derivation function. This flaw causes the key derivation to produce a constant key independent of the password or salt, enabling an attacker to supply malicious PKCS#12 files that verify successfully under any password. The issue is fixed in node-forge 1.4.1 by rejecting iteration counts less than 1.
A vulnerability in node-forge's TLS implementation allows a denial of service via an uncaught TypeError when processing a TLS record interleaved with a fragmented handshake message. This occurs because the process() function throws an exception after receiving an unexpected record type during a fragmented handshake, terminating Node.js processes using the documented socket wiring. The issue is fixed in node-forge version 1.4.1.
A denial of service vulnerability exists in node-forge's TLS implementation due to recursive processing of TLS records, which can exhaust the call stack. An attacker can send a chunk of thousands of small TLS records (e.g., heartbeat records) before handshake completion, causing a RangeError that terminates Node.js processes using the documented socket wiring. This flaw affects both client and server connections. The issue is fixed in node-forge version 1.4.1 by changing the processing to an iterative approach.
node-forge versions prior to 1.4.1 improperly handle deprecated X.509 certificate extension OIDs 2.5.29.10 and 2.5.29.13 by treating them as basicConstraints. This allows an attacker with a certificate containing a forged deprecated extension indicating CA privileges (cA TRUE) before the genuine basicConstraints extension (cA FALSE) to bypass CA validation checks. The vulnerability enables issuance of certificates accepted as CA certificates, potentially allowing impersonation in TLS connections. The issue is fixed in node-forge 1.4.1 by restricting verification to the standard basicConstraints OID 2.5.29.19.
A vulnerability in @nuxt/vite-builder versions 4.6.0 through before 4.6.3 allows exposure of a generated development appSecret via the Nuxt dev server's file serving. This secret enables forging session cookies if accessed. The issue affects dev servers exposed to untrusted networks but not production builds or dev servers with explicitly configured appSecrets. It is fixed in version 4.6.3.
A path normalization vulnerability in Nuxt versions 4.6.0 through 4.6.2 allows bypassing server-side middleware and route rules by using dot segments ('.' and '..') or their percent-encoded forms in request paths. This causes the page router to resolve these segments before rendering, while server-side checks see the unnormalized path, enabling unauthorized access to protected pages. The issue is fixed in Nuxt 4.6.3, which returns 404 for such paths and normalizes route rule keys accordingly.
A vulnerability in @nuxt/vite-builder versions 4.6.0 to 4.6.2 allows an attacker with TCP access to the Nuxt development server to read arbitrary files on the server filesystem by sending a crafted client error event. This issue affects only the development server and not production builds. The vulnerability is mitigated by default localhost binding, but exposing the dev server to untrusted networks can lead to sensitive file disclosure. The issue is fixed in version 4.6.3.
A vulnerability in the Nitro development server bundle used by Nuxt 3 and Nuxt 4 with Nitro 2 allows private runtime configuration values to be exposed through the Vite dev server. This occurs because the Nitro dev server bundle inlines private runtime config values, which can be fetched via HTTP if the dev server is exposed to a network. Production builds and Nitro 3 are not affected. The issue is fixed in @nuxt/vite-builder 4.6.3.
@sigstore/oci versions prior to 0.7.2 improperly send the registry Authorization header to a cross-host blob-upload Location URL. This occurs because the Authorization header is set as a default on the HTTP client and is attached to all requests, including those redirected to a different host for blob uploads. The vulnerability allows a malicious or compromised registry to capture credentials by redirecting blob uploads to an attacker-controlled host.
The follow-redirects library versions 1.16.0 and 1.16.1 contain a vulnerability where the sensitiveHeaders option is validated using instanceof Array, which fails for arrays created in different JavaScript realms. This causes the sensitiveHeaders array to be replaced with an empty list, allowing custom credential headers to be forwarded to attacker-controlled cross-origin redirect destinations. This can lead to disclosure of custom credential headers such as API keys. The issue is fixed in version 1.16.2.