Description

Chartbrew is an open-source web application for creating charts from databases and APIs. In versions 4.8.5 through 5.2.2, API connection creation and update operations accept the internal  allowPrivateHost  field from user input. An authenticated user with permission to manage API connections can enable this field to bypass private and reserved-network destination restrictions. An upgrade migration also enables the override on pre-existing API connections. The per-connection setting takes precedence over  CB_ALLOW_PRIVATE_NETWORK_CALLS , so disabling that instance option does not protect connections with the override enabled. Successful exploitation allows requests to internal HTTP services reachable from the Chartbrew server, potentially disclosing information or triggering unauthorized actions depending on the target service. Recognized cloud metadata endpoints remain separately blocked. This issue is fixed in version 5.2.3.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-11-06T22:17:59.390Z",
  "pubdate": "2026-11-06T22:17:59.390Z",
  "executiveSummary": "Chartbrew versions 4.8.5 through 5.2.2 contain a Server-Side Request Forgery (SSRF) vulnerability due to improper input validation during API connection management.\nThe vulnerability originates from the application's failure to sanitize the 'allowPrivateHost' field, which allows authenticated users with administrative privileges over API connections to bypass network segmentation controls.\nBy enabling this flag, an attacker can force the server to interact with internal services that are typically restricted from external access. An automated migration path also inadvertently enables this override for legacy API connections, increasing the attack surface.\nThe risk is exacerbated because the per-connection setting takes precedence over the global 'CB_ALLOW_PRIVATE_NETWORK_CALLS' configuration, rendering global security policies ineffective if an individual connection is modified.\nWhile cloud metadata services remain protected by secondary mechanisms, this flaw allows for the discovery and interaction with internal HTTP services, potentially leading to unauthorized data disclosure or the execution of internal service functions.\nExploitation requires authenticated access with sufficient permissions to manage API connections.",
  "technicalDetails": "The root cause of this vulnerability is an insecure implementation of input handling within the API connection configuration logic. The application permits user-controlled input to define the 'allowPrivateHost' boolean flag, which serves as a security bypass for the internal request proxy.\nIn affected versions (4.8.5 through 5.2.2), the application logic fails to validate whether the current user is authorized to override network restrictions. When a user creates or updates an API connection, they can inject 'allowPrivateHost: true' into the request payload. Because this field is processed as a persistent setting, the application stores the override within the connection metadata.\nThe attack flow proceeds as follows: 1. An authenticated user with sufficient privileges intercepts or crafts an API connection request. 2. The attacker sets the 'allowPrivateHost' parameter to true. 3. Upon request execution, the Chartbrew server-side component processes the connection. 4. The application logic prioritizes the per-connection 'allowPrivateHost' configuration over the global instance setting 'CB_ALLOW_PRIVATE_NETWORK_CALLS'. 5. Consequently, the internal proxy ignores established firewall rules or destination restrictions, allowing the server to perform HTTP requests against private IP ranges (e.g., 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).\nA significant complication exists regarding legacy data. An upgrade migration script included in the affected versions automatically enables this override on pre-existing API connections, potentially exposing internal infrastructure that was previously protected by the default global configuration.\nThis vulnerability is effectively an authenticated SSRF. While the metadata service remains hardened against these requests, other internal endpoints—such as databases with REST APIs, administrative dashboards, or internal microservices—become reachable. An attacker can perform reconnaissance on the internal network by probing open ports and capturing responses. Post-exploitation, an attacker can leverage this primitive to access sensitive business logic, perform unauthorized data exfiltration, or initiate authenticated actions against internal systems trusting the Chartbrew server's IP address."
}