PHP2Shell : deux failles critiques dans PHP menacent des millions de sites web

Il y a des alertes de sécurité qui concernent une extension WordPress installée sur quelques milliers de sites. D'autres touchent un logiciel un peu obscur dont la plupart des internautes n'ont jamais entendu parler. Et puis il y a celles qui concernent directement l'une des fondations du Web.

C'est précisément ce qui se passe avec PHP. Le 21 octobre 2026, l'équipe chargée de son développement a publié plusieurs mises à jour de sécurité destinées à corriger deux vulnérabilités particulièrement dangereuses. Le problème ne se trouve pas dans une application spécifique, mais dans le moteur PHP lui-même, celui qui exécute le code de nombreux sites et services en ligne.

Les deux failles, référencées CVE-2026-109618 et CVE-2026-109619, ont reçu un score CVSS de 9,2 sur 10. Elles peuvent, dans certaines conditions, permettre une exécution de code à distance sans authentification. Autrement dit, un attaquant pourrait compromettre un serveur vulnérable sans nécessairement connaître un identifiant ou un mot de passe.

L'alerte est suffisamment sérieuse pour que le CERT-FR, rattaché à l'ANSSI, ait publié un bulletin spécifique. L'équipe PHP recommande elle aussi une mise à jour immédiate, en précisant qu'aucune modification de configuration ne constitue une protection complète contre ces deux problèmes.

Deux bugs dans la gestion de la mémoire, et de très mauvaises conséquences

Derrière le nom PHP2Shell se cachent deux vulnérabilités distinctes, mais qui concernent toutes les deux la manière dont PHP manipule la mémoire pendant le traitement des requêtes.

La première, CVE-2026-109618, touche la gestion des erreurs provoquées par un manque de mémoire. Lorsqu'un programme atteint une limite mémoire, il doit normalement interrompre proprement son travail et libérer les ressources utilisées. Or, dans certaines situations, PHP peut arrêter une opération alors que des informations internes ne sont pas encore correctement initialisées.

Le problème apparaît ensuite pendant la phase de nettoyage. Le moteur PHP peut manipuler des données mémoire qui ne se trouvent plus dans un état valide. Un attaquant capable de provoquer cette situation pourrait exploiter la corruption mémoire qui en résulte pour exécuter du code malveillant.

La seconde vulnérabilité, CVE-2026-109619, fonctionne différemment. PHP peut conserver temporairement certaines informations internes entre deux requêtes traitées par un même processus. Normalement, ces informations doivent être réinitialisées lorsque leur durée de vie arrive à son terme. Mais dans certaines circonstances, une référence vers une zone mémoire libérée peut subsister et être réutilisée par une requête suivante.

En sécurité informatique, ce type de situation porte le nom de use-after-free. Le programme tente de réutiliser une ressource qui n'est plus valide, ce qui peut provoquer un comportement imprévisible. Dans le cas présent, les chercheurs ont démontré que certaines combinaisons permettaient d'aller jusqu'à l'exécution de code à distance.

Le plus inquiétant est que ces deux failles ne nécessitent pas systématiquement une vulnérabilité supplémentaire dans l'application Web. Selon la communication officielle de PHP, un scénario d'exploitation a notamment été démontré avec Apache et son module PHP, appelé mod_php, avant même que le code de l'application soit exécuté.

WordPress, Drupal et Joomla sont concernés par ricochet

Illustration originale GeekParadize — Une mise à jour du CMS ne corrige pas automatiquement une vulnérabilité du moteur PHP.

C'est probablement la principale différence avec les failles de sécurité que nous évoquons habituellement sur GeekParadize. Il ne s'agit pas d'un plugin WordPress oublié, d'un thème mal développé ou d'une mauvaise configuration propre à un CMS.

Le défaut existe à un niveau inférieur : celui du moteur chargé d'interpréter le code PHP. Par conséquent, un site WordPress parfaitement à jour peut continuer de présenter un risque si son serveur utilise une version vulnérable de PHP.

Le même raisonnement s'applique à Drupal, Joomla, Magento ou aux applications développées avec Laravel et Symfony. Cela ne signifie pas que tous ces sites sont automatiquement exploitables de la même manière. Les conditions d'attaque varient selon l'environnement, le mode d'exécution de PHP et les fonctionnalités accessibles. Mais aucune de ces plateformes ne peut corriger à elle seule une erreur située dans le langage qui la fait fonctionner.

La distinction mérite d'être soulignée, d'autant que GeekParadize avait déjà consacré un article à WP2Shell, une chaîne de vulnérabilités touchant directement WordPress en juillet dernier. Malgré la proximité des noms, PHP2Shell est une affaire différente : cette fois, c'est l'infrastructure logicielle sous-jacente qui doit être corrigée.

Les différents modes d'hébergement PHP sont concernés par l'alerte, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L'équipe PHP considère actuellement le risque comme particulièrement élevé pour mod_php, où une exploitation sans authentification et indépendante du code applicatif a été démontrée.

Quelles versions de PHP faut-il installer immédiatement ?

Infographie originale GeekParadize — Les deux CVE critiques et les quatre branches PHP disposant de correctifs officiels.

La bonne nouvelle, c'est que les correctifs officiels sont déjà disponibles. Le 21 octobre 2026, les développeurs de PHP ont publié quatre nouvelles versions de sécurité : PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 et PHP 8.5.12.

Ces versions corrigent les deux vulnérabilités. Toute installation utilisant une version antérieure de l'une de ces branches doit donc être mise à jour, sauf si elle bénéficie déjà d'un correctif rétroporté et confirmé par son fournisseur.

Pour les sites encore exécutés sur PHP 7 ou sur les branches 8.0 et 8.1, la situation est plus compliquée. Ces versions ne sont plus maintenues officiellement par le projet PHP. Certains distributeurs Linux et fournisseurs de maintenance longue durée peuvent néanmoins proposer des correctifs spécifiques. Exceptionnellement, l'équipe PHP a également publié des correctifs minimaux destinés aux branches 7.4, 8.0 et 8.1 pour faciliter leur intégration.

Cela ne doit pas être interprété comme un retour du support officiel de ces anciennes versions. La solution durable reste de migrer vers une branche de PHP toujours maintenue.

Les administrateurs qui utilisent PHP 8.2 devront eux aussi anticiper la suite : cette branche atteindra sa fin de vie officielle le 31 décembre 2026. Installer la version 8.2.35 protège contre les deux vulnérabilités actuelles, mais ne dispense pas de préparer une migration vers une version plus récente.

Un détail important pour les serveurs Linux : le numéro affiché par un paquet système ne reflète pas toujours les correctifs réellement appliqués. Certaines distributions conservent un numéro de version plus ancien tout en intégrant les réparations de sécurité. Il faut donc vérifier les bulletins de l'éditeur ou du fournisseur d'hébergement avant de conclure qu'un serveur est vulnérable uniquement sur la base de son numéro de version.

Des sites coupés par précaution en attendant les correctifs

L'affaire a rapidement pris une dimension internationale. Dès le 20 octobre, l'équipe PHP avait annoncé l'arrivée imminente d'une mise à jour exceptionnelle, sans révéler tous les détails techniques afin de laisser un peu de temps aux administrateurs et aux fournisseurs de sécurité.

L'annonce a déclenché une mobilisation importante. Selon Reuters, plusieurs sites gouvernementaux et services publics européens ont été temporairement mis hors ligne par précaution. L'objectif était d'éviter de laisser des systèmes potentiellement vulnérables accessibles depuis Internet pendant la préparation ou le déploiement des correctifs.

Le CERT-EU avait également recommandé aux organisations de recenser rapidement leurs applications PHP et, si nécessaire, d'isoler temporairement les services exposés ne pouvant pas être corrigés immédiatement.

Ces réactions peuvent sembler spectaculaires. Mais lorsqu'une vulnérabilité permet potentiellement à un attaquant de prendre le contrôle d'un serveur sans authentification, quelques heures d'indisponibilité programmée peuvent être préférables à plusieurs jours de restauration après une compromission.

Il faut néanmoins distinguer le risque potentiel des attaques effectivement confirmées. L'existence de preuves de concept et la publication de correctifs augmentent la pression sur les administrateurs, mais ne prouvent pas que chaque site vulnérable a déjà été attaqué.

L'intelligence artificielle a aussi participé à la découverte

Autre particularité de cette affaire : l'intelligence artificielle a joué un rôle dans les recherches qui ont conduit à identifier les vulnérabilités.

Selon Wiz Research, ses équipes ont découvert plusieurs problèmes critiques dans le cœur de PHP. De son côté, OpenAI indique qu'un chercheur de Calif a identifié une vulnérabilité avec l'aide d'un modèle d'IA, dans le cadre d'une initiative de recherche et de divulgation coordonnée.

Dans sa publication du 21 octobre, OpenAI explique avoir travaillé avec les mainteneurs de PHP, les chercheurs de Wiz et plusieurs entreprises de sécurité pour préparer les correctifs et les protections avant leur divulgation publique.

L'intérêt de l'IA dans ce contexte dépasse les démonstrations habituelles où un assistant génère quelques lignes de code. Des outils capables d'examiner de grandes bases logicielles peuvent aider les chercheurs à repérer des interactions complexes, des erreurs de gestion mémoire et des chemins d'exécution qu'une analyse humaine traditionnelle aurait pu mettre davantage de temps à identifier.

Mais cette évolution fonctionne dans les deux sens. Les mêmes capacités peuvent aussi aider des acteurs malveillants à analyser les différences entre une version vulnérable et sa version corrigée, afin de comprendre plus rapidement ce qui a été réparé.

La publication d'un correctif devient donc une course contre la montre. Les administrateurs ont besoin de temps pour mettre leurs systèmes à jour, tandis que les attaquants peuvent essayer d'exploiter les informations rendues publiques.

Vous gérez un site WordPress ? Voici ce qu'il faut vérifier

Si vous administrez un WordPress, un site associatif, un forum ou une petite boutique en ligne, la première chose à faire est de connaître la version de PHP réellement utilisée par votre hébergement.

Sur un hébergement mutualisé, cette information se trouve généralement dans le panneau d'administration, dans une rubrique consacrée à PHP ou à la configuration du site. WordPress affiche également des informations sur son environnement serveur depuis son outil de santé du site, accessible dans le tableau de bord.

Si vous gérez un serveur Linux, la commande php -v permet de connaître la version de PHP utilisée en ligne de commande. Attention cependant : cette version peut être différente de celle qui traite réellement les requêtes Web. Il faut également vérifier les processus PHP-FPM ou le module PHP chargé par Apache, selon votre installation.

Si votre serveur utilise PHP 8.4.26, par exemple, la version corrigée correspondante est PHP 8.4.27. Pour PHP 8.5.11, il faut passer au minimum à PHP 8.5.12. La même logique s'applique aux branches 8.2 et 8.3.

Sur un hébergement géré, il est préférable de contacter le fournisseur pour vérifier si les correctifs sont déjà déployés. En particulier, une mise à jour automatique de WordPress ne signifie pas nécessairement que l'environnement PHP a été corrigé. Les deux opérations relèvent de composants différents.

Une fois la mise à jour effectuée, il faut redémarrer les processus concernés lorsque l'environnement l'exige, vérifier le fonctionnement du site et surveiller les journaux système pour détecter d'éventuelles anomalies. Les applications utilisant des conteneurs ou des images intégrant leur propre version de PHP doivent également être vérifiées séparément.

Enfin, si vous soupçonnez une exploitation antérieure, l'installation du correctif ne suffit pas à éliminer une éventuelle compromission déjà présente. Il faut alors examiner les fichiers modifiés, les comptes privilégiés, les journaux d'accès et les mécanismes de persistance possibles, idéalement avec l'aide d'un professionnel de la réponse à incident.

Les réglages temporaires ne remplacent pas une vraie mise à jour

La documentation officielle de PHP propose plusieurs mesures permettant de réduire temporairement l'exposition lorsque le correctif ne peut vraiment pas être installé immédiatement. Elles concernent notamment la limitation des requêtes envoyées au serveur, la gestion des sessions et certains paramètres mémoire.

Pour la première faille, l'équipe PHP évoque par exemple la possibilité de modifier temporairement memory_limit. Mais désactiver cette limite au niveau de PHP peut également provoquer d'autres problèmes, notamment une consommation excessive des ressources du serveur. Ce type de changement doit donc être évalué par un administrateur qui maîtrise l'environnement concerné.

Pour la seconde, la désactivation du mécanisme session.upload_progress peut bloquer certaines méthodes d'exploitation identifiées. Là encore, il faut redémarrer les processus PHP concernés pour que le changement soit effectivement pris en compte, et d'autres chemins d'attaque peuvent subsister.

Un pare-feu applicatif ou un service comme Cloudflare peut apporter une couche de protection supplémentaire. Mais il ne corrige pas les vulnérabilités dans PHP et ne constitue pas une garantie contre toutes les variantes possibles.

Le message des développeurs est sans ambiguïté : seule l'installation d'une version corrigée, ou d'un correctif de sécurité équivalent fourni par un distributeur, permet de traiter complètement ces deux failles connues.

Si une mise à jour immédiate est impossible, limiter l'accès public à un service critique peut être nécessaire jusqu'à la correction. C'est une décision contraignante, mais parfaitement cohérente avec les recommandations des organismes de cybersécurité.

Un rappel brutal : la sécurité d'un site ne s'arrête pas à son CMS

PHP2Shell illustre finalement l'une des grandes difficultés de la sécurité Web moderne. Un site peut disposer d'un thème à jour, d'extensions régulièrement corrigées et d'un système de connexion correctement protégé, tout en restant exposé à une vulnérabilité située dans son environnement serveur.

Le problème dépasse largement WordPress. Il concerne les bibliothèques, les moteurs d'exécution, les services Web, les systèmes d'exploitation et toutes les petites couches logicielles qui permettent à une application de fonctionner.

Cette affaire rappelle également pourquoi les versions en fin de vie représentent un véritable risque. Lorsqu'un composant n'est plus officiellement maintenu, la publication d'une vulnérabilité critique laisse parfois les administrateurs dépendre d'un fournisseur tiers ou d'une migration compliquée.

Pour les propriétaires de sites, la priorité est donc claire : vérifier la version de PHP utilisée, appliquer le correctif correspondant et confirmer que la mise à jour a bien été prise en compte par le serveur Web.

Pour les administrateurs qui hébergent plusieurs applications, le travail consiste aussi à inventorier tous les services PHP, y compris les anciennes interfaces internes, les sous-domaines oubliés et les conteneurs rarement mis à jour.

En 2026, le Web repose toujours sur énormément de PHP. Ce n'est pas un défaut en soi : le langage continue d'évoluer, de recevoir des améliorations et de faire fonctionner des millions de projets. Mais une infrastructure aussi répandue exige une maintenance à la hauteur de son importance.

Et lorsque deux vulnérabilités critiques obtiennent chacune un score de 9,2 sur 10, mieux vaut éviter de remettre la mise à jour au prochain week-end pluvieux.

Cette fois, le message d'erreur le plus rassurant sera probablement celui qui vous annonce que le serveur redémarre après l'installation du correctif.