Une faille de sécurité classée 9,2 sur 10 menace les serveurs qui exécutent PHP depuis la version 5. Selon l’avis publié mardi par les développeurs du langage, deux vulnérabilités d’exécution à distance de code (RCE) pourraient permettre à un attaquant d’injecter et d’exécuter du code arbitraire sur les machines ciblées. La gravité de la situation a conduit les équipes de cybersécurité à recommander, dans certains cas, la mise hors ligne temporaire des applications tant que le correctif n’est pas appliqué.

Un correctif attendu aujourd’hui

Le correctif officiel doit être diffusé aujourd’hui à 10 h 00 (heure de l’Est). Les développeurs de PHP ont indiqué qu’ils pourraient l’avancer si les détails de la faille étaient rendus publics ou si des exploits actifs étaient détectés. Les administrateurs sont donc invités à « mettre à jour dès que le correctif est disponible ». Le correctif corrige les deux vulnérabilités RCE, qui affectent toutes les versions de PHP à partir de PHP 5, un éventail qui couvre la quasi-totalité des sites web actuels.

L’ampleur du problème

Un chercheur en sécurité estime que plus de 1,3 million d’hôtes connectés à Internet pourraient être concernés. Wordfence, le principal fournisseur de plugins de sécurité pour WordPress, rappelle que chaque site WordPress repose sur un serveur PHP ; avec plus de 40 % du Web alimenté par WordPress, la portée de la faille est gigantesque. Le correctif ne peut pas être installé via les mises à jour automatiques habituelles ; il faut que l’administrateur système identifie qui gère l’installation de PHP et applique le patch manuellement.

Que faire en attendant ?

Les équipes d’intervention d’urgence du réseau européen (ENISA) et du Centre national de cybersécurité britannique (NCSC) ont publié des avis urgents. Elles conseillent aux organisations qui ne peuvent pas patcher immédiatement de :

  • Isoler leurs applications exposées à Internet du reste du réseau ;
  • Restreindre l’accès public aux services web ;
  • Envisager de mettre les serveurs hors ligne jusqu’à ce que le correctif soit appliqué.

Le développeur du système d’exploitation mobile GrapheneOS a déjà mis son forum de discussion hors ligne, arguant que des preuves de concept d’exploitation circulaient déjà et que le risque était trop élevé pour laisser le service actif.

Premiers signes d’attaque

Des chercheurs de Sansec ont averti que des attaques massives pouvaient survenir dès 15 minutes après la publication du correctif, les cybercriminels profitant du temps où les administrateurs n’ont pas encore appliqué le patch. Cloudflare, qui protège de nombreux sites PHP, a confirmé observer « des attaques précoces » et a temporairement renforcé ses règles de pare‑feu comme mesure d’urgence.

Impact concret pour les sites

Si la faille est exploitée, les conséquences peuvent aller de la simple altération de pages web à la prise de contrôle complète du serveur, avec vol de bases de données, insertion de logiciels malveillants ou utilisation du serveur comme relais d’attaque. Pour les petites entreprises qui hébergent leurs sites sur des serveurs partagés, le risque est d’autant plus réel : une compromission peut affecter plusieurs sites clients.

Comment appliquer le correctif ?

  1. Identifier la version de PHP : la plupart des environnements affichent la version via php -v ou dans les informations du tableau de bord d’hébergement.
  2. Télécharger le correctif : les paquets officiels seront disponibles sur les dépôts habituels (apt, yum, Homebrew, etc.) dès la publication.
  3. Planifier une fenêtre de maintenance : redémarrer le service PHP (ou le serveur web) après l’installation pour que les changements prennent effet.
  4. Vérifier la mise à jour : exécuter php -v à nouveau ou consulter le journal des paquets pour confirmer la version corrigée.

Pourquoi la mise à jour manuelle est indispensable

Contrairement à la plupart des correctifs de sécurité qui s’appliquent via des systèmes de mise à jour automatiques, le correctif PHP ne peut pas être déployé de cette manière. La raison principale est que PHP est souvent intégré dans des stacks serveur personnalisées ; chaque distribution (Apache + mod_php, Nginx + php‑fpm, etc.) peut nécessiter un redémarrage ou une recompilation. Les administrateurs doivent donc prendre le contrôle direct du processus.

Risques résiduels après le patch

Même une fois le correctif installé, il est prudent de :

  • Scanner les fichiers du site à la recherche de traces d’intrusion ;
  • Réinitialiser les mots de passe des comptes administratifs ;
  • Vérifier les journaux d’accès pour détecter d’éventuelles tentatives d’exploitation avant la mise à jour.

Ces mesures complémentaires permettent de s’assurer qu’aucune porte dérobée n’a été laissée ouverte pendant la fenêtre de vulnérabilité.

Leçon à retenir

Cette crise rappelle que la gestion des dépendances serveur ne doit pas être reléguée au second plan. PHP alimente la majorité des sites web, mais il est rarement mis à jour avec la même fréquence que les applications elles‑mêmes. La meilleure défense reste une veille proactive : s’abonner aux bulletins de sécurité des projets clés, automatiser autant que possible les tests de compatibilité et préparer un plan d’action d’urgence pour les mises à jour critiques. En suivant ces bonnes pratiques, les équipes peuvent réduire drastiquement le temps d’exposition et éviter que la prochaine faille ne devienne un désastre à grande échelle.