CVE-2026-115332 in Lotus
Summary
by MITRE • 10/22/2026
Lotus through 0.10.2 contains an sql injection vulnerability that allows authenticated organization users to inject SQL by registering crafted subscription_filter_keys that bypass keyword-only validation. Attackers can create subscriptions using the malicious key, which is rendered as an unquoted group-by identifier, to inject SQL into usage aggregation queries against the shared multi-tenant database.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Lotus versions through 0.10.2 represents a significant security flaw within its subscription management subsystem, specifically targeting authenticated organization users. This issue is classified as an SQL injection vulnerability, which falls under CWE-89: Improper Neutralization of Special Elements used in an SQL Command according to industry standards for software weakness classification. The core technical failure lies in the handling of input parameters during the registration of subscriptions, where a specific parameter named subscription_filter_keys fails to undergo proper sanitization or type casting before being incorporated into database queries. Although the application implements keyword-only validation logic intended to restrict acceptable inputs, this mechanism is insufficient against crafted payloads that exploit how these keys are processed internally by the underlying SQL engine.
From an operational perspective, the vulnerability allows attackers who possess valid authentication credentials for a specific organization to inject arbitrary Structured Query Language code into usage aggregation queries. The attack vector involves registering a subscription with a maliciously constructed subscription_filter_key. When this key is passed through the application logic, it bypasses the existing validation checks and is subsequently rendered as an unquoted group-by identifier within the SQL statement executed against the shared multi-tenant database. This lack of proper quoting or parameterization means that any special characters or SQL syntax included in the input are interpreted directly by the database engine rather than being treated as literal string data, thereby enabling code injection.
The impact of this vulnerability is severe due to the context of a shared multi-tenant architecture. Because multiple organizations share the same underlying database infrastructure, successful exploitation could potentially allow an attacker not only to extract sensitive data belonging to their own organization but also to access or manipulate data from other tenants if proper isolation controls are compromised by the injection payload. This aligns with ATT&CK technique T1059: Command and Scripting Interpreter, as it involves executing commands within a database environment, and potentially T1078: Valid Accounts, since authentication is required to initiate the attack. The ability to manipulate usage aggregation queries may also lead to data integrity issues or denial of service conditions if malformed SQL causes query failures or excessive resource consumption on the server side.
Mitigation strategies for this vulnerability must focus on implementing robust input validation and secure coding practices at both the application and database layers. Developers should replace direct string concatenation with parameterized queries or prepared statements, which ensure that user-supplied data is treated strictly as data rather than executable code. Additionally, strict allow-listing of valid characters for subscription_filter_keys should be enforced, rejecting any input containing SQL special characters such as quotes, semicolons, or comment markers. Implementing a Web Application Firewall with rules specifically tuned to detect SQL injection patterns in API endpoints can provide an additional layer of defense. Regular security audits and static code analysis tools configured to flag improper neutralization issues are also recommended to prevent similar flaws from being introduced during future development cycles.