GitHub Security Advisory: GHSA-4j36-39gm-8vq8
Package: @oneuptime/common (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-749: Exposed Dangerous Method or Function
Vulnerable versions: < 10.0.20
Patched in: 10.0.20

Summary: OneUptime: Synthetic Monitor RCE via exposed Playwright browser object

Details:
Summary

OneUptime 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`.

This 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.

This 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`.

## Details

A normal project member can create or edit monitors and monitor tests:

- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Common/Models/DatabaseModels/Monitor.ts#L45-L78
- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Common/Models/DatabaseModels/MonitorTest.ts#L27-L60

The dashboard exposes a Playwright code editor for Synthetic Monitors and allows the user to queue a test run:

- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/App/FeatureSet/Dashboard/src/Components/Form/Monitor/MonitorStep.tsx#L861-L918
- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/App/FeatureSet/Dashboard/src/Components/Form/Monitor/MonitorTest.tsx#L66-L84

The probe worker polls queued monitor tests and executes them:

- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Probe/Jobs/Monitor/FetchMonitorTest.ts#L55-L85

For `MonitorType.SyntheticMonitor`, the user-controlled `customCode` is passed into `SyntheticMonitor.execute(...)`:

- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Probe/Utils/Monitors/Monitor.ts#L323-L338

`SyntheticMonitor.execute(...)` then runs that code through `VMRunner.runCodeInNodeVM(...)` and injects the live Playwright `browser` and `page` objects into the VM context:

- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Probe/Utils/Monitors/MonitorTypes/SyntheticMonitor.ts#L156-L168

`VMRunner.runCodeInNodeVM(...)` creates a Node `vm` context and exposes host objects into it, including the additional context objects:

- https://github.com/OneUptime/oneuptime/blob/8e90f451426b160718bdd1796b68c5ec15318101/Common/Server/Utils/VM/VMRunner.ts#L323-L405

The 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.

That is e