GHSA-vffh-c9pq-4crh — uptime-kuma
MEDIUMGHSA-vffh-c9pq-4crh is a medium-severity (CVSS 6.5) vulnerability in uptime-kuma. No vendor fix is recorded yet; mitigation options are listed below.
Uptime Kuma Server-side Template Injection (SSTI) in Notification Templates Allows Arbitrary File Read
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
In some Notification types (e.g., Webhook, Telegram), the send() function allows user-controlled renderTemplate input. This leads to a Server-side Template Injection (SSTI) vulnerability that can be exploited to read arbitrary files from the server.
Details
The root cause is how Uptime Kuma renders user-controlled templates via renderTemplate(). The function instantiates a Liquid template engine and parses the template argument without sanitization:
async renderTemplate(template, msg, monitorJSON, heartbeatJSON) {
const engine = new Liquid();
const parsedTpl = engine.parse(template);
// ...
}
In some Notification flows, the send() implementation passes user-editable fields directly into renderTemplate():
// webhook.js
if (notification.webhookContentType === "form-data") {
const formData = new FormData();
formData.append("data", JSON.stringify(data));
config.headers = formData.getHeaders();
data = formData;
} else if (notification.webhookContentType === "custom") {
data = await this.renderTemplate(notification.webhookCustomBody, msg, monitorJSON, heartbeatJSON); //<- this line cause SSTI
}
Because notification can be edited by users and is rendered by the Liquid engine without proper sandboxing or a whitelist of allowed operations, an attacker can supply a crafted template that causes the server to read arbitrary files. In particular, Liquid’s template tags (e.g. {% render ... %}) can be abused to include server-side files if the engine is not restricted, resulting in Server-side Template Injection (SSTI) that leaks sensitive file contents.
PoC
- Open Uptime Kuma → Notifications → Add or Edit an existing Webhook notification.
- Set notification type to Webhook and set Request Body to Custom Body.
- Paste the following JSON into the custom request body:
{
"Title": {% render '/etc/passwd' %}
}
- Click test.
- Your webhook will receive the file content
Impact
This is a post-authentication Server-side Template Injection (SSTI) vulnerability that allows an authenticated user to perform arbitrary file read on the server.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | uptime-kuma | all versions | No fix |
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.
Remediation status
No patched version of uptime-kuma has shipped for GHSA-vffh-c9pq-4crh yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
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-vffh-c9pq-4crh can be triaged on real exposure rather than presence alone.
Tailored to GHSA-vffh-c9pq-4crh. 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-vffh-c9pq-4crh in your dependencies?
O3 Security finds GHSA-vffh-c9pq-4crh across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.