CVE-2026-129166 in Keep
Summary
by MITRE • 11/13/2026
Keep 0.34.10 through 0.55.0 contains a blind SQL injection vulnerability in its CEL-to-SQL converter, which inserts bracket-indexed JSON keys from CEL filters unescaped into JSON path expressions for SQLite, PostgreSQL, and MySQL. Authenticated users with read:alert permission can submit crafted CEL expressions to /alerts/query or the cel parameter of /incidents, using result counts as a boolean oracle to extract other tenants' alerts and password hashes.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/13/2026
The vulnerability identified in Keep versions 0.34.10 through 0.55.0 represents a critical blind SQL injection flaw located within the Common Expression Language CEL-to-SQL converter component of the application architecture. This security defect arises from an improper neutralization of special elements used in SQL commands, specifically during the translation process where JSON keys indexed by brackets are extracted from user-supplied CEL filters and directly embedded into database query strings without adequate sanitization or parameterization. The affected systems include SQLite, PostgreSQL, and MySQL databases, indicating a widespread impact across different relational database management system implementations supported by the platform.
The technical mechanism of this vulnerability relies on the application's failure to escape bracket-indexed JSON keys when constructing SQL queries for data retrieval operations. When an authenticated user submits a CEL expression via endpoints such as /alerts/query or the cel parameter within /incidents, the backend processes these inputs and converts them into SQL statements targeting specific database tables. Because the conversion logic fails to properly handle special characters inherent in certain key names or crafted payloads, it allows for the injection of arbitrary SQL code. This flaw effectively bypasses intended access controls by allowing an attacker to manipulate the structure of the underlying database query rather than merely filtering results through legitimate application logic.
From a threat actor perspective, this vulnerability is particularly dangerous because it enables data exfiltration against other tenants in multi-tenant deployments. An authenticated user possessing only read:alert permissions can exploit this flaw using blind SQL injection techniques. By submitting carefully crafted CEL expressions that trigger distinct database responses based on boolean conditions, the attacker can use result counts as a boolean oracle to infer sensitive information bit by bit. This technique allows for the extraction of confidential data belonging to other tenants, including alert details and password hashes stored within the application's database. The ability to extract password hashes significantly escalates the risk profile, potentially leading to credential stuffing attacks or lateral movement if those credentials are reused elsewhere.
This vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. Furthermore, it maps directly to MITRE ATT&CK technique T1059.004 Command and Scripting Interpreter via scripting languages like CEL, which is then leveraged for data exfiltration techniques categorized under T1005 Data from Local System or T1213 Data from Information Repositories depending on the specific database interaction method employed. The exploitation path involves authenticated access followed by query manipulation to bypass authorization checks and extract unauthorized data, highlighting a failure in both input validation and principle of least privilege enforcement at the application layer.
To mitigate this vulnerability, organizations running affected versions must immediately upgrade Keep to version 0.55.1 or later where these issues have been addressed through improved sanitization logic within the CEL-to-SQL converter. For environments where immediate patching is not feasible, implementing strict input validation on all user-supplied parameters passed to /alerts/query and incident endpoints can provide a temporary layer of defense. Additionally, deploying Web Application Firewalls with rules specifically tuned for SQL injection patterns may help detect and block malicious payloads before they reach the application backend. It is also recommended to review database access permissions to ensure that service accounts used by the application adhere to least privilege principles, limiting the potential damage if an injection occurs. Regular security audits focusing on dynamic query construction practices are essential to prevent similar flaws in future development cycles.