SPIP 4.4.29 : mise à jour critique (CVE-2026-122032), élévation de privilèges et XSS sans authentification, passez directement en 4.4.30

Le 4 novembre 2026, l'équipe de maintenance de SPIP a publié la version 4.4.29, présentée comme une mise à jour critique de sécurité. Elle corrige plusieurs failles du CMS : une élévation de privilèges, une suppression arbitraire de fichiers après authentification, une faille XSS après authentification pouvant conduire à une exécution de code sur le serveur, une XSS avant authentification et une injection SQL. Toutes les versions de SPIP antérieures à 4.4.29 sont concernées, et l'éditeur précise que l'écran de sécurité ne protège pas contre ces failles. Le lendemain, la version 4.4.30 est sortie pour corriger des régressions introduites par la 4.4.29. Si vous hébergez un site SPIP sur un VPS Linux ou un serveur dédié, visez donc directement la 4.4.30. Voici ce que corrigent ces versions, comment lire votre version de SPIP, comment mettre à jour le coeur et les plugins, et comment limiter le risque en attendant.

Sources : annonce de SPIP 4.4.29 sur blog.spip.net, annonce de SPIP 4.4.30, changelog du plugin ecrire, avis VulnCheck sur CVE-2026-122032.

Ce que corrige SPIP 4.4.29

L'annonce de l'éditeur regroupe cinq types de vulnérabilités, signalées par 0xkidz, gaspard, Nostromo et Victor Soler Renaud (Devoteam Purple Team). Pour un administrateur, le point à retenir est le niveau d'accès nécessaire pour chacune :

La même version règle aussi un problème de cache : les contextes AJAX, stockés dans tmp/cache/contextes/, grossissaient sans limite et pouvaient être empoisonnés par des tentatives d'exploitation d'anciennes failles. D'après le changelog du plugin ecrire, ils sont désormais rangés dans des sous-répertoires, encodés en base64, et leur empreinte est vérifiée au décodage. Les données envoyées en POST par les formulaires ne sont plus mémorisées dans ces contextes.

L'écran de sécurité ne suffit pas. Ce fichier ecran_securite.php, déposé dans config/, bloque certaines attaques connues en attendant une montée de version. L'éditeur indique explicitement que les failles corrigées en 4.4.29 ne sont pas prises en charge par cet écran. Même avec un écran de sécurité à jour, un site en 4.4.28 ou plus ancien reste vulnérable tant que le coeur n'est pas mis à jour.

CVE-2026-122032 : lire toute la base depuis un simple compte rédacteur

Une seule faille a reçu un identifiant CVE à ce stade : CVE-2026-122032, l'injection SQL. Elle se trouve sur la page /ecrire/?exec=articles de l'espace privé. SPIP désinfecte normalement les paramètres reçus par la fonction spip_sanitize_from_request(), mais cette fonction supposait que la valeur venait d'une seule source. Un utilisateur authentifié envoie un paramètre where différent dans le corps de la requête POST et dans la chaîne de requête GET : la désinfection porte sur l'une des deux valeurs, et l'autre atteint la requête SQL. L'attaquant peut alors lire n'importe quelle table de la base de données MySQL ou PostgreSQL du site : articles non publiés, protégés ou restreints, adresses e-mail des auteurs, et surtout les hachages bcrypt des mots de passe de tous les comptes, y compris ceux des webmestres.

Le correctif, référencé dans le changelog sous le ticket securite#4966, fait en sorte que spip_sanitize_from_request() ne présume plus de la provenance des données et que le calcul du contexte reste cohérent avec la fonction _request(). Le score CVSS reste « moyen » en version 3.1 parce qu'un compte est nécessaire. En pratique, sur un site collaboratif qui accepte les inscriptions de rédacteurs, ou sur lequel un ancien contributeur a gardé un accès, ce prérequis est faible. Bcrypt ralentit le cassage des hachages, mais un mot de passe court ou courant finit par céder.

Qui est concerné et quelle version viser

Tous les sites SPIP en version inférieure à 4.4.29 sont vulnérables, y compris ceux qui tournent sur une ancienne branche (4.3, 4.2 ou plus ancienne). La branche 4.4 est la branche maintenue : d'après la page des versions de spip.net, elle reste en maintenance active jusqu'au 15 janvier 2027 et reçoit des correctifs de sécurité jusqu'au 21 juillet 2028, avec une compatibilité PHP de 7.4 à 8.5. Un site resté en 4.3 ou en 4.2 doit donc migrer vers 4.4.

La 4.4.29 a été publiée dans l'urgence et a cassé plusieurs choses. L'annonce de la 4.4.30, sortie le 5 novembre, liste les régressions corrigées :

Les critères {par num titre} et {par sinum titre} trient les boucles par le numéro placé devant le titre, une pratique très répandue dans les squelettes. Un site passé en 4.4.29 peut donc afficher des erreurs SQL dans ses boucles, et un administrateur déjà connecté peut tomber sur une erreur fatale en rouvrant la page de connexion. Ne vous arrêtez pas en 4.4.29 : la 4.4.30 contient les mêmes correctifs de sécurité sans ces régressions.

Lire la version de votre SPIP

Deux méthodes. La première, sans accès au serveur : le numéro de version s'affiche en bas de page de l'espace privé, une fois connecté. La seconde, en SSH, lit la variable $spip_version_branche dans le fichier ecrire/inc_version.php à la racine du site (adaptez le chemin à votre installation) :

grep -m1 'spip_version_branche' /var/www/monsite/ecrire/inc_version.php

Sur un serveur qui héberge plusieurs sites SPIP, la boucle suivante liste la version de chacun d'eux :

for f in /var/www/*/ecrire/inc_version.php; do printf '%s : ' "$f"; grep -m1 -o "spip_version_branche = '[^']*'" "$f"; done

Toute valeur inférieure à 4.4.30 doit être mise à jour. Pensez aussi aux copies de site oubliées : préproduction, ancien site laissé en ligne dans un sous-dossier, instance de test. Un SPIP vulnérable accessible depuis Internet suffit à compromettre le serveur, même s'il n'a plus de visiteurs.

Mettre à jour vers SPIP 4.4.30

1. Sauvegarder la base de données et les fichiers

Avant toute mise à jour, exportez la base de données et copiez les répertoires config/, IMG/, squelettes/ et plugins/. Notre guide sauvegarder MySQL avec mysqldump et cron détaille la méthode pour la base. Pour les fichiers, une copie rsync vers un autre serveur ou un stockage distant suffit (voir sauvegarder un VPS avec rsync).

2. Mettre d'abord à jour le plugin memoization

Si le plugin memoization est installé, passez-le en version 4.1.2 avant de toucher au coeur. Son changelog, daté du 4 novembre 2026, reporte le correctif de SPIP contre l'empoisonnement du cache. L'éditeur demande cette mise à jour en premier, et des commentaires sous l'annonce signalent des erreurs fatales dans l'espace privé sur des sites qui ont mis à jour SPIP avant ce plugin. La mise à jour se fait depuis le menu Configuration, Gestion des plugins, de l'espace privé, ou en remplaçant le dossier du plugin dans plugins/.

3. Mettre à jour le coeur avec spip_loader 8.0.5

spip_loader est l'outil officiel d'installation et de mise à jour automatique. Sa version actuelle est la 8.0.5, téléchargeable sur get.spip.net. Elle demande PHP 7.4 au minimum. La procédure :

1. Déposez spip_loader.php à la racine du site, de préférence en SFTP. En FTP classique, forcez le mode de transfert binaire, sinon la vérification de signature SHA-512 du script échoue.
2. Connectez-vous à l'espace privé avec le compte du webmestre : par défaut, seul l'auteur numéro 1 est autorisé à lancer une mise à jour. Pour autoriser d'autres comptes, créez un fichier spip_loader_config.php à la racine qui retourne un tableau avec la clé authorized.users.
3. Ouvrez https://votresite.tld/spip_loader.php, choisissez la version 4.4.30 et lancez la procédure. Les fichiers supprimés entre deux versions sont déplacés dans un répertoire fichiers_obsoletes_<date>.
4. Si SPIP vous propose une mise à jour de la base de données à la première connexion, acceptez-la.

Sans spip_loader, téléchargez l'archive spip-v4.4.30.zip sur files.spip.net et remplacez les fichiers du coeur (ecrire/, prive/, squelettes-dist/, plugins-dist/ et les fichiers PHP de la racine) en conservant vos répertoires config/, IMG/, squelettes/, plugins/ et local/.

4. Relancer la mise à jour des plugins

Les correctifs ne sont pas tous dans le plugin ecrire : plusieurs plugins distribués avec SPIP ont aussi changé de version. Après la mise à jour du coeur, ouvrez Configuration, Gestion des plugins, et appliquez les mises à jour proposées. Les versions attendues :

Videz ensuite le cache depuis l'espace privé, rechargez la page d'accueil et une page de rubrique qui utilise un tri {par num}, puis déconnectez-vous et reconnectez-vous pour vérifier la page de connexion. Contrôlez enfin les pièces jointes et les images des articles : plusieurs commentaires sous l'annonce signalent des documents qui ne s'affichaient plus après la 4.4.29.

Mots de passe : 12 caractères minimum et renouvellement

Depuis la 4.4.29, d'après le changelog du plugin ecrire, tout nouveau mot de passe doit compter 12 caractères au minimum. Les mots de passe existants plus courts continuent de fonctionner, mais ils ne pourront pas être réutilisés lors d'un changement. Prévenez vos rédacteurs avant de leur demander de renouveler leur mot de passe, sinon le formulaire leur paraîtra cassé.

Ce renouvellement est justement la deuxième action à mener. Si votre site est resté exposé avec des comptes rédacteurs dont vous ne maîtrisez pas tous les détenteurs, considérez que les hachages ont pu être lus. Demandez alors à chaque auteur de changer son mot de passe depuis sa fiche dans l'espace privé, supprimez les comptes inactifs, et changez en priorité ceux des administrateurs et des webmestres. Profitez-en pour vérifier que le mot de passe de la base de données, dans config/connect.php, n'est pas réutilisé ailleurs : un attaquant capable de lire la base a aussi pu lire les tables de configuration.

En attendant la mise à jour : restreindre l'accès à /ecrire/

Quatre des cinq failles exigent un compte de l'espace privé, et la page vulnérable à l'injection SQL se trouve sous /ecrire/. Si vous ne pouvez pas mettre à jour dans l'heure, limitez l'accès à ce répertoire aux adresses IP de votre équipe, ou protégez-le par une authentification HTTP. Les visiteurs ne sont pas affectés : le site public passe par spip.php et ne charge jamais d'URL sous /ecrire/. Cette restriction ne ferme pas la XSS avant authentification, qui peut viser une page publique : elle réduit l'exposition, elle ne remplace pas la mise à jour.

Nginx : filtrage par IP

Le bloc ci-dessous n'accepte les requêtes vers /ecrire/ que depuis deux adresses. Le préfixe ^~ est indispensable : sans lui, le bloc location ~ \.php$ habituel prendrait la main sur /ecrire/index.php et ignorerait la restriction. Le sous-bloc PHP doit reprendre les directives FastCGI de votre configuration existante (voir notre guide installer PHP-FPM sur un VPS Linux) :

location ^~ /ecrire/ {
    allow 203.0.113.10;
    allow 198.51.100.0/24;
    deny all;

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

sudo nginx -t && sudo systemctl reload nginx

Nginx ou Apache : authentification HTTP

Si vos rédacteurs travaillent depuis des adresses IP changeantes, remplacez le filtrage par un mot de passe HTTP. Créez le fichier d'utilisateurs avec htpasswd (paquet apache2-utils sur Debian et Ubuntu), puis ajoutez dans le bloc location ^~ /ecrire/ de Nginx :

sudo htpasswd -c /etc/nginx/.htpasswd-spip redaction
auth_basic "Espace prive SPIP";
auth_basic_user_file /etc/nginx/.htpasswd-spip;

Sur Apache 2.4, le même résultat s'obtient dans le VirtualHost, ou dans un fichier .htaccess déposé dans ecrire/ si AllowOverride l'autorise :

<Directory "/var/www/monsite/ecrire">
    AuthType Basic
    AuthName "Espace prive SPIP"
    AuthUserFile /etc/apache2/.htpasswd-spip
    Require valid-user
</Directory>

Pour un filtrage par IP sous Apache, remplacez les quatre directives d'authentification par Require ip 203.0.113.10. Une troisième option, plus durable, consiste à ne publier l'espace privé que sur un réseau privé : notre guide Tailscale sur VPS Linux montre comment joindre un service sans l'exposer sur Internet.

Vérifier que personne n'a exploité la faille

Aucune exploitation de CVE-2026-122032 n'est signalée publiquement au moment où nous écrivons, mais les détails techniques sont publics, ce qui facilite la création d'un exploit. Les journaux du serveur web permettent une première vérification : cherchez les requêtes POST vers la page exec=articles, qui est en temps normal consultée en GET :

grep 'POST /ecrire/' /var/log/nginx/access.log* | grep 'exec=articles'

Des rafales de requêtes depuis une même adresse, ou des paramètres where contenant des mots-clés SQL (UNION, SELECT, spip_auteurs), sont des signaux d'alerte. Vérifiez aussi, dans l'espace privé, la liste des auteurs : un compte administrateur inconnu ou un rédacteur récemment passé administrateur correspond à la faille d'élévation de privilèges. Comparez enfin les fichiers du site à votre dernière sauvegarde pour repérer un fichier PHP ajouté ou modifié dans IMG/, tmp/ ou local/. Notre guide vérifier qu'un serveur PHP n'est pas compromis détaille cette recherche. En cas de doute sérieux, restaurez une sauvegarde antérieure et changez tous les secrets du site.

SPIP sur un serveur que vous administrez

SPIP publie des correctifs de sécurité à un rythme soutenu : quatre versions critiques entre le 20 août et le 4 novembre 2026 sur la seule branche 4.4, selon le blog de l'éditeur. Sur un hébergement mutualisé, la version de PHP et les règles du serveur web sont fixées par l'hébergeur, et une restriction de /ecrire/ n'est pas toujours possible. Sur un VPS Linux KVM avec accès root, vous choisissez votre version de PHP, votre serveur web, Nginx ou Apache, et vous pouvez appliquer une mise à jour de SPIP ou une règle d'accès en quelques minutes, sans attendre un tiers. Pour garder le serveur lui-même à jour, combinez les mises à jour de sécurité automatiques du système, un Nginx correctement configuré, un certificat Let's Encrypt pour chiffrer les connexions à l'espace privé, et Fail2ban pour ralentir les tentatives de connexion répétées. Les autres CMS ne sont pas épargnés : voir notre actualité sur les 22 failles corrigées par WordPress 7.1.4.