GHSA-hfxh-rjv7-2369 — uptime-kuma
GHSA-hfxh-rjv7-2369 is a remote code execution vulnerability in uptime-kuma. A fix is available for uptime-kuma — see the affected versions and patch details below.
Uptime Kuma Authenticated remote code execution via TailscalePing
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
uptime-kumanpmDescription
Summary
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.
Remediation
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | uptime-kuma | ≥ 1.23.0&&< 1.23.7 | 1.23.7npm install uptime-kuma@1.23.7 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for uptime-kuma, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update uptime-kuma to 1.23.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hfxh-rjv7-2369 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-hfxh-rjv7-2369 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-hfxh-rjv7-2369. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-hfxh-rjv7-2369 in your dependencies?
O3 Security finds GHSA-hfxh-rjv7-2369 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.