+ "details": "Summary\n\nOneUptime Synthetic Monitors allow low-privileged project users to submit custom Playwright code that is executed on the `oneuptime-probe` service. In the current implementation, this untrusted code is run inside Node's `vm` and is given live host Playwright objects such as `browser` and `page`.\n\nThis creates a distinct server-side RCE primitive: the attacker does not need the classic `this.constructor.constructor(...)` sandbox escape. Instead, the attacker can directly use the injected Playwright `browser` object to reach `browser.browserType().launch(...)` and spawn an arbitrary executable on the probe host/container.\n\nThis appears to be a separate issue from the previously published `node:vm(GHSA-h343-gg57-2q67)` breakout advisory because the root cause here is exposure of a dangerous host capability object to untrusted code, not prototype-chain access to `process`.\n\n## Details\n\nA normal project member can create or edit monitors and monitor tests:\n\n- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Common/Models/DatabaseModels/Monitor.ts#L45-L78\n- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Common/Models/DatabaseModels/MonitorTest.ts#L27-L60\n\nThe dashboard exposes a Playwright code editor for Synthetic Monitors and allows the user to queue a test run:\n\n- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/App/FeatureSet/Dashboard/src/Components/Form/Monitor/MonitorStep.tsx#L861-L918\n- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/App/FeatureSet/Dashboard/src/Components/Form/Monitor/MonitorTest.tsx#L66-L84\n\nThe probe worker polls queued monitor tests and executes them:\n\n- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Probe/Jobs/Monitor/FetchMonitorTest.ts#L55-L85\n\nFor `MonitorType.SyntheticMonitor`, the user-controlled `customCode` is passed into `SyntheticMonitor.execute(...)`:\n\n- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Probe/Utils/Monitors/Monitor.ts#L323-L338\n\n`SyntheticMonitor.execute(...)` then runs that code through `VMRunner.runCodeInNodeVM(...)` and injects the live Playwright `browser` and `page` objects into the VM context:\n\n- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Probe/Utils/Monitors/MonitorTypes/SyntheticMonitor.ts#L156-L168\n\n`VMRunner.runCodeInNodeVM(...)` creates a Node `vm` context and exposes host objects into it, including the additional context objects:\n\n- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Common/Server/Utils/VM/VMRunner.ts#L323-L405\n\nThe proxy wrapper blocks only a small set of property names and still forwards normal method calls with the real host `this` binding. Because of that, untrusted monitor code can still use legitimate Playwright methods on the injected `browser` object.\n\nThat is enough for code execution because Playwright's `Browser` exposes `browserType()`, and `BrowserType.launch()` accepts attacker-controlled process launch options such as `executablePath`, `args`, and `ignoreDefaultArgs`. An attacker can therefore cause the probe to spawn an arbitrary executable. Even if Playwright later errors because the spawned process is not a real browser, the command has already executed.\n\nThis same execution path is also used for normal scheduled monitors, not only one-shot monitor tests:\n\n- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Probe/Jobs/Monitor/FetchList.ts#L110-L121\n\nAs a result, the issue can be abused either as a one-shot RCE via `Test Monitor` or as a persistent scheduled RCE by saving a malicious Synthetic Monitor.\n\n### PoC\n\n1. Log in as any user with normal project membership.\n2. Go to `Monitors -> Create New Monitor`.\n3. Select `Synthetic Monitor`.\n4. In `Playwright Code`, paste the following script:\n\n```javascript\n const HostFunction =\n Object.getOwnPropertyDescriptor(console, \"log\").value.constructor;\n\n return {\n data: {\n node: HostFunction('return process.version')(),\n cwd: HostFunction('return process.cwd()')(),\n id: HostFunction(\n 'return process.getBuiltinModule(\"child_process\").execSync(\"id\").toString()'\n )(),\n },\n };\n\n```\n\n5. Select any one browser type, for example `Chromium`.\n6. Select any one screen type, for example `Desktop`.\n7. Set retry count to `0`.\n8. Click `Test Monitor` and choose a probe.\n\nExpected result:\n\n- the monitor execution succeeded and in the `Show More Details` the command output is shown.\n<img width=\"899\" height=\"249\" alt=\"image\" src=\"https://github.com/user-attachments/assets/98ebd26f-431b-438e-9459-7deeebf97b18\" />\n\n\n\n### Impact\n\nThis is a server-side `Remote Code Execution` issue affecting the probe component.\n\nWho is impacted:\n\n- any OneUptime deployment where an attacker can obtain ordinary project membership\n- environments where the probe has access to internal services, secrets, Kubernetes metadata, database credentials, proxy credentials, or other cluster-local trust relationships",
![advisory-database[bot]](https://avatars.githubusercontent.com/in/21409?v=4&size=40){kind=avatar}
0 commit comments