CVE-2026-61743: Chartbrew DNS Rebinding SSRF Vulnerability

CVE-2026-61743 Overview

Chartbrew is an open-source web application that connects to databases and APIs to visualize data as charts. Versions prior to 5.2.2 contain a DNS rebinding vulnerability in the outbound request validation logic. The server/modules/safeRequest.js module calls validateOutboundUrl() to resolve and validate target hostnames, but the underlying request-promise library performs a separate DNS resolution when initiating the actual connection. An authenticated user who controls a target DNS name can return a public address during validation and a private address during the connection, bypassing the protections in server/modules/outboundTargetPolicy.js.

Critical Impact
Attackers can reach internal services, localhost resources, and cloud metadata endpoints, exposing sensitive infrastructure data.

Affected Products

Chartbrew versions prior to 5.2.2
server/modules/safeRequest.js component
server/modules/outboundTargetPolicy.js component

Discovery Timeline

2026-09-21 - CVE-2026-61743 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-61743

Vulnerability Analysis

The vulnerability is a classic time-of-check to time-of-use (TOCTOU) flaw expressed as DNS rebinding [CWE-350]. Chartbrew validates outbound URLs by resolving the hostname and confirming the resulting IP address is not private, internal, or otherwise restricted. The problem arises because the validation and the actual HTTP request perform independent DNS lookups against the attacker-controlled name.

An attacker with permission to create or test API connections registers a hostname on a DNS server they control. The first lookup returns a public IP that passes the allowlist. The second lookup, triggered by request-promise when opening the connection, returns a private address such as 127.0.0.1, 169.254.169.254, or an RFC1918 range. The resulting request reaches internal-only endpoints while the application believes it contacted a public host.

Root Cause

The root cause is the lack of a shared DNS resolution result between validation and request execution. Because request-promise did not accept a pinned lookup function, it re-resolved the hostname independently, allowing the attacker to serve different answers to each query.

Attack Vector

Exploitation requires an authenticated Chartbrew user with the ability to configure or test outbound API connections. The attacker points the connection at a domain whose authoritative DNS server rotates responses between a benign public address and a targeted internal address. Common targets include cloud instance metadata services, internal admin interfaces, and services bound to loopback.

javascript

// Security patch in server/modules/safeRequest.js
 const request = require("request-promise");
+const net = require("net");
 
 const { validateOutboundUrl } = require("./outboundTargetPolicy");
 const { sanitizeOutboundRequestOptions } = require("./sanitizeOutboundRequestOptions");

Source: GitHub Commit d38d745

javascript

// Security patch in server/modules/sanitizeOutboundRequestOptions.js
   "pool",
   "forever",
   "localAddress",
+  "lookup",
 ];

Source: GitHub Commit d38d745. The fix adds lookup to the allowlist of forwarded request options so that a pinned DNS resolver can be passed to request-promise, ensuring both validation and connection use the same resolved address.

Detection Methods for CVE-2026-61743

Indicators of Compromise

Outbound HTTP requests from Chartbrew servers to RFC1918, loopback, or link-local addresses such as 169.254.169.254.
API connection configurations pointing to domains with unusually low DNS TTL values.
Chartbrew audit logs showing repeated connection tests against the same external hostname within seconds.

Detection Strategies

Monitor DNS traffic from the Chartbrew host for domains that resolve inconsistently between successive queries.
Alert when the application process initiates connections to internal subnets or cloud metadata endpoints.
Review Chartbrew connection creation events for hostnames outside expected business partners.

Monitoring Recommendations

Enable egress logging on the Chartbrew server and correlate destination IPs with hostnames from prior DNS responses.
Instrument reverse proxies to record Host headers and destination IPs for all outbound traffic from the application.
Track authenticated Chartbrew API activity, focusing on users who create or modify data source connections.

How to Mitigate CVE-2026-61743

Immediate Actions Required

Upgrade Chartbrew to version 5.2.2 or later, which pins DNS resolution across validation and request execution.
Restrict which authenticated users can create or test outbound API connections until the upgrade is complete.
Block egress from the Chartbrew host to internal management ranges and cloud metadata endpoints at the network layer.

Patch Information

The fix is available in Chartbrew Release v5.2.2. Technical details are documented in the GitHub Security Advisory GHSA-9537-vm84-j26f and the remediation commit d38d745.

Workarounds

Deploy an egress firewall rule denying Chartbrew traffic to 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.169.254.
Route Chartbrew outbound traffic through a forward proxy that enforces destination IP allowlists after DNS resolution.
Disable cloud instance metadata service v1 and require IMDSv2 with hop-limit restrictions on the Chartbrew host.

bash

# Example iptables rules to block metadata and private ranges from the Chartbrew user
iptables -A OUTPUT -m owner --uid-owner chartbrew -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner chartbrew -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner chartbrew -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner chartbrew -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner chartbrew -d 127.0.0.0/8 -j REJECT