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:
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 you have all of those.
Second, the permission to create monitors is granted to Permission.ProjectMember — the lowest role — in Common/Models/DatabaseModels/Monitor.ts:46-51. There is no check that restricts Custom JavaScript Code monitors to admins only. And since open registration is on by default (disableSignup: false), any random person on the internet can reach this in about 30 seconds.