One HTTP header is all it takes. Send a request to a vulnerable SPIP site with an X-Spip-Filtre header attached and the content management system will run the PHP you put in it, with no login and nothing else required. SPIP shipped the fix, version 4.4.21, on 20 August, and said at the time that exploitation attempts had already been observed in the wild.
It has become easier since. Rapid7 merged a Metasploit module for the flaw into the framework on 24 August, which moves it from something an attacker has to build to something an attacker can pick off a list.
A header the template engine trusts
SPIP is a French open source content management system. The bug, tracked as CVE-2026-77806 and scored 9.8 out of 10, sits in its template rendering. According to the US National Vulnerability Database record, the X-Spip-Filtre request header is mishandled by a function called analyse_resultat_skel, and that is enough for an unauthenticated remote attacker to execute arbitrary code. In practice it means the web server process, and everything it can read or write, belongs to whoever sent the request.
SPIP describes it as a universal unauthenticated remote code execution flaw and, importantly, says its security screen does not mitigate it. That detail matters, because administrators often treat the screen as a safety margin that buys time between a disclosure and the next maintenance window. Here it buys none.
Update to 4.4.21, because there is no workaround
Everything before 4.4.21 is affected. SPIP's own announcement points users at spip_loader 7.0.0 from get.spip.net or a direct download of the 4.4.21 archive, and the release supports PHP 7.4 through 8.5. No workaround has been published, which combined with the missing screen protection leaves updating as the only real option.
Because exploitation predates the fix, patching does not settle whether you were already hit. A site that was internet-facing and unpatched between the disclosure and the update should be treated as possibly compromised: review web server logs for requests carrying an X-Spip-Filtre header, and check for files created or modified in the webroot around the time of any that show up.
How this one surfaced
The flaw appeared in Peru's CNSD integrated digital security bulletin No. 157-2026, published on 25 August, which flagged the SPIP code injection alongside seven other issues. That bulletin led with the maximum severity Oracle HTTP Server flaw US authorities added to their exploited vulnerabilities catalogue earlier this week. The disclosure and the fix, though, are SPIP's own: the project's critical security update announcement carries the detail.
Two code injection bugs under active attack inside a week, both in software that mostly runs quietly on somebody else's server, is the shape this month keeps taking; the same week brought a warning that a Gitea code injection bug was under attack. The pattern is not that these products are unusually weak. It is that a header or a parameter reaching a template engine is a very short path from the open internet to a shell, and attackers have got fast at walking it.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.