Skip to content

GCP and selected cloud providers provide metadata endpoints to the local network which can be queried to extract sensitive information via authentificated accounts in uptime kuma

Moderate
louislam published GHSA-qjxc-h5jf-c7rj Oct 13, 2025

Package

npm uptime-kuma (npm)

Affected versions

*

Patched versions

None
docker uptime-kuma (docker)
*
None

Description

Note

This advisory is not classified as an issue in uptime kuma, but rather the deployment platform.
Since we don't have the resources to work around the implementations of google/... we will not fix this issue in uptime-kuma.
Users of said cloud platforms are asked to enact tighter security if their security profile requires it.

Summary

Authenticated Arbitrary Data Exposure via SSRF

Details

It was discovered that the "Add New Monitor" feature is vulnerable to authenticated arbitrary data exposure via SSRF, using "HTTP(s) - keyword" mode, an authenticated attacker can fuzz the "Keyword" field and analyze the response errors. An attacker could potentially leak sensitive arbitrary information on an internal endpoint that exposes sensitive information

PoC

In this PoC, we will exfiltrate cloud metadata since major cloud providers, including Google Cloud Platform (GCP), Amazon Web Services (AWS), and Microsoft Azure, expose instance metadata services (IMDS) via an internal IP (169.254.169.254) or designated internal domains (metadata.google.internal, 169.254.169.253 for AWS, etc.). These endpoints provide sensitive information, such as OAuth tokens, SSH keys, IAM credentials, and internal networking details, for cloud-based instances.

In our case, Uptime Kuma was deployed in Google Cloud Platform, to test this PoC it need to be deployed in some cloud environment.

GCP PoC (click to expand)
  1. Authenticate
  2. Add new Monitor
  3. Set Monitor Type to HTTP(S) - Keyword
  4. Set Headers to 
    {
    "Metadata-Flavor": "Google"
}
  5. Set URL to for example http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
  6. Set keyword to any random data
    image
    Notice in response it return the first 50 char length as mentioned in code
  7. Now we can bruteforce for data that is long, although I'm showing PoC from the UI
    Case if a character is incorrect
    image
    Case if a character is correct
    image

But for data that is short, you can read the response, which in our case its the paths where you can check more data..

image

Impact

Data exposure through SSRF Vulnerability, the affected are the ones who hosts at a cloud provider

  1. Attackers can extract temporary cloud access tokens (AWS IAM roles, GCP service accounts, Azure Managed Identity) from the metadata API, allowing unauthorized access to cloud services and infrastructure.
  2. Attackers can retrieve sensitive metadata information, including:
  • Instance & Project Details
  • Networking Information
  • SSH Keys & User Data
  • Cloud Access Credentials

Recomended action for affected users

Docker

If a user requires a tighter security, they need to add packet filtering
https://docs.docker.com/engine/network/packet-filtering-firewalls/

nodejs

If a user requires a tighter security, they needs system level firewall like ufw

kuberenetes based

If a user requires a tighter security, they should add a network policy forbidding access to said metadata service.
GKE-users can add below network policy (other cloud providers need adjustments).

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-except-metadata
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32
      ports:
      - protocol: TCP
        port: 443
      - protocol: TCP
        port: 53
      - protocol: UDP
        port: 53

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required High
User interaction Passive
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability None
Subsequent System Impact Metrics
Confidentiality High
Integrity High
Availability High

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H

CVE ID

No known CVE

Weaknesses

Reliance on IP Address for Authentication

The product uses an IP address for authentication. Learn more on MITRE.

Missing Authentication for Critical Function

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. Learn more on MITRE.

Missing Authorization

The product does not perform an authorization check when an actor attempts to access a resource or perform an action. Learn more on MITRE.

Server-Side Request Forgery (SSRF)

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. Learn more on MITRE.

Credits