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, public dashboard passwords were stored in plaintext, accepted through a URL query parameter, and checked without effective attempt throttling. The vulnerable surface is public password-protected dashboard storage and validation routes. An unauthenticated attacker targets a public password-protected dashboard and repeatedly submits candidate passwords or obtains password-bearing server or proxy logs. Unlimited online guesses enable brute force, while cleartext storage and URL transport expose the secret in application storage and server or proxy access logs. The target must be a public dashboard with password protection enabled. Even failed attempts reveal chart count and configuration without the password; a recovered password grants access to the protected dashboard and its chart data. This vulnerability is fixed in 5.2.3.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-11-06T22:17:59.220Z",
  "pubdate": "2026-11-06T22:17:59.220Z",
  "executiveSummary": "Chartbrew versions prior to 5.2.3 are susceptible to a critical authentication vulnerability involving insecure storage and transmission of dashboard access credentials. The application stores passwords in plaintext and processes validation requests via URL query parameters, lacking any mechanism for rate limiting or request throttling. This combination of weaknesses facilitates unauthorized access through brute-force attacks and information exposure via system logging mechanisms.\nThe vulnerability resides within the public dashboard authentication component. An unauthenticated attacker can exploit these design flaws to conduct automated password guessing campaigns against protected dashboards. Because passwords are transmitted in plaintext via the request URI, they are frequently captured in server access logs, reverse proxy logs, and browser history, significantly expanding the attack surface beyond the application itself. Successful exploitation grants the attacker full access to the dashboard, exposing sensitive business intelligence, data visualizations, and underlying database or API configurations. The lack of brute-force protection ensures that even high-entropy passwords can be compromised given sufficient time and trial frequency. This flaw presents a severe risk to data confidentiality and organizational security posture.",
  "technicalDetails": "The vulnerability in Chartbrew arises from a multi-faceted failure in the implementation of the dashboard authentication module. At the architectural level, the application suffers from improper handling of sensitive secrets: public dashboard passwords are stored in plaintext within the backend database rather than being cryptographically hashed using industry-standard algorithms such as Argon2 or bcrypt.\nFurthermore, the application employs an insecure transport mechanism for validation, accepting password candidates through URL query parameters. This architectural choice forces the sensitive credential into the request URI, causing it to be logged in plain text by web servers, load balancers, and intermediate proxies. This behavior leads to secondary exposure risks, where an attacker with access to peripheral logging infrastructure can harvest passwords without interacting with the application's authentication logic directly.\nThe lack of authentication throttling mechanisms exacerbates these issues, as the system does not enforce rate limits or employ lockout policies on repeated failed attempts. An unauthenticated attacker can execute a programmatic brute-force or dictionary attack by repeatedly issuing GET requests with differing password parameters. The application responds to these requests synchronously, providing immediate feedback on the validity of the credential.\nBeyond unauthorized access, the application exhibits an information disclosure flaw where failed authentication attempts still return metadata, including the count of charts and configuration details for the target dashboard. This reconnaissance data allows an attacker to profile the sensitivity of the target prior to brute-forcing the credentials.\nThe step-by-step exploitation flow is as follows: 1) The attacker identifies a public Chartbrew dashboard protected by password authentication. 2) The attacker intercepts or identifies the authentication endpoint that consumes a password query parameter. 3) The attacker initiates an automated script to cycle through a wordlist, injecting candidate passwords into the query parameter. 4) Due to the absence of throttling, the attacker bypasses standard defensive latency, iterating through thousands of combinations. 5) Upon successfully guessing the password, the application grants the attacker access to the underlying chart data and API/Database configurations. 6) Throughout the process, the cleartext passwords are continuously written to the server's logs, increasing the likelihood of credential harvesting by unauthorized parties."
}