Faille critique PHP : pourquoi mettre à jour PHP sur votre site WordPress dès maintenant

Rédigé par le Jeudi 22 Octobre 2026 à 15:11



Le 21 octobre 2026, le projet PHP a publié des mises à jour d’urgence pour corriger deux vulnérabilités critiques. Elles peuvent permettre à un attaquant non authentifié d’exécuter du code à distance via le service PHP qui traite le trafic de votre site.

Le point à retenir : ces failles ne se trouvent ni dans WordPress, ni dans un plugin, ni dans un thème. Elles touchent PHP, le langage sur lequel repose WordPress. Mettre à jour WordPress, vos extensions ou votre thème n’installera donc pas les correctifs.
 


Ce qu’il faut savoir
 
Les deux failles sont référencées CVE-2026-109618 et CVE-2026-109619. Chacune obtient un score CVSS v4.0 de 9,2 sur 10. Elles permettent une exécution de code à distance, sans authentification. Un attaquant qui réussit obtient les mêmes accès que le site lui-même : lecture des identifiants de base de données, modification des fichiers, vol de données, installation d’une porte dérobée persistante. Certaines attaques peuvent démarrer avant même le chargement de WordPress.
 

Ce que font les deux vulnérabilités
 
Faille Mécanisme Conséquence CVE-2026-109618 PHP gère mal certaines données lorsqu’une requête provoque un dépassement de mémoire. Un attaquant non authentifié peut corrompre la mémoire et exécuter du code. CVE-2026-109619 Un processus PHP conserve des données d’une requête terminée alors qu’elles auraient dû être supprimées. Une requête ultérieure traitée par le même processus peut exploiter ces données pour exécuter du code.

 

Ce que les tests de Wordfence ont montré
 

L’équipe Wordfence Threat Intelligence a testé les deux failles dans des environnements de laboratoire PHP et WordPress. Ses résultats préliminaires :
 
CVE-2026-109619 : une preuve de concept a permis une exécution de code dans un laboratoire PHP configuré spécifiquement. Le même test n’a fait que planter une version PHP standard optimisée. CVE-2026-109618 : une version vulnérable de PHP a échoué sur une requête de test que la version corrigée a traitée normalement. L’exécution de code n’a pas été obtenue pour cette faille. Une attaque peut devoir être adaptée à un serveur précis, mais cela ne rend en aucun cas un serveur non corrigé sûr.


Quelles versions de PHP contiennent les correctifs ?
 

Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.

Les versions PHP 8.1 et antérieures ne reçoivent plus de mises à jour du projet PHP. Certains éditeurs de distributions Linux peuvent toutefois intégrer les correctifs à leurs paquets. Si vous utilisez une branche ancienne, demandez une confirmation explicite à votre fournisseur ou migrez vers une branche supportée.
 


Comment vérifier votre version de PHP
 

Dans WordPress, allez dans Outils > Santé du site > Info > Serveur pour voir la version de PHP utilisée par votre site. Ne vous fiez pas uniquement à la commande php -v en ligne de commande : un serveur peut utiliser une autre version pour les sites web.

Les éditeurs Linux et les hébergeurs peuvent aussi ajouter des correctifs de sécurité sans changer le numéro de version principal. Posez donc la question à votre hébergeur ou à votre administrateur serveur :

Le service PHP qui sert mon site est-il corrigé contre CVE-2026-109618 et CVE-2026-109619, et PHP a-t-il été redémarré ?


 

Que faire selon votre situation
 
Hébergement mutualisé ou géré : demandez à votre hébergeur de confirmer que les deux correctifs sont installés et que PHP a été redémarré. Serveur que vous administrez : mettez à jour PHP, puis redémarrez Apache, PHP-FPM ou tout autre service PHP pour que chaque processus utilise le nouveau code. Reconstruisez vos conteneurs à partir d’une image mise à jour. Paquets de distribution ou d’éditeur : les correctifs peuvent être livrés sous des numéros de version plus anciens. Consultez l’avis de sécurité de votre éditeur et vérifiez la révision complète du paquet. Agences et hébergeurs : contrôlez tous les sites et tous les environnements, y compris les sites de préproduction, les adresses d’origine et les anciens conteneurs, pas seulement le site public principal.

​ Après la mise à jour   Vérifiez la version de PHP dans Santé du site, puis confirmez la révision complète du paquet auprès de votre hébergeur ou via les outils de paquets du système. Conservez vos sauvegardes et vos journaux (serveur web, PHP, pare-feu, système) couvrant au moins les 48 heures précédant le 21 octobre jusqu’au correctif et au redémarrage de PHP. Si le correctif a tardé, examinez ces journaux à la recherche d’activités inhabituelles. L’absence de traces évidentes ne prouve pas qu’aucune exploitation n’a eu lieu.

Si vous ne pouvez pas mettre à jour immédiatement, consultez les recommandations temporaires du projet PHP. Elles peuvent réduire l’exposition à certains vecteurs d’attaque, mais elles restent incomplètes, peuvent perturber des fonctions du site et ne remplacent pas la mise à jour.


Changer la version PHP chez O2swtich  

Un pare-feu WordPress suffit-il ?
 

Non. Un pare-feu applicatif comme Wordfence protège la couche WordPress, mais ces failles se situent au niveau du serveur, et certaines attaques commencent avant le démarrage de WordPress. La bonne approche est la défense en profondeur : mises à jour et protections à chaque niveau (PHP, serveur web, système d’exploitation, réseau). Ici, mettre à jour et redémarrer PHP est indispensable.
 



Un WordPress parfaitement à jour peut rester exposé si le PHP qui le fait tourner n’est pas corrigé. Installez une version corrigée de PHP (ou un paquet d’éditeur confirmé comme contenant les deux correctifs), redémarrez PHP et vérifiez la version réellement utilisée par votre site.

| Rédigé par le Jeudi 22 Octobre 2026


| Commentaires (0)