Uptime Kuma Server-side Template Injection (SSTI) in Notification Templates Allows Arbitrary File Read

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

6.5 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

EPSS

No dated EPSS signal available.

As published by the source; long descriptions are shortened.

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: In some Notification flows, the send() implementation passes user-editable fields directly into renderTemplate(): 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…

Published by the source

20 Oct 2025, 20:03 UTC

Last modified by the source

2 Apr 2026, 13:29 UTC

Source last checked

26 Oct 2026, 12:38 UTC

1. Revision 2 · amended · 26 Oct 2026

   Amended from ghsa record GHSA-vffh-c9pq-4crh

2. Revision 1 · created · 24 Oct 2026

   Published from osv record GHSA-vffh-c9pq-4crh

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: GHSA-vffh-c9pq-4crh

Advisory: Uptime Kuma Server-side Template Injection (SSTI) in Notification Templates Allows Arbitrary File Read
IDs: GHSA-vffh-c9pq-4crh
Record: https://patchnext.com/advisories/ghsa-vffh-c9pq-4crh (revision 2, source checked 26 Oct 2026, 12:38 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Medium (CVSS 6.5)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor response not established. A vendor fix does not mean a deployment is fixed.

## Affected components
- npm uptime-kuma: affected >= 2.0.0-dev.0, <= 2.0.0-dev.0

## Suggested inspection (read-only)
- `npm ls uptime-kuma --all`: lists every installed copy and version, including transitive ones. Run in the project root after `npm ci`.

## Supported action
No complete vendor fix is recorded. Follow the primary source's mitigation guidance and check this record again before closing anything.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on uptime-kuma.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://osv.dev/vulnerability/GHSA-vffh-c9pq-4crh (OSV record GHSA-vffh-c9pq-4crh lists affected ranges: npm uptime-kuma >=2.0.0-dev.0 <=2.0.0-dev.0)
- Verified: https://github.com/advisories/GHSA-vffh-c9pq-4crh (GitHub-reviewed advisory GHSA-vffh-c9pq-4crh lists affected ranges: npm uptime-kuma >=2.0.0-dev.0 <=2.0.0-dev.0)

Commands are suggestions: review each one before running it.