Chartbrew: SSRF to Internal Network via User-Controlled allowPrivateHost Flag on API Connections
Chartbrew 4.8.5 through 5.2.2 lets an authenticated user with permission to manage API connections enable private-network requests via allowPrivateHost, and a migration enabled it on existing connections when upgrading.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 5.2.3
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. Affected Chartbrew versions are 4.8.5 through 5.2.2 (npm package chartbrew). The attacker must be able to create or update API connections (an authenticated user with permission to manage API connections). Instances upgraded to an affected version had the private-network exception enabled on pre-existing API connections by a migration.
- 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? →
- 17/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 web app for building charts from databases and APIs, lets an authenticated user with API-connection permissions reach internal HTTP services on the Chartbrew server's network by setting a hidden allowPrivateHost flag, in versions 4.8.5 through 5.2.2. Remotely exploiting this requires high-privilege login, and the flag also gets enabled on existing connections during upgrade, so disabling the instance-wide private-network setting does not block it.
Read the original 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.
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
- Severity9.1/10CVSS 9.1
- No patch0/5No signal
What would change the score
- Would score about 67 if added to CISA KEV
- Would score about 62 if CISA's SSVC rates exploitation active
- Would score about 24 if CISA's SSVC rates it automatable
What to do
Check whether your setup matches what the bug needs.
Affected Chartbrew versions are 4.8.5 through 5.2.2 (npm package chartbrew). The attacker must be able to create or update API connections (an authenticated user with permission to manage API connections). Instances upgraded to an affected version had the private-network exception enabled on pre-existing API connections by a migration.Upgrade to a fixed version: 5.2.3.
Workaround: Reset allowPrivateHost to NULL or false for every API connection in the Connection database table.
Timeline
- CVE published
- First seen by cve.now
- Posted on X by cve.now
Affected versions
- chartbrew chartbrew
fixed in 5.2.3
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-68935
Is CVE-2026-68935 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?
API connections can be given an allowPrivateHost flag that lets Chartbrew send requests to private internal network hosts. This is a server-side request forgery (SSRF) flaw that reaches the internal network.Source: github.com
Which versions are affected by CVE-2026-68935?
chartbrew: before 5.2.3.Source: cve.now feed data
Am I affected, and how do I check?
Affected versions are Chartbrew 4.8.5 through 5.2.2, the npm package chartbrew. Check the installed chartbrew package version to see whether it falls in that range. Instances upgraded to an affected version had the private-network exception enabled on existing API connections, so check the allowPrivateHost value on those connections in the Connection table.Source: github.com
How do I fix CVE-2026-68935?
The advisory names 5.3.0 as the patched version, while the product range data lists 5.2.3 as fixed, so check the release notes before choosing a target and prefer 5.3.0 if unsure. Until upgraded, reset allowPrivateHost to NULL or false for every API connection in the Connection database table.Source: github.com