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, a date-typed MongoDB variable placed inside a quoted query placeholder was inserted as an unescaped string, unlike the safely escaped or coerced string, number, and Boolean branches. The vulnerable surface is mongoDB-backed public, shareable, or embedded charts processed by date-variable substitution. An unauthenticated user supplies a crafted URL filter to a public, shareable, or embedded MongoDB chart whose query places a date-typed variable in a quoted literal. The crafted date value breaks out of the quoted literal and changes query logic; the chart's returned row count becomes a Boolean oracle for character-by-character field extraction. The chart must be externally reachable and use the vulnerable date-in-quoted-placeholder branch. Extraction is read-only and limited to one queried collection per request, and it requires neither an account nor a known field value. The blind oracle can disclose any field in the queried collection, including secrets the chart does not display. 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.567Z",
  "pubdate": "2026-11-06T21:17:11.567Z",
  "executiveSummary": "Chartbrew versions prior to 5.2.3 are susceptible to a critical MongoDB injection vulnerability occurring within the application's variable substitution logic.\nThe vulnerability allows an unauthenticated, remote attacker to perform blind data exfiltration by manipulating date-typed variables within MongoDB-backed queries for public, shareable, or embedded charts.\nBy breaking out of quoted query placeholders, an attacker can manipulate query logic to function as a Boolean oracle, enabling character-by-character extraction of arbitrary data from the underlying database.\nThis flaw bypasses authentication requirements, posing a significant risk to sensitive data confidentiality even for collections or fields not explicitly intended for public display.\nSuccessful exploitation requires the target chart to be externally reachable and configured to use a date-typed variable within a quoted query string.\nGiven the potential for unauthorized access to sensitive database content, this vulnerability represents a severe risk to data privacy and organizational security.",
  "technicalDetails": "The root cause of this vulnerability lies in an improper handling of input sanitization for date-typed variables within Chartbrew's query substitution module. While string, number, and Boolean types are correctly coerced or escaped, date-typed inputs are treated as raw strings when placed inside quoted query placeholders.\nThe vulnerable surface is specific to public, shareable, or embedded MongoDB charts. When an attacker provides a crafted date value through a URL filter, the application fails to safely sanitize the input, allowing the attacker to inject MongoDB query operators directly into the statement.\nThe exploitation flow initiates when an unauthenticated attacker identifies a public chart utilizing a date-typed variable. By appending a malicious payload to the URL filter parameter, the attacker escapes the intended quoted literal context, effectively modifying the structure of the MongoDB find/aggregate query.\nThis modification transforms the chart's row count into a Boolean oracle. An attacker can systematically extract data from the database by sending iterative requests, testing boolean conditions against the queried fields. For example, by crafting conditions that check if the first character of a sensitive field matches a specific character, the attacker observes changes in the returned row count of the chart (e.g., a count of 1 for 'True' and 0 for 'False') to confirm the value.\nThis character-by-character inference technique allows for the complete exfiltration of sensitive information from the database, including credentials, PII, or internal metadata, regardless of whether that data is intended to be displayed in the chart itself.\nThe vulnerability does not require any authentication or existing knowledge of internal field names, as the attacker can use the oracle to discover collection schemas and content through incremental discovery.\nThe impact is limited to read-only access to the collection associated with the target chart. However, because the oracle can be automated, large-scale data exfiltration is highly feasible once the initial injection vector is identified."
}