PHP et des chercheurs de Wiz ont coordonné la divulgation. Google Cloud indique que les versions de PHP de 5.4 à 8.5.11 sont concernées, avec des correctifs dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les versions 8.1 et antérieures, arrivées en fin de vie, ne reçoivent pas ces correctifs du projet PHP.

Le composant invisible sous le site

Pour un dirigeant, PHP peut sembler être un détail technique. En pratique, il se trouve dans des serveurs web, des systèmes de gestion de contenu, des conteneurs et parfois des interfaces d’administration intégrées à des équipements. Une entreprise peut donc l’utiliser sans l’avoir inscrit clairement dans son inventaire.

Le premier enjeu est de savoir où il est présent. La version affichée par une application n’est pas toujours celle exécutée partout : environnements de test, anciennes images de conteneurs, fonctions serverless et appliances peuvent suivre des cycles différents.

Corriger ne signifie pas seulement cliquer sur « mettre à jour »

La réponse dépend de l’hébergement. Certains services managés corrigent automatiquement leurs images prises en charge. D’autres imposent de reconstruire et redéployer l’application. Sur une distribution Linux, le numéro de version peut conserver une apparence ancienne tout en recevant un correctif rétroporté : la confirmation doit venir de l’avis de sécurité du fournisseur, pas seulement d’une comparaison superficielle.

Cette diversité explique pourquoi une simple mise à jour de WordPress ou d’un autre CMS ne suffit pas nécessairement. Le moteur PHP, l’image de conteneur, l’infrastructure d’exécution et les dépendances doivent être vérifiés ensemble.

Mesurer l’exposition sans improviser

Les équipes doivent prioriser les services accessibles depuis Internet et ceux qui traitent des données sensibles. Elles doivent conserver les journaux, rechercher les signes inhabituels selon les recommandations de leurs fournisseurs et tester le redéploiement. Une protection de pare-feu applicatif peut réduire certains risques, mais ne remplace pas le correctif.

Cette réponse doit rester défensive. Publier ou reproduire un code d’exploitation n’aide pas les lecteurs à se protéger. La priorité est l’inventaire, la mise à jour, la validation et, si nécessaire, l’isolement temporaire décidé par des professionnels.

Une alerte sur la dette technique

Les systèmes en fin de vie posent le problème le plus difficile. Une application ancienne peut dépendre d’une version qui ne reçoit plus de correctifs. La crise impose alors soit une migration accélérée, soit des mesures compensatoires limitées et documentées. Reporter la modernisation transforme un gain de court terme en exposition durable.

Conclusion

Ces failles ne signifient pas que tout site PHP a été compromis. Elles signifient que l’absence de visibilité est devenue un risque. Une entreprise qui connaît ses versions, ses fournisseurs et ses procédures de redéploiement peut agir vite ; les autres découvrent leur dépendance au moment le plus coûteux.