Le projet PHP a publié des mises à jour de sécurité d’urgence le 21 octobre 2026. Elles corrigent CVE-2026–109618 et CVE-2026–109619, chacune évaluée à 9,2 sur 10 selon CVSS v4.0. La première faille permet l’exécution de code à distance par corruption liée à un manque de mémoire. La seconde exploite un état obsolète d’un processus worker.

Ces problèmes touchent PHP, pas WordPress Core, les extensions ou les thèmes. Mettre WordPress à jour ne modifie pas le service PHP qui traite le trafic. Une exploitation réussie sans authentification donne à l’attaquant les mêmes accès que le site. Il peut alors lire des identifiants et des données, modifier des fichiers ou installer une porte dérobée persistante.

PHP a confirmé l’exécution de code à distance pour les deux failles. Il a également confirmé un chemin d’attaque lié à CVE-2026–109618 qui peut s’exécuter avant le démarrage de WordPress. CrowdStrike indique que son exploit privé fonctionnait de manière fiable sur des systèmes Intel, AMD et Arm, y compris contre des workers PHP redémarrés récemment. Wordfence n’a pas testé indépendamment cet exploit non publié. Une attaque peut devoir être adaptée à un serveur donné, mais un serveur non corrigé ne doit pas être considéré comme sûr. Des preuves de concept circulent déjà, avec des exemples parfois incomplets ou erronés.

L’équipe Wordfence Threat Intelligence a commencé ses essais quelques heures après la publication des correctifs. Dans un laboratoire Apache spécialement configuré avec PHP 8.5.11, une preuve de concept pour CVE-2026–109619 envoyée par HTTP a créé un fichier texte temporaire. Le test a ainsi démontré l’exécution de code dans cet environnement. Le même essai a fait tomber une compilation optimisée standard de PHP 8.5.11, tandis que PHP 8.5.12 est resté opérationnel. Pour CVE-2026–109618, PHP 8.5.11 a échoué sur la requête de test, alors que PHP 8.5.12 l’a traitée normalement. D’autres essais avec WordPress 7.1.3 et un paquet Ubuntu vulnérable contenant PHP 8.5.4 ont provoqué des erreurs ou des redémarrages dans certains environnements. Wordfence n’a pas obtenu indépendamment l’exécution de code pour cette CVE. Les tests se poursuivent, car le comportement peut varier selon les serveurs.

Les premières versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les distributions Linux et les fournisseurs de versions maintenues à long terme peuvent intégrer les correctifs dans des paquets portant un numéro de version principal plus ancien. Il faut donc vérifier la révision complète du paquet et l’avis de sécurité du fournisseur. Le projet PHP ne publie plus de versions pour PHP 8.1 et les branches antérieures. Les utilisateurs concernés doivent obtenir une confirmation explicite de leur fournisseur ou passer à une branche prise en charge.

Les clients d’un hébergement administré doivent demander si les deux CVE sont corrigées dans le service PHP de leur site et si PHP a été redémarré. Les opérateurs de serveurs autonomes doivent mettre PHP à jour et redémarrer Apache, PHP-FPM ou un autre service PHP. Les conteneurs doivent être reconstruits et redéployés depuis une image actualisée. Les agences et hébergeurs doivent contrôler les environnements de production, de test et d’origine, ainsi que les anciens conteneurs.

La version utilisée par le site apparaît dans WordPress sous Tools > Site Health > Info > Server. La commande `php -v` peut renvoyer la version d’une autre installation PHP. Après la mise à jour, il faut vérifier la version réellement utilisée et la révision complète du paquet. Les sauvegardes et les journaux du serveur web, de PHP, du pare-feu et du système doivent être conservés pour au moins les 48 heures précédant le 21 octobre jusqu’au correctif et au redémarrage. Une mise à jour tardive justifie une recherche d’activité inhabituelle. L’absence de traces évidentes ne prouve pas qu’il n’y a pas eu d’exploitation.

Les recommandations temporaires de PHP peuvent réduire l’exposition à certains chemins d’attaque si le correctif ne peut pas être installé immédiatement. Elles restent incomplètes, peuvent perturber le fonctionnement du site et ne remplacent pas la mise à jour. Le pare-feu Wordfence protège la couche applicative de WordPress. Ces failles se trouvent toutefois au niveau de PHP, et certaines attaques peuvent commencer avant le chargement de WordPress. Il faut donc maintenir à jour PHP, le serveur web et le système d’exploitation, avec des contrôles supplémentaires à la périphérie réseau.