Skip to content
Blockchain Posts

exploit

« Steal My Bitcoin » : un pentester vide le serveur PHP2Shell de Pavur en 19 heures

James Pavur a laissé en ligne un serveur PHP 8.4.26 vulnérable à PHP2Shell avec une prime en BTC. Le pentester britannique Jaydip Modhwadia l'a pris en 19 h 17.

par 4 min de lecture
rechercheoutilexploitbitcoininfrastructure

Le chercheur en sécurité James Pavur a mis en ligne le 24 octobre 2026 un serveur volontairement vulnérable aux failles PHP2Shell — corrigées par les mainteneurs PHP le 21 octobre — avec une prime en bitcoin à la clé du premier à prendre la main dessus. Le serveur tournait sur PHP 8.4.26, soit la dernière version publiée avant les correctifs. Le pentester britannique Jaydip Modhwadia, alias « Killa », a résolu le challenge le 25 octobre à 15:47 UTC, soit 19 h 17 min après le début, et empoché la prime, selon Journal du Coin et une couverture indépendante par The Register.

Ce qui s'est passé

Le site stealmybitcoin.com affichait une consigne lapidaire — « volez mon bitcoin » — et un compteur comptant le temps écoulé. Le wallet associé, embarqué sur le serveur, détenait la prime en BTC. Objectif : atteindre l'exécution de code à distance via PHP2Shell, lire la clé privée, signer une sortie des fonds.

Le compteur du site s'est arrêté sur « My Bitcoin was stolen after 19.28 hours ». Modhwadia, 26 ans, pentester et développeur installé au Royaume-Uni, dit avoir travaillé « trois heures environ au total » — l'essentiel du délai venant de l'adaptation du payload au binding spécifique du serveur. Pavur a payé 0,02511679 BTC au gagnant.

Pavur a reconnu publiquement avoir chargé la mauvaise clé sur la machine : la clé retrouvée dans la RAM ne débloquait pas la prime annoncée. Il a honoré la récompense depuis une adresse distincte. Les premiers participants s'étaient plaints d'un point d'entrée insuffisant — la page initiale ne servait que du HTML statique, ce qui empêchait l'exploit d'aboutir à un RCE — et Pavur avait ajouté un endpoint PHP dynamique en cours de challenge.

Mécanisme — ce que « PHP2Shell » exploite

PHP2Shell est une classe de vulnérabilités du moteur PHP qui autorise l'exécution de code à distance sans authentification sur les versions de l'interpréteur publiées entre la 5.4 et la 8.4.26 incluse. Les correctifs amont ont été livrés par les mainteneurs le 21 octobre 2026. Pavur a volontairement pris la version juste antérieure.

Le payload gagnant, selon Journal du Coin, est un unique script Python qui :

  • contourne l'ASLR du processus PHP ;
  • envoie une vingtaine de requêtes HTTP au plus pour pivoter de la lecture mémoire à l'exécution ;
  • lit la clé privée du wallet local et signe la transaction de sortie.

Le détail compte pour les équipes qui exposent du PHP non patché derrière un reverse proxy : la fenêtre d'exploitation est de l'ordre de la poignée de minutes, pas des heures, dès lors que l'endpoint dynamique est en place.

Chiffres

- Date de mise en ligne du serveur : 2026-10-24
- Patch amont PHP2Shell             : 2026-10-21
- Version serveur de Pavur          : PHP 8.4.26
- Fin du challenge                  : 2026-10-25 15:47 UTC
- Durée affichée au compteur        : 19 h 17 min
- Temps de travail estimé (gagnant) : ~3 h
- Prime initiale                    : 500 USD
- Prime finale (dons communautaires) : 2 000 USD
- Payout effectif                   : 0,02511679 BTC

Sources : Journal du Coin, The Register, Cybernews.

À retenir

  1. Toute instance PHP 5.4 → 8.4.26 non patchée doit passer en version 8.4.27 ou supérieure ; la mise à jour est publiée depuis dix jours.
  2. Les équipes qui opèrent un wallet « chaud » sur une même machine que leur stack web s'exposent au même scénario — isoler la signature sur une machine séparée reste la ligne de défense qui tient.
  3. Un bug-bounty publiquement doté est un signal : avant qu'un chercheur bienveillant ne mette la main dessus, un acteur malveillant peut déjà avoir balayé le même CVE sur Internet. Les équipes GRC qui attendent la deuxième vague d'articles pour prioriser le patch arrivent toujours en retard.

Contexte — le pattern du serveur-piège

Le format « serveur public + prime en BTC » n'est pas inédit : il reprend la logique du Pwn2Own, mais sans réglementation ni divulgation coordonnée. Il tient parce que la prime est auto-exécutante — le gagnant signe la transaction depuis la clé qu'il a extraite — et parce qu'une démonstration publique d'exploitabilité fait plus pour la discipline opérationnelle de patching qu'un rapport interne.

Côté PHP, les correctifs du 21 octobre couvrent les deux vecteurs documentés. Côté terrain, c'est l'inventaire des serveurs encore en production avec une version non patchée qui va dicter la prochaine vague d'incidents — et là, aucun bug-bounty public ne viendra prévenir les opérateurs.

Articles liés