GHSA-hx7h-9vf7-5xhg Uptime Kuma's Regular Expression in pushdeeer and whapi file Leads to ReDoS Vulnerability Due to Catastrophic Backtracking
SummaryThere 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.DetailsThe 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.For the regular expression `/\/*$/`, an attack string likecan 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.PoCThe 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: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/bf4cee61603e152c114fa8c4791f9f28After 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.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?****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.**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
CVSS v4.0 score: 6.7