Critical SPIP vulnerability: emergency protection deployed
On 20 August 2026, the SPIP team released version 4.4.21 to address a critical vulnerability allowing unauthenticated remote code execution. Exploitation attempts had already been observed, and SPIP’s usual security screen did not protect against this vulnerability.
The situation required an immediate response. We first inventoried every SPIP site and copy present across our shared web-hosting servers. The search deliberately included old copies, archive directories and upgrade environments that were still reachable below a web root.
Protection in several stages
Our first measure was a fleet-wide safeguard at the Apache level. It blocks the external HTTP vector used by the vulnerability before a request reaches SPIP. The rule was tested and then enabled on all eight servers without changing normal site behaviour.
This network barrier did not replace fixing the code. An immediate full upgrade was not realistic for every site: our hosting fleet includes several generations of SPIP, customised applications and different PHP versions.
We therefore analysed the official SPIP 4.4.21 security changes and prepared a minimal backported patch. It was adapted to the different code families in use and deployed through a transactional procedure: per-file backups, SHA-256 hashes before and after modification, exact substitution counts, syntax checks with the appropriate PHP environment and a documented rollback path.
Representative pilot sites were patched and tested first. Deployment then proceeded one server at a time, with code, Apache and HTTP-response checks after each stage.
Result of the intervention
The inventory found 100 SPIP trees. Of these, 92 were older than version 4.4.21 and received the backported fix; the eight installations already running 4.4.21 were left unchanged. At the end of the deployment, none of the inventoried trees still contained the known vulnerable pattern.
The Apache safeguard remains active as an additional layer of defence.
Work continues
This emergency patch neutralises this specific vulnerability, but it does not turn an old SPIP branch into a maintained release, nor can it by itself rule out an earlier compromise. We are therefore continuing targeted checks, removal of exposed historical copies and planning of full upgrades with the people responsible for the affected sites.
Anyone administering their own SPIP site should read the official SPIP announcement and move to a maintained release without delay.