Le correctif de PHP2Shell est disponible, mais la plupart des sites qui en ont besoin n’ont aucun bouton sur lequel cliquer. Les failles se trouvent dans PHP lui-même, le moteur qui fait tourner toutes les pages WordPress, Joomla et Drupal, sous le CMS, ses extensions et son écran de connexion. Mettre WordPress à jour n’y change rien. L’interpréteur corrigé doit être fourni par celui qui gère le serveur : l’hébergeur, le paquet de la distribution Linux ou l’image du conteneur. Tant que ce n’est pas fait, le site reste vulnérable, quoi que fasse son propriétaire.

C’est ce que les titres appelant à « appliquer le correctif sans attendre » passent sous silence. L’équipe de PHP a fait son travail. Le déploiement de son correctif sur un serveur donné dépend d’une chaîne de distribution qui avance au rythme de son maillon le plus lent, et la première journée a révélé l’écart entre ces maillons. Un propriétaire qui ignore d’où vient son PHP ne peut pas savoir dans quelle mesure son site reste exposé.

Pourquoi une mise à jour de WordPress ne suffit pas

Comme les bogues se trouvent dans l’interpréteur, l’avis de sécurité de PHP concerne toutes les installations qui répondent à des requêtes web, de PHP-FPM et mod_php pour Apache à php-cgi, FrankenPHP et LiteSpeed. The Hacker News souligne que même une simple page « Hello World » exécutée sur une version vulnérable peut être attaquée. Le pire scénario concerne mod_php : une seule requête envoyée par une personne sans compte peut déclencher l’attaque avant l’exécution du moindre code de l’application. Aucun module de sécurité ni écran de connexion ne peut donc la détecter.

Wordfence, l’éditeur de solutions de sécurité pour WordPress, a indiqué aux propriétaires de sites, comme l’a rapporté The Verge, que le correctif ne pouvait pas être distribué par les mises à jour automatiques et qu’ils devaient déterminer qui était responsable de leur PHP. Laravel Forge a tenu le même discours à ses clients au sujet de ses serveurs : ses mises à jour de sécurité automatiques ne corrigent pas PHP, et les mises à niveau sans surveillance d’Ubuntu ne récupèrent que les paquets du dépôt Ubuntu, pas ceux des dépôts tiers à partir desquels Forge installe PHP.

Ces sources de paquets n’ont pas réagi au même rythme. Le jour de la publication, le service de gestion de sites mySites.guru a signalé que cPanel EasyApache 4 proposait des versions corrigées quelques minutes après les avis de sécurité, tandis que le PPA d’Ondřej Surý — la source de paquets Ubuntu utilisée par Laravel Forge — et le dépôt de Remi n’en proposaient encore aucune. InMotion Hosting a indiqué que ses serveurs mutualisés et WordPress attendaient les versions de CloudLinux. Parmi les sites en ligne surveillés par mySites.guru, 0,08 % déclaraient utiliser une version corrigée de PHP à 13 h 52 UTC.

Le numéro de version peut induire en erreur

Vérifier la version est moins simple qu’il n’y paraît. Ubuntu, Debian et Red Hat rétroportent les correctifs de sécurité sans modifier le numéro de version en amont : un serveur Ubuntu 24.04 corrigé indique donc toujours un paquet en version 8.3.6. The Hacker News, qui cite Debian, recommande de rechercher la CVE dans le journal des modifications du paquet plutôt que de se fier au numéro de version. mySites.guru signale un deuxième piège : le binaire PHP qui répond à la commande php -v dans le terminal n’est souvent pas celui qui sert les pages. Il faut donc vérifier la version indiquée par le site lui-même.

Encore faut-il ensuite que le correctif soit chargé. L’avis de PHP et Forge insistent tous deux sur la nécessité de redémarrer Apache, PHP-FPM et tous les processus de longue durée. Les workers de traitement des files d’attente et les autres processus d’arrière-plan continuent d’utiliser l’ancien interpréteur tant qu’ils ne sont pas redémarrés, même si les fichiers corrigés sont déjà en place sur le disque.

Qui ne recevra pas de correctif officiel

Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 selon CVSS v4.0. Le projet PHP ne fournit rien aux versions 8.1 et antérieures, hormis des rétroportages minimaux du code source pour les versions 7.4, 8.0 et 8.1, destinés aux personnes qui compilent elles-mêmes PHP. Certains fournisseurs comblent cette lacune : InMotion indique que cPanel a rétroporté les correctifs pour ses paquets des versions 7.4 à 8.1 et que CloudLinux corrige toutes les versions qu’il distribue, tandis que CentOS 7 ne recevra aucun correctif.

Les sites concernés sont loin d’être rares. La veille de la publication, 22,7 % des sites Joomla et WordPress en ligne suivis par mySites.guru utilisaient PHP 8.1 ou une version antérieure, et 16,6 % tournaient encore sous PHP 7 ou une version plus ancienne. L’entreprise attribue en partie ce retard à WordPress lui-même, qui recommande PHP 8.3 tout en indiquant que la version 7.4, abandonnée depuis longtemps, reste compatible. PHP 8.2 bénéficie de ce correctif, mais son support de sécurité prendra fin le 31 décembre 2026.

Ce que bloque le réglage provisoire

La solution de contournement qui circulait avant la publication, à savoir définir session.upload_progress.enabled=0, est bien réelle, mais ne règle qu’une partie du problème. PHP précise qu’elle bloque les chemins d’attaque par session confirmés pour CVE-2026-109619, mais pas les autres variantes. Le réglage doit être appliqué dans php.ini ou dans la configuration du serveur ou du pool, puis tous les workers doivent être redémarrés. Sous PHP 8.5, fatal_error_backtraces=0 bloque un autre chemin confirmé. Aucun de ces réglages ne concerne CVE-2026-109618. Pour cette faille, PHP recommande un paramètre memory_limit=-1 impossible à remplacer, une valeur basse pour post_max_size et des limites de taille des requêtes au niveau du serveur web ou du proxy. PHP précise qu’aucune mesure d’atténuation ne protège complètement. InMotion souligne que WordPress, Joomla, Drupal, Magento et PrestaShop n’utilisent pas la progression des téléversements : la désactiver ne casse donc rien pour ces systèmes.

Cloudflare a activé des règles de pare-feu sur toutes ses formules. Son directeur technique, Dane Knecht, les a qualifiées de solution provisoire. Comme le fait remarquer mySites.guru, elles ne sont utiles que si le serveur situé derrière Cloudflare refuse le trafic qui le contourne pour accéder directement à son adresse IP.

Les attaques à ce jour

watchTowr indique que ses pots de miel ont enregistré des tentatives d’exploitation des deux failles le jour de la publication, et Cloudflare a observé des attaquants modifier leurs charges utiles pour contourner ses règles. Aucune source n’a confirmé l’intrusion réussie dans un serveur en particulier. Certains opérateurs n’ont pris aucun risque : The Hacker News rapporte que BambooHR a mis son service hors ligne et que des services publics néerlandais, dont DigiD, ont été coupés par précaution. Le CERT de l’UE et le National Cyber Security Centre du Royaume-Uni ont recommandé aux organisations incapables d’appliquer le correctif d’isoler les applications exposées ou de les mettre hors ligne.

Les failles ont été découvertes par Wiz Research, Calif et l’équipe Codex Security d’OpenAI. Selon la PHP Foundation, des signes de la faille de mémoire étaient apparus lors d’un audit en 2024, mais le correctif est resté bloqué pendant des mois, un retard qu’elle a qualifié de « défaillance structurelle ». Les chercheurs affirment que les modèles d’IA ont contribué à transformer ces bogues vieux de dix ans en exploits fonctionnels en une semaine environ.

Pour publier ce correctif, PHP a eu besoin d’un audit, de plusieurs mois d’impasse et d’une fuite. Pour un site hébergé sur un serveur mutualisé, la dernière étape consiste à ouvrir un ticket auprès de l’assistance.

Étiquettes: Cloudflare, PHP, PHP2Shell, vulnérabilités, WordPress