SURIQ
A single crafted web request can take full control of a SPIP-powered website, and the fix most operators installed yesterday does not stop it. SPIP is a widely deployed open-source content management system used by news outlets, associations, and public-sector sites, and it has a critical flaw tracked as CVE-2026-77806. It carries a CVSS score of 9.8, needs no login, and both MITRE and SPIP's own team report it is being exploited in the wild this month.
The sequence is the urgent part. SPIP shipped an emergency release, 4.4.20, to patch this corner of its code. Within about a day it had to ship 4.4.21, because the first fix left the door open. If you updated to 4.4.20 and moved on, your site is still exposed. The only version that closes the flaw is 4.4.21.
What the flaw lets an attacker do
SPIP builds its pages through a template engine that runs filters over incoming data. This bug lives in that machinery. An attacker sends an ordinary-looking HTTP request with one extra header named X-Spip-Filtre, and SPIP's analyse_resultat_skel routine handles the header contents unsafely. The header carries a chain of SPIP template filters, and a crafted chain turns attacker-supplied text into a command the server then runs. No account, no password, and nothing for a victim to click.
Execution lands as the web server user. From that position an attacker can read application secrets, drop a web shell for persistence, reach the database, or use the host as a foothold into the rest of your infrastructure. It is the same class of unauthenticated takeover we walked through with the Forminator WordPress plugin and the Phoca Cart flaws: the front door is a public web request that needs nothing from the person running the site.
Why patching to 4.4.20 is not enough
SPIP's team, which received the report anonymously through France's national cybersecurity agency ANSSI, describes this as a universal pre-authentication code-execution flaw that its built-in security screen does not catch. That screen normally blocks a large share of injection attempts before they reach application logic, so operators lean on it. Here it offers no protection, which is why the vendor calls the update mandatory and urgent.
What makes this one worse than a routine critical is the double release. The 4.4.20 build, put out one day earlier, addressed the same code path but did not fully close it. Public exploit development already reflects that: a Metasploit module in progress targets exactly this header handling, and the contributor behind it flags 4.4.20 as an incomplete fix. That work is filed under the earlier identifier CVE-2026-77647, while MITRE tracks the flaw that 4.4.21 fixes as CVE-2026-77806. For a defender the identifier matters less than the version: anything below 4.4.21 in the 4.4 branch should be treated as vulnerable, and teams on older SPIP branches should follow the vendor's advisory for their line.
How to tell if someone tried it
This flaw comes with an unusually clean detection signal. The attack rides a request header that legitimate traffic essentially never sends, so its presence against a SPIP site is suspicious on its own. Pull your web server, reverse proxy, and application-firewall logs and search for inbound requests carrying that X-Spip-Filtre header. Because SPIP has been under active exploitation this month, extend the search back through the days before you patched, not just forward from now.
Header hits are the first pass. The second is looking for what a successful hit leaves behind: PHP processes or files created by the web server user that you cannot explain, new files under the web root, unexpected outbound connections from the host, and modified template or configuration files. Public exploit code circulating is the reason to treat exploitation as ongoing rather than theoretical, the same posture we take on any flaw where a working unauthenticated attack is already in the open.
Patch to 4.4.21, then hunt for the header
Update every SPIP install in the 4.4 branch to 4.4.21 now, using the current spip_loader from the official SPIP download site. Confirm the running version afterward, since a site stopped at 4.4.20 will look patched but is not. If you genuinely cannot patch in the next hours, block or strip requests that contain the X-Spip-Filtre header at your web application firewall or reverse proxy as a stopgap, then patch as soon as you can, because only 4.4.21 removes the flaw.
After patching, do the log review rather than assuming the update ended it. Patching closes the hole going forward; it tells you nothing about whether you were hit in the window while the fix was incomplete or before you applied it. On an internet-facing content management system under confirmed exploitation, that window is exactly where the compromise you have not noticed yet would live.