Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The GET /api/badge/:id/ping/:duration? endpoint in server/routers/api-router.js does not verify that the requested monitor belongs to a public group. All other badge endpoints check AND public = 1 in their SQL query before returning data. The ping endpoint skips this check entirely, allowing unauthenticated users to extract average ping/response time data for private monitors. Affected Code File: server/routers/api-router.js, approximately line 304 The ping badge endpoint directly calls UptimeCalculator.getUptimeCalculator(requestedMonitorId) without first checking if the monitor is public. Compare with the status badge endpoint (~line 148) which correctly queries: Protected vs Vulnerable Endpoints | Endpoint | Has public=1 check? | |----------|-------------------| | /api/badge/:id/status | Yes | | /api/badge/:id/uptime/:duration? | Yes | | /api/badge/:id/avg-response/:duration? | Yes | | /api/badge/:id/cert-exp | Yes | | /api/badge/:id/response | Yes | |…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. For the regular expression /\/$/, an attack string like…
Recommended action: Upgrade to 2.0.0-beta.2 (pre-release); some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An Improper URL Handling Vulnerability allows an attacker to access sensitive local files on the server by exploiting the file:/// protocol. This vulnerability is triggered via the "real-browser" request type, which takes a screenshot of the URL provided by the attacker. By supplying local file paths, such as file:///etc/passwd, an attacker can read sensitive data from the server. Details The vulnerability arises because the system does not properly validate or sanitize the user input for the URL field. Specifically: 1. The URL input (<input data-v-5f5c86d7="" id="url" type="url" class="form-control" pattern="https?://.+" required="") allows users to input arbitrary file paths, including those using the file:/// protocol, without server-side validation. 2. The server then uses the user-provided URL to make a request, passing it to a browser instance that performs the "real-browser" request, which takes a screenshot of the content at the given URL. If a local file path is…
Recommended action: Upgrade to 2.0.0-beta.1 (pre-release) or 1.23.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Installation of a maliciously crafted plugin allows for remote code execution by an authenticated attacker. Details Uptime Kuma allows authenticated users to install plugins from an official list of plugins. This feature is currently disabled in the web interface, but the corresponding API endpoints are still available after login. After downloading a plugin, it's installed by calling npm install in the installation directory of the plugin: https://github.com/louislam/uptime-kuma/blob/8c60e902e1c76ecbbd1b0423b07ce615341cb850/server/plugins-manager.js#L210-L216 Because the plugin is not validated against the official list of plugins or installed with npm install --ignore-scripts, a maliciously crafted plugin taking advantage of npm scripts can gain remote code execution. PoC In the PoC below, the plugin at https://github.com/n-thumann/npm-install-script-poc will be installed. It only consists of an empty index.js and a package.json containing the script: "preinstall": "echo…
Recommended action: Upgrade to 1.22.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability via the plugin repository name allows an authenticated attacker to delete files on the server leading to unavailability and potentially data loss. Details Uptime Kuma allows authenticated users to install plugins from an official list of plugins. This feature is currently disabled in the web interface, but the corresponding API endpoints are still available after login. Before a plugin is downloaded, the plugin installation directory is checked for existence. If it exists, it's removed before the plugin installation. Because the plugin is not validated against the official list of plugins or sanitized, the check for existence and the removal of the plugin installation directory are prone to path traversal. Impact This vulnerability allows an authenticated attacker to delete files from the server Uptime Kuma is running on. Depending on which files are deleted, Uptime Kuma or the whole system may become unavailable due to data loss.
Recommended action: Upgrade to 1.22.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is basically GHSA-88j4-pcx8-q4q but instead of changing passwords, when enabling authentication. PoC - Open Uptime Kuma with authentication disabled - Enable authentication using another window - Access the platform using the previously logged-in window - Note that access (read-write) remains despite the enabled authentication - Expected behaviour: - After enabling authentication, all previously connected sessions should be invalidated, requiring users to log in. - Actual behaviour: - The system retains sessions and never logs out users unless explicitly done by clicking logout or refreshing the page. Impact See GHSA-g9v2-wqcj-j99g and GHSA-88j4-pcx8-q4q TBH this is quite a niche edge case, so I don't know if this even warrants a security report.
Recommended action: Upgrade to 1.23.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A moderate security vulnerability has been identified in Uptime Kuma platform that poses a significant threat to the confidentiality and integrity of user accounts. When a user changes their login password in Uptime Kuma, a previously logged-in user retains access without being logged out. This behaviour persists consistently, even after system restarts or browser restarts. This vulnerability allows unauthorized access to user accounts, compromising the security of sensitive information. The same vulnerability was partially fixed in https://github.com/louislam/uptime-kuma/security/advisories/GHSA-g9v2-wqcj-j99g but logging existing users out of their accounts was forgotten. Impact: The impact of this vulnerability is moderate, as it enables attackers or unauthorized individuals to maintain access to user accounts even after the account password has been changed. This can lead to unauthorized data access, manipulation, or compromise of user accounts, posing a threat to the…
Recommended action: Upgrade to 1.23.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The runTailscalePing method of the TailscalePing class injects the hostname parameter inside a shell command, leading to a command injection and the possibility to run arbitrary commands on the server. Details When adding a new monitor on Uptime Kuma, we can select the "Tailscale Ping" type. Then we can add a hostname and insert a command injection payload into it. The front-end application requires that the field follow a specific pattern, this validation only happens on the front-end and can be removed by removing the attribute pattern on the input element. https://github.com/louislam/uptime-kuma/blob/dc4242019331e65a79ac16deef97510144e01b12/server/monitor-types/tailscale-ping.js#L40-L46 We can finally add the new monitor and observe that our command is being executed. NOTE: When using Uptime Kuma inside a container, the "TailScale Ping" type is not visible. We can fake this information by intercepting WebSocket messages and set the isContainer option to false. PoC…
Recommended action: Upgrade to 1.23.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Google Analytics element Attribute Injection leading to XSS Details Since the custom status interface can set an independent Google Analytics ID and the template has not been sanitized, there is an attribute injection vulnerability here, which can lead to XSS attacks. PoC 1. Run the latest version of the louislam/uptime-kuma container and initialize the account password. 2. Create a new status page. 3. Edit the status page and change the Google Analytics ID to following payload(it only works for firefox. Any attribute can be injected, but this seems the most intuitive): 4. Click Save and return to the interface. XSS occurs. screenshots:
Recommended action: Upgrade to 1.23.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Attackers with access to a users' device can gain persistent account access. This is caused by missing verification of Session Tokens after password changes and/or elapsed inactivity-periods. Details uptime-kuma sets JWT tokens for users after successful authentication. These tokens have the following design flaws: - After successful login, a JWT token and it is stored in sessionStorage or localStorage. Which of the two is decided based on the Remember Me button. The users' token is valid without any time limitation, even after long periods of inactivity. This increases the risk of session hijacking if, for example, a user forgets to log off and leaves the PC. - sessions are only deleted on the client side after a user loggs out, meaning a local attacker could reuse said token with deep system access over the browser - If a user changes a password - any previously logged in clients are not logged out - previously issued tokens remained valid forever These flaws allow user…
Recommended action: Upgrade to 1.23.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.