Deux failles dans PHP notées 9,2 : ce que cela signifie pour une entreprise et ce que coûte l'attente

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 à un attaquant d'exécuter son propre code sur le serveur — sans identifiant, sans mot de passe et sans la moindre action des salariés de l'entreprise.

Pour une entreprise, ce n'est pas une nouvelle technique abstraite. PHP est le langage dans lequel est écrite la majorité des sites : WordPress, Joomla, OpenCart, Bitrix, Laravel, et encore des centaines de scripts maison qui relient le site au CRM, à la messagerie ou à 1C. Si votre entreprise a un site, une boutique en ligne ou un espace client, la seule question est de savoir si vous avez eu le temps de mettre à jour ou non.

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.

Ce que cela coûte à une entreprise

Personne ne cherche votre entreprise en particulier. Dès que les exemples d'exploitation deviennent publics — et ils le sont déjà —, des scanners automatiques démarrent en quelques heures et passent tout l'internet au crible. Peu leur importe qu'il s'agisse du site d'une usine ou de la page d'un salon de coiffure : seul compte le fait que le serveur réponde avec une version vulnérable.

Ensuite commence ce qui se compte en argent. Un webshell est déposé sur le serveur, le site distribue du spam ou des publicités étrangères, le domaine se retrouve sur des listes noires — et les courriels qui en partent n'arrivent plus chez les clients et les partenaires. Pendant ce temps, la boutique ne vend pas, les commerciaux ne reçoivent plus de demandes et les moteurs de recherche ont le temps de marquer le site comme dangereux. La restauration n'est pas une nuit de travail : c'est un nettoyage, une réémission des clés, un changement des mots de passe et la sortie du domaine des listes noires, ce qui prend des semaines.

Les données constituent un risque à part. Si le serveur héberge une base de clients ou un historique de commandes, leur fuite signifie aussi des questions posées à l'entreprise par les clients et par le régulateur, et pas seulement un incident technique.

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 entreprise n'a personne qui s'occupe des versions et des mises à jour sur le serveur, l'audit peut être confié à l'extérieur — par exemple à SmartGT: ils vérifieront les ressources et diront clairement s'il y a une menace et quoi en faire.

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