Summary
Uptime Kuma Authenticated remote code execution via TailscalePing
The runTailscalePing method of the TailscalePing class injects the hostname parameter inside a shell command, leading to a command injection and the possibility to run arbitrary commands on the server.
Details
When adding a new monitor on Uptime Kuma, we can select the "Tailscale Ping" type. Then we can add a hostname and insert a command injection payload into it. The front-end application requires that the field follow a specific pattern, this validation only happens on the front-end and can be removed by removing the attribute pattern on the input element.
We can finally add the new monitor and observe that our command is being executed.
NOTE: When using Uptime Kuma inside a container, the "TailScale Ping" type is not visible. We can fake this information by intercepting WebSocket messages and set the isContainer option to false.
PoC
- Authenticate.
- Create a new monitor.
- Select the TailScale Ping type (if not visible, see the note in the details section).
- Insert the command injection payload inside the
hostnamefield. (for example$(id >&2)) - Remove the
patternrequirement on the field. - Save and start the monitor.
Impact
An authenticated user can execute arbitrary command on the server running Uptime Kuma.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
There are other command execution in the codebase, they use a method spawn from the child_process module which does not interpret the command as a shell command, the same thing should be done here.
NOTE: The Tailscale CLI seems to support the -- sequence. It should be used between the ping subcommand and the hostname argument to avoid argument injection.
Frequently Asked Questions
- What is GHSA-HFXH-RJV7-2369? GHSA-HFXH-RJV7-2369 is a medium-severity security vulnerability in uptime-kuma (npm), affecting versions >= 1.23.0, <= 1.23.6. It is fixed in 1.23.7.
- Which versions of uptime-kuma are affected by GHSA-HFXH-RJV7-2369? uptime-kuma (npm) versions >= 1.23.0, <= 1.23.6 is affected.
- Is there a fix for GHSA-HFXH-RJV7-2369? Yes. GHSA-HFXH-RJV7-2369 is fixed in 1.23.7. Upgrade to this version or later.
- Is GHSA-HFXH-RJV7-2369 exploitable, and should I be worried? Whether GHSA-HFXH-RJV7-2369 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-HFXH-RJV7-2369 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-HFXH-RJV7-2369? Upgrade
uptime-kumato 1.23.7 or later.