Die Steal-My-Bitcoin-Challenge ist entschieden: Nach 19 Stunden und 28 Minuten gelang einem Sicherheitsforscher unter dem Namen KillaBoi ein erfolgreicher Angriff auf den verwundbaren PHP-Server. Der Betreiber bestätigte den Erfolg und zahlte die Bitcoin-Belohnung von 0,02511679 BTC aus – rund 2.021 US-Dollar zum Zeitpunkt des Gewinns. Ein öffentlicher Proof of Concept dokumentiert den Angriff.
Update vom 26. Oktober 2026: Challenge gelöst, Gewinner bestätigt
Der Betreiber von stealmybitcoin.com meldet den erfolgreichen Abschluss seiner Challenge. Nach den Angaben auf der Website wurde die Aufgabe am 25. Oktober 2026 um 15:47 UTC (16:47 Uhr MESZ) gelöst, rund 19,28 Stunden nach dem Start. Die Belohnung betrug zuletzt 0,02511679 BTC beziehungsweise rund 2.021,22 US-Dollar.
Als Gewinner wird der Sicherheitsforscher KillaBoi genannt. Unter GitHub: KillaBoi/StealMyBitcoin-PoC hat er einen technisch nachvollziehbaren Proof of Concept und eine Beschreibung des Angriffs veröffentlicht. Nach seiner Darstellung nutzt dieser eine Kombination aus Problemen bei der Speicherbehandlung während der Verarbeitung von PHP-Anfragen; der PoC ist auf eine spezifische PHP-8.4.26-Umgebung zugeschnitten. Damit ist keine universelle Ausnutzbarkeit aller PHP-Installationen belegt.
Warum die Bitcoin zunächst noch in der Wallet lagen
Bei der Recherche am Abend des 25. Oktober war das Guthaben der Challenge-Wallet noch sichtbar. Das schien zunächst dem behaupteten Erfolg zu widersprechen. Inzwischen liegt eine Erklärung vor: Der auf dem Server hinterlegte private Schlüssel gehörte aufgrund eines Fehlers bei der Einrichtung nicht zu der Wallet-Adresse, auf der die Belohnung lag. Der Angreifer konnte nach Angaben des Betreibers dennoch den hinterlegten Schlüssel durch Codeausführung auslesen. Der Betreiber wertete dies als erfolgreichen Angriff und veranlasste die Auszahlung selbst. Die spätere Bewegung der BTC ist deshalb kein Widerspruch zum bestätigten Angriff.
Der zuvor untersuchte angebliche PoC war nicht der Gewinner-Code
Unsere vorherige Warnung bezog sich auf einen anderen X-Account, @heapsoverflow, und einen als „Partial PoC“ bezeichneten Python-Ausschnitt, in dem keine eigentliche Angriffsroutine erkennbar war. Dieser Code darf nicht mit dem nun veröffentlichten Gewinner-PoC von KillaBoi verwechselt werden. Für die ältere Erfolgsmeldung und die Zuordnung der dort gezeigten Wallet-Gutschrift liegt weiterhin kein eigenständiger belastbarer Beleg vor. Dass die Challenge inzwischen nachweislich gelöst wurde, macht den damals geprüften Code nicht nachträglich zu einem funktionierenden Exploit.
Fazit: Die PHP2Shell-Challenge ist gelöst. Sie demonstriert, dass unter passenden Bedingungen eine praktische Ausnutzung möglich ist. Administratoren sollten betroffene PHP-Versionen aktualisieren und vermeintliche Exploit-Veröffentlichungen unabhängig davon weiterhin kritisch prüfen.
Redaktionelle Klarstellung: Die Einschätzung vom 25. Oktober bezog sich ausdrücklich auf den damals geprüften angeblichen PoC und den zu diesem Zeitpunkt sichtbaren Wallet-Stand. Sie war keine Widerlegung des später unabhängig bestätigten Angriffs durch KillaBoi.
Wer den Server kompromittiert, soll die Bitcoin bekommen
Unter stealmybitcoin.com steht eine ungewöhnliche Sicherheits-Challenge: Ein Betreiber stellt nach eigenen Angaben einen bewusst verwundbaren PHP-Server bereit. Wer sich darüber Zugriff auf den privaten Schlüssel einer hinterlegten Bitcoin-Wallet verschafft, kann die digitale Belohnung beanspruchen.
Die Challenge startete laut Community-Berichten mit einer kleineren Belohnung von ungefähr 500 US-Dollar. Inzwischen wird über einen Gegenwert von rund 2.000 US-Dollar berichtet. Der Betrag ist volatil, weil Bitcoin-Kurs und zusätzliche Einzahlungen ihn verändern können.
Was steckt hinter PHP2Shell?
PHP2Shell ist die Bezeichnung, die in aktuellen Diskussionen über PHP-Schwachstellen und mögliche Wege zur Remote Code Execution (RCE) verwendet wird. RCE bedeutet, dass Angreifer unter bestimmten Voraussetzungen Befehle oder eigenen Code auf einem entfernten System ausführen können.
Wichtig ist die Unterscheidung zwischen einer betroffenen Softwareversion und einem tatsächlich ausnutzbaren Server. Ob ein konkreter Angriff gelingt, hängt unter anderem davon ab, welche Funktionen erreichbar sind, wie der Webserver konfiguriert ist und ob der verwundbare Codepfad überhaupt ausgeführt wird.
Vor dem Erfolg: War das Ziel wirklich angreifbar?
In der Diskussion auf Hacker News wird nicht nur über mögliche Angriffe gesprochen. Teilnehmer hinterfragen auch, ob der öffentlich erreichbare Dienst die notwendigen Bedingungen für die behauptete Angriffsmethode tatsächlich erfüllt. Ein Hinweis auf eine PHP-Version in einem HTTP-Header reicht allein nicht als Beleg, dass sich darüber beliebiger Code ausführen lässt.
Damit steht neben dem Preisgeld eine grundsätzliche Frage im Mittelpunkt: Wird hier die praktische Ausnutzbarkeit einer Schwachstelle getestet, oder misst die Aktion eher die Schwierigkeit einer sehr speziellen Serverkonfiguration?
Warum ein Preisgeld von 2.000 Dollar zunächst nicht unbedingt reicht
Ein funktionierender, bislang nicht veröffentlichter Exploit könnte für Sicherheitsforscher wirtschaftlich oder wissenschaftlich wertvoller sein als das ausgelobte Preisgeld. Dass niemand die Wallet leert, würde daher nicht beweisen, dass die zugrunde liegende Sicherheitslücke harmlos ist. Umgekehrt ließe sich aus einem erfolgreichen Angriff nicht ableiten, dass jede PHP-Installation identisch gefährdet wäre.
Auch KI-Agenten werden als Angreifer diskutiert
Ein weiterer Aspekt der Community-Debatte: Nutzer berichten von Versuchen, KI-gestützte Agenten bei der Analyse des Servers einzusetzen. Solche Berichte sind noch kein unabhängiger Nachweis für einen erfolgreichen Exploit. Sie zeigen allerdings, dass öffentliche Sicherheits-Challenges inzwischen auch als Testfeld für automatisierte Werkzeuge dienen.
Was Administratoren daraus lernen können
Die ungewöhnliche Aktion ist ein anschauliches Experiment, ersetzt aber weder einen reproduzierbaren Sicherheitsnachweis noch die reguläre Absicherung produktiver Systeme. Betreiber sollten PHP und eingesetzte Komponenten aktuell halten, unnötige Funktionen reduzieren und erreichbare Angriffsflächen kontrollieren.
Entscheidend bleibt nicht nur, ob jemand die Bitcoin gewinnt, sondern auch, was der Versuch tatsächlich über die Sicherheit realer PHP-Server aussagt.
Frühere Beobachtung vom 25. Oktober: Fragwürdiger „Partial PoC“
In sozialen Netzwerken kursieren inzwischen unbestätigte Erfolgsmeldungen zur Steal-My-Bitcoin-Challenge. Ein X-Account namens @heapsoverflow behauptet, den Server mit einem selbst entwickelten PHP2Shell-Exploit kompromittiert zu haben. Als Beleg zeigt der Nutzer eine angebliche Bitcoin-Gutschrift über 0,02510313 BTC und verweist auf einen „Partial PoC“ auf GitHub. Doch wesentliche Nachweise fehlen.
Der vorgelegte Python-Code ähnelt über weite Strecken dem Standardmodul http.client aus Python. Er enthält zwar Klassen zum Verarbeiten von HTTP-Anfragen und -Antworten, aber im gezeigten Ausschnitt weder einen nachvollziehbaren Angriff auf die PHP-Schwachstelle CVE-2026-109618 noch eine konkrete Reproduktionsroutine. Die Überschrift „Partial PoC“ allein ist kein Beweis für einen funktionierenden Exploit. Das schließt nicht aus, dass der Verfasser nicht veröffentlichten Code besitzt.
Auch der Zahlungs-Screenshot ist kein belastbarer Nachweis: Bei einer Prüfung am Abend des 25. Oktober zeigte die öffentlich einsehbare Challenge-Wallet weiterhin ein bestätigtes Guthaben von 0,02510313 BTC, verteilt auf fünf UTXOs. Genau diese Menge erscheint im Screenshot als angeblicher Zahlungseingang. Die Übereinstimmung der Beträge belegt keine Übertragung an den behaupteten Gewinner. Eine dokumentierte Auszahlung aus der Challenge-Wallet ist damit nicht nachgewiesen.
Wichtig: Dass das Guthaben noch vorhanden ist, widerlegt nicht automatisch einen möglichen Serverzugriff. Es widerspricht aber der Darstellung, dass die hinterlegte Belohnung bereits erfolgreich abgezogen worden sei. Eine unabhängige Bestätigung des Betreibers oder ein überprüfbarer Transaktionsnachweis liegt für diese Behauptung bislang nicht vor.
Der Fall zeigt ein zusätzliches Risiko bei populären Sicherheitslücken: Unter bekannten CVE-Nummern erscheinen angebliche Exploits, deren technische Substanz oft ungeklärt ist. Administratoren sollten solche Repositories nicht allein aufgrund von Screenshots, Schlagworten oder vermeintlichen Erfolgsmeldungen herunterladen und ungeprüft ausführen. Ein belastbarer PoC braucht eine verständliche technische Erklärung und reproduzierbare Ergebnisse.
Stand dieses Updates: 25. Oktober 2026, ca. 21 Uhr. Die Blockchain-Beobachtung ist eine Momentaufnahme; spätere Transaktionen können die Lage verändern.
Quellen
