PHP2Shell : failles critiques dans PHP (CVE-2026-109618, CVE-2026-109619)

Article mis à jour le 21 octobre 2026, avant la publication de l’avis technique officiel de PHP. Certaines informations ci-dessous proviennent de chercheurs indépendants et restent à confirmer. Nous mettrons cet article à jour après la publication du correctif.

PHP2Shell désigne deux vulnérabilités critiques révélées dans PHP lui-même, référencées CVE-2026-109618 et CVE-2026-109619. Selon les premiers rapports, elles pourraient permettre à un attaquant non authentifié d’exécuter du code à distance sur un serveur web vulnérable.

La faille ne se trouve pas dans une extension WordPress, un paquet Laravel ou un CMS précis, mais dans le moteur d’exécution PHP. Toutes les applications qui reposent sur ce moteur pourraient donc partager la même exposition. L’équipe sécurité de PHP a confirmé les deux vulnérabilités et annoncé une version de sécurité d’urgence le 21 octobre 2026 à 14:00 UTC (15:00 heure du Maroc).

PHP2Shell en bref

À distinguer : le projet PHP a confirmé la sévérité et la publication d’urgence. Les identifiants CVE et l’impact RCE ont été rapportés par des chercheurs, dont watchTowr. Les versions exactement concernées, les conditions d’exploitation et le mécanisme technique doivent encore être confirmés par l’avis officiel.

Comment PHP2Shell pourrait fonctionner

L’hypothèse la plus discutée concerne le traitement natif des requêtes multipart/form-data par PHP et la fonctionnalité session.upload_progress. Contrairement à une faille applicative classique, l’attaque viserait un traitement qui a lieu avant que Laravel, Symfony, WordPress ou votre propre code ne prenne la main.

Chaîne de traitement supposée (non confirmée)

1. Requête HTTP contrôlée par l’attaquant, potentiellement une requête multipart forgée.
2. Serveur web ou reverse proxy : Nginx, Apache, etc.
3. Traitement natif de la requête par PHP : analyseur multipart et suivi de progression d’upload. C’est la couche soupçonnée d’être vulnérable.
4. Code applicatif : authentification, routage, contrôleurs.

Des chercheurs évoquent une corruption mémoire de type use-after-free dans le gestionnaire de session de suivi d’upload. Upwind a publié une version détaillée de cette théorie, mais d’autres tests indépendants n’ont pas reproduit le mécanisme RCE annoncé. Les causes exactes, et la différence entre les deux CVE, ne sont pas confirmées par PHP : considérez cette explication comme une recherche préliminaire, pas comme un fait établi.

Pourquoi c’est grave

Si l’exécution de code sans authentification est confirmée, un attaquant pourrait exécuter des commandes avec les privilèges du worker PHP, voler les secrets de l’application et les identifiants de base de données, puis tenter un mouvement latéral vers le reste de l’infrastructure. Une application Laravel ou WordPress bien sécurisée ne protège pas nécessairement contre une faille de l’interpréteur sous-jacent.

Versions PHP concernées et correctifs attendus

Tenable indique les versions de sécurité suivantes. Elles sont préliminaires et pas encore confirmées par le projet PHP.

Les branches 8.2 à 8.5 sont actuellement maintenues. Les distributions Linux peuvent rétroporter des correctifs : un numéro de version ancien ne signifie donc pas automatiquement que le paquet installé n’est pas corrigé.

État de l’exploitation au 21 octobre 2026

• Confirmé : deux vulnérabilités critiques existent. L’équipe sécurité PHP les a reconnues et a planifié une version d’urgence.
• Reproduction par la recherche : partielle. watchTowr indique avoir reproduit CVE-2026-109618. Cela ne prouve pas que toutes les preuves de concept publiques fonctionnent.
• Attaques : premières activités signalées. Le CTO de Cloudflare, Dane Knecht, a fait état d’attaques émergentes et du déploiement de règles WAF temporaires, y compris pour les clients gratuits. Ce n’est pas la confirmation d’une exploitation réussie à grande échelle.
• PoC public fiable : non vérifié. Du code d’exploitation circule, mais Tenable ne l’a pas validé. Certains fichiers présentés comme des exploits peuvent contenir des logiciels malveillants : ne les exécutez pas.

Que faire immédiatement

1. Inventoriez vos installations PHP, en priorité les serveurs exposés sur Internet, les conteneurs, l’hébergement mutualisé ou managé et les applications tierces qui embarquent PHP.
2. Préparez la mise à jour officielle dès sa publication, redémarrez PHP-FPM (ou l’équivalent) et vérifiez la version du runtime qui sert réellement les requêtes.
3. Réduisez temporairement l’exposition en restreignant l’accès public aux applications PHP non essentielles. Pour les systèmes à risque qui ne peuvent pas être corrigés rapidement, envisagez une isolation temporaire.
4. Utilisez des protections WAF temporaires, sans les considérer comme un correctif complet. Bloquer globalement les requêtes multipart peut casser les envois de fichiers, les paiements et d’autres fonctions légitimes.
5. Surveillez les signaux suspects : plantages inhabituels de workers PHP, processus enfants inattendus, connexions sortantes anormales et trafic POST suspect.

Le contournement session.upload_progress

Une mesure de configuration largement partagée en ligne consiste à désactiver le suivi de progression d’upload :

session.upload_progress.enabled = Off

Des chercheurs et des mainteneurs PHP avertissent toutefois que ce n’est pas une mitigation fiable à elle seule. La mise à jour du runtime PHP reste indispensable.

Vérifier vos versions PHP

Sur des systèmes que vous êtes autorisé à administrer, ces commandes sont un bon point de départ :

# Version de PHP en ligne de commande
php -v

# Version de PHP-FPM, si installé
php-fpm -v

# Paquets PHP sur Debian/Ubuntu
dpkg -l 'php*'

# Paquets PHP sur RHEL/Fedora
rpm -qa | grep -i php

Attention : le PHP en ligne de commande et le PHP qui sert vos pages web peuvent utiliser des versions différentes.

Entreprises au Maroc : par où commencer

Au Maroc, PHP reste très présent sur les sites institutionnels, l’e-commerce et les applications métier, souvent sur de l’hébergement mutualisé où la version de PHP dépend de l’hébergeur. Demandez dès aujourd’hui à votre hébergeur ou infogérant sa date de déploiement du correctif, et documentez vos actions : dans le cadre de la loi 09-08 et de la loi 05-20, la capacité à démontrer les mesures prises face à une vulnérabilité critique compte. Pour les applications exposées, un test d’intrusion web et API après correctif permet de vérifier que la surface d’attaque est réellement maîtrisée.

Ce que PHP2Shell change pour l’évaluation de la sécurité

Cet incident illustre l’importance d’une priorisation fondée sur des preuves. Une bonne stratégie de détection distingue l’exposition potentielle de la vulnérabilité confirmée. Tant que des méthodes de détection validées ne sont pas disponibles, un scanner ne devrait pas prétendre avoir prouvé PHP2Shell sur la seule base d’une bannière de version PHP ou d’une requête multipart acceptée.

Chez HEXBOX, nous privilégions l’inventaire du runtime PHP, les vérifications de paquets et de versions authentifiées lorsque c’est possible, le contrôle de l’état des correctifs fournisseur et l’identification des actifs exposés potentiellement concernés. Un constat ne passe au statut « confirmé » qu’avec une preuve fiable.

Sources à suivre

• PHP — annonce de sécurité officielle : source de référence pour la version, la matrice des versions concernées et les détails techniques finaux (php.net).
• CERT-EU — avis de sécurité 2026-018 : avis européen officiel sur les deux CVE, le risque et les mesures défensives immédiates.
• Tenable Research — FAQ PHP2Shell : versions corrigées attendues, revendications d’exploits, premières attaques et mitigations.
• JFrog Security Research : utile pour la gestion des vulnérabilités, l’inventaire des runtimes et la couverture de détection.
• BleepingComputer : chronologie de la rupture d’embargo et des révélations de watchTowr.

En résumé

PHP2Shell est un événement de sécurité réel et urgent, mais les mécanismes d’exploitation rapportés publiquement ne sont pas encore entièrement vérifiés. Inventoriez vos runtimes PHP dès maintenant, appliquez la version officielle dès sa sortie et vérifiez que le processus qui sert vos requêtes a bien été mis à jour.

Faire vérifier votre exposition PHP avec HEXBOX