PHP2Shell: exécution de code sans authentification dans les stacks PHP
Faille PHP exploitée activement: exécution de code à distance sans authentification, validée sur Apache mod_php. Correctifs 8.5.12, 8.4.27, 8.3.36, 8.2.35.
Qui est touché
- Sites et portails tournant sous PHP 8.2 à 8.5, versions antérieures à 8.5.12, 8.4.27, 8.3.36 et 8.2.35
- Déploiements Apache mod_php en priorité: l'exploitation complète a été validée avant tout code applicatif
- Sites vitrines, moteurs de réservation et back-offices hôteliers développés sur PHP, infogérés ou non
- Instances en PHP 8.1 et antérieurs, en fin de vie et non correctifs
- Lignes de contrôle d'accès dormakaba (exos 9300, MATRIX, evolo Manager, evolo smart, exivo, resivo, B-COMM, skyra, EntriWorX, Keyscan, Ambiance, Community): avis éditeur DKSA-26-23-101 du 21 octobre 2026, CVSS 9,2
Comment corriger
Monter à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 sans attendre. Appliquer en parallèle la mesure de contournement de l'avis éditeur: session.upload_progress.enabled=0 dans php.ini ou la configuration du pool FPM. Isoler du réseau public toute instance non corrigée le temps de la mise à jour. Rechercher les traces de compromission: fichiers ajoutés dans les racines web, processus enfant inattendus du worker, trafic sortant anormal. La CISA, qui a ajouté la faille au catalogue KEV le 26 octobre, exige une échéance de correction au 29 octobre et une triade forensique.
Ce qui se passe
CVE-2026-109618, surnommée PHP2Shell par l'équipe de recherche qui l'a documentée, est une faille du moteur PHP lui-même: lors d'un épuisement mémoire provoqué à distance, PHP abandonne le traitement d'une requête en laissant une mémoire dans un état invalide, que la procédure de fermeture lit ensuite. Enchaînée avec un second défaut corrélé (CVE-2026-109619), elle donne une exécution de code à distance sans authentification, validée par l'éditeur sur Apache mod_php avec la configuration par défaut, avant même que le code de l'application ne s'exécute. Les correctifs sont sortis en urgence le 21 octobre; la CISA a ajouté les deux failles au catalogue KEV le 26 octobre en signalant une exploitation réelle.
Pourquoi c'est grave pour un hôtel
- PHP équipe une large part du web hôtelier: sites vitrines, portails de réservation personnalisés, modules de paiement, back-offices d'exploitants. Un serveur touché expose les données de réservation transitées et sert de point d'appui vers le réseau interne.
- L'exploitation ne demande ni compte ni interaction: un simple requête HTTP suffit sur les configurations vulnérables, ce qui rend le ver dans la nature automatique et rapide.
- Les instances infogérées ne sont pas couvertes d'office: beaucoup de prestataires n'ont pas encore déployé les builds du 21 octobre.
Qui est touché
- Toute application web en PHP 8.2 à 8.5 non corrigée; Apache mod_php est le scénario confirmé, les autres SAPI (FPM, FrankenPHP, LSAPI) sont jugés vraisemblablement exposés par l'analyse source de l'éditeur.
- Les versions PHP 8.1 et antérieures, qui ne reçoivent plus de correctifs, doivent migrer vers une version maintenue.
- Attention: une troisième variante, CVE-2026-115560, reste ouverte après les correctifs du 21 octobre dans des configurations rares; la mesure de contournement ci-dessous la ferme aussi.
Comment corriger
- Mettre à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, sur tous les serveurs web, y compris les environnements de test et les instances gérées par un prestataire.
- Écrire session.upload_progress.enabled=0 dans php.ini ou la configuration du pool FPM (jamais via ini_set()), en attendant le prochain correctif régulier.
- Couper l'exposition internet des instances non corrigées le temps de la mise à jour.
- Chercher les traces de compromission antérieures au correctif: fichiers récents dans les racines web, comptes administrateurs ajoutés, connexions sortantes inhabituelles depuis le worker web.
- Exiger de chaque hébergeur et intégrateur la liste des builds PHP déployés, propriété par propriété.
Contexte
PHP2Shell rappelle la leçon des campagnes node2shell: quand une faille touche le socle d'exécution du web, le secteur le plus exposé n'est pas celui qui fait l'actualité, c'est celui dont les sites critiques tournent sur des briques anciennes rarement inventoriées. Les équipes de réponse françaises et américaines publient la même consigne: patcher d'abord l'exposition, puis vérifier ce qui est entré.