CVE-2026-72710 is an unusual chain: an unauthenticated attacker does not need to upload a PHP file or log in. Instead, they can use a mass-assignment weakness to place a carefully formed record in SPIP’s own background-job queue, then rely on the queue processor to execute it.
SPIP is the affected content-management software, and the issue applies to versions before 4.4.18. The supplied material does not identify particular organisations, sectors, or deployment patterns that run it, so teams should inventory their own web properties and hosted applications rather than infer exposure from industry alone.
An object editor can target internal tables
The vulnerable path is the editer_objet action in editer_objet.php. Mass assignment means a request can supply fields that an application then writes without limiting them to an expected set. Here, an attacker-controlled arg parameter can resolve to internal database tables. Where a table has no champs_editables allowlist, the attacker can write arbitrary rows into it.
That is more than unintended content editing. The attacker can target spip_jobs, SPIP’s job queue, and insert a row containing a controlled PHP function and its arguments. When cron processes that queued job, it dynamically executes the selected function. The result is remote code execution, with the confidentiality, integrity, and availability impact reflected in the supplied 9.3 severity assessment.
The key operational detail is that the initial request is unauthenticated: no prior account or elevated application role is required. Cron processing is the second stage. The material does not say how quickly a given installation runs its queue, what execution identity the worker uses, or whether a malicious job needs any particular scheduling conditions; those are details responders should establish locally.
Patch first, then inspect the queue
Upgrade SPIP to 4.4.18 or later immediately. The material identifies that version as the boundary for this flaw, but does not provide a patch diff or configuration workaround. Do not treat authentication in front of administrative functions as a substitute: the reported issue is reachable without authentication.
As a containment measure while patching, reduce public reachability of affected instances where operationally possible and review web-server and application logs for suspicious requests involving the affected action and unusual arg values. Inspect spip_jobs for unexpected function names, arguments, and recently created entries before allowing workers to continue normally. Preserve relevant logs and database evidence if suspicious records appear; deleting a job may stop a trigger but can also discard useful incident evidence.
The same release includes other identifiers, including CVE-2026-72709, but the supplied information does not establish whether it shares this attack path. Plan the update as a release-level maintenance action rather than narrowly assuming a single database write is the whole risk.
Public exploitation status is not established
The available material does not say that CVE-2026-72710 is being exploited in the wild, and it does not state whether it is listed in CISA’s Known Exploited Vulnerabilities catalog. It also provides no evidence of a public proof of concept. Those are unknowns, not reasons to defer action: an unauthenticated route from a request parameter to a queued PHP function is a concrete exposure worth closing.
For operators, the immediate work is straightforward: locate SPIP, upgrade past 4.4.18, examine the queue and logs, and verify that cron resumes only with trusted jobs. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs, which can help keep this kind of version boundary visible after the urgent patch is done.
