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.
PHPUnit versions 13.4.0 through 13.4.3 have a vulnerability in their PHPT code coverage feature where temporary test files are written to a fixed directory under the system's temporary path (e.g., /tmp/phpunit-phpt). On multi-user systems with shared temporary directories, a local attacker can pre-create this directory and replace test files to execute arbitrary code with the privileges of the PHPUnit user. This attack is stealthy as the test passes and coverage reports appear normal. The issue is fixed in PHPUnit 13.4.4 by using unpredictable directory names with restricted permissions.
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.
MariaDB Connector/J versions before 3.3.7, 3.4.5, and 3.5.11 contain a vulnerability where a rogue or MitM server can cause the client to allocate large amounts of heap memory based on server-declared lengths in OK packets. This can lead to excessive garbage collection pressure and potentially an OutOfMemoryError, impacting availability. The flaw arises because the client allocates memory before validating that the declared lengths fit within the actual packet size. The issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.
MariaDB Connector/J versions prior to 3.3.7, 3.4.5, and 3.5.10 improperly handle 8-byte length-encoded integers by truncating values larger than Integer.MAX_VALUE to a signed int without validation. This can cause negative or arbitrary lengths leading to client crashes or oversized memory allocations when interacting with a malicious or compromised server. The vulnerability impacts availability only and requires control over the server side. No confidentiality, integrity, or authentication bypass issues are involved. Fixed versions are available.
MariaDB Connector/J versions 3.0.0 through before 3.3.7, 3.4.0 through before 3.4.5, and 3.5.0 through before 3.5.11 contain a vulnerability in the XAResource.recover() method. The method trusts server-supplied gtrid_length and bqual_length values without validating them against XA specification bounds, leading to potential large memory allocations or exceptions during XA recovery. This can cause availability issues such as crashes or denial of service. Exploitation requires control over the server side of the connection. Fixed versions are 3.3.7, 3.4.5, and 3.5.11.
MariaDB Connector/J versions before 3.3.7, 3.4.5, and 3.5.11 improperly validate LOAD DATA LOCAL INFILE file requests by searching for the file name text anywhere in the SQL command, including inside quoted identifiers and comments. This flaw allows a malicious or compromised server, or a man-in-the-middle, to trick the client into sending arbitrary local files readable by the JVM to the server. The vulnerability affects standard JDBC calls such as DatabaseMetaData.getImportedKeys() and getExportedKeys(). A fix is available that properly parses the SQL command to validate the file request.
MariaDB Connector/J versions 3.0.0 through before 3.3.7, 3.4.0 through before 3.4.5, and 3.5.0 through before 3.5.11 have a vulnerability where the connector does not properly guard against changes to the character_set_results session variable. This allows a malicious or compromised server to switch the character set away from UTF-8 without the client noticing, causing incorrect decoding of query results. This can lead to integrity issues where application-side validation or escaping based on string values can be bypassed. The vulnerability requires control of the server side of the connection and does not impact confidentiality or availability. Fixed versions are 3.3.7, 3.4.5, and 3.5.11.
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.
The russh SSH agent server does not call the Agent::confirm method before signing with keys added with the confirm constraint (ssh-add -c). This confirm constraint is intended to require user approval before signing. The issue was introduced in version 0.50.0-beta.12 and affects all versions up to and including 0.64.1. As a result, keys added with the confirm constraint are signed without user confirmation, allowing any process with access to the agent to use those keys without approval. This undermines the security purpose of the confirm constraint defined in RFC 9987.
The pageant crate's PageantStream component improperly handles a 4-byte length prefix from its input stream without validating the claimed frame size. This allows a malicious peer to claim an oversized frame (up to ~4 GiB) and cause unbounded memory buffering, leading to a remote memory-exhaustion denial-of-service (DoS) on the client process. The vulnerability affects versions from 0.2.0 up to but not including 0.2.5. A fix is available in version 0.2.5 that rejects frames exceeding the transport's maximum size before buffering.
A vulnerability in russh versions 0.60.0 up to but not including 0.65 allows a peer to advertise a maximum packet size of zero in channel-open messages. This causes the AsyncWrite path to stall indefinitely because the write operation never completes or errors, leading to a silent hang of the application task. The issue arises from lack of validation of the peer-declared maximum packet size and inconsistent handling in the AsyncWrite code path. This can be exploited by an authenticated client against a server or by a malicious server against a client to cause a denial of service by hanging write operations.
The russh SSH agent server (version prior to 0.65.0) has a vulnerability where it unboundedly allocates memory when processing SSH_AGENT_CONSTRAIN_CONFIRM (0x02) records during key addition requests. Each 1-byte confirm record causes a 56-byte allocation retained for the process lifetime, with no limit on the number of such records per key or the number of keys stored. This can lead to persistent memory growth controlled by any local process able to connect to the agent socket. The issue was fixed in version 0.65.0.