Failles PHP2Shell : ce qui s’est passé, quoi vérifier

Mardi 20 octobre, l’équipe qui maintient PHP a publié une annonce inhabituelle. Pas de détails, juste une date : une mise à jour de sécurité critique sortirait le lendemain à 14 h UTC (16 h à Paris). Quand les gens qui font tourner les deux tiers du web vous préviennent ainsi, ce n’est pas bon signe.

Le lendemain, on a su : deux failles permettent à un inconnu, sans compte ni mot de passe, d’exécuter ses propres commandes sur un serveur web qui fait tourner PHP. Les chercheurs les ont baptisées PHP2Shell. Si vous avez un site WordPress, une boutique en ligne ou un simple site vitrine, il y a de bonnes chances que vous soyez concerné. Voici ce qui s’est passé et ce qu’il faut vérifier cette semaine.

Ce qui s’est passé, dans l’ordre

L’histoire commence bien avant la panique d’octobre. Selon l’éditeur de sécurité SentinelOne, l’entreprise Calif et OpenAI ont signalé chacun de leur côté la cause du problème à l’équipe de sécurité de PHP le 11 août 2026. Wiz a ensuite rapporté d’autres façons de l’exploiter le 24 août. Détail qui compte : Calif et Wiz disent s’être appuyés sur des modèles d’intelligence artificielle.

Suit la « divulgation coordonnée » : le correctif est écrit en silence, les distributions Linux le reçoivent en avance, et tout le monde se tait jusqu’à une date convenue, l’embargo. La sortie publique était prévue pour le 22 octobre.

Cela ne s’est pas passé comme prévu :

17 octobre : Amazon détecte, sur son réseau de serveurs-leurres, une tentative d’exploitation venue d’une adresse anonymisée. Quatre jours avant toute annonce publique. Amazon dit ne pas savoir comment l’attaquant avait obtenu l’information.
20 octobre : les identifiants des deux failles, CVE-2026-109618 et CVE-2026-109619, fuitent sur Hacker News et les réseaux sociaux. PHP annonce sa mise à jour pour le lendemain 14 h UTC, avec la possibilité de la sortir plus tôt. Le CERT-EU publie un avis. La société watchTowr confirme publiquement que les failles sont réelles et dit avoir reproduit la première.
21 octobre : sortie de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, avec l’avis de sécurité officiel. La publication a donc été avancée d’un jour à cause de la fuite. Cloudflare déploie en urgence des règles de filtrage. Amazon et watchTowr rapportent des tentatives d’attaque le jour même sur leurs leurres.
23 octobre : PHP publie un avis complémentaire sur la fonction de suivi des téléversements de session, liée à un problème distinct.

Deux mois et demi entre le signalement et le correctif, ce n’est pas scandaleux pour une faille aussi profonde. Mais SentinelOne rapporte que des signes du problème de mémoire en cause avaient déjà été repérés lors d’un audit de PHP en 2024, sans qu’on ait alors démontré d’attaque possible, et que la correction avait calé. La PHP Foundation parle elle-même d’un échec structurel de son processus de sécurité. On peut saluer la franchise.

Comment ça marche, sans jargon

Les deux failles relèvent de la corruption mémoire. Pour répondre à chaque visiteur, PHP réserve de la mémoire, y range les informations de la requête (formulaire, fichiers joints, session), puis fait le ménage. Si ce ménage se passe mal, un attaquant peut glisser ses propres données là où PHP s’attend à trouver les siennes, et finir par lui faire exécuter n’importe quoi.

La première faille : le ménage sur une table à moitié mise

Imaginez un serveur de restaurant qui dresse une table. Au milieu de l’opération, on lui crie de tout arrêter. Il part. Arrive l’équipe de débarrassage, qui suit sa fiche à la lettre : « couteau en place 3, verre en place 5 ». Sauf que la fiche a été remplie à moitié, et que certaines lignes contiennent n’importe quoi. L’équipe va chercher des objets qui n’existent pas, à des endroits qui ne sont pas les bons.

C’est à peu près ce que fait CVE-2026-109618. Quand PHP manque de mémoire, il interrompt brutalement la requête. Si cela arrive au mauvais moment, certaines de ses données internes ne sont qu’à moitié initialisées. La phase de nettoyage qui suit les traite pourtant comme valides. Et l’attaquant sait provoquer ce manque de mémoire à volonté, en envoyant un formulaire construit pour gonfler la consommation de PHP tout en restant sous les limites apparentes : des centaines d’en-têtes, des champs de fichier vides, des noms de champs imbriqués à l’infini.

La seconde faille : le ticket de vestiaire qui marche encore

Vous déposez votre manteau au vestiaire, vous le récupérez, vous partez. Mais l’employé oublie de déchirer votre ticket. La place est réattribuée au client suivant. Si quelqu’un ramasse votre vieux ticket, il peut se présenter au comptoir et repartir avec le manteau d’un autre, ou y glisser quelque chose.

Les spécialistes appellent ça un use-after-free : utiliser une zone mémoire après l’avoir libérée. Avec CVE-2026-109619, un « ticket » lié à une requête (un état interne concernant les erreurs ou la session) survit à la libération de la mémoire correspondante. Une requête suivante, traitée par le même processus PHP, s’en sert avant qu’il soit remis à zéro. L’attaquant envoie donc deux requêtes : la première laisse le ticket traîner, la seconde s’en sert.

Pourquoi on parle surtout de mod_php

PHP peut être branché au serveur web de plusieurs façons : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. L’avis officiel les cite tous comme à mettre à jour. Mais l’attaque complète n’a été démontrée que sur mod_php, où une requête anonyme suffit à déclencher l’attaque avant même que le code de votre site ne s’exécute. Ni WordPress, ni votre extension de sécurité n’ont leur mot à dire. Pour PHP-FPM, configuration très répandue chez les hébergeurs, l’exposition est jugée plausible par l’analyse du code ; pour la seconde faille, une attaque a été validée sur FPM dans un scénario lié aux sessions. On ne parierait pas un site client sur cette nuance.

Pourquoi c’est grave

La note officielle est de 9,2 sur 10 (CVSS v4.0) pour chacune des deux failles. Le message qui a fuité parlait de 10 sur 10 : ce chiffre n’a jamais été confirmé par PHP. La note est un peu tempérée parce que l’attaque est jugée complexe et dépend de certaines conditions. Ne vous y fiez pas trop : « complexe » veut dire complexe à mettre au point, pas à lancer une fois l’outil écrit. Et des codes prétendant exploiter PHP2Shell circulent déjà publiquement.

Le vrai problème, c’est l’étendue. D’après W3Techs, PHP est utilisé par 69,2 % des sites web dont on connaît le langage serveur (relevé du 25 octobre 2026). WordPress, écrit en PHP, fait tourner à lui seul 39,6 % de tous les sites. Ajoutez Prestashop, Joomla, Drupal et nombre d’outils métiers maison. Une faille dans une extension WordPress touche les sites qui l’utilisent ; une faille dans PHP lui-même touche tout ce qui est construit dessus.

Sur l’exploitation réelle, soyons précis, car les informations se contredisent. Amazon, watchTowr et Datadog rapportent des tentatives d’attaque. Cloudflare a parlé de premières attaques dès le 21 au matin. D’autres éditeurs, comme Sophos ou Bitdefender, disaient au même moment n’en voir aucune dans leurs données. L’agence américaine CISA n’avait pas inscrit les failles dans son catalogue des vulnérabilités exploitées au 23 octobre. Et plusieurs observations viennent de serveurs-leurres : on sait que des attaquants essaient, on ne sait pas combien réussissent. Notre lecture : quand des outils publics existent et que des acteurs différents tentent leur chance moins de vingt-quatre heures après le correctif, il faut considérer tout serveur resté sans mise à jour comme exposé. Le CERT-FR, le centre gouvernemental de veille et de réponse aux attaques, a d’ailleurs publié une alerte dédiée (CERTFR-2026-ALE-014).

La presse a aussi évoqué des sites publics mis hors ligne par précaution, en France comme aux Pays-Bas, et des failles qui remonteraient jusqu’à PHP 5. Ni l’un ni l’autre n’a été confirmé officiellement à ce jour. L’avis de PHP ne traite que des versions encore maintenues. Ce qui est sûr, c’est que les versions 5.x et 7.x ne recevront aucun correctif officiel du projet : seuls des correctifs minimaux pour 7.4, 8.0 et 8.1 sont fournis, à compiler soi-même.

Qui est exposé, concrètement

Tout site qui tourne sur une version de PHP antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, et qui n’a pas reçu de correctif de la part de son hébergeur ou de sa distribution Linux. C’est large. En pratique, on peut distinguer trois situations :

Vous êtes sur un hébergement mutualisé chez un acteur sérieux. Il a très probablement reçu les correctifs avant la date publique et les a appliqués. Très probablement ne veut pas dire certainement, et la date compte : une mise à jour faite le 21 au soir ou le 24 n’offre pas la même tranquillité.
Vous avez un serveur dédié ou un VPS « géré par vous-même » ou par un prestataire disparu. Personne n’a rien mis à jour à votre place. C’est le cas le plus dangereux.
Votre site tourne encore en PHP 7 ou PHP 5. W3Techs compte encore 7,7 % de sites PHP en version 5 et 26,8 % en version 7. Si c’est votre cas, ce n’est plus une question de faille du mois : votre socle n’est plus maintenu, et chaque nouvelle découverte vous trouvera sans correctif.

Ce que risque un site vitrine

« Mon site, c’est cinq pages et un formulaire de contact, qui irait s’y intéresser ? » Personne, justement. Des robots balaient Internet et prennent tout ce qui répond. Une fois dans la place, l’attaquant agit avec les droits du serveur web, ce qui suffit pour :

Voler des données. Les messages du formulaire de contact, les comptes clients, les identifiants de la base de données, qui se trouvent en clair dans le fichier de configuration de WordPress.
Défigurer le site, ou plus discrètement y injecter des pages de pharmacie et de casino que seul Google verra. Vous l’apprendrez quand votre référencement s’effondrera.
Envoyer du spam depuis votre serveur. Résultat : votre domaine finit sur des listes noires, et ce sont vos devis et vos factures qui n’arrivent plus chez vos clients.
Chiffrer ou effacer vos fichiers et réclamer une rançon. Sur un site vitrine, c’est surtout la sauvegarde qui fait la différence entre une matinée perdue et trois semaines sans site.

Quoi faire tout de suite

1. Vérifier la version de PHP

Le plus simple : votre panneau d’hébergement. Chez la plupart des hébergeurs, une rubrique « PHP », « Configuration » ou « Langages » affiche la version utilisée par chaque site. Dans WordPress, le menu Outils > Santé du site > Informations > Serveur donne aussi la version.

Sinon, créez un fichier info.php contenant simplement <?php phpinfo();, déposez-le à la racine du site, ouvrez-le dans votre navigateur, notez la version en haut de la page, puis supprimez-le immédiatement. Laissé en ligne, il affiche le plan de la maison sur la porte.

Un piège à connaître : sur certaines distributions Linux, le correctif est appliqué sans changer le numéro principal. Un serveur Debian ou Red Hat peut afficher 8.2.x avec un numéro plus ancien et pourtant être corrigé. Dans ce cas, seule la réponse de l’hébergeur fait foi.

2. Poser les bonnes questions à votre hébergeur

Un message court et précis ; « nos serveurs sont à jour » n’est pas une réponse :

Les correctifs CVE-2026-109618 et CVE-2026-109619 sont-ils appliqués sur le serveur qui héberge mon site ? À quelle date ?
Mon site utilise-t-il mod_php, PHP-FPM ou autre chose ?
Avez-vous observé des tentatives d’exploitation sur vos serveurs, et sur mon site en particulier ?
Quelles sauvegardes gardez-vous de mon site, sur combien de jours, et où sont-elles stockées ?
Si mon site tourne en PHP 8.1 ou plus ancien, quel est votre plan ?

3. Avoir une sauvegarde hors du serveur

Une sauvegarde stockée sur le même serveur que le site ne sert à rien le jour où ce serveur est compromis : l’attaquant y a accès comme au reste. Faites une copie complète (fichiers et base de données) et stockez-la ailleurs : un stockage en ligne, un disque à vous, peu importe, tant que ce n’est pas sur la machine attaquable. Faites-en une maintenant. Si vous découvrez plus tard une intrusion, une sauvegarde antérieure au 17 octobre vaudra de l’or ; Sophos conseille même, par prudence, d’examiner l’activité des systèmes exposés depuis le 1er août.

4. Chercher les signes de compromission

Sans être expert, vous pouvez repérer les signaux les plus courants :

un compte administrateur WordPress que personne ne reconnaît ;
des fichiers .php dans le dossier des médias (wp-content/uploads), où il ne devrait y avoir que des images et des PDF ;
des fichiers modifiés récemment alors que personne n’a touché au site ;
des redirections étranges, surtout depuis Google ou sur mobile ;
une alerte dans Google Search Console, ou un pic d’envois d’e-mails signalé par l’hébergeur.

Au moindre doute, ne nettoyez pas vous-même : effacer un fichier suspect en laisse souvent trois autres en place.

5. Changer les mots de passe, dans le bon ordre

Si votre serveur a été corrigé tard, ou si vous n’avez aucune certitude, partez du principe que ce qui était sur le serveur a pu être lu. Changez, après la mise à jour de PHP (sinon c’est inutile) : l’accès au panneau d’hébergement, les accès FTP ou SFTP, le mot de passe de la base de données, ceux de tous les administrateurs du site, et les clés de sécurité de WordPress, qui déconnectent toutes les sessions ouvertes. Si vous utilisiez le même mot de passe ailleurs, changez-le aussi là-bas. C’est fastidieux, mais moins qu’un domaine sur liste noire.

La leçon : ceux qui n’ont pas paniqué

Le 21 octobre, deux types d’entreprises ont vécu deux journées très différentes. Celles dont le site était suivi ont reçu, au mieux, un message de leur prestataire : « correctif appliqué, sauvegarde vérifiée, rien d’anormal dans les journaux ». Les autres ont découvert le problème dans la presse, puis cherché pendant une heure qui avait les accès à l’hébergement.

Il n’y a rien de magique là-dedans. Une faille comme PHP2Shell ne se prévoit pas, mais la réponse, elle, se prépare : savoir où est hébergé le site et avec quelle version, avoir des sauvegardes testées et stockées ailleurs, appliquer les mises à jour dans les heures qui suivent leur sortie plutôt qu’au prochain « quand on aura le temps ». C’est un travail invisible quand tout va bien, et c’est pour ça qu’il est rarement fait.

Et il y en aura d’autres. Si l’intelligence artificielle aide désormais à fouiller le code de logiciels aussi anciens que PHP, les découvertes vont plutôt s’accélérer.

Encore faut-il savoir qui a les clés. Si vous ne savez pas qui détient les accès à votre hébergement ou à votre nom de domaine, commencez par là : on explique pourquoi dans notre article sur la propriété de son site. Et si vous préparez de toute façon une refonte, c’est le bon moment pour repartir sur un socle à jour, sans perdre votre référencement : la méthode est dans cet article.

Chez APE Com’, c’est pour cette raison que toutes nos offres, de l’Essentielle à la Sur-mesure en passant par Présence et Existence, incluent l’hébergement, la maintenance, les mises à jour et les sauvegardes : on préfère que ce travail soit fait, plutôt que de le vendre en urgence le jour où il manque. Si vous ne savez pas répondre aux questions de cet article pour votre propre site, ou si la réponse de votre hébergeur vous laisse perplexe, écrivez-nous, on vous aidera à y voir clair.

Failles PHP2Shell : ce qui s’est passé et ce que vous devez vérifier