Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The resend-verification-code endpoint allows any authenticated user to trigger a verification code resend for any UserWhatsApp record by ID. Ownership is not validated (unlike the verify endpoint). Affected Source - Endpoint: UserWhatsAppAPI.ts - Service: UserWhatsAppService.ts - Verify ownership (present in verify endpoint for comparison): UserWhatsAppAPI.ts Full Code Lines (UserWhatsAppAPI.ts) Resend path (authorization gap): Verify path (ownership check present): Prerequisites - Valid attacker account with access to a project - Attacker access token - A victim’s UserWhatsApp itemId belonging to the same project Steps to Reproduce 1. Set your attacker token: 2. Trigger resend for the victim’s item: Expected/Observed Behavior - HTTP 200 with {} body and a new verification code sent to the victim’s phone - No checks confirm that item.userId equals the authenticated user’s ID for the resend path Impact - Spam/DoS against victims’ phone numbers, social engineering pressure,…
Recommended action: Upgrade to 10.0.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: - 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-L52 The dashboard exposes a Playwright…
Recommended action: Upgrade to 10.0.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A low‑privileged user can bypass authorization and tenant isolation in OneUptime v10.0.20 by sending a forged is-multi-tenant-query header together with a controlled projectid header. Because the server trusts this client-supplied header, internal permission checks in BasePermission are skipped and tenant scoping is disabled. This allows attackers to: 1. Access project data belonging to other tenants 2. Read sensitive User fields via nested relations 3. Leak plaintext resetPasswordToken 4. Reset the victim’s password and fully take over the account This results in cross‑tenant data exposure and full account takeover. Details Root cause The API trusts a client‑controlled header to determine whether a request should bypass authorization checks. CommonAPI.ts BasePermission.ts When the attacker sends: the system skips all authorization checks including: - Table permission validation - Query permission validation - Select permission validation - Tenant isolation enforcement…
Recommended action: Upgrade to 10.0.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OneUptime's GitHub App callback trusts attacker-controlled state and installationid values and updates Project.gitHubAppInstallationId with isRoot: true without validating that the caller is authorized for the target project. This allows an attacker to overwrite another project's GitHub App installation binding. Related GitHub endpoints also lack effective authorization, so a valid installation ID can be used to enumerate repositories and create CodeRepository records in an arbitrary project. Details The callback decodes unsigned base64 JSON from state and uses the embedded projectId directly: - https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L34-L112 It then writes the supplied installationid into the target project with root privileges: The userId in state is only checked for presence, not authenticity: - https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L73-L79 The install flow also generates state as plain…
Recommended action: Upgrade to 10.0.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: -…
Recommended action: Upgrade to 10.0.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OneUptime allows project members to run custom Playwright/JavaScript code via Synthetic Monitors to test websites. However, the system executes this untrusted user code inside the insecure Node.js vm module. By leveraging a standard prototype-chain escape (this.constructor.constructor), an attacker can bypass the sandbox, gain access to the underlying Node.js process object, and execute arbitrary system commands (RCE) on the oneuptime-probe container. Furthermore, because the probe holds database/cluster credentials in its environment variables, this directly leads to a complete cluster compromise. Details The root cause of the vulnerability exists in Common/Server/Utils/VM/VMRunner.ts where user-supplied JavaScript is executed using vm.runInContext(): The Node.js documentation explicitly warns that the vm module is not a security boundary and should never be used to run untrusted code. When a user creates a Synthetic Monitor, the code inputted into the Playwright script…
Recommended action: Upgrade to 10.0.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An OS command injection vulnerability in NetworkPathMonitor.performTraceroute() allows any authenticated project user to execute arbitrary operating system commands on the Probe server by injecting shell metacharacters into a monitor's destination field. Details The vulnerability exists in Probe/Utils/Monitors/MonitorTypes/NetworkPathMonitor.ts, lines 149–191. The performTraceroute() method constructs a shell command by directly interpolating the user-controlled destination parameter into a string template, then executes it via childprocess.exec() (wrapped through promisify): The destination value originates from the public trace() method (line 31), which accepts URL | Hostname | IPv4 | IPv6 | string types. When a raw string is passed (line 47: hostAddress = destination), no validation or sanitization is performed before it reaches performTraceroute(). childprocess.exec() spawns a shell (/bin/sh), so any shell metacharacters (;, |, $(), , &&, ||, \n) in destination will be…
Recommended action: Upgrade to 10.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OneUptime lets project members write custom JavaScript that runs inside monitors. The problem is it executes that code using Node.js's built-in vm module, which Node.js itself documents as "not a security mechanism — do not use it to run untrusted code." The classic one-liner escape gives full access to the underlying process, and since the probe runs with host networking and holds all cluster credentials in its environment, this turns into a full cluster compromise for anyone who can register an account. Details The vulnerable code is in Common/Server/Utils/VM/VMRunner.ts at line 55: The JavaScript that reaches this call comes straight from the monitor's customCode field, which is only validated as Zod.string().optional() in Common/Types/Monitor/MonitorStep.ts:531. No AST analysis, no keyword filtering, nothing — just a string that goes directly into vm.runInContext(). Both CustomCodeMonitor.ts and SyntheticMonitor.ts import VMRunner directly inside the probe process. So…
Recommended action: Upgrade to 10.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A low-permission user can create new accounts through a direct API request instead of being restricted to the intended interface. PoC A low-permission user sends a crafted API request to the user-creation endpoint and the system creates the account successfully. Impact This allows attackers to create unauthorized accounts.
Recommended action: Upgrade to 9.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
During the login process, the server response included a parameter called isMasterAdmin. By intercepting and modifying this parameter value from false to true, a user is able to gain access to the admin dashboard interface. However, despite accessing the admin panel, the user does not have sufficient permissions to view or interact with actual data. PoC Intercept the login response and change "isMasterAdmin": false → "isMasterAdmin": true <img width="1405" height="567" alt="image" src="https://github.com/user-attachments/assets/7036398b-bb41-46c1-b66a-e49ec2bc3abb" / <img width="1533" height="476" alt="2" src="https://github.com/user-attachments/assets/4efcaef5-a939-4729-be43-3af62a7d02f8" / Impact The admin dashboard is viewable.
Recommended action: Upgrade to 8.0.5567 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.