Failles PHP2Shell : que vérifier sur votre hébergement

Éléphant PHP en pierre fissuré par un éclair orange dans une salle de serveurs éclairée de rouge, avec le texte « PHP2Shell, vérifiez votre PHP » et « 21 octobre »

Article de Kami

Selon Al Jazeera et Reuters (22 octobre 2026), la NSA américaine a conseillé de mettre hors ligne les sites qu’on ne peut pas mettre à jour sur-le-champ, et le ministère français de l’Intérieur a désactivé les sites officiels de services d’administration locale. La cause tient en deux failles PHP, baptisées PHP2Shell. Si vous hébergez un WordPress, un forum ou le panneau web d’un serveur de jeu, le sujet vous concerne, et il ne se règle pas dans WordPress.

Pourquoi ces failles PHP échappent aux mises à jour de WordPress

Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619 (un CVE est le numéro public attribué à une faille connue). L’équipe PHP les note 9,2 sur 10 selon l’échelle CVSS v4, qui mesure la gravité d’une faille de 0 à 10. IT-Connect précise que d’autres sources annoncent 10 sur 10. Dans les deux cas, il s’agit d’une exécution de code à distance (RCE) : une personne qui ne possède aucun compte peut faire tourner ses propres commandes sur votre serveur.

IT-Connect, Florian Burnel, 21 octobre 2026 : l’article en français sur les correctifs et les versions concernées.

Ces failles PHP se trouvent dans le moteur du langage qui fait tourner le site, pas dans le code de WordPress ni dans celui d’une extension. Mettre à jour WordPress, son thème et ses plugins ne change donc rien. Les annonces de version publiées le 21 octobre sur php.net sont sans ambiguïté : « There are no complete mitigations, updating is the only safe choice. » (Il n’existe aucune parade complète, mettre à jour est le seul choix sûr.)

Selon IT-Connect, tous les modes qui servent des requêtes web sont concernés : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Ce sont les différentes manières dont un serveur fait exécuter PHP. Le risque est jugé maximal avec mod_php, où une requête sans authentification peut déclencher l’attaque avant que le code du site ne s’exécute. Wiz affirme avoir obtenu une exécution de code sans authentification sur les images de WordPress, Drupal et Joomla qu’il a testées.

Des attaques déjà en cours, selon les sources

Les sources ne disent pas toutes la même chose. Le 21 octobre en fin d’après-midi (heure de New York), Huntress, un éditeur de sécurité, n’avait observé aucune exploitation chez ses partenaires, tout en notant que d’autres chercheurs signalaient des attaques. Fortune rapporte qu’Amazon (AWS) parle d’une faille « now being broadly exploited in the wild » (désormais exploitée à grande échelle dans la nature), et que Cloudflare a compté des centaines de milliers de tentatives en deux heures, puis des millions le soir du 21.

Une fuite a accéléré le calendrier. Huntress raconte qu’un message annonçant la divulgation a circulé le 20 octobre, et que PHP a publié ses correctifs le lendemain, plus tôt que prévu. Sur l’ampleur du parc touché, Fortune cite 22,6 millions d’instances potentiellement vulnérables d’après Palo Alto Networks. Le chiffre de « 70 % du web » vient de Wiz, et Fortune précise ne pas l’avoir vérifié.

Wiz Research, Sagi Tzadik, Shir Tamari, Nir Ohfeld et Tomer Schwartz, 21 octobre 2026 : l’analyse à l’origine du chiffre de 70 %.

Une découverte à deux, avec des IA

Les deux failles PHP ont été trouvées avec l’aide de modèles d’IA. D’après Al Jazeera, Calif, une société de sécurité, a signalé la première le 11 août en travaillant avec OpenAI, qui l’avait invitée dans son programme Patch the Planet. Fortune date la découverte au 1er août et cite GPT-5.6 Sol. Wiz, de son côté, indique avoir identifié son premier défaut le 19 août avec Gemini 4 Argon, GPT-5.6 Sol et son outil Wiz Atlas, puis alerté l’équipe PHP le 24 août. Les correctifs sont sortis le 21 octobre, deux mois après.

Nous avions déjà raconté comment OpenAI a livré GPT-5.6-Cyber, un modèle conçu pour trouver des failles. PHP2Shell illustre ce que ces outils changent des deux côtés, et la Fondation PHP prévient que ces outils « find bugs faster than ever, for defenders and attackers alike » (trouvent des failles plus vite que jamais, pour les défenseurs comme pour les attaquants).

La check-list pour votre hébergement

Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Face à ces failles PHP, les cinq points ci-dessous reprennent ce que disent PHP, IT-Connect et Huntress.

Lisez la version de PHP que le site utilise vraiment. Dans WordPress, ouvrez Outils, Santé du site, onglet Info, section Serveur. Sinon, une page phpinfo() déposée temporairement affiche la même information (supprimez-la ensuite). La commande php -v en ligne de commande peut annoncer une autre version que celle du serveur web.
Visez une version corrigée. Sur Debian et Ubuntu, IT-Connect avertit que le numéro de version reste identique après correction : c’est la révision du paquet qui change (par exemple 8.1.34-9 sur le dépôt Sury). Un site qui affiche encore l’ancien numéro n’est donc pas forcément vulnérable. Demandez ou vérifiez la révision.
Hébergement mutualisé : écrivez au support. Vous ne contrôlez pas PHP, demandez la date du correctif. Nous n’avons trouvé, dans les sources consultées, aucune déclaration d’un hébergeur français précis, et nous n’en affirmons donc aucune.
VPS ou serveur dédié : mettez à jour le paquet, puis redémarrez. PHP-FPM ou Apache doivent être relancés pour que le correctif prenne effet. Priorité aux serveurs ouverts sur Internet.
PHP 8.1 ou plus ancien : planifiez la migration. L’équipe PHP n’a publié que des rétroportages minimaux du code source pour les versions 7.4, 8.0 et 8.1, à compiler soi-même, et rien d’officiel en dessous. PHP 8.2 cessera aussi d’être corrigée le 31 décembre 2026.

Si vous ne pouvez pas mettre à jour, ou si vous avez un doute

Pour une version en fin de vie, Huntress conseille de la retirer de l’accès public ou de la placer derrière un VPN ou un pare-feu applicatif (WAF, un filtre qui inspecte les requêtes web). Des réglages de php.ini circulent comme palliatif, mais IT-Connect souligne qu’ils ne couvrent qu’une partie des chemins d’attaque, ce qui rejoint l’avertissement de PHP : aucune configuration ne remplace la mise à jour.

Si vous soupçonnez une intrusion, Huntress recommande d’isoler le serveur, de conserver les journaux web et PHP, puis de chercher des fichiers inconnus dans le dossier du site, des tâches planifiées et des comptes créés sans vous. Wiz a aussi démontré une fuite de la mémoire de PHP, qui peut contenir des mots de passe ou des clés d’API selon IT-Connect. Notre lecture : sur un serveur resté exposé sans correctif, changer ces secrets après la mise à jour est une précaution raisonnable.