OneUptime Patches Critical Command Injection Vulnerability in Probe Servers
Take action: If you are using OneUptime, this is important. Consider Treat every authenticated user as a potential risk. Plan a very quick update your monitoring Probes to version 10.0.7. Ensure your monitoring infrastructure is isolated from your core production network to prevent lateral movement if it's compromised.
Learn More
OneUptime, an open-source platform for monitoring and managing online services, patched a critical security flaw in its Probe Server component.
The vulnerability is tracked as CVE-2026-27728 (CVSS score 9.9), allows authenticated users to execute arbitrary commands on the underlying host. The vulnerability stems from improper input handling within the NetworkPathMonitor.performTraceroute() function. This function processes traceroute operations by taking a user-supplied "destination" string and passing it to the Node.js child_process.exec() method. Because exec() spawns a shell to run commands, it interprets shell metacharacters like semicolons, pipes, and subshell syntax. An attacker can craft a malicious monitor configuration, such as example.com; cat /etc/passwd, to break out of the intended command and run unauthorized code with the privileges of the Probe server.
Successful exploitation grants an attacker full remote code execution (RCE) on the Probe server. Since Probe servers often require elevated network permissions to perform monitoring tasks, a compromise could expose internal services that are usually isolated from the public internet.
The flaw impacts OneUptime versions up to and including 10.0.6. Although the vulnerability requires authentication, any project user with basic permissions to create or edit monitors can trigger the exploit.
OneUptime released version 10.0.7 to resolve the issue by migrating from exec() to execFile(). Unlike the previous method, execFile() executes binaries directly with an array of arguments, preventing the shell from interpreting metacharacters. Administrators should update their instances immediately using the latest Docker images.
If patching is delayed, organizations should restrict monitor creation permissions to highly trusted users and isolate Probe servers within a segmented network to limit the potential blast radius.
