Le 21 octobre 2026 à 14 h 00 UTC (16 h 00 heure de Paris), l'équipe PHP a publié deux correctifs de sécurité critiques. Les deux failles, CVE-2026-109618 et CVE-2026-109619, permettent à un simple visiteur, sans compte ni mot de passe, d'exécuter du code sur le serveur qui fait tourner votre site. Toute installation PHP antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 selon votre branche est concernée. La seule réponse complète est la mise à jour. Voici ce qui s'est passé, qui est exposé, ce que vous risquez et quoi faire aujourd'hui.
Ce qui s'est passé, en deux dates
Le 20 octobre 2026, les détails de deux failles non encore publiées ont fuité sur Internet avant la divulgation coordonnée prévue avec l'équipe PHP. La fuite s'accompagnait d'un outil d'exploitation baptisé PHP2Shell, revendiqué par ses auteurs comme fonctionnant contre toutes les versions de PHP depuis la 5.4. Confrontée à cette fuite, l'équipe de sécurité de PHP a réagi par un pré-avis officiel : un correctif sortirait le 21 octobre à 14 h 00 UTC, plus tôt si des preuves d'exploitation apparaissaient.
Le 21 octobre à 14 h 00 UTC, les versions corrigées sont sorties simultanément sur les quatre branches maintenues, avec un avis de sécurité d'une rare sévérité pour PHP : les deux failles sont notées 9.2 sur 10 en CVSS v4.0, et l'avis s'ouvre sur « mettez à jour immédiatement ». Dans la journée, l'éditeur de solutions de sécurité Rapid7 indiquait que la reproduction indépendante des failles était déjà en cours, et qu'une exploitation réelle était attendue vu le nombre de sites concernés.
| Branche PHP | Version corrigée (21 octobre 2026) |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Toute version inférieure à ces numéros est touchée. Les branches PHP 8.1 et antérieures ne reçoivent plus de correctifs depuis l'équipe PHP : l'avis publie tout de même des correctifs sources pour 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes. Autrement dit, un site resté sur une vieille branche reste exposé sans date de correctif prévue.
Qui est exposé exactement
L'avis de php.net concerne toutes les installations PHP qui servent des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le point le plus important pour un e-commerce : php.net estime le risque le plus élevé pour mod_php, le mode où PHP tourne comme module d'Apache. Un exploit y a été démontré sur une installation standard, et il se déclenche avant même l'exécution du code de votre site.
Une RCE (remote code execution, exécution de code à distance) signifie que l'attaquant fait exécuter ses propres instructions par votre serveur. mod_php est le module Apache qui interprète le PHP à l'intérieur du serveur web lui-même, un montage fréquent sur les hébergements mutualisés et les anciens serveurs dédiés.
Pourquoi c'est si grave pour une boutique ? Parce que la faille se trouve dans PHP, pas dans votre CMS. Votre WordPress, votre WooCommerce ou votre PrestaShop peut être parfaitement à jour, extensions comprises : avec mod_php, le chemin d'attaque démontré touche le moteur avant que la première ligne de votre code ne tourne. Aucun plugin de sécurité, aucun pare-feu applicatif dans WordPress ne peut intercepter cette séquence.
Le détail technique éclaire ce constat. La première faille exploite la gestion de la mémoire : une requête construite avec des morceaux multipart (le format des formulaires avec fichiers) peut épuiser la mémoire de PHP tout en respectant les limites configurées, et déclencher un état corrompu que la procédure de nettoyage traite comme valide. La seconde exploite un état interne qui survit entre deux requêtes du même processus : la requête qui prépare le terrain et celle qui déclenche l'exécution peuvent être distinctes, ce qui complique la détection. Pour cette seconde faille, un chemin d'exploitation a aussi été validé sous PHP-FPM, le mode pourtant considéré comme mieux protégé pour la première.
Ce que vous risquez, concrètement
Une RCE sans authentification, c'est la porte ouverte à tout ce qui se fait sur les boutiques piratées : pose d'un webshell (petit script de prise de contrôle caché dans vos fichiers), vol des identifiants de base de données, extraction de la base clients, détournement des paiements en injectant un skimmer dans la page de commande, envoi de spam depuis vos domaines, redirection de vos visiteurs, ou chiffrement des fichiers. Les conséquences dépassent l'incident technique : listes noires d'emailing, désindexation ou signalement de sécurité dans Google, déclaration RGPD auprès de la CNIL si des données clients sont sorties, et des semaines de rétablissement de confiance.
Le vecteur est silencieux. Les robots qui frappent déjà en permanence sur wp-login.php et xmlrpc.php n'ont pas besoin de succès sur vos mots de passe pour cette faille : ils interrogent directement le moteur. C'est pour cette raison que php.net publie la même phrase en gras dans ses deux avis : seule la mise à jour est une réponse complète.
Que faire aujourd'hui, dans l'ordre
1. Connaître votre version de PHP
- WordPress : menu Outils, Santé du site, onglet Informations, section Serveur. La version de PHP y est affichée.
- PrestaShop : Paramètres avancés, Informations. La version de PHP apparaît dans les paramètres serveur.
- Hébergement mutualisé : la version se change souvent dans le panneau de l'hébergeur, rubrique « configuration PHP » ou « environnements ».
- En SSH : la commande php -v affiche la version de l'interpréteur en ligne de commande, qui peut différer de celle du site : vérifiez dans l'interface aussi.
2. Mettre à jour selon votre situation
| Situation | Action |
|---|---|
| Hébergement mutualisé (OVH, o2switch, Ionos, etc.) | Ouvrez un ticket demandant l'application des versions corrigeant CVE-2026-109618 et CVE-2026-109619, puis contrôlez la version effective. php.net indique que les distributions et les éditeurs ont reçu les correctifs en avance, ce qui raccourcit le délai. |
| Site géré par une agence ou un infogéreur | Transmettez la référence des deux CVE et demandez la version exacte en production. C'est une demande légitime : la référence suffit à identifier le correctif. |
| Serveur dédié, VPS ou conteneurs gérés en interne | Appliquez les paquets de votre distribution ou reconstruisez vos images avec les versions corrigées, puis contrôlez la version réellement servie, pas seulement la version installée. |
3. Si vous ne pouvez pas mettre à jour aujourd'hui
php.net documente des atténuations partielles, à réserver aux installations qu'on ne peut pas corriger immédiatement. Elles réduisent l'exposition sans l'annuler : désactiver session.upload_progress, imposer memory_limit à une valeur illimitée dans la configuration du serveur plutôt que du site, resserrer post_max_size (8 Mo sans besoin d'envoi de fichiers, 32 Mo sinon), désactiver fatal_error_backtraces sur PHP 8.5, et faire redémarrer tous les processus PHP. Chacune de ces mesures est explicitement présentée comme incomplète par php.net. Elles achètent du temps, jamais la sécurité.
4. Après la mise à jour, vérifier et surveiller
Une fois la version corrigée en place, trois contrôles valent le détour : la version réellement utilisée par le site (pas celle du panneau), la présence de fichiers ou de comptes administrateur inconnus, et l'intégrité des fichiers sensibles comme les pages de paiement. Si vous découvrez des traces d'intrusion, ne nettoyez pas en surface : un nettoyage incomplet laisse le webshell et laisse repartir l'attaquant. Notre procédure complète de décontamination WordPress est décrite sur la page nettoyage d'un site WordPress piraté.
Ce que nous avons appliqué ce 21 octobre
Sur les sites PHP que nous maintenons, le plan du jour a été le suivant, appliqué dans les trois heures suivant la publication des correctifs.
- Les atténuations documentées par php.net ont été posées sur chaque serveur Apache en mod_php (session.upload_progress désactivé, memory_limit imposé côté serveur, post_max_size resserré), avec rechargement sans interruption de service.
- Les sites gérés en conteneurs ont reçu en plus une limite mémoire par conteneur, pour borner tout épuisement mémoire même pendant la fenêtre de mise à jour.
- Les images serveur ont été reconstruites sur les dernières versions publiées par les éditeurs (8.3.35 pour les WordPress que nous gérons, en attendant la disponibilité de 8.3.36 dans les images officielles), avec vérification de la version réellement servie, de la disponibilité des sites et des extensions PHP.
- Une veille quotidienne a été posée : elle détecte automatiquement la publication des versions corrigées dans les images de base et déclenche la reconstruction.
- Les contrôles d'intrusion du jour (fichiers modifiés, comptes administrateur, tentatives de connexion, journaux d'attaque) ne montrent aucune trace de compromission : les campagnes de bruteforce habituelles sur les formulaires de connexion restaient bloquées, comme avant la publication de la faille.
Ce qui reste vrai demain l'est aussi aujourd'hui : une boutique sous maintenance WordPress ou maintenance PrestaShop ne découvre pas ce type d'avis au hasard d'une newsletter. La mise à jour de sécurité fait partie du contrat, avec la vérification après application. Pour un site sans contrat, ce 21 octobre est exactement le genre de journée où il faut le prendre.
En résumé
Deux failles critiques de PHP, corrigées le 21 octobre 2026, permettent une exécution de code à distance sans authentification, y compris avant l'exécution du code du site avec Apache mod_php. Les versions corrigées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12 ; tout ce qui est en dessous est exposé, et les branches 8.1 et antérieures n'auront pas de correctif. La mise à jour est la seule réponse complète, les atténuations achètent seulement du temps.
Vous ne savez pas quelle version fait tourner votre site, ou vous voulez une vérification complète après mise à jour ? Faites-le contrôler : notre audit gratuit de site couvre la version PHP, les traces d'intrusion et les points de sécurité majeurs. Pour une reprise en main après incident ou une mise à jour accompagnée, demandez-nous un devis, réponse sous 24 h ouvrées.
Sources
- php.net, avis de sécurité « Critical remote code execution vulnerabilities, update now », 21 octobre 2026 (consulté le 21 octobre 2026) : php.net/archive/2026.php
- php.net, avis technique GHSA-w8hw-w9fx-j79w, RCE via OOM corruption, CVE-2026-109618 (consulté le 21 octobre 2026) : github.com/php/php-src
- php.net, avis technique GHSA-6wmf-4rv5-p3rp, RCE via stale global state, CVE-2026-109619 (consulté le 21 octobre 2026) : github.com/php/php-src
- CIRCL Luxembourg, avis TR-102 « Critical Remote Code Execution Vulnerabilities in PHP », 21 octobre 2026 (consulté le 21 octobre 2026) : circl.lu
- Huntress, « Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities », 20 octobre 2026 (consulté le 21 octobre 2026) : huntress.com
- Sansec, « Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619 », 21 octobre 2026 (consulté le 21 octobre 2026) : sansec.io
- Rapid7, « Critical Unauthenticated Remote Code Execution in PHP », 21 octobre 2026 (consulté le 21 octobre 2026) : rapid7.com
