Faille PHP critique : que faire pour votre site d’entreprise

Cette faille PHP recouvre deux vulnérabilités corrigées en urgence dans le cœur du langage : CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 sur l’échelle CVSS v4.0. Elles permettent, dans certaines conditions, d’exécuter du code à distance sans aucune authentification, et de lire la mémoire des processus PHP, où peuvent se trouver mots de passe, jetons d’accès et clés d’API.

Le calendrier a été bousculé : des informations ont fuité avant la date prévue, obligeant l’équipe de sécurité à avancer la publication. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Des tentatives d’exploitation ont été relevées le jour même par plusieurs équipes de recherche.

C’est le point le plus souvent mal compris. La faille PHP n’est pas une vulnérabilité de WordPress, de WooCommerce ou d’une extension : elle est dans l’interpréteur qui exécute le code de votre site. Tout site reposant sur une version vulnérable est concerné, quels que soient son CMS et la qualité de son développement.

Deux conséquences pratiques. D’une part, un site vitrine de cinq pages est exposé au même titre qu’une boutique à fort trafic : face à une faille PHP, il n’existe pas de site « trop petit pour intéresser quelqu’un », car les attaques sont automatisées. D’autre part, vos journaux applicatifs peuvent ne rien montrer, puisque l’attaque se joue sous la couche de votre site.

Face à cette faille PHP, trois cas de figure se présentent selon votre hébergement :

• Hébergement mutualisé : la mise à jour relève de l’hébergeur, et les principaux acteurs français ont déployé le correctif sur leurs serveurs partagés. Vérifiez tout de même la version de PHP affectée à votre site dans votre panneau d’administration.
• VPS ou serveur dédié : personne ne le fera à votre place, l’hébergeur fournissant l’infrastructure sans toucher à votre système.
• Infogérance ou maintenance : votre prestataire doit vous avoir écrit. Si ce n’est pas le cas, c’est en soi une information.

Sur un serveur, la commande php -v donne la version. Attention : elle indique la version en ligne de commande, qui peut différer de celle réellement utilisée par le site.

Installer la version corrigée est nécessaire, mais le correctif n’est actif qu’après le redémarrage des processus PHP, Apache ou PHP-FPM selon votre configuration. Tant que les anciens processus tournent en mémoire, le serveur reste exposé à la faille PHP alors que la commande de version affiche déjà le bon numéro. C’est l’erreur la plus fréquente constatée cette semaine.

Second piège : les versions de PHP qui ne sont plus maintenues. Les branches 8.1 et antérieures ne reçoivent pas de correctif officiel du projet. Des paquets corrigés existent chez certains éditeurs de distributions, mais pour les versions plus anciennes, il n’y a pas de solution. Si votre site tourne sur une version non maintenue, la réponse à cette faille PHP est une migration, pas un correctif. C’est le genre de sujet que couvre un bon contrat de maintenance WordPress.

L’équipe de sécurité de PHP est explicite : aucun réglage de configuration ne neutralise complètement cette faille PHP. Les mesures suivantes réduisent l’exposition en attendant, sans jamais remplacer la mise à jour :

• désactiver le suivi de progression des envois de fichiers (session.upload_progress.enabled = 0), puis redémarrer les processus ;
• limiter la taille des requêtes acceptées au niveau du serveur web ou du proxy ;
• bloquer les requêtes d’envoi de fichiers si votre site n’en utilise pas ;
• restreindre l’accès depuis Internet aux serveurs non corrigés.

Un pare-feu applicatif apporte un filtrage utile, mais il se contourne : il fait gagner des heures, pas des semaines. Ces sujets relèvent plus largement de la sécurité d’un site internet, qui ne se résume jamais à un seul correctif.

Aucun de ces signes ne constitue une preuve, mais ils justifient un examen sérieux :

• des erreurs 500 répétées ou des redémarrages inexpliqués des processus PHP ;
• des requêtes d’envoi de fichiers inhabituelles suivies d’erreurs de mémoire ;
• des cookies de session anormalement volumineux ;
• des fichiers récents que personne ne reconnaît, notamment dans les répertoires d’envoi.

En cas de doute réel, la bonne réaction n’est pas d’attendre de voir : il faut traiter le serveur comme potentiellement compromis, renouveler les mots de passe et les clés qu’il détient, et restaurer depuis une sauvegarde si nécessaire. Nous détaillons la méthode de mise à jour sans casse dans notre article sur la mise à jour de WordPress.