Uptime Kuma 2.5.4 landed on September 11, 2026, a signed release published on the project’s official GitHub page by maintainer louislam. The headline item is a critical security fix: a vulnerability in the JSONata library that Uptime Kuma uses to evaluate conditions in notifications and status page logic could be chained into arbitrary code execution on the host running the monitor. Uptime Kuma typically holds API keys and tokens for dozens of connected notification services, so code execution on that host has a wider blast radius than the monitoring dashboard alone. JSONata conditions in Uptime Kuma are written by whoever configures your monitors and notifications, normally just the instance admin, so this isn’t something a random visitor to a public status page can trigger on its own. The real-world exposure is narrower than the CVSS score alone suggests on a typical single-admin homelab instance, and wider on any instance where monitor or notification configuration is shared with less-trusted collaborators. Either way, the fix is a one-line dependency bump with no downside, so there’s little reason to wait for a routine maintenance window.
A critical JSONata code execution flaw
The fix is tracked as CVE-2026-77415, rated 9.3 out of 10 on the CVSS v4.0 scale (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N): network-exploitable, no privileges or user interaction required, with high impact on confidentiality, integrity, and availability. It’s documented as GHSA-66mm-25pp-rfff and lives in JSONata, the expression language Uptime Kuma embeds so conditions can run inside notifications and status page logic.
A crafted JSONata expression could chain several object-integrity weaknesses together: overwriting the built-in $clone function through evaluateTransformExpression, using $merge to expose and pick apart internal functions, and from there reaching prototype getters and constructor access. That chain ends at process.getBuiltinModule and Node’s child_process module, enough to run arbitrary commands with the privileges of the Uptime Kuma process itself.
Uptime Kuma closes the flaw by bumping its jsonata dependency to version 2.2.2 (PR #7838). There’s no separate patch inside Uptime Kuma’s own code to apply; updating to 2.5.4 pulls in the fixed library automatically.
A second, smaller fix
This release also closes GHSA-wf2j-5mc7-5c4w, described in the changelog as a denial-of-service weakness. No CVE number or CVSS score has been published for it, and it’s a smaller concern than the JSONata flaw, but it ships in the same 2.5.4 build, so there’s no reason to delay the update over it.
New features: SFTP monitoring and three notification providers
Security fixes aside, 2.5.4 also brings genuine feature work:
- A new SFTP monitor type, with support for both password and private key authentication (PR #7034).
- Three new notification providers: Signalgrid, Notify!, and Amoot SMS.
On the interface side, the login page now has a show/hide toggle for the password field, a small usability fix that’s been requested for a while.
Other fixes in this release
A handful of smaller bugs got cleaned up too: the browser context used by the “real browser” monitor type didn’t always close properly, the iOS PWA icon had an unwanted black background, two ping-timeout ceiling fields in the monitor form were swapped with each other, a MariaDB connection-pool timing issue was corrected, and a custom accepted-status-code range no longer gets discarded when a tag is created.
Should you update?
CVE-2026-77415 is rated critical, but exploiting it requires the ability to author a malicious JSONata expression in your instance’s monitor or notification configuration, not just visit a public status page. On most single-admin setups that means the update matters more as good hygiene than as an emergency; it matters more urgently on instances where monitor configuration is shared with people you don’t fully trust. Updating follows the usual Uptime Kuma routine: pull the new image if you’re running the official Docker container, or update the npm package if you installed on Node.js directly, then restart the service.
If you haven’t set up Uptime Kuma yet, our Uptime Kuma guide walks through the Docker install, HTTP/TCP/ping monitoring, and public status pages from scratch, and our earlier coverage of Uptime Kuma 2.5.0 covers the NTP monitor and npm cooldown feature introduced in the previous release.
Sources: the Uptime Kuma 2.5.4 release notes on GitHub, and the GHSA-66mm-25pp-rfff advisory for CVE-2026-77415.