Chartbrew: SSRF guard bypass via IPv6 NAT64/DNS64 addresses in API Data Connection outbound policy (validateOutboundUrl)
Only affects Chartbrew instances before 5.2.1 deployed on NAT64/DNS64 networks. No vendor rating is given; CVSS scores it High (7.0). Fixed in 5.2.1.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 5.2.1
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. Chartbrew instance is deployed on a NAT64/DNS64 network Attacker must be a user who can create or edit an API Data Connection
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 15/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Chartbrew, an open-source app for building charts from databases and APIs, contains an SSRF guard bypass in its API Data Connection outbound request policy that lets a remote attacker with high-privilege, logged-in access read responses from internal IPv4 hosts, including cloud metadata services, through a NAT64/DNS64 gateway. The bypass only works in NAT64/DNS64 deployments, and it requires the attacker to be able to create or edit API connections.
Read the original description
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.1, the outbound URL guard recognized ordinary IPv4, IPv6, and IPv4-mapped IPv6 destinations but did not recognize IPv4 addresses embedded in NAT64 prefixes. The vulnerable surface is aPI Data Connection outbound requests routed through server/modules/outboundTargetPolicy.js. An authenticated user with permission to create or edit an API connection supplies an attacker-controlled hostname or redirect whose DNS answer is a NAT64 address embedding a private or link-local IPv4 destination. The policy treated the NAT64 address as public; a NAT64 gateway then translated it to the embedded private IPv4 address after validation. The bypass requires a NAT64/DNS64 deployment path and connection-management privileges. IPv4-only deployments are not affected by this specific bypass. The attacker can read responses from 169.254.169.254 cloud metadata and arbitrary internal IPv4 hosts and ports reachable through the NAT64 gateway. This issue is fixed in version 5.2.1.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure8/25Specific setups only, reachable over the network
- Reach?/20Unknown. No tracked technology or package matched
- Severity7/10CVSS 7.0
- No patch0/5No signal
What would change the score
- Would score about 65 if added to CISA KEV
- Would score about 60 if CISA's SSVC rates exploitation active
- Would score about 22 if CISA's SSVC rates it automatable
What to do
Check whether your setup matches what the bug needs.
Chartbrew instance is deployed on a NAT64/DNS64 network Attacker must be a user who can create or edit an API Data ConnectionUpgrade to a fixed version: 5.2.1.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- chartbrew chartbrew
fixed in 5.2.1
Evidence 3
- Advisory
- Repository
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-54589
Is CVE-2026-54589 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
The outbound URL check for API Data Connections fails to block IPv6 addresses that NAT64/DNS64 translates to internal IPv4 addresses. An authenticated user who can create or edit an API connection can therefore make the server reach cloud metadata at 169.254.169.254 and internal IPv4 hosts and read the responses, such as IAM credentials and instance metadata.Source: github.com
Which versions are affected by CVE-2026-54589?
chartbrew: before 5.2.1.Source: cve.now feed data
Am I affected, and how do I check?
Chartbrew versions before 5.2.1 running on a NAT64/DNS64 network. To check, look at the installed Chartbrew version and whether the instance's network uses NAT64/DNS64 translation.Source: github.com
How do I fix CVE-2026-54589?
Upgrade Chartbrew to 5.2.1 or later, the listed fixed version.Source: github.com