SPIP CVE-2026-77806 : faille RCE critique exploitee, sites francais en danger

— Comprendre CVE-2026-77806 : anatomie d'une RCE dans SPIP

Le 22 aout 2026, le CERT-FR a publie l'avis CERTFR-2026-ACT-036 alertant sur l'exploitation active d'une vulnerabilite critique dans le CMS SPIP. Referencee CVE-2026-77806, cette faille permet a un attaquant distant, sans aucune authentification prealable, d'executer du code PHP arbitraire sur le serveur hebergeant un site SPIP. Le score CVSS attribue est de 9.8 sur 10 — le seuil maximal de la categorie "critique".

SPIP est un systeme de gestion de contenu open source developpe en France depuis 2001. Historiquement adopte par les institutions publiques francaises pour sa philosophie de logiciel libre et sa simplicite d'utilisation, SPIP propulse encore aujourd'hui des milliers de sites web de collectivites territoriales, d'universites, d'associations, de syndicats et de plusieurs administrations centrales. Contrairement a WordPress ou Drupal, SPIP dispose d'un moteur de templates proprietaire — les "squelettes" — qui genere les pages HTML a partir de balises specifiques et de filtres PHP.

C'est precisement dans ce moteur de templates que reside la vulnerabilite. La fonction analyse_resultat_skel, chargee de traiter le resultat du rendu d'un squelette, lit la valeur du header HTTP X-Spip-Filtre envoye par le client. En fonctionnement normal, ce header est utilise en interne par SPIP pour appliquer des filtres de mise en forme au contenu genere — par exemple, compresser le HTML ou appliquer un encodage. Le probleme est que la valeur de ce header n'est pas validee avant d'etre utilisee comme nom de fonction PHP dans un appel de type call_user_func().

Concretement, un attaquant peut envoyer une requete HTTP contenant X-Spip-Filtre: system (ou toute autre fonction PHP dangereuse comme exec, passthru, shell_exec), et le moteur SPIP executera cette fonction en lui passant le contenu de la page rendue comme argument. Le resultat ? L'attaquant controle completement l'execution de code cote serveur. Il peut lire des fichiers, modifier la base de donnees, installer un webshell, exfiltrer des donnees ou pivoter vers d'autres systemes du reseau.

— Exploitation active en aout 2026 : chronologie et preuves

La chronologie de CVE-2026-77806 illustre la rapidite avec laquelle une vulnerabilite critique dans un CMS largement deploye peut passer de la decouverte a l'exploitation massive. Aux alentours de la mi-aout 2026, la vulnerabilite a ete identifiee dans le code source de SPIP. L'equipe de developpement de SPIP a publie la version corrective 4.4.21 le 19 aout, integrant un correctif qui ajoute une liste blanche (allowlist) sur les noms de filtres acceptes par analyse_resultat_skel.

Deux jours plus tard, le 21 aout, une preuve de concept (PoC) fonctionnelle a ete publiee publiquement. Cette PoC demontre qu'une simple commande curl suffit pour exploiter la faille : il suffit d'ajouter le header X-Spip-Filtre: system a une requete vers n'importe quelle page d'un site SPIP vulnerable. La publication de cette PoC a declenche une vague d'exploitation automatisee a grande echelle.

Le 22 aout, le CERT-FR a emis l'avis CERTFR-2026-ACT-036, qualifiant la situation de critique et recommandant la migration immediate vers SPIP 4.4.21. En parallele, Cybermalveillance.gouv.fr a relaye l'alerte aupres des collectivites territoriales et des associations, deux categories d'utilisateurs de SPIP particulierement vulnerables du fait de leurs ressources limitees en securite informatique. Les analyses de CERT-FR et de plusieurs equipes de recherche (IONIX, Rapid7) confirment que les attaques se sont intensifiees entre le 23 et le 29 aout, ciblant principalement des sites publics francais.

Les scans automatises recherchent les signatures SPIP dans les headers de reponse HTTP (X-Spip-Cache, Composed-By: SPIP) et dans les chemins d'URL caracteristiques (/spip.php, /ecrire/). Une fois un site SPIP identifie, l'exploit est lance automatiquement. Les logs des honeypots montrent des tentatives d'injection de fonctions comme system, passthru et base64_decode via le header X-Spip-Filtre.

— SPIP dans le secteur public francais : un heritage numerique a haut risque

Pour comprendre l'ampleur de la menace, il faut mesurer l'importance de SPIP dans le paysage numerique francais. SPIP n'est pas un CMS marginal — c'est le CMS historique du service public francais. Cree en 2001 par des developpeurs francais proches du mouvement du logiciel libre, il a ete massivement adopte par les administrations, les collectivites territoriales, les universites et les associations francaises a une epoque ou WordPress en etait a ses debuts et ou le choix d'un outil open source francophone relevait d'une politique numerique publique.

Aujourd'hui encore, on estime que plus de 6 500 sites web francais fonctionnent sous SPIP. Parmi eux, une proportion importante n'est pas maintenue activement : le webmaster d'origine a change de poste, le budget de maintenance du site a ete reduit, ou l'organisation considere que le site "fonctionne" et ne necessite pas de mises a jour. Cette realite est particulierement aigue dans les petites collectivites (communes de moins de 10 000 habitants), les laboratoires de recherche universitaire et les associations locales dont le site SPIP a ete cree il y a 10 ou 15 ans et n'a jamais ete migre vers un CMS plus recent.

Le profil type d'un site SPIP vulnerable en 2026 est celui d'une commune rurale ou d'une communaute de communes dont le site web a ete developpe dans les annees 2010-2015, heberge chez un prestataire local ou sur un serveur mutualise, et pour lequel aucune maintenance de securite reguliere n'est prevue au budget. Le site affiche les deliberations du conseil municipal, les horaires de la mairie, les evenements locaux — des informations publiques, certes, mais le serveur qui l'heberge contient aussi des boites mail, des documents internes et parfois des bases de donnees avec des informations personnelles de citoyens.

Le cas des universites est egalement preoccupant. Beaucoup de laboratoires de recherche et de departements academiques operent des sites SPIP independants du systeme d'information central de l'universite, echappant ainsi a la politique de securite de la DSI. Ces sites peuvent contenir des travaux de recherche sensibles, des donnees d'etudiants ou des informations sur des projets finances. Un attaquant qui compromet un de ces sites via CVE-2026-77806 obtient un point d'entree dans le reseau de l'universite.

— Risques concrets : site patche vs site non patche

Pour rendre tangible l'urgence de la mise a jour, voici une comparaison directe des risques entre un site SPIP patche (version 4.4.21+) et un site qui reste sur une version anterieure.

— Mesures de contournement : filtrer X-Spip-Filtre au niveau WAF/reverse proxy

Pour les organisations qui ne peuvent pas appliquer immediatement la mise a jour vers SPIP 4.4.21 — parce que le prestataire n'est plus joignable, parce que le site a des personnalisations qui risquent de casser, ou simplement parce que le processus de validation prend du temps — le CERT-FR recommande une mesure de contournement efficace : bloquer ou filtrer le header HTTP X-Spip-Filtre au niveau du reverse proxy ou du WAF.

Cette mesure est elegante dans sa simplicite. Puisque la vulnerabilite repose entierement sur le traitement du header X-Spip-Filtre par le moteur SPIP, empecher ce header d'atteindre l'application neutralise completement le vecteur d'attaque. Voici les configurations recommandees selon l'infrastructure en place :

RequestHeader unset X-Spip-Filtre

proxy_set_header X-Spip-Filtre "";

http-request del-header X-Spip-Filtre

Supprimer le header X-Spip-Filtre dans les regles de transformation des requetes entrantes

Cette mitigation est une mesure temporaire. Elle neutralise le vecteur d'attaque specifique de CVE-2026-77806, mais ne corrige pas la vulnerabilite sous-jacente dans le code SPIP. Si d'autres failles sont decouvertes dans le moteur de templates, elles ne seront pas couvertes par cette regle. La mise a jour vers SPIP 4.4.21 reste la seule remediation definitive. Nous recommandons de deployer la mitigation WAF immediatement et de planifier la mise a jour sous 7 jours maximum.

Attention egalement a un piege courant : certains sites SPIP sont heberges sur des serveurs mutuealises ou le client n'a pas acces a la configuration du serveur web (Apache/Nginx). Dans ce cas, il faut contacter l'hebergeur pour qu'il applique la mitigation au niveau de l'infrastructure, ou utiliser un fichier .htaccess si le serveur est Apache avec AllowOverride active.

— Plan d'action complet : remediation et investigation

Que votre site SPIP ait ete compromis ou non, un plan d'action structure est necessaire. Voici les etapes recommandees par nos equipes, classees par priorite.

1. 1
   Identifier toutes les instances SPIP

   Commencez par un inventaire exhaustif. Scannez votre perimetre a la recherche de signatures SPIP : headers HTTP Composed-By: SPIP, URL contenant /spip.php, repertoire /ecrire/. N'oubliez pas les sous-domaines et les sites heberges sur des serveurs mutualises.

2. 2
   Verifier la version installee

   Connectez-vous a l'interface d'administration (/ecrire/) ou verifiez le fichier ecrire/inc_version.php pour identifier la version exacte de SPIP. Toute version anterieure a 4.4.21 est vulnerable. Les branches 4.3.x, 4.2.x et anterieures sont egalement affectees si elles n'ont pas recu de backport.

3. 3
   Appliquer la mitigation WAF immediatement

   Configurez votre reverse proxy, WAF ou .htaccess pour supprimer le header X-Spip-Filtre des requetes entrantes. Cette mesure prend quelques minutes et neutralise le vecteur d'attaque principal.

4. 4
   Migrer vers SPIP 4.4.21

   Telechargez la version 4.4.21 depuis le site officiel de SPIP et suivez la procedure de mise a jour standard. Testez le site apres la mise a jour pour verifier que les squelettes personnalises fonctionnent correctement. Si votre version est tres ancienne (SPIP 3.x), une migration complete peut etre necessaire — envisagez dans ce cas une refonte vers un CMS maintenu activement.

5. 5
   Rechercher les indicateurs de compromission

   Examinez les logs d'acces du serveur web a la recherche de requetes contenant le header X-Spip-Filtre avec des valeurs suspectes (system, exec, passthru, base64_decode). Recherchez egalement des fichiers PHP suspects dans l'arborescence du site (webshells), des modifications recentes de fichiers systeme, et des connexions sortantes inhabituelles.

6. 6
   Changer tous les mots de passe

   Si la moindre trace de compromission est detectee, changez immediatement : les mots de passe d'administration SPIP, les credentials de la base de donnees MySQL/MariaDB, les mots de passe SSH/FTP du serveur, et les mots de passe des comptes de messagerie heberges sur le meme serveur. Un attaquant ayant obtenu une RCE a pu lire les fichiers de configuration contenant ces credentials.

7. 7
   Evaluer l'obligation de notification CNIL

   Si votre site SPIP stocke des donnees personnelles (formulaires de contact, inscriptions a des evenements, comptes utilisateurs) et qu'une compromission est confirmee, vous etes dans l'obligation de notifier la CNIL sous 72 heures conformement au RGPD. Les collectivites territoriales sont tenues a cette obligation au meme titre que les entreprises privees.

— Ce que ca signifie pour vous

Si vous etes une collectivite territoriale ou une association utilisant SPIP : verifiez immediatement la version de votre site. Contactez votre prestataire web ou la DSI de votre intercommunalite pour demander une mise a jour d'urgence. Si vous n'avez plus de prestataire, contactez Cybermalveillance.gouv.fr qui peut vous orienter vers un prestataire labellise.

Si vous etes un hebergeur ou un prestataire web gerant des sites SPIP pour des clients : deployez immediatement la mitigation WAF sur tous vos serveurs hebergeant des instances SPIP, puis planifiez les mises a jour en coordination avec vos clients. Vous avez une responsabilite contractuelle et ethique de proteger les sites que vous hebergez.

Si vous etes RSSI ou DSI d'une organisation susceptible d'utiliser SPIP (universite, administration, grande association) : lancez un scan de votre perimetre a la recherche de signatures SPIP. Les instances SPIP "oubliees" — deployees par un departement sans passer par la DSI — sont souvent les plus vulnerables car elles echappent a votre gestion de la surface d'attaque.

Si vous envisagez une refonte de votre site : CVE-2026-77806 est un signal clair que le moment est venu de migrer vers un CMS activement maintenu avec des mecanismes de mise a jour automatique. SPIP reste un outil fonctionnel, mais sa base d'utilisateurs et de developpeurs s'est considerablement reduite par rapport aux annees 2000-2010, ce qui impacte la reactivite de la communaute face aux vulnerabilites. Un audit de cybersecurite complet de votre infrastructure web vous aidera a prioriser les actions.

— Conclusion

CVE-2026-77806 dans SPIP est une vulnerabilite d'une gravite exceptionnelle (CVSS 9.8) qui affecte un CMS profondement ancre dans le tissu numerique francais. L'injection de fonctions PHP via le header X-Spip-Filtre est triviale a exploiter, ne necessite aucune authentification et donne un controle total du serveur a l'attaquant. L'exploitation active est confirmee depuis la derniere semaine d'aout 2026, et les scans automatises ciblent specifiquement les sites SPIP francais.

La remediation est claire : migrer vers SPIP 4.4.21 et, en attendant, filtrer le header X-Spip-Filtre au niveau du serveur web ou du WAF. Mais au-dela de la correction technique, cette vulnerabilite doit servir d'electrochoc pour toutes les organisations qui operent des sites SPIP sans maintenance de securite. Le secteur public francais ne peut plus se permettre d'ignorer la dette technique de ses sites web — les attaquants, eux, ne l'ignorent pas.