PHP2Shell : la saga des failles critiques PHP se prolonge avec un troisième correctif

L’écosystème PHP traverse une période de turbulences inédite. Après la divulgation en urgence de deux failles d’exécution de code à distance, CVE-2026-109618 et CVE-2026-109619, collectivement baptisées « PHP2Shell » – la fondation PHP a confirmé l’existence d’une troisième vulnérabilité critique, identifiée sous la référence CVE-2026-115560.

Contrairement à ses deux prédécesseures, cette nouvelle faille ne bénéficiera pas de correctif d’urgence. La fondation estime que son exploitation requiert une combinaison « très improbable » de configuration et de code applicatif spécifique, peu susceptible de se rencontrer en production. Le vecteur d’attaque impose que l’application active la gestion de progression de téléchargement de session, utilise un gestionnaire de sérialisation binaire ou PHP, puis le change dynamiquement à l’exécution avant d’initialiser la session.

Cette annonce intervient alors que les tentatives d’exploitation de PHP2Shell s’intensifient. Des chercheurs de Wiz, OpenAI et Calif ont documenté des attaques massives dès la publication des premiers correctifs, avec un délai de quatre jours entre les premiers sondages malveillants et la divulgation publique. Aucune compromission réussie sur versions corrigées n’a été confirmée à ce jour, mais l’agence américaine Mandiant qualifie la menace de « viable et très sérieuse ».

Le langage PHP alimente environ 70 % des sites web dont la technologie serveur est connue. La surface d’attaque est donc considérable. Les deux premières failles résidaient dans des défauts de sécurité mémoire du moteur PHP, permettant à un attaquant distant d’exécuter du code arbitraire sans authentification. Les correctifs ont été publiés mercredi dernier, mais l’historique montre que les environnements hébergés mutualisés et les déploiements legacy mettent souvent des semaines à appliquer les mises à jour.

Pour les administrateurs, la priorité reste l’application immédiate des correctifs PHP 8.1.31, 8.2.26 et 8.3.14. La fondation recommande également, par mesure de précaution, de désactiver la progression de téléchargement de session via la directive session.upload_progress.enabled = 0 dans php.ini, ce qui neutralise le vecteur de la troisième faille en attendant la prochaine version de maintenance.

Sources : The Hacker News, The Register, Numerama, BleepingComputer

Sources : The Hacker News, The Register, Numerama, BleepingComputer