CVE-2026-72710 in SPIP
Summary
by MITRE • 09/11/2026
SPIP before 4.4.18 contains a remote code execution vulnerability in the editer_objet action where the arg parameter resolves SQL table names without enforcing an editable columns allowlist, allowing attackers with a valid nonce to inject attacker-controlled rows into the spip_jobs table. Attackers can supply arg=job/0 with crafted fonction and args values, which are later unserialized and executed when the cron job queue is drained, resulting in arbitrary PHP function execution on the underlying system.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in SPIP versions prior to 4.4.18 represents a critical remote code execution flaw rooted in improper input validation within the editer_objet action handler. This security defect specifically targets the arg parameter, which is intended to specify the object type and identifier for editing operations. In vulnerable implementations, this parameter is used to dynamically resolve SQL table names without adequately enforcing an allowlist of editable columns or validating that the target operation is safe from injection attacks. The core technical flaw lies in the lack of strict validation on how user-supplied data interacts with the internal job queue mechanism, allowing malicious actors to manipulate the structure and content of database records intended for background processing tasks.
The operational impact of this vulnerability is severe due to its interaction with SPIP's cron job system. An attacker who possesses a valid nonce can inject arbitrary rows into the spip_jobs table by supplying specific crafted values for the arg parameter, such as setting it to job/0 along with maliciously constructed fonction and args parameters. These parameters are designed to define which PHP function should be executed and what arguments it should receive during the processing of queued jobs. Because the system fails to sanitize these inputs before storage, the injected data persists in the database until the cron daemon drains the queue. At that point, the application unserializes the stored payload and executes the specified functions with attacker-controlled arguments, leading directly to arbitrary PHP code execution on the server hosting the SPIP instance.
This attack vector aligns closely with CWE-94 Improper Control of Generation of Code (Code Injection) as it involves injecting executable logic into a system through manipulated input data that is later processed by an interpreter or runtime environment. Furthermore, from a tactical perspective, this vulnerability facilitates initial access and command execution capabilities consistent with MITRE ATT&CK techniques such as T1059 Command and Scripting Interpreter for executing arbitrary commands via PHP functions. The requirement of a valid nonce indicates that the attacker must have some level of authenticated access or be able to forge session tokens, which may limit the scope but does not diminish the severity given the potential for full system compromise once execution is achieved.
Mitigation strategies primarily involve upgrading to SPIP version 4.4.18 or later where this issue has been addressed through stricter input validation and enforcement of editable column allowlists. For environments unable to upgrade immediately, administrators should ensure that web application firewalls are configured to detect and block attempts to inject malicious payloads into the arg parameter, particularly those containing serialized data structures indicative of PHP object injection patterns. Additionally, restricting database permissions for the SPIP user account can limit the impact if an injection attempt succeeds by preventing unauthorized modifications to critical system tables like spip_jobs. Regular auditing of cron job configurations and monitoring for unusual activity in background task queues can also aid in early detection of exploitation attempts.