Security: node:vm sandbox escape in probe/workflow — GHSA-v264-xqh4-9xmm (critical) #62

Closed
opened 2026-04-05 16:18:47 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @dendrite-soup on 2/25/2026

Summary

GHSA-v264-xqh4-9xmm was published 2026-02-24. Flagging here since there is no corresponding tracker issue and self-hosters need a heads-up.

What is happening

The probe and workflow components execute user-supplied JavaScript via Node's built-in node:vm module (VMRunner.ts:55). Node.js explicitly documents vm as not a security mechanism — the classic constructor chain escape gives full access to the host process in one line.

Two things make this especially bad in OneUptime's deployment model:

1. Probe environment exposure. The probe runs with network_mode: host and carries ONEUPTIME_SECRET, DATABASE_PASSWORD, REDIS_PASSWORD, and CLICKHOUSE_PASSWORD as environment variables. Sandbox escape = full cluster credential dump.

2. Low permission bar. Custom JavaScript Code monitors are accessible to Permission.ProjectMember — the lowest role. With open registration on by default, any unauthenticated person can reach this in about 30 seconds.

Bonus: the IsolatedVM microservice is also affected. IsolatedVM/API/VM.ts:41 calls the same VMRunner.runCodeInSandbox() — it does not use the isolated-vm npm package despite the name.

Fix direction

Replace node:vm with the isolated-vm npm package, which provides real V8 isolate sandboxing. This is the standard solution for untrusted JS execution in Node — used by Figma, Cloudflare Workers locally, and others.

Short-term mitigation while the fix is in progress: restrict Custom JavaScript Code monitors to admin/owner roles only.

References

*Originally created by @dendrite-soup on 2/25/2026* ## Summary GHSA-v264-xqh4-9xmm was published 2026-02-24. Flagging here since there is no corresponding tracker issue and self-hosters need a heads-up. ## What is happening The probe and workflow components execute user-supplied JavaScript via Node's built-in `node:vm` module (`VMRunner.ts:55`). Node.js explicitly documents `vm` as **not a security mechanism** — the classic constructor chain escape gives full access to the host process in one line. Two things make this especially bad in OneUptime's deployment model: **1. Probe environment exposure.** The probe runs with `network_mode: host` and carries `ONEUPTIME_SECRET`, `DATABASE_PASSWORD`, `REDIS_PASSWORD`, and `CLICKHOUSE_PASSWORD` as environment variables. Sandbox escape = full cluster credential dump. **2. Low permission bar.** Custom JavaScript Code monitors are accessible to `Permission.ProjectMember` — the lowest role. With open registration on by default, any unauthenticated person can reach this in about 30 seconds. **Bonus: the IsolatedVM microservice is also affected.** `IsolatedVM/API/VM.ts:41` calls the same `VMRunner.runCodeInSandbox()` — it does **not** use the `isolated-vm` npm package despite the name. ## Fix direction Replace `node:vm` with the [`isolated-vm`](https://github.com/laverdet/isolated-vm) npm package, which provides real V8 isolate sandboxing. This is the standard solution for untrusted JS execution in Node — used by Figma, Cloudflare Workers locally, and others. Short-term mitigation while the fix is in progress: restrict Custom JavaScript Code monitors to admin/owner roles only. ## References - Advisory: https://github.com/advisories/GHSA-v264-xqh4-9xmm - CVE: CVE-2026-27574 - isolated-vm: https://github.com/laverdet/isolated-vm
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/oneuptime#62