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.3, Chart share and embed tokens were signed with CB_SECRET, including known or shipped-default values in stock source and repository Docker Compose installs. The vulnerable surface is chart share-token verification and filter-access routes for private charts. An attacker who knows the deployment's CB_SECRET targets a private chart that has been shared at least once so a share-policy row exists, then forges a Chart-subject token for that chart id. The known signing key permits valid Chart tokens, and the filter-access path accepts sequential integer ids without requiring a legitimate share link; token expiry and revocation are ineffective once the secret is known. The condition requires a known or default secret and an existing share-policy row. A bare container where CB_SECRET is undefined is outside this path, and a unique secret excludes it only while the value remains unknown and unpredictable. An unauthenticated attacker can enumerate integer ids and read arbitrary private chart data, including chartData, without possessing a legitimate share link. This issue is fixed in version 5.2.3.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-11-06T21:17:11.183Z",
  "pubdate": "2026-11-06T21:17:11.183Z",
  "executiveSummary": "Chartbrew versions prior to 5.2.3 contain a critical authentication bypass vulnerability stemming from the use of predictable or default CB_SECRET values for signing chart share and embed tokens.\nThe vulnerability enables unauthenticated, remote attackers to access private chart data without legitimate share links or authorization. By leveraging the known signing secret, an adversary can forge valid JSON Web Tokens (JWT) for any private chart that has at least one existing share-policy record.\nThe attack is facilitated by the application's acceptance of sequential integer IDs in the filter-access routes, which lack sufficient validation. Because token revocation mechanisms fail when the signing key is compromised, an attacker can persistently exfiltrate sensitive data associated with arbitrary private charts.\nThe risk is highest in deployments using default, shipped-with-source, or non-randomized CB_SECRET configurations. This vulnerability represents a significant breach of data confidentiality, as it bypasses standard access control policies to grant unauthorized access to sensitive database and API visualizations.",
  "technicalDetails": "The vulnerability resides in the Chartbrew token verification logic within the chart share and embed functionality. The system uses a CB_SECRET environment variable to sign tokens that grant access to charts via share links. In versions prior to 5.2.3, deployments—specifically those utilizing default source configurations or standard Docker Compose templates—often relied on hardcoded or publicly known values for this secret.\nThe root cause is a combination of weak cryptographic secret management and improper authorization checks on the filter-access path. The application processes share-policy records to determine access; however, the API endpoint responsible for serving chart data fails to properly validate the integrity and provenance of the share-token beyond the signature verification.\nAn attacker can exploit this by first identifying a target chart ID, which is often a sequential integer. Because the application exposes filter-access routes that accept these integer IDs, an attacker can enumerate the chart space. Once a chart has been shared at least once by a legitimate user, a corresponding row is created in the share-policy table, satisfying the backend requirement for token validation.\nThe exploitation flow proceeds as follows: First, the attacker determines the deployment's CB_SECRET (e.g., via documentation, source code, or dictionary attacks on default values). Second, the attacker generates a malicious, signed JWT representing a 'Chart-subject' claim for a specific integer-based chart ID. Third, the attacker submits this forged token to the filter-access route. Because the server trusts tokens signed with the now-compromised secret, it proceeds to authorize the request.\nBecause the server validates the signature but fails to implement robust secondary authorization checks, the attacker is granted unauthorized read access to the private chart data (chartData). The impact is severe as the vulnerability persists regardless of token expiry or explicit administrative revocation, as long as the secret remains constant. The lack of proper validation on the filter-access route means an attacker does not require a legitimate share link to gain access, effectively turning a private, restricted resource into an publicly accessible endpoint for anyone who can perform the token forgery."
}