CVE-2026-30232
SSRF Vulnerability in Chartbrew API Data Connections Allows Internal Access
Publication date: 2026-04-10
Last updated on: 2026-04-14
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| depomo | chartbrew | to 4.8.5 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | 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. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-30232 is a high-severity Server-Side Request Forgery (SSRF) vulnerability in Chartbrew, an open-source web application that connects to databases and APIs to create charts.
Before version 4.8.5, authenticated users could create API data connections with arbitrary URLs. The server would fetch these URLs using the deprecated request-promise library without validating the IP addresses or URL schemes.
This lack of validation allows attackers to perform SSRF attacks by making the server send requests to internal network addresses or cloud metadata endpoints, potentially exposing sensitive internal services or cloud credentials.
- No filtering of private IP ranges (e.g., 127.0.0.0/8, 10.0.0.0/8) or cloud metadata endpoints (e.g., 169.254.169.254).
- No URL scheme validation.
- Use of deprecated request-promise library without SSRF protections.
An attacker with authentication can exploit this by specifying URLs that access internal services or cloud metadata, leading to unauthorized data access or credential theft.
How can this vulnerability impact me? :
This vulnerability can have serious impacts including unauthorized access to internal network services and theft of cloud metadata credentials.
- Attackers can retrieve sensitive information such as AWS, GCP, or Azure instance metadata and credentials by exploiting the SSRF flaw.
- It can allow unauthorized access to internal services like databases (e.g., Redis, Elasticsearch) or administrative interfaces that are normally protected.
- Since any authenticated team member can exploit this, it increases the risk of insider threats or compromised accounts being used to attack internal infrastructure.
Overall, the vulnerability can lead to data breaches, privilege escalation, and compromise of cloud infrastructure.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unusual or unauthorized outbound HTTP requests originating from the Chartbrew server, especially requests to internal IP ranges (such as 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata service endpoints (e.g., 169.254.169.254).
Since the vulnerability involves authenticated users creating API connections with arbitrary URLs, reviewing logs for POST requests to the endpoint `/team/:team_id/connections/:type/test` can help identify attempts to exploit the SSRF.
Suggested commands to detect potential exploitation attempts include:
- Use network monitoring tools like tcpdump or Wireshark to capture outbound HTTP requests from the Chartbrew server and filter for requests to private IP ranges or metadata IPs. Example: `tcpdump -i eth0 dst net 10.0.0.0/8 or dst net 169.254.169.254`
- Check web server or application logs for POST requests to the vulnerable API endpoint: `grep "/team/" /path/to/chartbrew/logs/access.log | grep "/connections/"`
- Use curl or similar tools to test if the server allows requests to internal IPs by attempting to create API connections with URLs pointing to internal services or metadata endpoints (requires authentication).
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Upgrade Chartbrew to version 4.8.5 or later, where protections against SSRF attacks have been introduced.
- If upgrading is not immediately possible, restrict access to the vulnerable API endpoint `/team/:team_id/connections/:type/test` to trusted users only, as exploitation requires authentication.
- Implement network-level controls such as firewall rules to block outbound HTTP requests from the Chartbrew server to private IP ranges and cloud metadata IP addresses.
- Review and apply the new configuration flag `CB_ALLOW_PRIVATE_NETWORK_CALLS` (default false) to control whether private network calls are allowed, and set the `allowPrivateHost` attribute appropriately for connections.
- Monitor outbound requests and audit logs for suspicious activity related to SSRF attempts.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in Chartbrew allows authenticated users to perform Server-Side Request Forgery (SSRF) attacks, enabling unauthorized access to internal networks and cloud metadata endpoints. This can lead to theft of sensitive credentials and unauthorized access to internal services and databases.
Such unauthorized access and potential data exposure can negatively impact compliance with common standards and regulations like GDPR and HIPAA, which require protection of sensitive data and prevention of unauthorized access.
Specifically, the ability to access cloud metadata credentials or internal databases could lead to breaches of personal or protected health information, violating confidentiality and security requirements mandated by these regulations.