Le 25 octobre 2026, un pentester installé au Royaume-Uni a exploité la faille PHP baptisée PHP2Shell sur un serveur que le chercheur James Pavur avait volontairement laissé sans correctif, avec la clé d'un portefeuille bitcoin en guise d'appât. Le défi « Steal My Bitcoin » est tombé un peu plus de 19 heures après son lancement, quatre jours après la publication des correctifs. Pour la sécurité des serveurs de PME suisses qui hébergent un site PHP, l'expérience montre à quelle vitesse une faille connue devient exploitable.

Comment le défi « Steal My Bitcoin » a-t-il été remporté ?

James Pavur, chercheur en sécurité informatique, a mis en ligne le site stealmybitcoin.com le samedi 24 octobre 2026. Selon Cybernews, son serveur tournait exprès sous PHP 8.4.26, une version antérieure aux correctifs du 21 octobre. Le premier participant capable d'y exécuter du code à distance pouvait récupérer la clé d'un portefeuille bitcoin.

La règle tenait en une phrase, rapporte BankInfoSecurity : une attaque complète, rejouée dans un seul fichier Python écrit avec la bibliothèque standard. La récompense, d'environ 500 dollars au départ, a été quadruplée par les dons de la communauté. Elle a atteint 0,02511679 bitcoin, soit environ 2'000 dollars.

Le vainqueur s'appelle Jaydip Modhwadia, pentester de 26 ans connu sous le pseudonyme KillaBoi sur GitHub. Il a obtenu l'exécution de code le dimanche 25 octobre 2026 à 15 h 47 UTC. Le compteur du site affichait alors 19,28 heures.

Ce chiffre surestime le temps d'attaque réel. Au lancement, l'adresse du défi menait à une page statique. Pavur ne l'a fait pointer vers une page PHP dynamique que vers 13 h UTC le dimanche, selon BankInfoSecurity. Modhwadia dit avoir travaillé environ trois heures au total, selon Journal du Coin.

Le portefeuille n'a d'ailleurs pas été vidé par l'attaquant. Pavur a reconnu avoir placé sur le serveur la clé du portefeuille parent, et non celle du sous-portefeuille qui contenait les fonds. Il a vérifié l'intrusion dans ses journaux, puis versé lui-même la prime.

Que fait l'exploit, en termes simples ?

L'attaque repose sur les deux failles PHP2Shell, CVE-2026-109618 et CVE-2026-109619. Modhwadia en a publié le détail sur GitHub, avec un script qui demande au plus 20 requêtes HTTP. Son principe, décrit dans son compte rendu cité par BankInfoSecurity, se résume en trois étapes :

  • un envoi de 32 Ko pousse PHP à consommer bien plus de mémoire, jusqu'à sa limite de 128 Mio ;
  • à court de mémoire, PHP laisse un état périmé dans un processus réutilisé, et des requêtes suivantes en font fuir deux adresses mémoire par les cookies de session ;
  • une dernière requête place une fausse structure interne que PHP exécute ensuite comme une commande système.

Les deux adresses servent à contourner l'ASLR (Address Space Layout Randomization), la protection qui place le code et les données d'un programme à des endroits aléatoires de la mémoire. Alon Gal, directeur technique de la société de renseignement sur les menaces Hudson Rock, a jugé l'exploit « impressionnant », notamment parce qu'il respecte la limite de 1 Mo par requête du serveur web Nginx.

Ce que l'expérience prouve, et ce qu'elle ne prouve pas

Le fait établi tient dans une chronologie. Les correctifs sont sortis le 21 octobre 2026. Un exploit fonctionnel et public existait le 25 octobre. Le même week-end, Adel Ka, responsable de la détection et de la réponse aux incidents chez Perplexity, a relevé sur six pots de miel 35 exploitations réussies venues de deux adresses IP. L'accès administrateur (root) suivait 1,6 milliseconde plus tard.

L'agence américaine de cybersécurité CISA a inscrit les deux failles à son catalogue des vulnérabilités activement exploitées le 26 octobre 2026, selon Journal du Coin. Elle a donné aux agences fédérales américaines jusqu'au 29 octobre pour corriger.

Les experts tirent des conclusions différentes. Le chercheur Matthew Hickey estime que l'exploit, facile à adapter, rend la mise à jour urgente. Le chercheur britannique Daniel Card nuance : chaque serveur est construit, configuré et protégé différemment, ce qui rend beaucoup d'autres cibles plus difficiles à attaquer que ce serveur de démonstration.

Notre analyse : le défi ne prouve pas que tous les serveurs non corrigés tombent en trois heures. Il prouve qu'un serveur exposé avec une version standard, sans correctif, peut tomber quatre jours après la publication du correctif, avec un outil désormais public. Le serveur de Pavur n'avait qu'une version de retard : 8.4.26 au lieu de 8.4.27.

Ce que 2clics a déjà publié sur PHP2Shell

Les versions corrigées (8.5.12, 8.4.27, 8.3.36 et 8.2.35) et les réglages temporaires sont détaillés dans notre article sur la faille PHP PHP2Shell. Le 22 octobre 2026, plus de 23'000 serveurs liés à la Suisse restaient vulnérables, selon le relevé de Risikomonitor présenté dans notre article sur la cybersécurité des PME face à PHP2Shell.

Un élément s'est ajouté depuis. Le vendredi 23 octobre 2026, le projet PHP a signalé une troisième faille d'exécution de code, CVE-2026-115560, selon BankInfoSecurity. Il juge son exploitation peu probable en pratique et la corrigera dans sa prochaine version régulière, sans correctif d'urgence. En attendant, il conseille de régler session.upload_progress.enabled=0. Un serveur qui a déjà appliqué ce réglage contre PHP2Shell n'a rien d'autre à faire pour cette troisième faille.

Que recommande l'OFCS à une PME qui héberge un site PHP ?

L'Office fédéral de la cybersécurité (OFCS) a publié le 21 octobre 2026 un avertissement sur ces failles. Il ne limite pas le contrôle au site public : PHP peut aussi tourner dans une interface d'administration, une application métier interne, un conteneur ou un appareil. Ses recommandations, dans l'ordre :

  • Recenser les installations PHP, leurs versions, leur accessibilité et leurs responsables, y compris chez les prestataires ; traiter d'abord ce qui est accessible depuis internet ou touche des données sensibles.
  • Mettre à jour sans délai, et obtenir de l'hébergeur ou du fabricant la confirmation que le correctif est appliqué.
  • Redémarrer les services PHP après la mise à jour ; les conteneurs peuvent devoir être reconstruits.
  • Vérifier la version réellement active : une distribution Linux peut intégrer le correctif sans changer le numéro de version, c'est le paquet indiqué par le fournisseur qui fait foi.
  • Contrôler les journaux : requêtes inhabituelles, plantages, fichiers modifiés, processus inattendus. Une mise à jour ne répare pas une intrusion déjà survenue.

Si la mise à jour est impossible tout de suite, l'OFCS demande de restreindre l'accès aux seules personnes et systèmes qui en ont besoin. Pour une application critique, il faut envisager une déconnexion temporaire d'internet. Les mesures transitoires, comme désactiver la barre de progression des envois ou bloquer les requêtes multipart, réduisent seulement certains chemins d'attaque. L'office précise qu'un pare-feu applicatif web, seul, ne suffit pas.

Ce que ça change pour une PME : depuis le 25 octobre, le contrôle des journaux n'est plus une précaution théorique. Un site corrigé après cette date a été exposé à un exploit public et mérite cette vérification. Au-delà de l'urgence, la norme minimale TIC de la Confédération donne un cadre pour tenir l'inventaire à jour.

Ce qu'on ne sait pas encore

  • La part des tentatives observées sur les pots de miel qui aboutissent sur des serveurs réels, mieux protégés, n'a pas été mesurée.
  • James Pavur a laissé entendre qu'il pourrait lancer un nouveau défi, sans en donner la forme ni la date.

Sources