PHP2Shell : deux failles critiques dans PHP, un correctif d’urgence attendu ce mercredi

Ce qu’il faut retenir :

• PHP publie ce mercredi 21 octobre à 14 h UTC un correctif d’urgence pour deux failles critiques notées 9,2.
• Selon watchTowr, ces failles permettent d’exécuter du code à distance sur un serveur PHP vulnérable.
• Seules les versions 8.2 à 8.5 recevront un correctif, les branches plus anciennes n’auront aucun correctif officiel.

PHP, le langage qui fait tourner WordPress, Drupal ou Magento, publie ce mercredi 21 octobre à 14 h UTC (16 h à Paris) une mise à jour de sécurité hors calendrier. Elle corrige deux vulnérabilités que l’équipe sécurité de PHP classe comme critiques, avec une note de 9,2 sur l’échelle CVSS 4.0, le barème de référence pour mesurer la gravité d’une faille. PHP n’a encore rien dit de leur fonctionnement.

Les chercheurs de watchTowr affirment qu’il s’agit de failles d’exécution de code à distance (RCE) : un attaquant pourrait prendre la main sur un serveur sans y avoir accès. Le milieu de la cybersécurité les a déjà baptisées PHP2Shell. Aucune exploitation n’a été signalée à ce stade.

Comment l’existence des failles PHP a fuité

PHP n’avait pas prévu d’en parler si tôt. Le 20 octobre au matin, un message publié sur le forum Hacker News annonce deux failles RCE dans PHP, notées 10 sur 10, touchant toutes les versions depuis PHP 5, avec une divulgation prévue le jeudi 22 octobre. Son auteur reconnaît n’avoir aucune preuve à l’appui. Le message disparaît, mais des captures d’écran circulent déjà.

Quelques heures plus tard, watchTowr confirme sur X que la fuite dit vrai. L’entreprise explique que les deux failles sont sous embargo et que tout le monde devait attendre jeudi pour les dévoiler.

L’équipe de PHP réagit le soir même, à 19 h 33 UTC. Elle avance la publication du correctif à mercredi, un jour plus tôt que prévu, et se réserve le droit d’aller plus vite si des détails techniques fuitent ou si des attaques apparaissent.

Que sait-on vraiment des failles PHP2Shell ?

Beaucoup de choses circulent, peu sont confirmées. La seule source officielle reste l’avis de PHP : deux failles critiques, notées 9,2, corrigées le 21 octobre à 14 h UTC. L’avis ne cite ni identifiant, ni composant, ni version touchée. PHP promet de publier tous ces éléments avec la mise à jour.

Les identifiants CVE-2026-109618 et CVE-2026-109619, repris par les chercheurs et par le CERT-EU dans son avis 2026-018, proviennent du message qui a fuité. La note de 10 aussi : PHP retient 9,2. L’affirmation selon laquelle toutes les versions depuis PHP 5 seraient touchées n’a pas été confirmée non plus. La FAQ de watchTowr précise qu’aucune condition de configuration n’a été décrite.

Selon Huntress et Phoenix Security, watchTowr a reproduit la première faille en laboratoire. Une courte vidéo d’exploitation a brièvement été mise en ligne avant d’être retirée. Des rapports évoquent aussi un kit de démonstration attribuant les bugs au traitement des envois de fichiers. Ces éléments restent invérifiés, et les spécialistes conseillent de considérer tout code qui circule comme potentiellement piégé.

Quelles versions de PHP recevront le correctif ?

PHP ne corrige que les branches qu’il maintient encore : 8.2, 8.3, 8.4 et 8.5. Les versions 8.4 et 8.5 bénéficient d’un support actif, les 8.2 et 8.3 ne reçoivent plus que des correctifs de sécurité. Plusieurs observateurs, dont Alpine Linux et le chercheur Kevin Beaumont, s’attendent aux versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP n’a pas confirmé ces numéros.

Tout ce qui précède, de PHP 8.1 jusqu’à PHP 5, est en fin de vie. Si les failles touchent ces branches, aucun correctif officiel n’arrivera.

Le parc concerné pèse lourd. La société Mallory a recensé le 20 octobre, via le moteur de recherche Shodan, environ 884 000 serveurs exposés sur Internet affichant PHP 8.1 ou plus ancien. Cela représente 59 % des quelque 1,5 million de serveurs qui indiquent leur version. Environ 740 000 autres utilisent PHP sans afficher de version. Ces chiffres reposent sur des bannières déclaratives et ne désignent pas des systèmes vulnérables confirmés, mais on pourrait imaginer que la moitié d’Internet est impactée.

Comment se protéger avant le patch PHP ?

PHP n’a publié aucune mesure de contournement. Huntress recommande de commencer par un inventaire complet, sans oublier PHP embarqué dans des équipements, des logiciels Windows ou des panneaux d’administration comme cPanel et Plesk. Sansec ajoute que les boutiques Magento, Shopware et WooCommerce sont concernées.

À 14 h UTC, vous devrez appliquer la mise à jour en commençant par les serveurs exposés sur Internet, puis vérifier les paquets de votre distribution Linux ou de votre hébergeur. Sur une version en fin de vie, trois options : migrer, couper l’accès à Internet, ou placer le serveur derrière un VPN ou un pare-feu applicatif (WAF). Le CERT-EU conseille d’isoler des réseaux publics les applications exposées tant qu’aucun correctif n’est installé.

Côté détection, Huntress recommande de déclencher une alerte dès qu’un processus PHP lance un shell, un interpréteur ou un outil de téléchargement. Sur Linux, l’outil process-watcher de Florian Roth journalise chaque programme démarré par PHP. Son auteur prévient qu’il « n'empêche rien ». En cas de doute, isolez le serveur, conservez les journaux et cherchez des web shells, de nouveaux fichiers, tâches planifiées ou comptes.

Ce qu’il faut surveiller après la publication

Les attaquants vont eux aussi décortiquer le correctif. En comparant l’ancien et le nouveau code, ils peuvent localiser les failles en quelques heures. Sansec prévoit des attaques de masse dans les 15 minutes suivant la publication, une projection et non une mesure. Lors de la divulgation de CVE-2024-4577, une faille PHP visant Windows, en juin 2024, Akamai avait observé des tentatives d’exploitation en moins de 24 heures.

Pour l’instant, ni Huntress ni watchTowr n’ont détecté d’attaque, et l’agence américaine CISA n’a pas inscrit les deux failles à son catalogue des vulnérabilités exploitées. PHP doit enfin préciser cet après-midi quelles versions sont touchées, quel composant est en cause et si l’attaque exige une configuration ou un compte particulier.