Vulnérabilités critiques de PHP : ce que cela signifie pour les sites des projets de reconstruction

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 : WordPress, Joomla, OpenCart, Bitrix, Laravel. Dans le contexte de la reconstruction, cela désigne les portails de programmes, les pages de collecte, les registres de biens endommagés, les sites d'organisations de la société civile et d'entreprises prestataires — c'est-à-dire des ressources où cohabitent données personnelles, documents et coordonnées de paiement.

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 un site de projet piraté est une question de confiance et pas seulement de technique

Personne ne cherche votre projet 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 passent tout l'internet au crible, adresse après adresse. Peu leur importe qu'il s'agisse du portail d'un programme national ou de la page d'une initiative pour une seule commune : seule compte la version avec laquelle le serveur répond.

Les conséquences habituelles sont connues : un webshell sur le serveur, du spam et des publicités étrangères sur les pages, le domaine sur les listes noires, le courrier qui n'arrive plus. Mais pour les projets de reconstruction, c'est autre chose qui coûte le plus cher. Premièrement, la substitution des coordonnées bancaires pour les contributions — le scénario classique où un site avec dons est piraté non pour l'abîmer, mais pour changer discrètement le numéro de compte. Deuxièmement, la transparence publique : si les documents et les chiffres peuvent être modifiés de l'extérieur, c'est le sens même de l'ouverture sur laquelle repose la confiance des donateurs et des partenaires qui s'effondre.

Troisièmement, les données des personnes. Les demandes, les registres des biens endommagés et les questionnaires des participants aux programmes se trouvent généralement sur le même serveur que le site.

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 votre projet n'a personne de responsable des mises à jour et des accès, l'audit des ressources peut être commandé à l'extérieur — notamment auprès de SmartGT.

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