CVE-2026-122032 in SPIP
Summary
by MITRE • 11/04/2026
SPIP before 4.4.29 contains a SQL injection vulnerability that allows authenticated attackers with back-office access to inject arbitrary SQL by submitting a differing where parameter value in the POST body versus the GET query string on the /ecrire/?exec=articles endpoint, bypassing spip_sanitize_from_request() sanitization. Attackers can exploit this request parameter mismatch to extract database contents, including protected articles and bcrypt password hashes of users.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in SPIP versions prior to 4.4.29 represents a critical authentication-based SQL injection flaw that stems from an inconsistent handling of HTTP request parameters within the application's core logic. Specifically, this issue affects the /ecrire/?exec=articles endpoint, which is part of the administrative back-office interface. The root cause lies in how the framework processes input data when both GET query string parameters and POST body parameters are present with differing values for the same key, particularly regarding where clause construction. Although SPIP employs a sanitization function known as spip_sanitize_from_request() intended to neutralize malicious SQL payloads by escaping special characters or validating inputs, this protection mechanism is bypassed due to an architectural oversight in parameter resolution order. When an attacker submits a request containing conflicting values for the same parameter across different HTTP methods, the application fails to consistently apply sanitization rules to all instances of that parameter before using them in database queries. This discrepancy allows specially crafted SQL commands embedded within one set of parameters to remain unescaped and subsequently executed by the underlying relational database management system.
From a technical perspective, this vulnerability is classified under CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly referred to as SQL Injection. The specific mechanism exploits a parameter pollution scenario where the application logic does not enforce strict consistency between GET and POST data sources before constructing dynamic SQL statements. By manipulating the request structure to include divergent values for critical filtering parameters such as those defining article categories or publication statuses, an authenticated attacker can inject arbitrary SQL syntax into the query execution flow. This is particularly dangerous because it occurs within a context that requires prior authentication, meaning the attack surface is limited to users who have already gained access to the administrative panel. However, since many content management systems allow multiple user roles with varying levels of back-office privileges, even low-privileged accounts can potentially leverage this flaw if they possess basic editing or publishing rights.
The operational impact of exploiting this vulnerability is severe and multifaceted. Once an attacker successfully injects SQL commands, they gain the ability to interact directly with the database backend beyond the intended application logic. This capability enables unauthorized data extraction, allowing adversaries to dump sensitive information stored in the SPIP database. Critical assets at risk include protected articles that are not publicly accessible, internal configuration settings, and most critically, user credential hashes. Since modern versions of SPIP utilize bcrypt for password hashing, successful exploitation could lead to the exfiltration of these hashed passwords. While bcrypt is computationally expensive to crack, large-scale extraction combined with offline brute-force attacks remains a significant threat vector for compromising account integrity across the platform or potentially other systems where users may have reused credentials.
In terms of adversarial tactics, this vulnerability aligns with MITRE ATT&CK technique T1059: Command and Scripting Interpreter, specifically through SQL commands used to execute arbitrary operations within the database environment. It also relates to T1213: Data from Information Repositories, as the primary goal is often data exfiltration rather than immediate system control. The exploitation path requires initial access via valid credentials, placing it under the Initial Access or Persistence phases depending on whether the attacker uses the extracted data for further lateral movement or maintains long-term access through compromised accounts.
To mitigate this vulnerability and prevent similar issues in future development cycles, immediate action is required to upgrade SPIP installations to version 4.4.29 or later where these parameter handling inconsistencies have been addressed. For organizations unable to patch immediately due to compatibility constraints with custom plugins or themes, temporary mitigation strategies should focus on strict input validation at the web server level using Web Application Firewalls configured to detect and block anomalous request patterns involving conflicting GET/POST parameters for SQL-sensitive fields. Additionally, developers must review all code paths that construct dynamic SQL queries based on user-supplied data from multiple sources, ensuring that sanitization functions are applied uniformly regardless of whether input originates from query strings or POST bodies. Implementing parameterized queries throughout the application framework would further reduce reliance on string-based escaping mechanisms and provide a more robust defense against injection attacks. Regular security audits focusing on authentication flows and administrative interface endpoints should be conducted to identify any residual risks associated with complex request handling logic.