Deux failles critiques affectant PHP (CVE-2026-109618 et CVE-2026-109619), annoncées hier, pourraient permettre à un attaquant d’exécuter du code à distance, sans authentification, sur des serveurs web. Le CERT-FR a publié une alerte, et l’équipe de PHP a diffusé des correctifs aujourd’hui (voir son avis de sécurité).
Tribune – A ce titre, voici ci-dessous les commentaires des experts de Filigran :
« Le plus difficile n’est pas d’installer le correctif, mais de savoir où PHP s’exécute : sous les systèmes de gestion de contenu, les plateformes d’hébergement, les appliances et les produits tiers qui ne le mentionnent jamais. C’est pourquoi des gouvernements mettent des sites hors ligne plutôt que d’attendre. La rapidité joue dans les deux sens. L’IA a trouvé des failles restées inaperçues pendant plus de dix ans, et les mêmes outils permettent aux attaquants de développer des exploits fonctionnels en quelques heures, des attaques précoces étant déjà signalées. Les responsables de la sécurité devraient faire trois choses dès aujourd’hui. Inventorier tous les systèmes exposés et demander à chaque éditeur si son produit embarque PHP. Corriger ou isoler ce qui ne peut pas être corrigé, en commençant par tout ce qui est accessible depuis Internet. Puis partir du principe que quelqu’un est entré le premier : rechercher les web shells, les fichiers inattendus et les nouvelles connexions sortantes. Un correctif ne compte que lorsqu’on a prouvé qu’il est appliqué partout où un attaquant peut l’atteindre. » – Samuel Hassine, CEO et cofondateur, Filigran
« Mettre un site hors ligne pendant une journée est une décision bien moins coûteuse que d’expliquer une compromission pendant un an. Les agences qui demandent aux organisations de le faire donnent un conseil judicieux, et la rapidité de la réponse coordonnée montre à quel point la discipline a gagné en maturité. Ces failles se trouvaient dans du code qui remonte à 2004 et ont été découvertes grâce à l’IA. Les mêmes outils aideront les attaquants à aller tout aussi vite, et des attaques précoces sont déjà signalées. La mission est simple à énoncer et difficile à accomplir. Identifier tous les systèmes qui exécutent PHP, y compris ceux cachés dans des produits tiers. Passer à une version supportée ou mettre le système hors ligne. Puis vérifier que rien n’est entré pendant que la fenêtre était ouverte. Corriger est la partie facile. Savoir ce que l’on exploite est le vrai test. » – Samuel Hassine, CEO et cofondateur, Filigran
« PHP2Shell réunit bon nombre des ingrédients de Log4Shell : une exécution de code à distance sans authentification, dans un logiciel présent presque partout, déclenchée par une seule requête spécialement conçue. Mais le scénario est différent. Log4j était enfoui profondément dans les dépendances Java, et les équipes ont passé des semaines simplement à le localiser. PHP est plus facile à repérer, ce qui permet aux organisations d’identifier plus vite leurs expositions. Et contrairement à Log4Shell, un correctif est déjà disponible. Les failles de PHP sont aussi plus difficiles à exploiter que Log4Shell, mais maintenant qu’un exploit fonctionnel existe, cela ne ralentira pas longtemps les attaquants. Les équipes de sécurité doivent corriger immédiatement les systèmes PHP exposés sur Internet, puis vérifier que ces correctifs tiennent réellement. » – Debrah Galea, Senior Product Marketing Manager, Filigran
« Publier un exploit PHP2Shell fonctionnel avant la disponibilité du correctif officiel n’était pas de la recherche. Cela a donné une longueur d’avance aux attaquants, alors que les défenseurs n’avaient rien à déployer. La divulgation coordonnée existe précisément pour éviter cela. Maintenant que l’exploit est public, la première priorité est de connaître sa surface d’attaque : quels points d’accès PHP sont réellement joignables depuis Internet, y compris les systèmes anciens oubliés, et si les protections existantes se trouvent bien sur le chemin. La deuxième est la responsabilité et l’impact. Chaque actif exposé doit avoir un responsable capable d’agir immédiatement, et il faut comprendre ce que signifierait une compromission : données clients, identifiants ou point d’entrée vers le réseau interne. Les scores de sévérité seuls placent tous les serveurs PHP au même rang. Des urgences comme celle-ci ne testent pas la rapidité avec laquelle les organisations lisent les avis de sécurité ; elles testent si elles connaissaient déjà leur exposition avant la publication de l’avis. » – Mathieu Rigotoo, CISO de Filigran
Faille critique dans PHP : Likuid applique les correctifs
PHP est le langage sur lequel sont basés la plupart des géants du Web comme WordPress, WooCommerce ou encore Prestashop et la majorité des sites web. Elles pourraient permettre à un attaquant d’exécuter du code sur un serveur sans avoir à se connecter. L’hébergeur canadien Likuid déclare avoir appliqué l’ensemble des correctifs sur ses serveurs afin de sécuriser les sites hébergés.
Ce qui a été fait :
- Les correctifs seront appliqués à toutes les versions de PHP installées sur notre environnement d’hébergement.
- cPanel distribue les correctifs graduellement afin de limiter la charge sur ses serveurs de mise à jour. Nos serveurs ne reçoivent donc pas tous les paquets au même moment.
- Nous appliquons les mises à jour dès leur réception, sans intervention de votre part.
Versions corrigées publiées par cPanel :
- PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35
- Versions plus anciennes, avec correctif rétro-porté : PHP 8.1.34, 8.0.30, 7.4.33 et 7.2
Ce que vous devez faire :
Aucun correctif n’existe pour PHP 7.3. Si votre site utilise cette version, il doit passer à une version plus récente sans attendre. Vous pouvez le faire dans votre cPanel, sous « Sélectionner la version de PHP ». Avant le changement, mettez à jour WordPress, votre thème et vos extensions, et faites une copie de sauvegarde.
Si votre site roule encore sur PHP 7, prévoyez aussi le passage à PHP 8.2 ou plus récent. Ces versions ne sont plus soutenues et le correctif actuel est une mesure exceptionnelle.