GHSA-hfxh-rjv7-2369
GHSA-hfxh-rjv7-2369 is a remote code execution vulnerability in uptime-kuma. O3 Security confirms whether GHSA-hfxh-rjv7-2369 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Uptime Kuma Authenticated remote code execution via TailscalePing
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
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.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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 pinpoints whether GHSA-hfxh-rjv7-2369 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
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 detects GHSA-hfxh-rjv7-2369 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.