PHP2Shell : près d’un site PHP sur deux n’a pas de correctif officiel, et ce n’est pas toujours de la négligence

Développement Web / 22 Oct 2026

Agence marketing digital Paris, Seo / Google Ads

par Emmanuel, Développeur WEB/Responsable technique SEO

Le 21 octobre 2026 à 16 h, heure de Paris, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent deux failles critiques permettant d’exécuter du code sur un serveur à distance, sans identifiant (avis officiel php.net). Les premières attaques ont été repérées le jour même. Selon W3Techs, environ 48 % des sites PHP tournent pourtant sur une version 8.1 ou plus ancienne, pour laquelle aucune version officielle n’existe. Derrière ces sites, il y a rarement de la négligence : un budget, une décision du client, ou un site devenu trop ancien pour suivre. Ces raisons expliquent le retard, elles ne réduisent pas le risque. Il faut donc un plan adapté à chacune.

48 heures entre une fuite et un correctif d’urgence

L’histoire commence par une fuite. Le 20 octobre au matin, un message publié sur Hacker News annonce deux failles critiques dans PHP avant leur divulgation coordonnée. Il est retiré, mais les captures circulent. Quelques heures plus tard, la société watchTowr confirme leur existence et indique avoir reproduit l’une d’elles (Huntress). La divulgation était prévue sous embargo le jeudi 22 octobre. L’équipe PHP avance la publication au mercredi 21 à 14 h UTC.

Le 21 octobre, avant même la sortie du correctif, Patchstack confirme des cas d’exploitation active (Patchstack) et le directeur technique de Cloudflare, Dane Knecht, déclare voir « émerger les premières attaques » (Tenable). Cloudflare déploie des règles de pare-feu applicatif pour tous ses clients, offre gratuite comprise, en précisant qu’elles ne remplacent pas le correctif (Journal du Geek).

La faille est dans le moteur, pas dans votre CMS

Les deux failles, CVE-2026-109618 et CVE-2026-109619, sont notées 9.2 sur 10 en CVSS v4.0 (php.net). Elles touchent l’interpréteur PHP lui-même. Conséquence directe : WordPress, Drupal, Magento, Joomla ou Laravel sont exposés dès qu’ils tournent sur une version vulnérable, quelle que soit leur propre version (Patchstack). Mettre à jour vos extensions ce matin ne change rien au problème.

La première faille exploite la façon dont PHP gère un manque de mémoire : si l’erreur survient au mauvais moment, PHP nettoie des données à moitié construites comme si elles étaient valides (avis GitHub GHSA-w8hw). La seconde exploite un reste de la requête précédente, conservé par erreur et réutilisé par la suivante (avis GitHub GHSA-6wmf). Dans les deux cas, un attaquant n’a besoin ni de compte ni d’action de votre part.

Le risque le plus élevé concerne les serveurs Apache avec mod_php : l’équipe PHP y décrit un exploit démontré où une seule requête déclenche l’attaque avant que le code du site ne s’exécute (php.net). PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont aussi concernés. Et la discrétion ne protège pas : plusieurs workers et du trafic concurrent augmentent le nombre de tentatives nécessaires, sans empêcher l’attaque (GHSA-w8hw).

Près d’un site PHP sur deux est hors du périmètre du correctif

Les versions officielles ne couvrent que les branches 8.2 à 8.5. En croisant les deux tableaux de W3Techs du 21 octobre (versions majeures, sous-versions PHP 8), on obtient la répartition suivante parmi les sites PHP : 51,6 % sur une branche corrigée officiellement, 13,7 % en PHP 8.0 ou 8.1, 27,0 % en PHP 7 et 7,8 % en PHP 5 ou plus ancien.

Deux nuances honnêtes. Un site déclaré en 8.1 peut déjà être protégé, parce que les distributions Linux et les fournisseurs de support long terme ont reçu les correctifs en avance et les rétroportent sans changer le numéro de version (php.net). À l’inverse, un site en 8.3 reste vulnérable tant que la 8.3.36 n’est pas installée. Le chiffre dit où se trouve le risque structurel, pas qui est piraté.

Pourquoi la version n’a pas été montée

Il serait facile d’écrire que 48 % des sites sont mal tenus. Ce serait faux, et ça n’aiderait personne à décider. Quand on reprend un site resté en PHP 7 ou en 8.0, on retrouve presque toujours l’une de ces trois situations, souvent combinées. Chacune appelle une réponse différente face à PHP2Shell.

Le budget : une montée de version qui coûte une refonte

Changer de version de PHP n’est pas toujours un réglage. Passer de PHP 7 à PHP 8 demande souvent des modifications importantes du code (MacGeneration). Sur un site récent et propre, c’est une intervention de maintenance. Sur un site construit il y a longtemps, la montée de version oblige parfois à revoir toute la structure : on ne parle plus d’une mise à jour mais d’une refonte, avec le budget qui va avec. Beaucoup d’entreprises ont repoussé cette dépense, de façon rationnelle tant que le site fonctionnait.

Ce qui change avec PHP2Shell, c’est le coût de l’attente. Reporter la refonte revenait jusqu’ici à accepter une dette technique. C’est maintenant exposer un serveur à une prise de contrôle à distance, déjà exploitée. La refonte reste un projet ; la protection immédiate, elle, ne peut plus attendre ce projet.

Le client n’a pas validé la montée de version

Deuxième cas, très fréquent : la montée de version a été proposée, mais jamais validée. Le client a préféré ne pas toucher à un site qui marche, par crainte d’une régression, faute de budget ou parce que le sujet ne semblait pas prioritaire. C’est une décision légitime, et c’est la sienne. Mais elle a été prise avant qu’une faille de ce niveau existe, avec un autre rapport entre risque et coût.

Notre position est simple : la décision appartient toujours au client, mais elle doit être reprise avec les nouvelles données. On lui présente le risque, les options et leur coût, et on applique dès maintenant les mesures d’atténuation qui ne demandent pas de validation lourde.

Le site est trop ancien pour suivre

Troisième cas, le plus délicat : le site ne peut pas passer en PHP 8 sans casser. Les causes qu’on rencontre sont toujours les mêmes : des plugins anciens qui ne sont plus mis à jour, des thèmes que leur éditeur ne maintient plus, et des développements sur mesure ajoutés au fil des années par plusieurs intervenants successifs, sans documentation commune. Certains plugins et thèmes ne supportent toujours pas PHP 8.2 et plus, et une montée de version forcée peut les casser (Wordify).

Sur ces sites, chaque montée de version suppose d’auditer le code, de remplacer ce qui n’est plus maintenu et de tout retester. C’est faisable, mais pas en une journée. C’est précisément pour ces sites que les mesures d’atténuation et la protection en amont prennent tout leur sens.

Changer de plateforme ne règle pas l’urgence

Pour un site e-commerce vieillissant, la faille peut sembler être l’occasion de tout reprendre, par exemple en basculant sur Shopify. L’idée peut être bonne à moyen terme. Elle ne répond pas à l’urgence : une migration de plateforme demande un temps conséquent, peut entraîner une coupure et une perte de chiffre d’affaires, et le site actuel reste exposé pendant toute la durée de la bascule. Si vous partez sur cette voie, protégez d’abord le site existant, puis migrez.

Même raisonnement pour l’objection la plus courante, « mettre à jour en urgence risque de casser le site ». C’est vrai. Mais un site en panne quelques heures se répare ; un serveur compromis impose de chercher des portes dérobées, de restaurer et de prévenir les personnes dont les données ont pu fuiter. L’arbitrage n’est donc pas entre mettre à jour et ne rien faire, il est entre plusieurs façons de réduire le risque, dans le bon ordre.

Que faire selon votre situation

Votre site tourne en PHP 8.2, 8.3, 8.4 ou 8.5. Installez la version corrigée de votre branche, puis redémarrez tous les processus PHP : un simple rechargement de configuration peut ne pas suffire, car un worker peut conserver l’état vulnérable (php.net). Sur un hébergement mutualisé, vérifiez dans votre panneau que l’hébergeur a bien déployé la mise à jour. En PHP 8.2, prévoyez dès maintenant la suite : cette branche n’aura plus de correctifs de sécurité après le 31 décembre 2026.

Votre site tourne en PHP 8.1, 8.0 ou 7.4, sur un serveur sous Debian, Ubuntu ou RHEL. Vérifiez si votre distribution ou votre fournisseur de support long terme a publié un paquet corrigé. L’équipe PHP a aussi publié des correctifs sources minimaux pour ces trois branches sur GitHub, destinés à ceux qui compilent PHP eux-mêmes (php.net). Si vous utilisiez le dépôt communautaire remirepo, il n’avait pas de mise à jour le 21 octobre : passez aux paquets de votre distribution ou compilez.

Votre site tourne sur une version plus ancienne, ou aucun correctif n’est disponible. Appliquez les mesures d’atténuation ci-dessous, placez le site derrière un pare-feu applicatif, et lancez la montée de version ou la refonte. Si le site traite des données sensibles et qu’aucune de ces options n’est possible rapidement, CERT-EU recommande de l’isoler d’Internet et le NCSC britannique évoque la mise hors ligne temporaire (Journal du Geek, Help Net Security).

Vous utilisez Docker. Reconstruisez l’image avec la version corrigée et remplacez les conteneurs : un simple redémarrage relance l’ancien binaire (Teramont).

Vous ne savez pas quelle version sert votre site. C’est la première chose à vérifier, auprès de votre prestataire ou dans votre panneau d’hébergement. La version affichée en ligne de commande peut différer de celle qui sert réellement le site (Teramont).

Les mesures d’atténuation achètent du temps, pas de la sécurité

L’avis officiel est sans ambiguïté : seule la mise à jour est une solution complète, les mesures suivantes réduisent l’exposition à certains chemins d’attaque sans rendre l’installation sûre (php.net).

Désactiver la progression d’upload de session : session.upload_progress.enabled = 0, dans le php.ini ou la configuration du pool, puis redémarrer tous les workers. Ne pas se fier à ini_set() ni aux fichiers .user.ini.
Abaisser la taille maximale des requêtes : post_max_size à 8M sans upload de fichiers, 32M si des uploads sont nécessaires, et limiter au niveau du serveur web le nombre de champs, de parties multipart et d’en-têtes.
En PHP 8.5 : fatal_error_backtraces = 0.
Ne pas utiliser RLIMIT_AS ni RLIMIT_DATA, qui déclenchent précisément l’échec d’allocation vulnérable. Masquer les erreurs (display_errors, opérateur @) ne sert à rien.

Un point mérite d’être précisé. L’avis officiel recommande de supprimer la limite mémoire de PHP (memory_limit = -1) pour fermer le chemin d’attaque par épuisement mémoire (php.net). C’est la mesure à appliquer en attendant le correctif. Mais sur un serveur partagé entre plusieurs sites, elle n’est acceptable qu’accompagnée d’une limite mémoire par client au niveau du système. Sur un serveur qui n’héberge qu’un site, l’absence de limite ne pose pas de problème particulier. Sur une grosse machine où plusieurs clients sont cloisonnés, un script qui s’emballe chez l’un peut consommer la mémoire de tous et bloquer des sites qui, eux, ne risquaient rien.

La protection la plus rapide à mettre en place pour un site qui ne peut pas être mis à jour reste en amont du serveur. Passer le domaine derrière Cloudflare permet de profiter des règles déployées contre les vecteurs connus, et d’ajouter des règles de limitation du nombre de requêtes, qui compliquent les attaques nécessitant de nombreuses tentatives. Ces règles bloquent les vecteurs identifiés, à condition que tout le trafic passe par elles ; elles ne couvrent pas les variantes qui apparaîtront dans les prochains jours.

Encadré : mon site a-t-il déjà été touché ?

Les signaux à rechercher, selon Huntress : des processus shell, curl ou wget lancés par php-fpm ou Apache, des commandes de reconnaissance comme whoami ou uname depuis le serveur web, des fichiers récents dans la racine du site, des tâches planifiées ou des comptes administrateur que personne n’a créés. Côté hébergement, on surveille aussi les hausses anormales de trafic et les tentatives de connexion SSH au serveur. En cas de doute, isolez le serveur et conservez les journaux avant toute remise en état.

Ce qui est établi, ce qui reste un pari

Établi : les deux failles, leur gravité, les versions corrigées, l’exposition maximale de mod_php, l’absence de version officielle pour PHP 8.1 et antérieurs, les premières exploitations du 21 octobre. Tout cela vient de l’avis officiel ou de sources concordantes.

Pari : que la vague d’attaques dure des mois. C’est l’avis du chercheur Kevin Beaumont, qui anticipe « une masse d’incidents », et de Hal Pomeranz, qui parle d’une « longue traîne » (Help Net Security). On le partage, parce que près de la moitié des sites PHP ne recevront pas de correctif automatique, pour les raisons décrites plus haut, mais c’est une projection.

Ce qui nous ferait changer de position : une mesure d’atténuation reconnue complète par l’équipe PHP, ou une confirmation officielle que les versions antérieures à 7.4 ne sont pas exploitables. D’ici là, la règle est simple : si votre site tourne sur une branche corrigée, c’est trente minutes de maintenance, faites-le aujourd’hui ; s’il tourne sur une version plus ancienne, c’est un projet, et il commence par les mesures d’atténuation cette semaine.

Les sites dont l’équipe dev de Let’s Clic assure la maintenance sont traités en priorité ; si votre site est géré ailleurs et que vous ne savez pas dans quelle situation il se trouve, elle peut faire le diagnostic avec vous.