Failles critiques PHP d’octobre 2026 : risques, versions concernées et plan de correction

1. Ce que PHP a confirmé le 21 octobre

L’avis de sécurité publié le 21 octobre avec les correctifs lève les incertitudes de la veille. PHP confirme deux vulnérabilités critiques permettant une exécution de code à distance sans authentification : CVE-2026-109618, où une interruption pour dépassement de la limite mémoire laisse des données internes de requête partiellement initialisées, que le nettoyage de la requête traite ensuite comme valides, et CVE-2026-109619, où un état interne propre à une requête survit à la libération de sa mémoire et peut être réutilisé par une requête suivante traitée par le même processus. Toutes les installations qui servent des requêtes web sont concernées (PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed) ; PHP juge le risque le plus élevé pour mod_php, avec un exploit démontré où une requête non authentifiée déclenche l’attaque avant toute exécution du code applicatif.

Le CERT-EU avait publié dès le 20 octobre au soir l’avis 2026-018, qui reprenait les identifiants cités par les chercheurs et recommandait de préparer une mise à jour immédiate, voire d’isoler les applications exposées sur Internet si le correctif ne pouvait pas être appliqué rapidement. L’équipe sécurité de Drupal a fait de même le 21 octobre. Cloudflare, associé à l’effort coordonné de mitigation avec la PHP Foundation, OpenAI et Wiz, indique avoir observé du trafic d’attaque visant ses clients alors que la vulnérabilité avait fuité avant la date de publication officielle, et avoir vu les attaquants modifier leurs charges pour tenter de contourner ses règles.

• Confirmé par PHP : deux failles critiques, score CVSS 4.0 de 9.2, exécution de code à distance sans authentification, identifiants CVE-2026-109618 et CVE-2026-109619, correctifs publiés le 21 octobre 2026 à 14h00 UTC dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
• Confirmé par PHP également : il n’existe aucune parade complète, la mise à jour est le seul choix sûr. Quelques réglages réduisent l’exposition à certains chemins d’attaque sans rendre l’installation sûre (voir la section 6).
• Infirmé : score de 10, annonce le 22 octobre, correction par un simple réglage du php.ini. Cloudflare rappelle de son côté que les failles touchent le moteur PHP lui-même : mettre à jour le code du site ou ses extensions ne corrige rien, il faut mettre à jour PHP ou le demander à l’hébergeur.

2. Pourquoi une exécution de code à distance change tout

Une vulnérabilité d’exécution de code à distance permet à un attaquant d’exécuter ses propres commandes sur le serveur à partir d’une simple requête HTTP, sans compte ni mot de passe si la faille est accessible avant toute authentification. L’attaquant obtient alors les droits de l’utilisateur qui fait tourner PHP : lecture de la configuration et des identifiants de base de données, dépôt d’un script de contrôle (webshell), modification des pages servies aux visiteurs.

Pour une boutique en ligne, cela signifie des données clients exfiltrées, des scripts de vol de cartes bancaires injectés dans le tunnel de commande et une base de données modifiable. Pour une application métier connectée à un ERP ou à un CRM, c’est une porte d’entrée vers le système d’information. Le serveur compromis sert aussi de relais pour chiffrer les données (rançongiciel) ou miner des cryptomonnaies.

Les précédents donnent le tempo. La faille PHP-CGI CVE-2024-4577, corrigée le 6 juin 2024, était exploitée dans les 24 heures d’après Akamai, et le rançongiciel TellYouThePass l’utilisait dès le 8 juin selon Imperva. Pour les failles d’octobre 2026, la société Sansec, spécialiste de la sécurité Magento, s’attendait à des attaques massives dans les minutes suivant la publication des correctifs, et Cloudflare confirme avoir observé du trafic d’attaque visant ses clients avant même la divulgation officielle.

3. Quelles versions de PHP sont corrigées

PHP ne corrige que les branches encore supportées. Les versions publiées le 21 octobre 2026 sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; PHP rappelle que la branche 8.2 atteint sa fin de vie le 31 décembre 2026 et ne recevra plus de correctif de sécurité après cette date. PHP 8.1 a atteint sa fin de vie le 31 décembre 2025 ; PHP 8.0, 7.x et 5.x ne reçoivent plus rien depuis longtemps. Vu la gravité des failles, l’équipe sécurité a toutefois publié des rétroportages de source minimaux pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes ou n’ont pas d’éditeur LTS ; les distributions Linux et les éditeurs LTS ont reçu les correctifs en avance, et certains fournissent des paquets rétroportés pour ces anciennes branches.

Le parc concerné est considérable. D’après W3Techs, PHP fait tourner environ 69 % des sites dont le langage serveur est connu, et près d’un site PHP sur deux utilise encore une branche en fin de vie (PHP 5, 7, 8.0 ou 8.1). Côté WordPress, les statistiques de wordpress.org montrent qu’environ un site sur trois tourne sur une version de PHP qui ne sera pas corrigée.

• PHP 8.5 et 8.4 : mettez à jour vers 8.5.12 ou 8.4.27, branches en support actif.
• PHP 8.3 : mettez à jour vers 8.3.36, support de sécurité jusqu’au 31 décembre 2027.
• PHP 8.2 : mettez à jour vers 8.2.35, mais fin du support le 31 décembre 2026 : prévoyez la migration vers 8.3 ou 8.4 dès maintenant.
• PHP 8.1 et antérieures : pas de version officielle. Rétroportages de source minimaux fournis par PHP pour 7.4, 8.0 et 8.1, paquets rétroportés chez certaines distributions et certains hébergeurs, sinon migration et isolation.

4. Magento, PrestaShop, WordPress, Symfony, Laravel… : où en est votre application

La version de PHP que vous pouvez installer dépend de la version de votre application. C’est là que le blocage apparaît : une plateforme ancienne impose une version de PHP qui n’est plus corrigée, et mettre à jour PHP sans mettre à jour l’application casse le site. Les matrices officielles de compatibilité, au 21 octobre 2026, donnent les marges de manœuvre suivantes. Les mêmes questions se posent pour toute autre application PHP, outil interne, API, connecteur ERP ou site sur mesure : la version minimale est fixée par le framework et les bibliothèques utilisés.

Deux situations demandent une décision rapide. Magento 2.4.4 et 2.4.5, limités à PHP 8.1, ainsi que PrestaShop 8, dont la version recommandée est PHP 8.1, n’ont pas de chemin de correction sans montée de version de l’application. Les sites WordPress encore sur PHP 7.4, fréquents chez les hébergeurs mutualisés, sont dans le même cas.

• Magento et Adobe Commerce : 2.4.6 accepte PHP 8.1 ou 8.2 ; 2.4.7 PHP 8.2 ou 8.3 ; 2.4.8 PHP 8.3 ou 8.4 ; 2.4.9 PHP 8.5. En deçà de 2.4.6, PHP 8.1 au mieux.
• WordPress 6.x : PHP 8.3 recommandé, fonctionne de 7.4 à 8.5 ; vérifiez les extensions et le thème avant de changer de branche.
• PrestaShop : la version 8 plafonne officiellement à PHP 8.1 ; PrestaShop 9.0 accepte PHP 8.1 à 8.4 et 9.1 jusqu’à 8.5.
• Symfony : 6.4 LTS requiert PHP 8.1 minimum, 7.4 LTS PHP 8.2, 8.x PHP 8.4. Laravel 12 et 13 tournent sur PHP 8.2 à 8.5 ; Laravel 11 n’est plus maintenu depuis mars 2026.
• Drupal : 10.4 à 10.6 acceptent PHP 8.1 à 8.4, Drupal 11 demande PHP 8.3 minimum. Dolibarr 23 : PHP 7.2 à 8.4.

5. Le plan d’action en cinq étapes

L’ordre compte : inventorier avant de patcher, patcher avant de surveiller, mais sans attendre la fin de l’inventaire pour corriger ce qui est déjà identifié. Comptez en heures, pas en jours, en commençant par les serveurs exposés sur Internet.

Attention aux fausses certitudes lors de la vérification : la commande php -v en ligne de commande peut afficher une autre version que celle du serveur web (PHP-FPM, module Apache, sélecteur de version par répertoire chez certains hébergeurs). Vérifiez la version réellement servie, puis redémarrez PHP-FPM ou le serveur web après la mise à jour pour qu’elle prenne effet.

• Inventorier : listez chaque serveur, conteneur et hébergement mutualisé qui exécute PHP, avec la version servie et l’application installée. N’oubliez pas les environnements de recette, les anciens sites laissés en ligne et les outils internes.
• Mettre à jour : installez PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (dépôts de votre distribution, dépôts Sury pour Debian et Ubuntu, images Docker officielles, sources officielles). PHP prévient que le dépôt Remi, maintenu par des bénévoles, n’aura pas les mises à jour le jour même et recommande de passer aux paquets de la distribution ou de compiler depuis les sources. Reconstruisez les images de conteneurs sans vous fier à un tag déjà présent en cache.
• Vérifier : contrôlez la version après redémarrage, sur chaque serveur et chaque répertoire, puis testez les parcours critiques (connexion, panier, paiement, exports ERP).
• Isoler ce qui ne peut pas être corrigé : restreindre l’accès par adresse IP ou VPN, placer un pare-feu applicatif (WAF) devant le site (Cloudflare active ses règles par défaut sur tous ses plans, voir la section 6), ou couper temporairement un service exposé qui ne peut pas être mis à jour.
• Surveiller : fichiers récemment créés ou modifiés dans les répertoires web, tâches planifiées inconnues, connexions sortantes inhabituelles, requêtes POST anormales dans les journaux, comptes administrateurs apparus sans raison. Conservez les journaux pour l’analyse.

6. Si la mise à jour est impossible à court terme

PHP est formel : il n’existe aucune parade complète, seule la mise à jour est sûre. L’avis liste toutefois des mesures qui réduisent l’exposition à certains chemins d’attaque sans rendre l’installation sûre. Pour CVE-2026-109618 : fixer memory_limit à -1 d’une façon que les applications ne peuvent pas surcharger (php_admin_value dans le pool FPM ou la configuration Apache) et abaisser post_max_size (8M si l’application n’envoie pas de fichiers, 32M sinon, avec upload_max_filesize en dessous). Pour CVE-2026-109619 : désactiver session.upload_progress.enabled dans le php.ini ou la configuration du pool FPM, puis redémarrer tous les processus, et sur PHP 8.5 désactiver fatal_error_backtraces. Masquer les erreurs avec error_reporting, display_errors ou @ n’aide en rien.

Deuxième couche : un pare-feu applicatif. Cloudflare a déployé des protections contre ces failles, baptisées php2shell, environ neuf heures avant la divulgation publique. Depuis le 21 octobre à 03h02 UTC, elles sont actives par défaut pour tous les clients de son WAF, offre gratuite comprise : dans le Cloudflare Managed Free Ruleset pour l’offre gratuite, et dans le Cloudflare Managed Ruleset pour les plans Professional, Business et Enterprise, où il faut vérifier que ce jeu de règles est bien déployé en mode blocage. Cloudflare insiste : la protection s’ajoute au correctif et ne le remplace pas.

Pour une application bloquée sur PHP 8.1 ou antérieur, trois voies restent possibles : obtenir un paquet rétroporté de l’hébergeur ou de la distribution (PHP a transmis les correctifs en avance aux éditeurs LTS et publie des rétroportages de source minimaux pour 7.4, 8.0 et 8.1), isoler l’application derrière une authentification ou un VPN le temps de planifier la montée de version, ou accélérer cette montée de version. Un audit court permet de chiffrer l’effort et de décider.

7. Ce que le RGPD et NIS2 attendent de vous

L’article 32 du RGPD impose des mesures techniques appropriées au risque, et la CNIL considère l’application sans délai des correctifs critiques comme un minimum. Sa sanction de 1,7 million d’euros contre Nexpublica, en décembre 2025, visait précisément des vulnérabilités connues de l’entreprise et corrigées seulement après les violations de données. Un site qui traite des données de clients ou de salariés est donc tenu de corriger une faille de ce niveau rapidement, et de pouvoir le prouver.

La directive NIS2 ajoute, pour les entités concernées, une obligation explicite de gestion des vulnérabilités. Sa transposition française n’est pas encore adoptée au 21 octobre 2026, mais les entreprises qui y seront soumises ont intérêt à documenter dès aujourd’hui leur inventaire, les dates de correction et les mesures d’isolation prises.

8. Comment AXELITES peut vous aider

Nous maintenons et hébergeons des boutiques Magento, des sites WordPress et PrestaShop et des applications Symfony, Laravel ou PHP sur mesure pour des PME et des ETI. Face à cette alerte, nous proposons trois interventions : un audit d’exposition rapide (inventaire des serveurs, versions de PHP réellement servies, applications bloquées sur une branche en fin de vie), l’application des correctifs avec vérification et redémarrage des services, et la mise en place d’une surveillance des signes de compromission.

Pour une boutique Magento, l’audit gratuit en cinq jours ouvrés couvre déjà la version de PHP, les correctifs de sécurité Adobe manquants et les modules à risque. Pour les applications qui ne peuvent pas être corrigées sans montée de version, notre tierce maintenance applicative prend en charge la planification et la réalisation de cette migration.

Sources et documentation

• PHP : avis de publication de sécurité critique (20 octobre 2026)
• PHP : avis de sécurité du 21 octobre 2026, versions corrigées et mesures de réduction d’exposition
• Cloudflare : protections WAF déployées contre php2shell (21 octobre 2026)
• PHP : versions supportées
• CERT-EU, avis 2026-018 : vulnérabilités critiques dans PHP
• Drupal, PSA-2026-10-20 : publication de sécurité critique de PHP
• Adobe Commerce : configuration système requise
• W3Techs : usage de PHP par version
• Akamai : exploitation de CVE-2024-4577 un jour après sa divulgation
• CNIL : sanction SAN-2025-015 (Nexpublica)