Une vulnérabilité critique de SPIP référencée CVE-2026-77806 permet à un attaquant distant et non authentifié d'exécuter du code sur le serveur, et elle est déjà exploitée. Toute installation antérieure à la version 4.4.21, publiée le 20 août 2026, doit être mise à jour puis auditée sans attendre.
Ce que dit exactement l'alerte SPIP#
La faille SPIP référencée CVE-2026-77806 est notée 9,8 sur 10. Selon Cyberattaque.org, elle repose sur une injection de code liée au traitement incorrect de données envoyées au serveur, et permet à un attaquant distant, non authentifié, sans aucune action de la victime, d'exécuter du code arbitraire avec les droits du processus web. Toutes les installations antérieures à SPIP 4.4.21 sont concernées. La version corrective a été publiée le 20 août 2026.
Deux précisions changent la nature de l'urgence. D'abord, l'équipe SPIP indique que la faille n'est pas bloquée par l'écran de sécurité : le mécanisme de protection habituellement recommandé ne suffit pas, c'est le cœur du CMS qui doit être mis à jour. Ensuite, une preuve de concept publique circule et des tentatives d'exploitation ont été observées, ce que Cybermalveillance.gouv.fr confirme selon la même source. Autrement dit, le scénario n'est plus théorique : des robots balayent déjà Internet à la recherche d'instances vulnérables.
Pourquoi la fenêtre de correction se compte en heures#
Quand une preuve de concept est publiée pour une faille pré-authentification, le délai entre la publication et les premières campagnes de masse est très court. Le scan d'Internet est automatisé et peu coûteux : il suffit de détecter une signature SPIP dans le code source ou les en-têtes, puis d'envoyer la requête d'exploitation. Aucun ciblage n'est nécessaire, aucun compte administrateur non plus. Un site de collectivité avec 300 visiteurs par mois est exactement aussi exposé qu'un portail à fort trafic.
Sur les parcs que nous exploitons et hébergeons, la règle appliquée pour ce type d'alerte est simple : les correctifs de sécurité critiques pré-authentification passent avant toute autre tâche planifiée, y compris les mises en production fonctionnelles. Ce n'est pas un excès de zèle, c'est une question d'arbitrage économique. Une mise à jour SPIP prend en général moins d'une heure sur une instance saine. La remise en état après compromission, entre analyse forensique, nettoyage, réinitialisation des accès et notification éventuelle à la CNIL en cas de données personnelles touchées, se compte en jours et en milliers d'euros.
Le plan d'action à dérouler dans l'ordre#
La mise à jour urgente est nécessaire mais pas suffisante. Si le site est resté exposé depuis la publication de la faille, patcher ne supprime pas une éventuelle porte dérobée déjà déposée. Il faut donc enchaîner correctif et audit, dans cet ordre précis :
- Faire une sauvegarde complète avant intervention : fichiers et base de données, horodatée, stockée hors du serveur. Elle sert de pièce à conviction si une compromission est découverte ensuite, et de point de retour si la mise à jour se passe mal.
- Passer en SPIP 4.4.21 minimum, sans se contenter d'activer ou de vérifier l'écran de sécurité, explicitement inopérant sur cette faille selon l'équipe SPIP.
- Vérifier les fichiers modifiés ou créés récemment, en particulier dans les répertoires accessibles en écriture par le serveur web (dossiers d'upload, cache, tmp). Cherchez les fichiers PHP inattendus, y compris avec des noms anodins ou des extensions doubles.
- Lister les comptes administrateurs et rédacteurs. Tout compte inconnu, tout compte créé après la publication de la faille, tout changement de niveau de droits doit être considéré comme suspect jusqu'à preuve du contraire.
- Inspecter les tâches planifiées côté CMS et côté système (cron). C'est le mécanisme de persistance le plus courant après une exécution de code : le correctif ferme la porte, la tâche planifiée la rouvre.
- Éplucher les journaux du serveur web sur la période allant du 20 août 2026 à aujourd'hui, à la recherche de requêtes POST anormales, de codes de réponse inhabituels ou de pics depuis une même adresse.
- Réinitialiser tous les secrets : mots de passe administrateurs, accès FTP et SSH, identifiants de base de données, clés d'API, jetons de services tiers. Un attaquant ayant exécuté du code a pu lire les fichiers de configuration.
- Contrôler les sauvegardes antérieures pour identifier la dernière version saine, et vérifier que la rotation ne les a pas déjà écrasées avec une version compromise.
Si l'audit révèle des traces d'intrusion, ne nettoyez pas au fil de l'eau. Repartez d'une installation propre sur laquelle vous réinjectez uniquement les contenus et les médias, après contrôle. Un serveur compromis ne se répare pas par retouches successives.
Sécurité CMS : ce que cette alerte dit de votre socle technique#
SPIP est un CMS français solide, largement déployé dans les collectivités, les associations, les établissements publics et les médias, avec une équipe qui publie ses correctifs et communique clairement, comme ici avec la précision sur l'écran de sécurité. Le problème n'est presque jamais le CMS lui-même. Il est dans l'écart entre la date de publication d'un correctif et la date de son application réelle sur le site.
Cet écart a une cause structurelle chez beaucoup de PME et de collectivités : le site a été livré il y a six, huit ou douze ans, le prestataire d'origine n'est plus là, personne en interne ne sait qui a les accès serveur, et la version installée est bloquée par un plugin maison ou un squelette sur mesure jamais mis à jour. Dans ce cas, l'alerte n'est pas isolée : c'est la troisième cette année en sécurité CMS, avec des failles critiques comparables signalées en août 2026 sur WordPress et sur l'extension Forminator Forms selon la même source. Le vrai sujet n'est donc pas cette CVE, c'est la capacité de l'organisation à appliquer un correctif dans la journée.
Maintenir SPIP ou lancer une migration : comment trancher#
La question n'est pas idéologique. Un SPIP à jour, hébergé correctement, avec une supervision et une procédure de mise à jour documentée, est un socle parfaitement défendable. Le tableau ci-dessous résume les critères sur lesquels nous appuyons cet arbitrage lors d'un audit.
| Situation | Arbitrage raisonnable |
|---|---|
| Version récente, accès maîtrisés, correctifs appliqués sous 48 h | Maintenir, formaliser la procédure de veille |
| Version bloquée par des développements sur mesure non maintenus | Évaluer une migration SPIP ou une remise à niveau technique |
| Prestataire d'origine injoignable, accès serveur inconnus | Reprise en main urgente, inventaire complet avant tout |
| Site vitrine ancien, besoins fonctionnels nouveaux non couverts | Refonte site sur un socle actuel, avec reprise des contenus |
Une migration SPIP vers un socle moderne se justifie quand le coût cumulé du maintien dépasse celui d'une refonte site, ou quand le CMS empêche des évolutions attendues : accessibilité RGAA, performances, formulaires connectés à un outil métier, publication multicanale. Elle ne se justifie pas si le seul argument est l'âge du logiciel. Websource accompagne depuis 2010 des refontes et des reprises de sites existants, avec 70 avis clients vérifiés pour une moyenne de 5/5, et travaille pour des organisations comme Société Générale, Michelin ou Le Point. Si votre site institutionnel est concerné et que vous ne savez pas par quel bout le prendre, un audit préalable permet au moins de savoir ce que vous hébergez réellement.
Ce qu'il faut mettre en place après le correctif#
Une fois l'incident traité, trois dispositifs évitent de revivre la même course. Le premier est un inventaire écrit : version du CMS, extensions et squelettes installés, hébergeur, détenteurs des accès, date du dernier correctif appliqué. Sans ce document, personne ne peut répondre en dix minutes à la question « sommes-nous concernés ». Le second est un canal de veille : abonnement aux annonces de sécurité de l'éditeur du CMS et aux alertes de Cybermalveillance.gouv.fr, avec un destinataire nommé et un suppléant.
Le troisième est un contrat de maintenance qui engage explicitement un délai d'application des correctifs critiques, et des sauvegardes testées. Une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est une hypothèse. Prévoyez au minimum une restauration de test par an sur un environnement séparé, et une rétention suffisante pour remonter avant une compromission qui aurait pu passer inaperçue plusieurs semaines. Ces trois éléments coûtent bien moins qu'une remise en état d'urgence, et ils transforment une alerte comme celle-ci en tâche de routine d'une heure.
Questions fréquentes#
Comment savoir si mon site tourne sous SPIP et dans quelle version ?#
La version apparaît généralement dans l'espace privé du CMS, sur le tableau de bord d'administration. Sans accès, une balise generator dans le code source de la page d'accueil ou la présence d'une URL de type spip.php sont des indices fiables. En cas de doute, demandez à votre hébergeur ou à votre prestataire technique la version exacte et la date du dernier correctif appliqué.
J'ai fait la mise à jour vers 4.4.21, suis-je tranquille ?#
La mise à jour ferme la vulnérabilité mais n'annule pas une compromission survenue avant. Si votre site est resté exposé depuis le 20 août 2026, il faut vérifier les fichiers créés ou modifiés récemment, les comptes administrateurs, les tâches planifiées et les journaux du serveur, puis réinitialiser tous les mots de passe et clés d'API.
L'écran de sécurité SPIP ne suffit-il pas à me protéger ?#
Non. L'équipe SPIP précise explicitement que cette faille n'est pas bloquée par l'écran de sécurité. C'est une particularité importante de cette CVE : le correctif doit être appliqué au CMS lui-même, l'installation du mécanisme de protection seul laisse le site vulnérable.
Faut-il migrer hors de SPIP après cet incident ?#
Pas nécessairement. Un SPIP tenu à jour, hébergé correctement et couvert par une procédure de mise à jour documentée reste un socle valable. La migration se justifie quand la version est bloquée par des développements sur mesure abandonnés, quand plus personne ne maîtrise les accès, ou quand le CMS empêche des évolutions attendues comme la mise en conformité d'accessibilité.
Que faire si je découvre que le site a été compromis ?#
Conservez une copie complète du serveur avant tout nettoyage, elle sert de preuve et d'élément d'analyse. Repartez ensuite d'une installation propre en réinjectant uniquement les contenus contrôlés, plutôt que de retoucher un système compromis. Si des données personnelles ont pu être consultées, la question d'une notification à la CNIL sous 72 heures doit être examinée.
Sources#
- Cyberattaque.org — SPIP : une faille critique 9,8/10 déjà exploitée permet de prendre le contrôle d'un site
- Cybermalveillance.gouv.fr
- SPIP — site officiel du CMS
Article rédigé le 28/08/2026 par l'équipe Websource à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.
