CVE-2026-68935 in Chartbrew
Summary
by MITRE • 11/06/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/06/2026
Chartbrew serves as an open-source web application designed to facilitate the creation of visual charts by integrating data from various databases and APIs. In versions ranging from 4.8.5 through 5.2.2, a critical security flaw exists within the API connection management functionality that allows for unauthorized access to internal network resources. The vulnerability stems from the application accepting an internal configuration field named allowPrivateHost directly from user input during both the creation and update operations of API connections. This design oversight permits authenticated users who possess permissions to manage API connections to manipulate this setting, effectively overriding security controls intended to restrict outbound requests to private or reserved IP address ranges.
The technical nature of this flaw constitutes an insecure direct object reference combined with a lack of proper validation for internal network destinations, aligning closely with CWE-918 Server-Side Request Forgery and CWE-20 Improper Input Validation. By enabling the allowPrivateHost flag, an attacker can bypass standard private-network restrictions that are typically enforced to prevent servers from interacting with sensitive internal services such as database backends, management consoles, or other microservices residing on the same network segment. This behavior is particularly dangerous because it allows for Server-Side Request Forgery attacks where the server itself acts as a proxy, initiating requests to targets that would otherwise be inaccessible from external networks due to firewall rules or network segmentation policies.
The operational impact of this vulnerability is significant, as successful exploitation enables an authenticated user to send HTTP requests to internal services reachable by the Chartbrew server. Depending on the nature and security posture of these targeted internal services, attackers may achieve unauthorized information disclosure by querying sensitive endpoints or trigger arbitrary actions within those systems. This capability effectively extends the attack surface from a single web application into the broader internal infrastructure, potentially leading to further compromise if internal services lack robust authentication mechanisms themselves. Notably, while cloud metadata endpoints are separately blocked and remain protected against this specific bypass technique, other internal resources such as local databases or administrative interfaces remain exposed to exploitation via this vector.
Complicating mitigation efforts is a migration behavior present in the affected versions where an upgrade process automatically enables this override setting on pre-existing API connections. This means that even if administrators disable the global instance-level configuration variable CB_ALLOW_PRIVATE_NETWORK_CALLS, which normally restricts private network access across the application, individual connections with the allowPrivateHost flag set will continue to operate without restriction because the per-connection setting takes precedence over the global configuration. Consequently, simply disabling the environment variable is insufficient to remediate the vulnerability for existing configurations, requiring manual intervention or a version upgrade to resolve the issue completely.
To mitigate this risk, organizations running Chartbrew versions 4.8.5 through 5.2.2 must immediately upgrade to version 5.2.3 where the flaw has been addressed by removing the ability of users to manipulate the allowPrivateHost field via user input and ensuring that internal network restrictions are consistently applied regardless of connection-specific settings. In environments where upgrading is not immediately feasible, administrators should audit existing API connections for any instances where private host access might have been enabled during migration or manual configuration changes and disable those overrides manually. Additionally, implementing strict egress filtering at the network perimeter can provide a compensating control by blocking outbound requests to internal IP ranges from the Chartbrew server's public-facing interface, thereby limiting the effectiveness of potential SSRF attacks even if the application-level vulnerability is exploited.