Des pirates exploitent déjà les failles critiques de PHP, le langage de 70 % des sites web

Le 24 octobre, trois serveurs pièges installés par Adel Karimi, chercheur en sécurité chez Perplexity, enregistrent 35 exécutions de commandes réussies. Les attaques viennent de deux adresses IP. Elles visent des serveurs Apache (mod_php) qui font tourner PHP 8.4.26, une version antérieure au correctif. Deux jours plus tard, le 26 octobre, l'agence américaine de cybersécurité (CISA) ajoute les deux failles surnommées PHP2Shell à son catalogue des vulnérabilités activement exploitées (KEV).

Les failles CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10, peuvent permettre à un attaquant sans compte d'exécuter du code à distance sur un serveur PHP non corrigé. Le langage fait tourner environ 70 % des sites web. L'équipe de PHP a publié les correctifs le 21 octobre, après des fuites de détails techniques. Cyberiack avait alors raconté comment ces deux failles avaient fuité avant leur correctif.

Les versions à installer sans attendre

Selon The Register, les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, selon votre branche. Les serveurs qui tournent encore sur une branche qui n'est plus maintenue doivent être mis à niveau ou recevoir un correctif de leur fournisseur. À défaut, ils doivent être retirés d'Internet. Les administrations fédérales américaines avaient jusqu'au 29 octobre pour se mettre en conformité. Cette échéance ne s'applique pas aux entreprises, mais la CISA les invite à traiter ces failles en priorité.

Une troisième faille, CVE-2026-115560, n'a toujours pas de correctif. L'équipe de PHP a publié un contournement le 23 octobre. Elle ne serait exploitable que dans une combinaison inhabituelle de réglages et de code applicatif. Cyberiack a détaillé le réglage qui en protège.

Ce que montrent les attaques observées

Les tentatives ont commencé tôt. Selon Amazon, elles remontent au 17 octobre, quatre jours avant les correctifs. Cloudflare, Hadrian, watchTowr et Patchstack ont eux aussi signalé des essais avant la publication, mais aucun n'avait abouti selon eux.

Les résultats d'Adel Karimi changent la situation. D'après The Register, les attaquants ont combiné l'épuisement de la mémoire et la divulgation de son contenu pour exécuter du code à distance, puis ont tenté de télécharger d'autres outils avec PHP, curl et wget, sans y parvenir. Les traces correspondent à la première faille, CVE-2026-109618. Le chercheur prévient toutefois que ses serveurs pièges étaient réglés de façon « favorable », avec un seul processus de traitement. Les serveurs de production pourraient donc être plus difficiles à atteindre.

Le laboratoire de renseignement sur les menaces de l'université de Delft a de son côté compté plus de 50 000 requêtes d'exploitation, venues de plus de 600 adresses IP dans 70 pays. Parmi elles, 171 adresses ont envoyé du code d'attaque ou de quoi installer un logiciel malveillant.

Plusieurs annonces ont été corrigées depuis. Sophos a requalifié ses premières observations en simples balayages et en tentatives ratées. Palo Alto Networks a retiré son affirmation qui reliait ces failles à une intrusion dans une agence gouvernementale européenne. La CISA, elle, n'a nommé aucune victime.

Que faire ?

Les correctifs existent depuis une semaine : le travail consiste surtout à retrouver tous les serveurs concernés.

• Faites l'inventaire de tous vos serveurs PHP : sites, intranets, outils internes, conteneurs. Vérifiez la version avec php -v ou par la page de diagnostic de votre hébergeur.
• Mettez à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Sur un hébergement mutualisé, demandez à l'hébergeur si c'est déjà fait.
• Si un serveur est resté exposé sans correctif après le 17 octobre, cherchez dans les journaux des appels sortants inhabituels, par exemple curl ou wget lancés par le serveur web.
• Isolez ou coupez les serveurs qui ne peuvent pas être corrigés.

Reste à savoir si des compromissions vont être confirmées sur de vrais sites. Jusqu'ici, aucune victime n'a été nommée publiquement.