EUVD-2026-270425

fkie_cve-2026-27574

OneUptime is a solution for monitoring and managing online services. In versions 9.5.13 and below, custom JavaScript monitor feature uses Node.js's node:vm module (explicitly documented as not a security mechanism) to execute user-supplied code, allowing trivial sandbox escape via a well-known one-liner that grants full access to the underlying process. Because the probe runs with host networking and holds all cluster credentials (ONEUPTIME_SECRET, DATABASE_PASSWORD, REDIS_PASSWORD, CLICKHOUSE_PASSWORD) in its environment variables, and monitor creation is available to the lowest role (ProjectMember) with open registration enabled by default, any anonymous user can achieve full cluster compromise in about 30 seconds. This issue has been fixed in version 10.0.5.

GHSA-v264-xqh4-9xmm — OneUptime:: node:vm sandbox escape in probe allows any project member to achieve RCE

Affected: npm: @oneuptime/common

### Summary

OneUptime lets project members write custom JavaScript that runs inside monitors. The problem is it executes that code using Node.js's built-in `vm` module, which Node.js itself documents as "not a security mechanism — do not use it to run untrusted code." The classic one-liner escape gives full access to the underlying process, and since the probe runs with host networking and holds all cluster credentials in its environment, this turns into a full cluster compromise for anyone who can register an account.

### Details

The vulnerable code is in `Common/Server/Utils/VM/VMRunner.ts` at line 55:

```typescript vm.runInContext(script, sandbox, { timeout }) ```

The JavaScript that reaches this call comes straight from the monitor's `customCode` field, which is only validated as `Zod.string().optional()` in `Common/Types/Monitor/MonitorStep.ts:531`. No AST analysis, no keyword filtering, nothing — just a string that goes directly into `vm.runInContext()`.

Both `CustomCodeMonitor.ts` and `SyntheticMonitor.ts` import `VMRunner` directly inside the probe process. So when the probe picks up a monitor and runs it, the escape executes in the probe's own process — not a child process, not a container.

Two things make this especially bad:

First, the probe runs with `network_mode: host` (see `docker-compose.base.yml:397`) and carries `ONEUPTIME_SECRET`, `DATABASE_PASSWORD`, `REDIS_PASSWORD`, and `CLICKHOUSE_PASSWORD` as environment variables. Once you escape the sandbox…

Most recent entries from all

EUVD-2026-270425

fkie_cve-2026-27574

GHSA-v264-xqh4-9xmm — OneUptime:: node:vm sandbox escape in probe allows any project member to achieve RCE