| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| oneuptime | < 10.0.21 | 10.0.21 |
| @oneuptime/common | < 10.0.21 | 10.0.21 |
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.
A 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-L70MonitorTest 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:
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(...):
Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phí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:
this binding 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 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.
Monitors -> Create New Monitor.Synthetic Monitor. browser.browserType().launch({
executablePath: "/bin/sh",
ignoreDefaultArgs: true,
args: [
"-c",
"id"
],
timeout: 1000,
}).catch((err) => {
console.log(String(err));
});
return {
data: {
launched: true
}
};
Chromium.Desktop.0.Test Monitor and choose any probe.Expected result:
This is a server-side Remote Code Execution issue affecting the probe component.
Who is impacted: