This CVE exposes a failure in SPIP's database abstraction layer where the SQLite code path handles array-typed input unsafely while the MySQL path apparently does not. The root cause is not simply parallel code paths drifting — it's that SPIP's query construction diverges at the builder level: MySQL uses PDO prepared statement parameter binding, while SQLite falls back to string interpolation or concatenation. This creates an evaluation boundary in the MySQL path that makes the attack impossible regardless of developer intent, while the SQLite path makes it possible regardless of intent.
The array-typed input mechanism reveals a cognitive gap: PHP's request parameter handling allows both scalar and array values, but developers typically validate against the string case and miss the array mutation vector. When array input reaches the SQLite query builder, it breaks out of quoted string context during PHP evaluation, enabling injection.
Two non-obvious points should shape your response. First, the CVE states MySQL is unaffected — but this may reflect testing bias rather than proven safety. If researchers found this against SQLite, the MySQL path may simply be untested against array mutation vectors. Audit your MySQL SPIP deployments with the same input patterns before assuming safety. Second, the authenticated-editor requirement should not reassure you. SPIP's editor privileges grant content management plus file upload and template access — the jump from editor to RCE is often a lateral move within the same account's legitimate capabilities, not a privilege escalation. Treat this as urgent in any multi-user SPIP installation.
Your immediate actions: verify which database backend your SPIP instance uses, check whether the navigation menu endpoint processes array-typed parameters, and audit other endpoints for similar SQLite-specific query construction patterns. The vulnerability is in the abstraction boundary itself, not just this endpoint — patch one vector and others may remain.