OneUptime probe allows anonymous RCE via node:vm sandbox escape

OneUptime probe lets an anonymous user achieve full cluster RCE in about 30 seconds, thanks to a node:vm sandbox escape

Short version, and then the bit that should make your board pick up the phone: a recent advisory disclosed a critical vulnerability in OneUptime where the custom JavaScript monitor feature uses Node.js’s node:vm module as an execution sandbox. Because node:vm is explicitly not a security boundary, a trivial one-liner can escape the sandbox and execute code in the probe process. The probe runs with host networking and carries cluster credentials in its environment variables, so an attacker can go from anonymous user to full cluster compromise in roughly 30 seconds. The issue is fixed in OneUptime 10.0.5.

Slow version, with the worrying details. OneUptime monitors run probes that hold secrets like ONEUPTIME_SECRET, DATABASE_PASSWORD, REDIS_PASSWORD and CLICKHOUSE_PASSWORD in their environment. Monitor creation is available to the ProjectMember role, and open registration is enabled by default. That combination means the lowest-privilege user, or someone who simply signs up, can create a malicious monitor, run the payload and pull secrets or run arbitrary commands on the host. It is the kind of chain you hope only exists in tabletop exercises, not in production clusters.

Why this matters to your organisation

Although this affects OneUptime users directly, the business consequences are familiar. If cluster credentials are exposed an attacker can read or modify databases, hijack caches, exfiltrate data, or push further exploits — all of which can cause operational outage, contractual breaches, regulatory reporting obligations and expensive remediation. Organisations that rely on monitoring platforms for uptime and alerts could suddenly find those very tools used to sabotage services or steal data. That is not hypothetical. It is a neat, high-speed route to a catastrophic incident.

Because the probe runs with host networking and rich environment variables, the blast radius grows quickly. Following a compromise there is a real risk of downstream impacts on customers, partners and suppliers, and of regulators demanding explanations about why privileged secrets were left exposed to code supplied by regular project members. Boards do not enjoy those calls. IT teams enjoy them even less.

How this kind of failure typically plays out, if ignored

While a quick upgrade will stamp out the immediate bug, ignoring the underlying habits that made it possible invites repetition. Attackers can quietly harvest credentials, create persistent backdoors, or tamper with telemetry so incidents go undetected. Backups and failover processes can be sabotaged. Staff time gets swallowed by firefighting. Customers get angry. Contracts get cancelled. All too soon the cost of recovery outstrips the investment that would have prevented the problem in the first place.

Short pause. Parachutes you have never opened are no good. Untested incident response plans are the same. If your monitoring platform can be used as an attack vector, your observability tooling has stopped being an ally and become a weapon.

What should have been in place, and how ISO 27001 helps

Although this vulnerability is specific, the root causes are common: unsafe code execution, excessive privileges, weak registration and onboarding controls, and poor secret management. An ISO 27001 information security management system helps businesses address these precisely, by insisting on documented risk assessments, clear access control policies, supplier and third-party controls, and change management for software features that execute user-supplied code.

Since monitoring probes are effectively part of your infrastructure, they should be subject to the same controls as production services. That means running probes with the least privilege necessary, avoiding environment variables for long-term secrets where possible, using dedicated service accounts, and isolating network access so a compromised probe cannot talk to everything.

Although technical fixes are vital, process matters too. ISO 27001 can help you embed secure development practices and require justification for any feature that executes untrusted code. And if your business needs to keep operating during or after an incident, ISO 22301 business continuity planning ensures there are tested plans to keep customers served and staff paid while you sort the clean-up.

Practical immediate steps, do this now

Mitigation

• Upgrade OneUptime to version 10.0.5 immediately, or follow vendor guidance if you cannot upgrade straight away.

• Disable or restrict the custom JavaScript monitor feature until you have secured its execution model.

• Turn off open registration and restrict monitor creation to trusted roles only, and review project member privileges.

• Rotate any secrets that may have been exposed, including ONEUPTIME_SECRET, database passwords, Redis and ClickHouse credentials, and any service tokens used by probes.

Containment and review

• Isolate probe hosts from sensitive infrastructure via network segmentation, and restrict host networking for probes so they cannot reach everything.

• Audit logs for suspicious monitor creation and execution, and look for unexpected network connections or credential use.

• Run a focused incident response investigation, and consider a forensic review if you see signs of secret exfiltration or unauthorised access.

Medium-term fixes

• Move secret storage away from plain environment variables where feasible, for example into a dedicated secrets manager with strict access control and auditing.

• Apply least privilege to service accounts and probes, and adopt defence-in-depth with MFA for administrative actions and role-based access control that prevents low-privilege users from creating executable monitors.

• Introduce secure code review and testing for any feature that executes user-supplied code, and document the risk acceptance explicitly as part of change control.

Where Synergos services can help, without the sales patter

Although the fixes are straightforward, organisations frequently need expert help to translate them into policies, tests and plans that actually stick. If you want structured guidance on what to do next, ISO 27001 consultancy can convert this incident into manageable controls and evidence for auditors. If you worry about continuity while you recover, look at ISO 22301 support to keep services running under pressure.

Since baseline controls stop a lot of simple attacks, consider practical measures such as Cyber Essentials and IASME for quick wins, and security awareness training so your teams spot suspicious onboarding or monitor creation activity earlier. If you would rather not lift a finger yourself, Synergos’ ongoing support packages can help with patching, configuration reviews and incident response playbooks that actually get used.

Although it is tempting to treat monitoring tools as unrestricted developer playgrounds, they are part of your attack surface and need the same careful controls you apply to databases and application servers.

Final nudge: while an upgrade and a couple of config changes will close this particular hole, treat the incident as an opportunity to tighten secrets handling, restrict who can run code, and practise your incident response. Do that, and the next alert will be about uptime not an emergency board call.