CVE-2026-27005
SQL Injection in Chartbrew Allows Unauthorized Database Access
Publication date: 2026-03-06
Last updated on: 2026-03-10
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| depomo | chartbrew | to 4.8.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-27005 is a high-severity SQL injection vulnerability in the Chartbrew web application, specifically affecting versions up to 4.0.0-beta.9. The issue arises because date-type variables are not properly escaped when interpolated into SQL queries, unlike string-type variables which are correctly escaped. This flaw allows an unauthenticated attacker to inject malicious SQL code by including single quotes in date-type variables, breaking out of the quoted context.
The vulnerability can be exploited through two unauthenticated endpoints that accept user-supplied variables and pass them directly into SQL queries without proper sanitization. This enables attackers to execute arbitrary SQL commands on connected MySQL or PostgreSQL databases.
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': "This vulnerability allows an unauthenticated attacker to execute arbitrary SQL commands on databases connected to Chartbrew. Depending on the database user's privileges, the attacker can read, modify, or delete data within those databases."}, {'type': 'paragraph', 'content': 'Since Chartbrew connects directly to production databases for analytics, exploitation of this vulnerability can lead to significant data breaches, data loss, or unauthorized data manipulation, posing serious risks to the confidentiality, integrity, and availability of your data.'}] [1]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by testing the vulnerable endpoints for SQL injection via date-type variables, specifically by injecting payloads that include single quotes to break out of the quoted context.'}, {'type': 'paragraph', 'content': 'The two unauthenticated endpoints to test are:'}, {'type': 'list_item', 'content': 'POST /project/:project_id/chart/:chart_id/filter'}, {'type': 'list_item', 'content': 'POST /chart/:chart_id/query'}, {'type': 'paragraph', 'content': "You can use curl commands to send crafted JSON payloads with date-type variables containing SQL injection payloads such as `2024-01-01' OR 1=1 --` to these endpoints and observe if the database responds with unexpected data or errors indicating SQL injection."}, {'type': 'paragraph', 'content': 'Example curl command to test the filter endpoint:'}, {'type': 'list_item', 'content': 'curl -X POST https://your-chartbrew-instance/project/1/chart/1/filter -H "Content-Type: application/json" -d \'{"start_date":"2024-01-01\' OR 1=1 --"}\''}, {'type': 'paragraph', 'content': 'Similarly, test the query endpoint by sending a POST request with a JSON body containing a date-type variable with the injection payload.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade Chartbrew to version 4.8.3 or later, where the vulnerability has been patched by properly escaping single quotes in date-type variables.
If upgrading is not immediately possible, consider restricting access to the vulnerable endpoints to trusted users only, or applying network-level controls to block unauthenticated access.
Additionally, review database user privileges to minimize the impact of potential exploitation.