Failles PHP critiques du 21 octobre 2026 : 2 vulnérabilités à 9,2, toutes les branches concernées
Cet article dit ce que la publication contient, quelles versions installer, qui est responsable de la mise à jour selon le type d'hébergement, et dans quel ordre agir. Il s'adresse aux responsables de sites internet sous Drupal, WordPress, Symfony, Sylius ou Magento, aux DSI et aux prestataires qui maintiennent ces sites web pour leurs clients, en France et au Luxembourg.
- Annoncées la veille par l'équipe sécurité de PHP et relayées par la Drupal Security Team : 2 failles critiques, 9,2 en CVSS v4.0.
- Versions corrigées : 8.5.12, 8.4.27, 8.3.36, 8.2.35. Le langage lui-même est touché, pas un CMS en particulier.
- La mise à jour relève de l'hébergement, pas du prestataire Drupal ou WordPress : hébergeur mutualisé, infogérant ou image Docker.
- PHP 8.1 et antérieurs n'ont pas de version corrigée, seulement un rétroportage en code source. PHP 8.2 en reçoit une, mais s'arrête le 31 décembre 2026.
- Exploitable sans authentification, avant le code de l'application. Les réglages d'attente réduisent l'exposition sans rendre l'installation sûre : la version corrigée se déploie le jour même.
Une publication annoncée la veille
PHP publie ses correctifs de sécurité sans préavis la plupart du temps. Une annonce préalable signale une publication hors norme. C'est ce qui s'est passé cette fois, avec un relais inhabituel du côté de Drupal.
Mardi 20 octobre, 22h32 : l'annonce de PHP
L'équipe sécurité de PHP publie sur php.net une annonce préalable : une publication de sécurité le mercredi 21 octobre 2026 à 14h UTC, soit 16h à Paris et à Luxembourg, pour « deux vulnérabilités critiques, toutes deux notées 9,2 en CVSS v4.0 ». Elle demande à tous les utilisateurs de se préparer pour mettre à jour dès la disponibilité, et se réserve le droit de publier plus tôt si les détails fuitent ou si une exploitation active est constatée. Les versions touchées et corrigées sont gardées pour la publication.
Mardi 20 octobre : le relais de la Drupal Security Team
PSA-2026-10-20 reprend l'annonce et demande à tous les propriétaires de sites web Drupal de réserver du temps pour mettre PHP à jour dès la sortie. L'annonce rappelle la règle : les propriétaires de sites web sont responsables de la sécurité de leur plateforme d'hébergement, PHP compris, et l'équipe sécurité de Drupal ne corrige que le code hébergé sur drupal.org. C'est la 5e annonce de ce type sur du code tiers, après celles de 2011, 2019, 2024 et septembre 2025.
Mercredi 21 octobre, en avance : les versions
La publication est arrivée avant l'horaire annoncé, en milieu d'après-midi. L'avis de sécurité et les 4 versions sont sortis ensemble : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Chaque annonce de version répète la même phrase : « il n'existe aucune mesure d'atténuation complète, la mise à jour est le seul choix sûr ». L'avis précise que les distributions Linux et les éditeurs de versions à support long ont reçu les correctifs à l'avance, et que le dépôt communautaire rpms.remirepo.net n'aura pas de paquets le jour même. L'annonce de la 8.2.35 ajoute un rappel : PHP 8.2 atteint sa fin de vie le 31 décembre 2026 et ne recevra plus rien après.
Mercredi 21 octobre, la journée : CERT-FR, NIST, et un surnom
L'annonce préalable réservait le droit de publier plus tôt « si les détails de l'une ou l'autre vulnérabilité devenaient publics ». Des éléments techniques circulaient dès la veille chez des chercheurs en sécurité, et la publication est arrivée avec près d'une heure d'avance. Le NIST a mis en ligne les fiches CVE-2026-109618 et CVE-2026-109619 à 14h17 UTC, notées 9,8 en CVSS v3.1 et 9,2 en CVSS v4.0. Le CERT-FR a publié l'avis CERTFR-2026-AVI-1359 puis l'alerte CERTFR-2026-ALE-014, qui liste comme affectées toutes les versions 5 à 8.1, plus 8.2 à 8.5 avant correctif, et recommande d'isoler les équipements affectés avant de migrer. Dans la presse et chez les chercheurs, les 2 failles ont reçu le surnom de « PHP2Shell ». Plusieurs médias généralistes ont rapporté des sites web mis en maintenance par précaution dans l'après-midi.
Les 2 failles
L'avis nomme les 2 vulnérabilités, décrit leur mécanisme en quelques lignes et renvoie aux avis détaillés sur GitHub. Toutes les installations qui servent des requêtes web sont exposées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le risque est jugé le plus élevé avec mod_php, avec un exploit démontré où une requête sans authentification déclenche l'attaque avant même que le code de l'application s'exécute.
CVE-2026-109618 : exécution de code par corruption en manque de mémoire
Quand PHP manque de mémoire au milieu du traitement d'une requête, l'interruption peut survenir alors que les données internes de la requête ne sont qu'en partie initialisées. Le nettoyage de fin de requête traite alors ces données invalides comme valides. L'avis détaillé décrit comment une requête provoque ce manque de mémoire en restant sous les limites apparentes : un envoi multipart sans longueur de contenu exploitable, un nombre illimité d'en-têtes par partie, des champs imbriqués qui multiplient le travail. Avec mod_php, la procédure de fin de requête s'exécute même quand le démarrage a échoué, donc avant toute ligne de l'application. Avis détaillé : GHSA-w8hw-w9fx-j79w, sévérité critique, versions touchées en dessous de 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
CVE-2026-109619 : exécution de code par état global périmé
Un état interne propre à une requête peut survivre après la libération de la mémoire qui le portait. La requête suivante traitée par le même processus de travail peut utiliser cet état périmé avant que l'initialisation normale le remette à zéro. L'avis cite les chemins confirmés : le suivi de progression des téléversements de session, et sur PHP 8.5 les traces d'erreurs fatales. Avis détaillé : GHSA-6wmf-4rv5-p3rp, sévérité critique, mêmes versions touchées.
Les mesures d'attente, partielles par construction
L'avis donne des réglages qui réduisent l'exposition « à des chemins d'attaque précis » sans rendre l'installation sûre. Pour la première faille : memory_limit=-1 imposé au niveau du pool FPM ou de la configuration Apache, de façon qu'aucune application ne puisse remettre une limite, et un post_max_size bas (8M sans téléversement, 32M avec), avec des limites de taille de requête au niveau du serveur web. Pour la seconde : session.upload_progress.enabled=0 puis redémarrage de tous les processus de travail, réglé dans php.ini ou la configuration du pool, jamais par ini_set(), et sur PHP 8.5 fatal_error_backtraces=0. Masquer les erreurs avec display_errors ou @ ne protège de rien. Le CERT-FR ajoute le blocage des requêtes multipart au niveau du pare-feu applicatif, ce qui coupe les téléversements de fichiers le temps de la mise à jour. Ces réglages se posent en attendant le paquet, pas à sa place.
Pour PHP 7.4, 8.0 et 8.1, qui ne sont plus maintenus, l'équipe sécurité a publié des rétroportages minimaux du correctif sous forme de code source, sur des branches dédiées du dépôt GitHub, pour ceux qui compilent eux-mêmes ou n'ont pas d'éditeur de support long. Ce n'est pas une version officielle : c'est un dépannage pour un site web qui ne peut pas monter de branche dans la journée, et qui doit le faire ensuite.
Quelle version installer selon votre branche
Les 4 branches maintenues reçoivent un correctif. Les dates de fin de support viennent du calendrier officiel de PHP, relu le 21 octobre 2026.
| Votre branche | Version corrigée | Fin de support | Chemin |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | Sécurité jusqu'au 31 décembre 2029 | Mise à jour de correctif, sans recette |
| PHP 8.4 | 8.4.27 | Correctifs jusqu'au 31 décembre 2026, sécurité jusqu'au 31 décembre 2028 | Mise à jour de correctif, sans recette |
| PHP 8.3 | 8.3.36 | Sécurité jusqu'au 31 décembre 2027 | Mise à jour de correctif, sans recette |
| PHP 8.2 | 8.2.35 | Sécurité jusqu'au 31 décembre 2026 | Mise à jour de correctif, puis montée en 8.3 ou 8.4 avant la fin de l'année |
| PHP 8.1 et antérieurs | Aucune version. Rétroportage minimal en code source pour 7.4, 8.0 et 8.1 | Terminé, 8.1 depuis le 31 décembre 2025 | Montée de branche avec recette complète, le rétroportage ne sert qu'à tenir quelques jours |
| PHP 8.6.0 RC | RC4 prévue le 22 octobre | Version finale le 19 novembre 2026 | Environnements de test uniquement |
Le cas que nous rencontrons le plus souvent en reprise de site web : un PHP 8.1, parfois 8.0 ou 7.4, maintenu en vie par un hébergeur qui ne force pas la montée de version. Ces sites web n'ont reçu aucun correctif de sécurité PHP depuis des mois, et n'en recevront pas pour les 2 failles du 21 octobre. La montée de branche demande une recette, parce que chaque version majeure de PHP retire des fonctions et change des comportements. C'est le sujet de notre guide de la maintenance d'un site internet.
Qui met à jour PHP : ça dépend de l'hébergement
C'est la question qui bloque le plus souvent. Le prestataire qui maintient Drupal ou WordPress met à jour le CMS, ses modules et ses thèmes. PHP est en dessous, sur le serveur, et appartient à celui qui administre ce serveur. Quand personne n'a la réponse écrite dans un contrat, personne ne fait la mise à jour.
Hébergement mutualisé
L'hébergeur déploie les paquets corrigés, en général dans les heures qui suivent, parfois en plusieurs jours. La version se choisit dans le panneau d'administration ou dans un fichier de configuration à la racine, et la version réellement exécutée peut différer de celle affichée. À faire : vérifier la version exécutée, et si le correctif n'est pas disponible, ouvrir une demande au support en citant le numéro de version attendu. Un hébergeur qui n'a pas déployé le correctif sous 48 heures sur une faille à 9,2 est une information à retenir pour le prochain renouvellement.
Serveur dédié, VPS, infogérance
Les paquets viennent de la distribution (Debian, Ubuntu, Red Hat) ou d'un dépôt tiers, et leur délai de publication est celui du mainteneur du paquet, pas celui de php.net. Un serveur Debian stable attend le rétroportage du correctif dans sa version, ce qui peut prendre de quelques heures à plusieurs jours. À faire : demander à l'infogérant la date de déploiement prévue, et vérifier que le numéro de version du paquet inclut bien le correctif, car une distribution rétroporte parfois la correction sans changer le numéro de version de PHP.
Conteneurs et plateformes
Une image Docker fige la version de PHP au moment de sa construction. Il faut reconstruire l'image sur l'image de base corrigée, puis redéployer. Les plateformes gérées (Platform.sh, Acquia, Pantheon, Clever Cloud, Scalingo et les autres) mettent à jour leur image de base de leur côté, avec un délai qu'elles annoncent sur leur page d'état. À faire : lire la page d'état de la plateforme, puis redéployer une fois l'image disponible.
Dans les 3 cas, la vérification est la même : la version de PHP vue depuis le site web lui-même, pas depuis le panneau. Sur Drupal, le rapport d'état de l'administration l'affiche. Sur WordPress, l'écran « Santé du site » de l'administration. Sur Symfony, php -v depuis le conteneur ou le serveur qui exécute l'application, pas depuis un poste de travail.
Que faire le 21 octobre, dans l'ordre
Le plan compte 4 étapes. La première se fait en 5 minutes par site web, et répond à la seule question qui compte : suis-je exposé.
-
1. Relever la version exécutée, site web par site web
Depuis le CMS, pas depuis le panneau de l'hébergeur. Noter le numéro complet, par exemple 8.3.35, et la date du relevé. Un parc de plusieurs sites web se relève en une liste : site web, hébergement, version, responsable de la mise à jour. Cette liste est le livrable de l'étape.
-
2. Déclencher la mise à jour chez le bon responsable
Mutualisé : changer la version dans le panneau dès que le correctif y apparaît, ou ouvrir une demande. Serveur : mise à jour des paquets par l'infogérant. Conteneur : reconstruction de l'image. Une version de correctif ne change ni la syntaxe ni les fonctions, la préproduction suffit, le jour même.
-
3. Vérifier après déploiement
Le numéro de version depuis le CMS, puis les pages qui sollicitent le plus PHP : formulaire de contact, recherche, connexion, paiement pour une boutique. Sur un serveur de distribution, vérifier dans le journal des modifications du paquet que le correctif est bien inclus, le numéro de version PHP pouvant rester inchangé.
-
4. Planifier les montées de branche
Les sites web en 8.1 ou plus ancien n'ont pas d'autre protection que la montée de branche. Ceux en 8.2 ont jusqu'au 31 décembre 2026. Cette publication est l'occasion de dater ces chantiers, avec une recette complète à chaque fois, et de les inscrire au contrat de maintenance.
Ce que cette publication dit de la maintenance d'un site web
C'est la 2e publication de sécurité PHP en moins d'un mois : le 24 septembre 2026, les versions 8.5.11, 8.4.26, 8.3.35 et 8.2.34 corrigeaient déjà une série de vulnérabilités. Et c'est la 2e alerte critique en une semaine pour un site web Drupal, après SA-CORE-2026-014 le 14 octobre.
PHP est une des couches du site web, avec son propre responsable
Un site web tient sur PHP, un serveur web, une base de données, un système d'exploitation et souvent un cache. Chaque couche a son calendrier de correctifs et son responsable. Un contrat de maintenance qui ne dit pas qui met à jour PHP laisse un trou que personne ne voit avant une faille à 9,2.
La montée de version de PHP se planifie à l'avance
PHP 8.2 s'arrête le 31 décembre 2026, PHP 8.4 passe en sécurité seule le même jour, PHP 8.6 sort le 19 novembre. Drupal 12, prévu la semaine du 7 décembre, exige PHP 8.5. Un site web qui n'a pas de calendrier de montée de version subit ces dates au lieu de les choisir.
L'annonce préalable laisse le temps d'agir
Une publication annoncée la veille au soir permet de relever les versions, de prévenir l'hébergeur et de bloquer une fin d'après-midi. Sans veille, la même publication se découvre une semaine plus tard, dans un journal d'attaque. Sur les sites internet que nous maintenons, la procédure est la même qu'à chaque avis : lecture de l'annonce, relevé des versions sur le parc, demande à l'hébergeur ou reconstruction de l'image, déploiement le jour de la publication, contrôle, et une ligne dans le journal de maintenance avec l'heure.
Obligations en France et au Luxembourg
Un correctif appliqué à temps ne déclenche aucune obligation. Une exploitation constatée qui expose des données personnelles avec un risque pour les personnes, oui. Une faille critique dans le langage qui exécute le site web peut donner accès à toute l'application et à sa base de données.
- France : en cas de violation de données personnelles, notification à la CNIL sous 72 heures, article 33 du RGPD. La transposition de NIS2 n'est toujours pas promulguée au 21 octobre 2026, l'ANSSI a ouvert un pré-enregistrement.
- Luxembourg : même délai de 72 heures auprès de la CNPD. Pour les entités soumises à NIS2, transposée par la loi du 5 mai 2026, alerte précoce sous 24 heures et notification sous 72 heures auprès de l'ILR.
- Dans les 2 pays : la date de publication des correctifs, 21 octobre 2026 à 14h UTC, et la date de leur application sont les 2 éléments qu'un régulateur demandera. Les noter au moment de l'intervention.
Questions fréquentes sur les failles PHP du 21 octobre
Sources officielles consultées
Cet article s'appuie sur les annonces de l'équipe sécurité de PHP, sur le calendrier officiel des versions et sur l'annonce de la Drupal Security Team, relus le 21 octobre 2026 à 19h30. Les liens sont externes et peuvent évoluer.
PHP
- php.net, actualités 2026, l'annonce préalable du 20 octobre et les annonces de versions
- php.net, avis de sécurité du 21 octobre 2026, les 2 failles, les versions corrigées, les mesures d'attente
- GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp, les avis détaillés des 2 vulnérabilités
- php.net, versions supportées, dates de fin de support des branches 8.2 à 8.5
- php.net/security, politique de sécurité de PHP
Drupal Security Team et régulateurs
- drupal.org/psa-2026-10-20, l'annonce du 20 octobre 2026 sur la mise à jour critique de PHP
- CERT-FR, alerte CERTFR-2026-ALE-014 et avis CERTFR-2026-AVI-1359, 21 octobre 2026, versions affectées, isolement et mesures d'attente
- NVD, CVE-2026-109618 et CVE-2026-109619, fiches du NIST publiées le 21 octobre 2026 à 14h17 UTC, scores CVSS v3.1 et v4.0
- CNIL et CNPD, notification de violation de données personnelles
- ANSSI et ILR, NIS2 en France et au Luxembourg
Cette ressource est mise à jour au fil des informations officielles. Si un point factuel vous semble erroné ou incomplet, écrivez-nous à contact@adevweb.com.
Pour aller plus loin
PSA Drupal SA-CORE-2026-014 : faille critique
L'alerte de la semaine précédente, le 14 octobre 2026 : exécution de code dans Field UI, notée 19 sur 25.
Maintenance d'un site internet : prix et contrat
Ce qu'un contrat de maintenance doit couvrir, PHP et serveur compris, et ce que ça coûte en 2026.
Drupal 12 en décembre 2026 : prérequis et migration
Drupal 12 exige PHP 8.5 : pourquoi la version de PHP décide du calendrier de migration.
Reprise et maintenance de site web
Un parc de sites web à relever, un hébergeur à relancer, des montées de version à planifier : ce que nous prenons en charge.
Un parc de sites web à vérifier ?
Nous relevons les versions de PHP, relançons l'hébergeur ou reconstruisons les images, et planifions les montées de branche. Réponse sous 24 heures ouvrables.