Summary
OneUptime 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.
Details
A normal project member can create or edit monitors and monitor tests:
The dashboard exposes a Playwright code editor for Synthetic Monitors and allows a user to queue a test run:
For MonitorType.SyntheticMonitor, attacker-controlled customCode is passed into SyntheticMonitor.execute(...):
SyntheticMonitor.execute(...) then calls VMRunner.runCodeInNodeVM(...) and injects live Playwright objects into the VM context:
Relevant code path:
result = await VMRunner.runCodeInNodeVM({
code: options.script,
options: {
timeout: PROBE_SYNTHETIC_MONITOR_SCRIPT_TIMEOUT_IN_MS,
args: {},
context: {
browser: browserSession.browser,
page: browserSession.page,
screenSizeType: options.screenSizeType,
browserType: options.browserType,
},
},
});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:
Because of that, untrusted code can still use legitimate Playwright methods on the injected browser object.
The probe pins Playwright 1.58.2:
In 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:
browser.browserType().launch({
executablePath: "/bin/sh",
ignoreDefaultArgs: true,
args: ["-c", "id"],
});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:
This 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.
PoC
- Log in to the dashboard as a regular project member.
- Go to
Monitors -> Create New Monitor.
- Select
Synthetic Monitor.
- In the Playwright code field, paste:
browser.browserType().launch({
executablePath: "/bin/sh",
ignoreDefaultArgs: true,
args: [
"-c",
"id"
],
timeout: 1000,
}).catch((err) => {
console.log(String(err));
});
return {
data: {
launched: true
}
};
- 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.
Impact
This 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 membership
- environments where the probe has access to internal services, secrets, Kubernetes metadata, database credentials, proxy credentials, or other cluster-local trust relationships
References
maru1009 Reporter
Summary
OneUptime Synthetic Monitors allow a low-privileged authenticated project user to execute arbitrary commands on the
oneuptime-probeserver/container.The root cause is that untrusted Synthetic Monitor code is executed inside Node's
vmwhile live host-realm Playwrightbrowserandpageobjects are exposed to it. A malicious user can call Playwright APIs on the injectedbrowserobject 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
vmsandbox escape.Details
A normal project member can create or edit monitors and monitor tests:
Monitoraccess control: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Common/Models/DatabaseModels/Monitor.ts#L45-L70MonitorTestaccess 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:
Test Monitorflow: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/App/FeatureSet/Dashboard/src/Components/Form/Monitor/MonitorTest.tsx#L69-L83For
MonitorType.SyntheticMonitor, attacker-controlledcustomCodeis passed intoSyntheticMonitor.execute(...):SyntheticMonitor.execute(...)then callsVMRunner.runCodeInNodeVM(...)and injects live Playwright objects into the VM context:Relevant code path:
VMRunner.runCodeInNodeVM(...)wraps host objects in proxies, but it still forwards normal method calls with the real hostthisbinding. It only blocks a few property names such asconstructor,__proto__,prototype, andmainModule:thisbinding during method calls: https://github.com/OneUptime/oneuptime/blob/707bfd62e721a2845ee05b87cb5d3c611bda2276/Common/Server/Utils/VM/VMRunner.ts#L81-L103Because of that, untrusted code can still use legitimate Playwright methods on the injected
browserobject.The probe pins Playwright
1.58.2:In that version,
Browser.browserType()returns aBrowserTypeobject, andBrowserType.launch()accepts attacker-controlledexecutablePath,ignoreDefaultArgs, andargs. 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:
This appears distinct from prior
node:vmbreakout issues because the exploit does not need to recoverprocessfrom the VM. The dangerous capability is already exposed by design through the injected Playwright object.PoC
Monitors->Create New Monitor.Synthetic Monitor.Chromium.Desktop.0.Test Monitorand choose any probe.Expected result:
Impact
This is a server-side Remote Code Execution issue affecting the probe component.
Who is impacted:
References