CVE-2026-71287 in Cacti
Summary
by MITRE • 08/05/2026
Cacti's sanitize_sql_column() (lib/functions.php) sanitizes user-supplied ORDER BY column names using the regex `preg_replace('/[^a-zA-Z0-9_().]/', '', $column)`. Because this allowlist retains letters, digits, underscore, parentheses, and dot (intended to support expressions like COUNT(id) and table.column), a payload such as `SLEEP(5)` passes through completely unmodified. The sanitized value is concatenated directly into raw SQL ORDER BY clauses (which cannot be parameterized) driven by a `sort_column` GET parameter in at least user_log.php, utilities.php, user_domains.php, and user_group_admin.php, allowing any authenticated Cacti user, regardless of privilege level, to perform time-based blind SQL injection against the Cacti database.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/05/2026
The vulnerability resides within Cacti's sanitize_sql_column() function located in lib/functions.php which implements inadequate input validation for ORDER BY column names in database queries. This function employs a regular expression pattern '/[^a-zA-Z0-9_().]/' to strip potentially dangerous characters from user-supplied input, yet this approach fails to adequately address SQL injection risks by permitting characters that can be used to construct malicious SQL expressions. The regex allowlist includes alphanumeric characters, underscores, parentheses, and dots which were presumably intended to support legitimate database expressions such as COUNT(id) and table.column references, but inadvertently allows dangerous payloads like SLEEP(5) to pass through unmodified.
The technical flaw manifests when user-supplied data from the sort_column GET parameter is processed through this sanitization function and subsequently concatenated directly into raw SQL ORDER BY clauses without proper parameterization. This design pattern creates a time-based blind SQL injection vulnerability that affects multiple administrative pages including user_log.php, utilities.php, user_domains.php, and user_group_admin.php. The vulnerability operates at the application layer and requires only authenticated access to exploit, making it particularly dangerous as any user account can potentially perform this attack regardless of their privilege level within the system.
The operational impact of this vulnerability extends beyond simple data exfiltration as it enables attackers to perform time-based blind SQL injection attacks against the underlying database. An attacker can leverage the SLEEP(5) payload to determine whether the injection is successful and potentially extract information from the database through timing variations. This vulnerability affects the integrity and confidentiality of the Cacti system since any authenticated user can execute arbitrary SQL commands, potentially leading to unauthorized data access, modification, or deletion. The risk is elevated because the vulnerability exists in core administrative functionality that handles user logging and management operations.
Mitigation strategies should include implementing proper parameterization of SQL queries where possible, using a more restrictive allowlist that excludes characters commonly used in SQL injection payloads, and implementing input validation that considers the context in which data will be used. Organizations should also consider employing prepared statements with proper parameter binding instead of direct string concatenation into SQL queries. Additionally, implementing proper access controls and privilege separation would limit the damage potential of authenticated users who might exploit this vulnerability. The vulnerability aligns with CWE-89 SQL Injection and ATT&CK technique T1213 Data from Information Repositories, representing a significant security risk that requires immediate attention and remediation through code-level fixes and architectural improvements to prevent unauthorized database access.
The root cause of this vulnerability stems from improper input sanitization and the dangerous practice of concatenating user-supplied data into SQL queries without proper validation or parameterization. This pattern violates fundamental security principles and demonstrates a lack of proper defense-in-depth measures within the application's security architecture. The vulnerability represents a classic example of how seemingly benign functionality can introduce critical security flaws when proper input validation and output encoding practices are not applied consistently throughout the codebase.