CVE-2026-61743 in Chartbrew
Summary
by MITRE • 09/21/2026
Chartbrew is an open-source web application that can connect directly to databases and APIs and use the data to create charts. Prior to 5.2.2, Chartbrew's server/modules/safeRequest.js calls validateOutboundUrl() to resolve and validate a target hostname, but request-promise performs a separate DNS resolution for the actual connection. An authenticated user who can create or test API connections and controls the target DNS name can return a public address during validation and a private address during the request, bypassing the protections implemented by server/modules/outboundTargetPolicy.js. This DNS rebinding condition can expose internal services, localhost resources, or cloud metadata endpoints. This issue is fixed in version 5.2.2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
Chartbrew serves as an open-source web application designed to facilitate data visualization by connecting directly to various databases and APIs to generate charts. The security architecture of the platform includes mechanisms intended to restrict outbound network connections, specifically through a module named safeRequest.js which utilizes a function called validateOutboundUrl(). This validation process is critical for preventing server-side request forgery attacks where an attacker might attempt to direct the application to make requests to internal or restricted resources that should not be accessible from the public-facing interface. The intended security control relies on resolving and validating the target hostname before initiating any network connection, ensuring that only approved external domains are contacted by the backend service.
However, a critical DNS rebinding vulnerability exists in versions prior to 5.2.2 due to an inconsistency between how domain names are validated and how they are resolved during actual transmission. The validateOutboundUrl() function performs an initial DNS resolution to check if the target hostname is permitted under the outbound policy defined in server/modules/outboundTargetPolicy.js. If this validation passes, the application proceeds to use request-promise to establish the actual connection. Crucially, request-promise performs its own independent DNS resolution at the time of the HTTP request rather than reusing the IP address obtained during the initial validation phase. This architectural flaw creates a race condition window where an authenticated user who has the ability to create or test API connections can manipulate this discrepancy by controlling the target DNS name.
By exploiting this timing gap, an attacker can configure their controlled domain to return a public, allowed IP address when queried by validateOutboundUrl(), thereby passing the initial security check. Subsequently, before request-promise executes its own DNS lookup for the actual connection, the attacker modifies the DNS record to resolve to a private internal IP address or a cloud metadata endpoint. When request-promise performs its resolution and initiates the connection, it connects directly to the internal resource rather than the originally validated public address. This effectively bypasses the outbound target policy protections because the validation step never sees the final destination of the network traffic.
The operational impact of this vulnerability is significant as it allows an authenticated user with API creation privileges to access sensitive internal services that are not exposed to the internet. Potential targets include localhost resources, internal database servers, and cloud metadata endpoints such as those found in AWS or Azure environments which often contain authentication credentials and configuration details. This type of attack falls under Common Weakness Enumeration CWE-918, specifically Server-Side Request Forgery (SSRF), where a web application fetches a remote resource without validating the user-supplied URL. Furthermore, this technique aligns with MITRE ATT&CK tactic T1557, Adversary-in-the-Middle, as it involves intercepting and manipulating network communications to gain unauthorized access to internal infrastructure components that are otherwise isolated from external threats.
To mitigate this vulnerability, organizations must upgrade Chartbrew to version 5.2.2 or later where the code has been patched to ensure consistent DNS resolution throughout the request lifecycle. In environments where upgrading is not immediately feasible, administrators should implement strict network-level controls such as firewall rules that restrict outbound traffic from the application server to only known external domains and block access to private IP ranges like 10.x.x.x, 172.16.x.x through 172.31.x.x, and 192.168.x.x. Additionally, implementing DNS sinkholing for internal names or using a dedicated proxy that validates the final resolved IP against the initial request can provide an additional layer of defense against DNS rebinding attacks. Regular security audits focusing on outbound connection handling in web applications are essential to identify similar patterns where validation and execution steps are decoupled.