Failles critiques PHP d’octobre 2026 : ce qu’il faut faire maintenant

Deux failles critiques dans le moteur PHP, CVE-2026-109618 et CVE-2026-109619, permettent dans certaines conditions d’exécuter du code à distance sur un serveur, sans authentification. Le projet PHP a publié les correctifs le 21 octobre 2026 et le CERT-FR a émis une alerte le même jour. Toutes les branches sont touchées, de PHP 5 à PHP 8.5. Ce guide explique ce qui se passe, qui est concerné et comment corriger, y compris quand la mise à jour ne peut pas se faire tout de suite.

Il s’adresse aux dirigeants, aux DSI et aux responsables d’application dont le site, la boutique ou l’application métier tourne sur PHP : WordPress, Drupal, PrestaShop, Magento, Symfony, Laravel ou un développement sur mesure. Le point de départ est simple : la faille est dans PHP lui-même, pas dans votre application. Mettre à jour WordPress ou un module ne suffit pas, il faut mettre à jour PHP sur le serveur.

Ce qui s’est passé

Le 20 octobre 2026, l’équipe de sécurité de PHP a annoncé deux failles critiques et la publication de leurs correctifs pour le lendemain, 16 h, heure de Paris. Les identifiants des failles circulaient déjà sur des forums : selon la PHP Foundation, la publication a été avancée du 22 au 21 octobre à cause de cette fuite.

Le 21 octobre, PHP a publié quatre versions corrigées et deux avis de sécurité détaillés. Le même jour, le CERT-FR a publié l’alerte CERTFR-2026-ALE-014, et l’agence américaine de cybersécurité (CISA) une alerte qui demande d’appliquer les correctifs immédiatement, en commençant par les serveurs exposés à Internet.

À la publication de son alerte, la CISA ne signalait pas d’exploitation active. Mais le fonctionnement des failles est désormais décrit publiquement, dans les avis de PHP eux-mêmes : la mise à jour se traite comme une urgence, pas comme une maintenance à planifier.

Les deux failles, en clair

Les deux failles touchent la façon dont PHP prépare puis nettoie chaque requête web. Un attaquant peut les déclencher avec des requêtes HTTP construites pour cela, avant même que le code de votre application s’exécute.

• CVE-2026-109618 : une corruption de mémoire après un manque de mémoire. Si une requête atteint la limite de mémoire de PHP au mauvais moment, des données internes à moitié initialisées sont ensuite traitées comme valides. Sur Apache avec mod_php, PHP indique que l’exécution de code a été démontrée par HTTP avec les réglages par défaut.
• CVE-2026-109619 : un état périmé réutilisé. Une erreur fatale au mauvais moment peut laisser un état interne qui pointe vers la mémoire d’une requête précédente ; la requête suivante traitée par le même processus le réutilise. L’exécution de code a été confirmée sur mod_php, et le chemin qui passe par la progression d’envoi de fichiers (session upload progress) a aussi été validé sur PHP-FPM.

PHP note les deux failles 9,2 sur 10 (CVSS 4.0), soit le niveau critique. Aucune authentification n’est nécessaire. L’attaque demande des conditions précises et parfois plusieurs essais, ce qui ne la rend pas moins sérieuse : un serveur exposé reçoit des requêtes de n’importe qui, en continu.

Qui est concerné

Selon PHP, toutes les installations qui servent des requêtes web sont concernées, quel que soit le mode d’exécution : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le risque est le plus élevé avec mod_php.

Versions d’après l’alerte du CERT-FR et les avis de PHP ; calendrier des branches d’après php.net.

Sont donc concernés tous les sites et applications qui reposent sur PHP : CMS (WordPress, Drupal, Joomla), e-commerce (PrestaShop, Magento), frameworks (Symfony, Laravel) et applications sur mesure. Sans oublier les environnements de recette ou de préproduction accessibles depuis Internet, les anciens sites qu’on croyait arrêtés, les outils internes (extranet, webmail, back-office) et les logiciels qui embarquent PHP sans le dire, que la CISA cite expressément.

Corriger : mettre à jour PHP, puis redémarrer

La seule correction complète est la mise à jour de PHP. Les avis de PHP le répètent : les mesures d’attente réduisent l’exposition, elles ne rendent pas un serveur sûr.

• Faire l’inventaire. Listez chaque serveur, conteneur et hébergement qui exécute PHP, avec sa version et son mode d’exécution (PHP-FPM, mod_php…). La CISA place cette étape en premier : un serveur oublié reste vulnérable.
• Traiter d’abord ce qui est exposé à Internet. Sites publics, API, back-offices accessibles en ligne, puis le reste.
• Installer la version corrigée par le bon canal. Paquets de votre distribution Linux ou du dépôt que vous utilisez, image Docker reconstruite sur une image de base corrigée, ou mise à jour par votre hébergeur. PHP indique que les distributions et les éditeurs de support long ont reçu les correctifs à l’avance ; certains dépôts tiers ne publient pas le jour même.
• Redémarrer tous les processus PHP. PHP-FPM, Apache, et les processus de longue durée (FrankenPHP en mode worker, consommateurs de files de messages, Laravel Octane…). Tant qu’un processus tourne avec l’ancienne version chargée en mémoire, le serveur reste vulnérable.
• Vérifier la version réellement servie. Pas seulement celle de la ligne de commande : PHP-FPM et le module Apache peuvent tourner dans une autre version que la commande php.

Sur un serveur Debian ou Ubuntu avec PHP-FPM, la séquence ressemble à ceci (adaptez le numéro de branche à votre installation) :

# Versions installées : ligne de commande et PHP-FPM
php -v
php-fpm8.3 -v

# Mettre à jour les paquets PHP depuis le dépôt configuré
sudo apt update
sudo apt install --only-upgrade 'php8.3*'

# Redémarrer les processus PHP
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # si PHP tourne en mod_php

Sur un hébergement mutualisé ou managé, c’est l’hébergeur qui met PHP à jour. Vérifiez dans votre espace client la version utilisée, demandez-lui confirmation que les correctifs du 21 octobre sont appliqués, et passez à une branche maintenue si votre site tourne encore en 8.1 ou avant. Si un prestataire assure la maintenance applicative de vos sites, c’est à lui de mener ces étapes : demandez-lui l’état de chaque serveur.

Si vous ne pouvez pas mettre à jour tout de suite

Le CERT-FR et PHP donnent des mesures d’attente. Elles ne remplacent pas la mise à jour, et chacune ne couvre qu’une partie du risque.

• Désactiver la progression d’envoi de fichiers. session.upload_progress.enabled = Off dans php.ini, ou php_admin_flag[session.upload_progress.enabled] = off dans le pool PHP-FPM, puis redémarrer tous les processus PHP. Selon le CERT-FR, cette mesure ne réduit la surface d’attaque que pour l’une des deux failles.
• Sur PHP 8.5 : fatal_error_backtraces = 0, puis redémarrage. PHP indique que ce réglage coupe le chemin d’exploitation confirmé de CVE-2026-109619 sur cette version.
• Filtrer les requêtes multipart. Le CERT-FR recommande de bloquer, par exemple avec un pare-feu applicatif (WAF), les requêtes dont l’en-tête Content-Type vaut multipart, ou à défaut de les surveiller. Attention : ce blocage casse les formulaires d’envoi de fichiers.
• Limiter la taille et la complexité des requêtes au niveau du serveur web ou du proxy (taille, nombre de champs, de parties, d’en-têtes), comme le détaille l’avis de PHP sur CVE-2026-109618.

; php.ini (configuration chargée au démarrage de PHP)
session.upload_progress.enabled = Off

; Pool PHP-FPM : réglage que l'application ne peut pas modifier
php_admin_flag[session.upload_progress.enabled] = off

PHP 8.1 et versions antérieures

Les branches 5.x à 8.1 ne reçoivent plus de mises à jour du projet PHP, et aucune version officielle ne corrige ces failles. PHP publie des correctifs minimaux pour 7.4, 8.0 et 8.1, à compiler soi-même, et certaines distributions ou éditeurs de support long fournissent des paquets corrigés.

Le CERT-FR recommande d’isoler les serveurs concernés, puis de migrer vers une version maintenue. La CISA va plus loin : mettre hors ligne les systèmes PHP qui ne peuvent pas être corrigés, jusqu’à leur correction. Pour une application ancienne, c’est le moment de planifier la montée de version : notre guide sur la fin du support de PHP 8.2 détaille la méthode, et rappelle que la branche 8.2 elle-même ne sera plus corrigée après le 31 décembre 2026.

Après la mise à jour : vérifier et surveiller

• Chaque serveur de l’inventaire sert une version corrigée, vérifiée depuis le serveur web et pas seulement en ligne de commande.
• Tous les processus PHP ont été redémarrés.
• Les environnements de recette et de préproduction, et les anciens sites, ont été corrigés ou coupés d’Internet.
• Les journaux sont surveillés : la CISA recommande de guetter les processus PHP qui lancent un shell ou téléchargent des outils.
• La progression d’envoi de fichiers reste désactivée si vous ne vous en servez pas : PHP le recommande même après la mise à jour.
• La date de la mise à jour et les versions installées sont notées, pour vos clients ou pour un audit.

Si vous constatez un comportement anormal, ou si un serveur exposé n’a pas pu être corrigé à temps, traitez-le comme un incident : isolez-le, conservez les journaux et faites-vous accompagner, par exemple par un prestataire trouvé via Cybermalveillance.gouv.fr. Si des données personnelles ont pu être exposées, l’article 33 du RGPD impose de notifier la CNIL, si possible dans les 72 heures après en avoir pris connaissance, sauf si la violation n’entraîne pas de risque pour les personnes.

Questions fréquentes

Un correctif à appliquer partout, pas seulement en production

Ces deux failles ne demandent pas de modifier votre application : elles demandent de savoir où tourne PHP, de le mettre à jour partout et de vérifier que la nouvelle version est bien en service. Quelques gestes par serveur, à condition de connaître tous ses serveurs.

Si vous manquez de visibilité sur vos serveurs, ou si vos applications tournent encore sur une version de PHP en fin de vie, l’équipe nearshore d’iones assure la maintenance applicative et la sécurité des infrastructures web : inventaire, mises à jour, migration de version. Écrivez-nous pour faire le point sur votre parc.