GHSA-jw8q-gjvg-8w4q OneUptime has Synthetic Monitor RCE via exposed Playwright browser object
SummaryOneUptime Synthetic Monitors allow a low-privileged authenticated project user to execute arbitrary commands on the `oneuptime-probe` server/container.The root cause is that untrusted Synthetic Monitor code is executed inside Node's `vm` while live host-realm Playwright `browser` and `page` objects are exposed to it. A malicious user can call Playwright APIs on the injected `browser` object and cause the probe to spawn an attacker-controlled executable.This is a server-side remote code execution issue. It does not require a separate `vm` sandbox escape.DetailsA normal project member can create or edit monitors and monitor tests:`Monitor` access control: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Common/Models/DatabaseModels/Monitor.ts#L45-L70`MonitorTest` access control: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Common/Models/DatabaseModels/MonitorTest.ts#L27-L52The dashboard exposes a Playwright code editor for Synthetic Monitors and allows a user to queue a test run:Synthetic Monitor editor: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/App/FeatureSet/Dashboard/src/Components/Form/Monitor/MonitorStep.tsx#L260-L289`Test Monitor` flow: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/App/FeatureSet/Dashboard/src/Components/Form/Monitor/MonitorTest.tsx#L69-L83For `MonitorType.SyntheticMonitor`, attacker-controlled `customCode` is passed into `SyntheticMonitor.execute(...)`:https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Probe/Utils/Monitors/Monitor.ts#L323-L338`SyntheticMonitor.execute(...)` then calls `VMRunner.runCodeInNodeVM(...)` and injects live Playwright objects into the VM context:https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Probe/Utils/Monitors/MonitorTypes/SyntheticMonitor.ts#L156-L168Relevant code path:`VMRunner.runCodeInNodeVM(...)` wraps host objects in proxies, but it still forwards normal method calls with the real host `this` binding. It only blocks a few property names such as `constructor`, `__proto__`, `prototype`, and `mainModule`:Blocked properties: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Common/Server/Utils/VM/VMRunner.ts#L20-L25Real host `this` binding during method calls: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Common/Server/Utils/VM/VMRunner.ts#L81-L103Additional context injection into the VM: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Common/Server/Utils/VM/VMRunner.ts#L388-L395Because of that, untrusted code can still use legitimate Playwright methods on the injected `browser` object.The probe pins Playwright `1.58.2`:https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Probe/package-lock.json#L4438-L4459In that version, `Browser.browserType()` returns a `BrowserType` object, and `BrowserType.launch()` accepts attacker-controlled `executablePath`, `ignoreDefaultArgs`, and `args`. Playwright then passes those values into a child-process spawn path.As a result, a malicious Synthetic Monitor can do this from inside the sandboxed script:Even if Playwright later throws because the spawned process is not a real browser, the command has already executed.This execution path is reachable through both one-shot monitor testing and normal scheduled monitor execution:Monitor tests fetched by the probe: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Probe/Jobs/Monitor/FetchMonitorTest.ts#L55-L85Scheduled monitor execution: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Probe/Jobs/Monitor/FetchList.ts#L96-L126This appears distinct from prior `node:vm` breakout issues because the exploit does not need to recover `process` from the VM. The dangerous capability is already exposed by design through the injected Playwright object.PoCLog in to the dashboard as a regular project member.Go to `Monitors` -> `Create New Monitor`.Select `Synthetic Monitor`.In the Playwright code field, paste:Select one browser type, for example `Chromium`.Select one screen type, for example `Desktop`.Set retry count to `0`.Click `Test Monitor` and choose any probe.Expected result:the monitor execution succeeded and in the Show More Details the command output is shown.
<img width="1537" height="220" alt="image" src="https://github.com/user-attachments/assets/4fa5b458-cae9-4ec8-add0-bfc288ee7568" />ImpactThis is a server-side Remote Code Execution issue affecting the probe component.Who is impacted:any OneUptime deployment where an attacker can obtain ordinary project membershipenvironments where the probe has access to internal services, secrets, Kubernetes metadata, database credentials, proxy credentials, or other cluster-local trust relationships
CVSS v3.1 score: 9.9