Des failles de sécurité critiques dans PHP Core affectent les sites Web, y compris WordPress

L’équipe de sécurité PHP a publié aujourd’hui, le 21 octobre 2026, des correctifs d’urgence pour deux failles critiques qui peuvent permettre aux attaquants d’exécuter du code sur les serveurs de sites Web sans se connecter.

Les versions fixes sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP affirme que la mise à jour est le seul choix sûr car aucune solution de contournement ne résout complètement les vulnérabilités.

PHP indique que toutes les installations répondant aux requêtes de sites Web sont à risque. Serveurs Apache utilisant mod_phpqui exécute PHP directement dans Apache, est confronté au risque le plus élevé. Une attaque démontrée peut être exécutée avant le démarrage du code du site Web.

PHP exécute WordPress sur votre serveur Web. La mise à jour de WordPress ou de ses plugins ne mettra pas à jour PHP. Demandez à votre hébergeur d’installer le correctif. Si votre compte d’hébergement vous permet de changer de version de PHP via cPanel, confirmez que la version que vous sélectionnez inclut le correctif.

Les anciennes versions de PHP nécessitent une mise à niveau

PHP 8.1 et versions antérieures restent sur la liste de fin de vie et ne reçoivent plus de mises à jour officielles régulières.

Pour cette urgence, PHP a fourni des correctifs limités au code source pour PHP 7.4, 8.0 et 8.1 pour les équipes qui construisent PHP elles-mêmes. Les fournisseurs d’hébergement et les fournisseurs de support à long terme peuvent également fournir leurs propres mises à jour. Ces correctifs ne restaurent pas le support continu. Demandez à votre hébergeur de confirmer la protection lors de l’organisation d’une mise à niveau vers une version prise en charge.

Sites gouvernementaux mis hors ligne avant le patch PHP

International Cyber ​​Digest a rapporté que les sites Web du parlement néerlandais et des cyberagences, les services Web du gouvernement finlandais et les sites des universités ont été mis hors ligne avant la publication. Il a décrit les fermetures finlandaises comme une mesure de précaution et non comme une violation.

Sansec a également signalé que la Chambre des représentants néerlandaise et le Centre national de cybersécurité avaient mis leurs sites Web hors ligne par mesure de précaution.

Avant la publication, le CERT-EU et le Centre national de cybersécurité du Royaume-Uni ont conseillé d’envisager un isolement temporaire ou des arrêts lorsqu’une protection immédiate n’était pas possible.

Ce que les propriétaires de sites Web devraient faire maintenant

Suivez le guide WordPress PHP pour vérifier votre version : ouvrir Outils > Santé du sitesélectionner Informationset développez Serveur.

  • Demandez à votre hébergeur d’installer l’une des versions corrigées répertoriées ci-dessus ou confirmez que sa mise à jour PHP inclut les deux correctifs.
  • Si vous utilisez PHP 8.1 ou une version antérieure, sauvegardez le site et organisez une mise à niveau. Demandez à votre hébergeur s’il peut appliquer un correctif fourni par le fournisseur entre-temps.

Si vous ne pouvez pas appliquer le correctif immédiatement, envisagez de mettre le site concerné hors ligne jusqu’à ce qu’il puisse être mis à jour. Un pare-feu d’application Web (WAF), tel que Cloudflare, peut bloquer certaines tentatives d’attaque, mais il ne remplace pas l’installation des correctifs.

Si vous mettez votre site hors ligne pour patcher PHP, demandez à votre hébergeur d’afficher une page de maintenance avec une réponse HTTP 503 (Service non disponible), comme le recommande Google. Cela signale une panne temporaire ; votre hébergeur peut servir la page via le serveur Web ou un réseau de diffusion de contenu (CDN), sans recourir à PHP.

Si vous utilisez un pare-feu, assurez-vous que toutes les visites passent par celui-ci. Les attaquants qui peuvent accéder directement au serveur de votre site Web peuvent contourner ces contrôles.

Après l’application des correctifs, recherchez les shells Web (scripts malveillants qui donnent accès aux attaquants), les comptes d’administrateur inconnus et les modifications inattendues des fichiers PHP. Un correctif ne supprime pas une compromission existante.

Voir aussi: Google rappelle aux sites de servir un 503 pendant le temps d’arrêt du correctif PHP

Préparez-vous à des vulnérabilités plus graves

Comme je l’avais prédit en août en écrivant sur la façon dont l’IA change la sécurité des sites Web, les attaquants peuvent agir plus rapidement que les éditeurs de logiciels ne peuvent fournir de correctif. Les rapports faisant état d’un outil d’attaque circulant avant ce patch PHP montrent que le problème de timing se produit déjà.

Le correctif est désormais disponible, mais il ne protège votre site qu’une fois installé. Une compromission peut exposer les données des clients et nuire à la visibilité de la recherche.

Demandez à votre équipe technique d’auditer votre code et de surveiller les activités suspectes. Convenez avec votre hébergeur qui appliquera des correctifs d’urgence ou mettra hors ligne un site concerné s’il ne peut pas être protégé.

Les attaquants peuvent utiliser des modèles non censurés sans restrictions de sécurité. Ces modèles peuvent acquérir des capacités grâce à la distillation, qui les entraîne sur les résultats de modèles frontières plus puissants. En conséquence, une IA plus puissante peut atteindre les mauvais acteurs sans les garanties des modèles d’origine, leur donnant ainsi de meilleurs outils pour trouver et exploiter les faiblesses. C’est pourquoi je m’attends à ce que de graves vulnérabilités comme celles-ci soient découvertes plus fréquemment, avec moins de temps pour répondre aux propriétaires de sites Web. Se préparer à ce rythme fait désormais partie de la protection de votre site Web et de sa visibilité dans les recherches.