Summary
Lotus contains a SQL injection vulnerability in custom metric queries that allows authenticated organization users to submit stacked SQL statements.
When the metrics endpoint accepts attacker-controlled query content without reliably preventing additional statements, an attacker may read or modify data across tenants.
Lotus contains a SQL injection vulnerability in custom metric queries that allows authenticated organization users to submit stacked SQL statements.
When the metrics endpoint accepts attacker-controlled query content without reliably preventing additional statements, an attacker may read or modify data across tenants.
Affected context
The vulnerability occurs in Lotus custom metric query processing through the POST /app/metrics/ endpoint. It becomes risky when authenticated organization users can submit metric expressions that are incorporated into SQL statements and validation checks only the first statement, allowing appended statements to reach the database.
The vulnerability occurs in Lotus custom metric query processing through the POST /app/metrics/ endpoint. It becomes risky when authenticated organization users can submit metric expressions that are incorporated into SQL statements and validation checks only the first statement, allowing appended statements to reach the database.
Exploit preconditions
- Attack surface: The custom metrics HTTP endpoint
- Required access: Valid authentication as an organization user
- Trigger point: Submission of a crafted custom metric query
- Why exploitation is possible: Query validation does not reliably prevent stacked statements before user-controlled content reaches SQL execution
- Attack surface: The custom metrics HTTP endpoint
- Required access: Valid authentication as an organization user
- Trigger point: Submission of a crafted custom metric query
- Why exploitation is possible: Query validation does not reliably prevent stacked statements before user-controlled content reaches SQL execution
Why this happens
The underlying flaw is the construction or execution of SQL using insufficiently constrained user-controlled metric query content. Validation that examines only the first SQL statement can be bypassed when the database interface accepts additional semicolon-separated statements.
This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), because input is treated as executable SQL syntax rather than as strictly bounded data or a validated query structure.
The underlying flaw is the construction or execution of SQL using insufficiently constrained user-controlled metric query content. Validation that examines only the first SQL statement can be bypassed when the database interface accepts additional semicolon-separated statements.
This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), because input is treated as executable SQL syntax rather than as strictly bounded data or a validated query structure.
Potential impact
- An attacker may read sensitive records from the database
- Tenant isolation may be bypassed
- Data belonging to other organizations could be modified or deleted
- Application integrity and reporting accuracy could be affected
- Database credentials or other sensitive values could be exposed
- The application or connected services may experience disruption
- An attacker may read sensitive records from the database
- Tenant isolation may be bypassed
- Data belonging to other organizations could be modified or deleted
- Application integrity and reporting accuracy could be affected
- Database credentials or other sensitive values could be exposed
- The application or connected services may experience disruption
General mitigation guidance
Mitigation generally focuses on ensuring that metric definitions cannot alter SQL structure.
Common defensive patterns include:
- Use parameterized queries and trusted query builders for all variable values
- Represent metric expressions through an allowlisted, structured query model instead of accepting raw SQL fragments
- Reject stacked statements and enforce complete-query validation where query text must be supported
- Apply strict type, identifier, operator, and function allowlists
- Enforce database permissions that limit each application component to the minimum required operations
- Apply database-level tenant isolation as defense in depth
- Avoid returning detailed database errors to clients
- Treat authenticated users as untrusted for query construction purposes
Mitigation generally focuses on ensuring that metric definitions cannot alter SQL structure.
Common defensive patterns include:
- Use parameterized queries and trusted query builders for all variable values
- Represent metric expressions through an allowlisted, structured query model instead of accepting raw SQL fragments
- Reject stacked statements and enforce complete-query validation where query text must be supported
- Apply strict type, identifier, operator, and function allowlists
- Enforce database permissions that limit each application component to the minimum required operations
- Apply database-level tenant isolation as defense in depth
- Avoid returning detailed database errors to clients
- Treat authenticated users as untrusted for query construction purposes
How teams detect issues like this
Detection can include static analysis for string concatenation, interpolation, or formatting used to build SQL from request parameters. Code review should examine custom metric parsing, statement validation, database API usage, and whether parameter binding is used consistently.
Runtime monitoring may alert on semicolon-separated statements, unexpected SQL keywords, abnormal cross-tenant access patterns, and metric requests that produce database errors. Policy enforcement in CI can require approved query-building libraries and block raw SQL execution paths fed by HTTP input. Automated code review and software composition analysis tools may help identify related patterns.
Detection can include static analysis for string concatenation, interpolation, or formatting used to build SQL from request parameters. Code review should examine custom metric parsing, statement validation, database API usage, and whether parameter binding is used consistently.
Runtime monitoring may alert on semicolon-separated statements, unexpected SQL keywords, abnormal cross-tenant access patterns, and metric requests that produce database errors. Policy enforcement in CI can require approved query-building libraries and block raw SQL execution paths fed by HTTP input. Automated code review and software composition analysis tools may help identify related patterns.
