Vulnérabilités critiques de PHP : le risque pour les sites des communes, des établissements municipaux et des projets régionaux

Le 21 octobre 2026, l'équipe PHP a publié des mises à jour exceptionnelles, et l'équipe européenne de réponse aux incidents informatiques CERT-EU a publié une alerte urgente. Deux vulnérabilités avec une note de dangerosité de 9,2 sur 10 permettent d'exécuter du code étranger sur le serveur sans autorisation.

PHP est le langage dans lequel est écrite la majorité des sites d'internet : WordPress, Joomla, OpenCart, Bitrix, Laravel. À l'échelle régionale, cela désigne les sites des conseils municipaux et ruraux, des entreprises municipales, des écoles, des bibliothèques, des musées et des projets de reconstruction — c'est-à-dire précisément la partie de l'infrastructure numérique qui n'a d'ordinaire ni administrateur propre ni budget de maintenance.

Ce qui a été découvert exactement

Il y a deux vulnérabilités, toutes deux notées 9,2, et toutes deux mènent au même résultat : l'exécution de code étranger sur le serveur sans aucune authentification.

CVE-2026-109618 — rupture en cas de manque de mémoire

PHP possède un paramètre memory_limit: une requête qui a consommé trop de mémoire est interrompue de force. Le problème est la manière exacte dont elle est interrompue. PHP peut s'arrêter au moment où les données internes de la requête ne sont remplies qu'à moitié — par exemple pendant l'analyse d'un fichier envoyé via un formulaire de téléversement. Le nettoyage qui suit une telle requête prend ces données inachevées pour de vraies données et tente de libérer une mémoire qui n'a jamais existé. Et dans cette mémoire peut se trouver ce que l'attaquant y a déposé lors de requêtes précédentes.

CVE-2026-109619 — restes de la requête précédente

La seconde faille concerne le fait que le serveur n'« oublie » pas complètement le visiteur précédent. L'état interne qui appartenait à une requête survit parfois à la libération de la mémoire — après une erreur fatale, par exemple. La requête suivante, tombée dans le même processus de travail, a le temps d'utiliser ces restes avant que l'initialisation habituelle ne les remette à zéro.

Est menacée toute installation de PHP qui traite des requêtes web : PHP-FPM, Apache avec le module mod_php, php-cgi, FrankenPHP, LiteSpeed. La configuration la plus risquée, selon l'équipe PHP, est précisément celle d'Apache avec mod_php — elle reste la configuration standard chez beaucoup d'hébergeurs bon marché.

L'exploit de démonstration fonctionne avec une seule requête non authentifiée — avant même que le code du site ne commence à s'exécuter. Autrement dit, ni les plugins de sécurité, ni les mots de passe complexes, ni l'authentification à deux facteurs n'aident ici : l'attaque se produit un niveau plus bas.

Quelles versions sont menacées

Tout ce qui est antérieur à ces versions est vulnérable :

Branche PHP	Version sûre
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 et antérieures	plus de support

Une catégorie de risque à part : les produits commerciaux et libres dans lesquels PHP est intégré sans que cela se voie de l'extérieur — panneaux d'administration, équipements réseau, systèmes de vidéosurveillance, portails d'entreprise. La liste de ces logiciels est tenue dans le dépôt du NCSC néerlandais.

Pourquoi c'est une question de résilience numérique de la commune et non d'un site isolé

Personne ne cherche séparément le site d'une commune en particulier. Dès que des exemples d'exploitation deviennent publics — et ils le sont déjà —, des scanners automatiques se lancent en quelques heures et parcourent tout internet sans distinction. Peu leur importe qu'il s'agisse du portail d'une administration régionale ou de la page d'une maison de la culture rurale : seule compte la version avec laquelle répond le serveur.

La particularité du secteur public est que ses ressources sont rarement isolées. Le site du conseil, le système de requêtes électroniques, le calendrier des services et la page d'une entreprise municipale vivent souvent sur le même hébergement et sous le même compte. En compromettant le plus faible d'entre eux, un attaquant accède à tous les autres — et peut ensuite non seulement diffuser du spam, mais aussi publier des communiqués au nom de l'autorité. Pour la commune, ce n'est plus une panne technique, mais une perte de confiance envers le canal officiel d'information.

La conclusion pratique pour ceux qui sont responsables du volet numérique dans une commune : il faut commencer non par la mise à jour, mais par l'inventaire — quelles ressources existent réellement, chez quel hébergeur elles se trouvent et qui y a accès. Très souvent, il s'avère qu'une partie des sites n'est suivie par personne depuis des années.

Que faire — étape par étape

1. Déterminez votre version. Dans le panneau d'hébergement, c'est la rubrique « Version de PHP » ou « PHP Selector » ; sur un serveur à soi, la commande php -v. Il est important de vérifier la version avec laquelle le site fonctionne réellement, et non celle de la ligne de commande : elles diffèrent souvent.
2. Mettez à jour au sein de votre branche. Passer de 8.2.29 à 8.2.35 est une correction à l'intérieur d'une même branche : la compatibilité est préservée et le site n'en casse pas. Ne confondez pas cela avec le passage de 8.2 à 8.4 — celui-là demande bien des vérifications.
3. Si vous êtes en 8.1 ou plus ancien — ces branches ne sont plus supportées. Vu la gravité de la situation, l'équipe de sécurité de PHP a publié des correctifs minimaux aussi pour 7.4, 8.0 et 8.1, et une partie des hébergeurs maintient ses propres compilations. Mais la bonne décision est de passer à une branche supportée, et il vaut mieux le planifier maintenant que la prochaine fois.
4. Redémarrez les gestionnaires. Sans redémarrage de php-fpm ou d'Apache, les processus de travail continuent de tourner avec l'ancien code et la mise à jour n'a en fait aucun effet.
5. Vérifiez le résultat. Le plus simple est une page temporaire avec phpinfo(), qu'il faut supprimer juste après la vérification, ou bien la rubrique « Version de PHP » du panneau après le redémarrage.

Les clients d'un hébergement n'auront le plus souvent rien à faire à la main : les grands fournisseurs ont reçu les correctifs à l'avance et mettent à jour leurs machines eux-mêmes. Il vaut la peine d'écrire une ligne au support — « PHP est-il mis à jour vers les versions du 21 octobre 2026 ? » — et d'obtenir la réponse par écrit.

Si la mise à jour immédiate est impossible

Il arrive qu'un site soit ancien et que la mise à jour demande une préparation. Il existe alors des mesures temporaires qui réduisent la fenêtre d'attaque :

• fermer le débordement de mémoire comme point d'entrée : memory_limit=-1, défini de telle sorte que l'application ne puisse pas le redéfinir, et une vérification qu'aucun pool ni répertoire ne remet la limite en place ;
• réduire post_max_size — 8M pour les sites sans téléversement de fichiers, 32M si les téléversements sont nécessaires, et upload_max_filesize à garder plus bas ;
• désactiver session.upload_progress.enabled et redémarrer tous les processus de travail ;
• sur PHP 8.5, désactiver en plus fatal_error_backtraces;
• limiter la taille et la complexité des requêtes au niveau du serveur web ou du proxy.

Aucune de ces mesures ne rend l'installation sûre. Elles ne ferment que les chemins connus — seule la mise à jour règle complètement le problème.

Si même cela est impossible, le CERT-EU conseille une solution simple et impopulaire : retirer le service vulnérable de l'internet public jusqu'à ce que le correctif soit installé et vérifié.

D'où viennent ces informations

• CERT-EU, Security Advisory 2026-018 « Critical Vulnerabilities in PHP »
• L'annonce de la publication des mises à jour sur php.net
• Description technique de CVE-2026-109618 et CVE-2026-109619

---

Si la commune ou l'établissement n'a pas de spécialiste chargé des mises à jour, l'audit des ressources peut être confié à l'extérieur — notamment à SmartGT.

Auteur de l'article — SmartGT. Source originale : « Vulnérabilités critiques de PHP : la mise à jour ne peut pas attendre ».