← Toutes les actualités
ARTICLE
Rumeurs
23 octobre 2026 4 min de lecture
Produit par Neska

Vulnérabilité PHP2Shell : mettez PHP à jour, deux failles RCE exploitées

Deux failles critiques de PHP, CVE-2026-109618 et CVE-2026-109619, permettent d'exécuter du code sans authentification et sont déjà exploitées. Les versions corrigées sont sorties le 21 octobre.

Dans cet article
  1. Ce qui est confirmé
  2. Vulnérabilité PHP2Shell : quelles versions de PHP sont sûres
  3. Ce qui se dit
  4. Pourquoi c'est important pour vous
  5. Que faire aujourd'hui

La vulnérabilité PHP2Shell recouvre en réalité deux failles critiques du langage PHP, CVE-2026-109618 et CVE-2026-109619, qui permettent à un attaquant sans identifiants d'exécuter du code sur un serveur web. Le projet PHP a publié les versions corrigées le 21 octobre 2026, et les premières attaques ont été observées le jour même. Si l'un de vos serveurs, ou celui d'un client, exécute PHP, mettez-le à jour aujourd'hui.

Une grande salle informatique vue de dessus, avec des rangées de baies de serveurs et des panneaux « Mail servers » et « World Wide Web servers ».
Photo : Florian Hirzinger - www.fh-ap.com (CC BY-SA 3.0), Wikimedia Commons.

Ce qui est confirmé

Le projet PHP a reçu les premiers signalements le 11 août 2026. Amazon Threat Intelligence a fait état d'une tentative d'exploitation le 17 octobre, avant la divulgation publique. Le 20 octobre, les détails ont fuité en ligne avant la date convenue, et PHP a avancé la publication d'urgence au 21 octobre. Ce jour-là, watchTowr a observé une exploitation active sur son réseau de honeypots.

CVE-2026-109618 concerne la gestion des erreurs de mémoire insuffisante : si PHP manque de mémoire pendant la préparation des données de la requête, ces données ne sont initialisées que partiellement et le nettoyage final les traite comme valides. CVE-2026-109619 est un défaut d'état global non réinitialisé qui conduit à un use-after-free sur le tas, avec lecture de la mémoire et exécution de code. Toutes deux permettent l'exécution de code à distance, sans authentification, avec les privilèges du compte du serveur web. Les avis des éditeurs de sécurité leur attribuent la note de 9,2 sur CVSS v4.0.

Toutes les installations PHP qui servent des requêtes web sont concernées : Apache avec mod_php, PHP-FPM, php-cgi, LiteSpeed et FrankenPHP. Le projet PHP juge le risque maximal pour mod_php, car l'attaque peut aboutir avant l'exécution du moindre code applicatif. Pour la même raison, un pare-feu applicatif ou un agent RASP placé dans le processus PHP peut ne pas l'arrêter.

Vulnérabilité PHP2Shell : quelles versions de PHP sont sûres

  • PHP 8.5 : passez à la 8.5.12.
  • PHP 8.4 : passez à la 8.4.27.
  • PHP 8.3 : passez à la 8.3.36.
  • PHP 8.2 : passez à la 8.2.35.
  • PHP 8.1, 8.0 et 7.4 : aucune version officielle. Des backports minimaux n'existent que sous forme de code source, ou de paquets de distributions et d'éditeurs LTS.
  • PHP 7.3 et antérieures, PHP 5 compris : aucun correctif, il faut passer à une branche prise en charge.

Les distributions Linux corrigent souvent une faille sans changer le numéro de version : consultez le changelog du paquet, pas seulement la sortie de php -v.

Rumeur

Ce qui se dit

Les sources divergent sur l'état de l'exploit. Certains chercheurs affirment que les deux failles sont déjà enchaînées dans un script unique fonctionnel et que des analyses et un outil sont publics. Huntress indique ne pas avoir reproduit de preuve de concept, et JFrog avertit que de faux exploits circulent. Quiconque télécharge un prétendu exploit PHP2Shell sur un forum risque d'installer un malware.

Au 22 octobre, les failles ne figuraient pas dans le catalogue CISA KEV, selon watchTowr. Le Centre national de cybersécurité britannique (NCSC) a demandé aux organisations de mettre à jour immédiatement ou de mettre hors ligne les systèmes exposés. VirusTotal estime à plus de 5,1 millions le nombre d'hôtes PHP joignables depuis Internet.

Pourquoi c'est important pour vous

Si vous gérez l'informatique d'une PME ou de plusieurs clients, PHP ne se trouve pas seulement dans les sites que vous avez écrits vous-même. Il est dans WordPress, Joomla, Magento, PrestaShop, les webmails, les vieux logiciels métier et tout conteneur dont l'image de base embarque PHP. Un conteneur garde le PHP avec lequel il a été construit : il faut le reconstruire, ou récupérer une image corrigée, puis le redéployer.

Que faire aujourd'hui

  1. Faites l'inventaire : php -v sur chaque hôte et docker exec <container> php -v sur chaque conteneur qui sert du PHP.
  2. Passez à la version corrigée, ou au paquet corrigé de votre éditeur, puis redémarrez PHP-FPM ou Apache.
  3. Si vous ne pouvez pas mettre à jour tout de suite, retirez ce système de l'accès direct à Internet.
  4. Comme mesures provisoires, qui ne protègent pas complètement : session.upload_progress.enabled=0 et un redémarrage des workers, une valeur basse pour post_max_size (8M, ou 32M si vous avez besoin d'envois de fichiers) et des limites de mémoire au niveau du conteneur.
  5. Examinez les journaux d'accès depuis le 17 octobre et, si vous soupçonnez une lecture de la mémoire des processus, changez mots de passe, jetons et clés d'API.

Le projet PHP est clair : aucune configuration n'atténue totalement ces failles, et la mise à jour est la seule défense durable. Pour être aidé à fixer les priorités et à corriger vite, découvrez nos services de cybersécurité.

Sources : watchTowr, FAQ sur PHP2Shell ; BleepingComputer ; Qualys ; JFrog ; Huntress.

← ← Toutes les actualités