Summary
Cacti improperly sanitizes user-controlled sorting column names, allowing SQL expressions such as time-delay functions to pass through into ORDER BY clauses. Any authenticated Cacti user may be able to perform time-based blind SQL injection, subject to the database account's permissions and the exposed sorting functionality.
Affected context
The vulnerability occurs in Cacti sorting functionality that accepts a sort_column GET parameter and inserts the resulting value into raw SQL ORDER BY clauses. It affects deployments where the relevant pages are accessible to authenticated users and where the database connection account has query permissions beyond the minimum required by the application.
Exploit preconditions
- Attack surface: HTTP GET endpoints that use the
sort_columnparameter, including affected user-management and utility pages - Required access: Authentication to Cacti; the vulnerable behavior is not limited to administrative roles
- Trigger point: Construction and execution of a database query containing a user-controlled ORDER BY expression
- Why exploitation is possible: The sanitization allowlist retains parentheses and other characters that can form SQL expressions, and the resulting value is concatenated into SQL rather than safely constrained to a predefined column
Why this happens
The underlying defect is insufficient neutralization of user-controlled SQL identifiers and expressions. The sanitize_sql_column() regular expression removes some characters but permits syntax such as parentheses and dots, so values that resemble SQL functions can remain intact. Because the sanitized result is concatenated into an ORDER BY clause, the application treats attacker-influenced text as SQL syntax rather than as a member of a fixed set of sortable fields. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
Potential impact
- An attacker may infer database behavior through response timing
- Sensitive database values could potentially be extracted through blind SQL techniques
- Application data may be exposed or altered if the database account has corresponding privileges
- Database performance and application availability could be degraded by resource-intensive expressions
- The vulnerability could provide a stepping stone for broader compromise if combined with other weaknesses
General mitigation guidance
Mitigation generally focuses on eliminating free-form SQL expressions from sorting controls and reducing database trust boundaries.
Common defensive patterns include:
- Mapping externally supplied sort identifiers to a fixed, server-side allowlist of column names
- Rejecting unknown fields and expressions rather than attempting to sanitize them
- Keeping ORDER BY fragments separate from general user input and generating them only from validated internal values
- Applying least privilege to the Cacti database account
- Limiting database access to required schemas, operations, and network locations
- Preserving centralized authorization checks for all affected endpoints
- Avoiding reliance on character-stripping filters as a substitute for structural query construction
How teams detect issues like this
Detection can combine application review, runtime monitoring, and policy enforcement:
- Use static analysis to identify concatenation of request parameters into SQL statements, especially ORDER BY clauses
- Review functions that sanitize identifiers with regular expressions but permit punctuation associated with SQL syntax
- Search code and templates for
sort_columnor equivalent parameters reaching database query builders - Monitor database and application logs for unusual sorting expressions, repeated requests, or response-time anomalies
- Add automated tests that verify unknown sort fields and SQL-like expressions are rejected
- Enforce code-review policies requiring fixed mappings for dynamic SQL identifiers
