Steal My Bitcoin: PHP-Exploit-Hype trifft Realität

Wer in letzter Zeit in Security-Kreisen auf Social Media unterwegs war, hat die Behauptung gesehen: Die neuen Remote-Code-Execution-Lücken in PHP seien so trivial, dass KI-Agenten bereits tausendfach verwundbare Server autonom ausnutzen. Ganze Schwärme davon. Nicht zu stoppen. Ein Entwickler hatte genug vom Lärm und reagierte darauf auf wunderbar direkte Weise. Er richtete einen Server mit einer PHP-Version ein, die noch vor dem Patch lag, und versteckte einen Bitcoin-Schlüssel im Wert von etwa fünfhundert Dollar dort, wo ein erfolgreicher Angreifer herankommt. Dann postete er einen Link mit einer zweiwortigen Einladung: Klau es. Ein PHP-Exploit ist angeblich etwas, das ein Chatbot vor dem Mittagessen ausspuckt. Der Timer der Seite begann zu zählen. Und dann passierte etwas Interessantes: nichts.

Stunden vergingen. Die Coins lagen einfach da. In der Kommentarspalte breitete sich eine ganz besondere Art von Stille aus, die Stille von Dutzenden Leuten, die tagelang behauptet hatten, der Exploit sei ein Kinderspiel, und plötzlich dringende Gründe entdeckten, warum sie ihn unmöglich vorführen konnten. Was man auch von dem Stunt hält: Er hat etwas geschafft, das im Security-Diskurs selten vorkommt. Er hat aus einer viralen Behauptung etwas gemacht, das sich widerlegen lässt.

Ein Server, der zum Ausrauben gebaut wurde

Der Aufbau orientiert sich an Capture-the-Flag-Wettbewerben. Der private Bitcoin-Schlüssel liegt nicht in einer Datei im Webroot oder in einer Umgebungsvariable, sondern wird von einem print-flag-Binary gehalten, auf das der PHP-Benutzer zugreifen kann. Ein erfolgreicher Angreifer braucht also tatsächliche Codeausführung auf dem System und nicht nur eine Informationspreisgabe oder einen Path Traversal. Er muss eine Shell bekommen, das Binary ausführen, den Schlüssel auslesen und das Wallet leerräumen, bevor es sonst jemand tut. Die PHP-Version wurde bewusst von vor den aktuellen CVE-Patches gewählt, und das Ganze wurde mit einem fröhlichen Hinweis angekündigt, dass sämtlicher Traffic protokolliert wird und auf dem Rechner nichts als privat gelten sollte.

Auf diesem Server ist ein Bitcoin-Schlüssel versteckt, der etwa 502 $ wert ist. Er ist über das print-flag-Binary für den PHP-Benutzer zugänglich. Wer zuerst das Wallet hat, gewinnt.

Der Autor bewies außerdem einen Hauch von Stil: Wer das Geld nicht braucht, solle es doch bitte für einen guten Zweck spenden. Und die Seite zeigte praktischerweise einen Live-Zähler an, also die Stunden ohne erfolgreichen Hack, der die ganze Seite in eine Anzeigetafel verwandelte. Jede weitere Stunde war selbst ein Datenpunkt. Innerhalb eines Tages war der Zähler zur interessantesten Security-Kennzahl des Internets geworden, gerade weil er eine Prognose maß, auf die Leute ihren Ruf gesetzt hatten.

Warum ein 500-Dollar-Kopfgeld eine Maschine zur Falsifizierung ist

Die meisten Aussagen in der Security sind per Design nicht widerlegbar. „Angreifer nutzen das bereits in freier Wildbahn aus“ – basierend auf Telemetrie, die man nicht sehen kann. „Jeder Junior-Analyst könnte das an einem Nachmittag waffenfähig machen“ – nie demonstriert. „Unsere Agenten haben autonom funktionierende Exploits gefunden“ – bitte dem Demo-Video vertrauen. Einen Negativbeweis kann man nicht führen, also sammeln sich die Behauptungen einfach an. Panik ist billig, weil Panik niemandem Rechenschaft abverlangt.

Ein öffentliches Kopfgeld mit öffentlichem Timer ändert die Buchhaltung. Wenn Tausende autonome Agenten tatsächlich das Internet durchkämmen und jede ungepatchte PHP-Kiste knacken, dann müsste eine Box, die genau diese Lücke mit einem Geldpreis und ausdrücklicher Erlaubnis anbietet, in Minuten fallen. Nicht in Stunden. In Minuten. Die Anreize sind perfekt ausgerichtet: Es ist legal, es ist ausdrücklich erwünscht, und es zahlt sich aus. Als der Zähler stattdessen weiterlief, bekam eine konkrete Behauptung einen direkten Treffer: dass die massenhafte autonome Ausnutzung bereits stattfindet. Ein Kommentator brachte es auf den Punkt: Die Geschichte von Agenten-Schwärmen, die alles kompromittieren, was ihnen vor die Flinte läuft, passiert offensichtlich nicht, sonst wären die Coins längst weg.

Das ist ein Trick, den man sich für die eigene Arbeit abschauen kann. Wenn das nächste Mal ein Hersteller oder Influencer behauptet, eine Lücke werde überall ausgenutzt, frag nach, welche Beobachtung ihn widerlegen würde. Gibt es keine, dann hörst du keine Analyse, sondern Marketing. Das Bitcoin-Kopfgeld hat funktioniert, weil es Bauchgefühl in eine Wette verwandelte, und Wetten haben die schöne Eigenschaft, dass man sie abrechnen kann.

Exploit-Ökonomie: Warum echte Angreifer nicht mitspielen

Hier ist das Gegenargument, und es ist ein gutes: Das Schweigen beweist weniger, als es scheint, denn ein funktionierender Exploit für eine frische CVE ist weit mehr als 500 $ wert, aber nur solange er geheim bleibt. Jedes Mal, wenn du einen Exploit auf ein Ziel abfeuerst, riskierst du, dass er protokolliert, reverse-engineert und verbrannt wird. Ihn auf einen Server abzufeuern, dessen Betreiber vorab angekündigt hat, dass sämtlicher Traffic mitgeschrieben wird und das ganze Internet zuschaut? Das ist kein Kopfgeld, das ist ein Freudenfeuer.

Der Thread brachte genau diese Überlegung von beiden Seiten des Zauns ans Licht. Offensive Akteure haben lohnendere Ziele als eine Wallet mit 500 $ und kein Interesse daran, ihre Werkzeuge jenen zu überlassen, die die Logs lesen. Defensive Forscher, die über privilegierte Informationen zu den Lücken verfügen, haben ein Patch-Fenster zu schützen. Ein Security-CEO sagte öffentlich, sein Team habe eine funktionierende RCE, werde sie aber gerade deshalb nicht vorführen, weil Details in Umlauf zu bringen, während die Leute noch patchen, echten Schaden anrichten würde. Beide Gruppen haben dieselbe Rechnung aufgemacht: Der erwartete Gewinn beim Abgreifen der Coins liegt bei fünfhundert Dollar, die erwarteten Kosten bei der Verbrennung von etwas, das deutlich mehr wert ist. Ein schlechter Deal. Die ehrliche Lesart des unbeanspruchten Kopfgelds lautet daher nicht „Es existiert kein Exploit“, sondern „Niemand mit einem Exploit schätzt 500 $ höher als Geheimhaltung“. Das sind sehr unterschiedliche Befunde, und nur einer davon war eigentlich angeklagt.

Der Realitätscheck für KI-Agenten

Der unterhaltsamste Teil des Threads war, wie die KI-Behauptungen auf ein echtes Ziel prallten. Ein Kommentator legte die Challenge fünf Frontier-Modellen vor und veröffentlichte die Ergebnisse. Zwei Modelle deuteten sie als legitime öffentliche Herausforderung, was sie ja auch war, und machten sich an die Arbeit. Eines stufte sie als Cybersecurity-Anfrage ein und verwies den Nutzer an ein Prüfprogramm. Eines verweigerte schlicht die Antwort. Eines wurde von einem Content-Filter des Anbieters gestoppt, bevor es überhaupt antworten konnte. Von fünf State-of-the-Art-Systemen waren also zwei überhaupt bereit, es zu versuchen, und zunächst hat keines die Flag geliefert.

Dieses gemischte Bild ist aussagekräftiger als beide Extrempositionen. Die reflexhafte Haltung „KI wird nie irgendetwas hacken“ liegt falsch, denn die Modelle haben sich tatsächlich eingelassen, und agentische Ausnutzung bekannter Schwachstellen in CTF-artigen Zielen wird wirklich besser. Doch die Fraktion „autonome Schwärme leeren jeden ungepatchten Server“ stellt eine viel stärkere Behauptung auf, und genau diese starke Behauptung wird von einer öffentlichen, autorisierten, mit Geld belohnten Honeypot-Anlage auf die Probe gestellt. Außerdem hatte ein bekannter Pentesting-Influencer gerade behauptet, er habe mit einem Chatbot in zwei Stunden einen generischen, funktionierenden PoC gebaut, um dann – aus einem Zufall, der sicher nichts mit der Sache zu tun hat – seine KI-Pentesting-Plattform zu bewerben. Hätte diese Behauptung gestimmt, wäre das Kopfgeld gefallen, bevor der Timer die erste Stunde erreicht hätte. Das ist nicht passiert. Wir haben dieses Muster schon einmal gesehen: Demos und Leaderboards schmeicheln Fähigkeiten, die bei echter Arbeit zusammenbrechen. Genau diese Lücke haben wir in warum KI-Benchmarks den größten Teil echter Arbeit verfehlen untersucht.

Der Fall, dass das Experiment manipuliert war

Bevor wir den Timer zur Wissenschaft erklären, gibt es einen technischen Einwand, der ernsthaft durchdacht werden sollte: Die konkrete Serverkonfiguration ist möglicherweise gar nicht durch die fraglichen CVEs angreifbar. Ein scharfsinniger Kommentator ging das durch. Die Kiste nutzt den CLI-Server von PHP statt eines klassischen CGI-Setups, begrenzt Requests auf 1 MiB, liefert eine im Wesentlichen inaktive Seite aus und erlaubt ein hohes Speicherlimit. Je nachdem, in welchen Codepfaden die Schwachstellen liegen, kann diese Kombination genau die Primitive abschneiden, die ein Exploit braucht. Anders gesagt: Der Honeypot ist vielleicht nicht deshalb unverwundbar, weil die Bugs schwer zu finden sind, sondern weil diese bestimmte Maschine die verwundbare Oberfläche gar nicht bereitstellt.

Falls das stimmt, leistet das Experiment trotzdem etwas Nützliches. Es sammelt Proof-of-Concept-Versuche für Konfigurationen, die tatsächlich verwundbar sind, und widerlegt die Behauptung eines trivialen, universellen Exploits, der überall funktioniert. Die Existenz eines funktionierenden Exploits gegen reale Deployments widerlegt es allerdings nicht, und die sehen größtenteils nicht wie eine gehärtete CTF-Kiste aus. Das ist die allgemeine Lehre über Negativergebnisse in der Security: Sie sind nur so stark wie die Treue der Testumgebung. Fehlende Belege sind nur dann ein Beleg für Abwesenheit, wenn man am richtigen Ort mit den richtigen Instrumenten gesucht hat. Der Timer misst also die Fähigkeit des Internets, diesen Server zu hacken, und das ist eine schmalere, aber interessantere Frage als die, über die alle gestritten haben.

Was Verteidiger tatsächlich mitnehmen sollten

Nichts davon ist ein Plädoyer für Gelassenheit. Das Patch-Fenster nach einer PHP-RCE ist wirklich gefährlich. Warum den Stecker zu ziehen während des letzten PHP-CVE-Fensters besser war als clevere Workarounds, haben wir bereits beschrieben, und dieser Rat gilt weiterhin. Was das Kopfgeld ändert, ist die Kalibrierung deiner Angst. Patch schnell, weil internetexponierte RCEs existenzielle Risiken sind, nicht weil irgendein Thread dir erzählt hat, der Himmel stürze schon ein.

• Falsifizierbarkeit einfordern. Wenn jemand behauptet, massenhafte Ausnutzung sei im Gange, frag, welche Belege die Frage entscheiden würden. Ein öffentlicher Honeypot mit Timer ist grob, aber rigoroser als tausend Retweets.
• Eigene Canaries betreiben. Ein Kommentator erwähnte, er habe jahrelang ein unverschlüsseltes Bitcoin-Wallet auf seinem privaten Rechner als Stolperdraht laufen lassen. Canary-Tokens, Honey-Credentials und Köderdateien sind günstige Frühwarnsysteme, die aus der Frage „Bin ich kompromittiert?“ eine Telemetriefrage machen statt einer Bauchgefühlfrage.
• Die Ökonomie ernst nehmen. Versierte Angreifer horten Exploits, laute Kommentatoren verdienen mit der Angst. Keine dieser Gruppen hat Anreize, die dir eine akkurate Bedrohungsbewertung liefern, also gewichte Primärtelemetrie höher als Kommentare.
• Die Behauptungen trennen. „Ein Exploit existiert“, „Ausnutzung findet statt“ und „autonome Agenten nutzen alles aus“ sind drei verschiedene Aussagen mit drei verschiedenen Beweisanforderungen. Panik verschmilzt sie zu einer. Lass das nicht zu.
• Trotzdem schnell patchen. Ein ruhiger Honeypot bedeutet keine ruhige Exposition. Deine Produktivsysteme bieten kein 500-Dollar-Kopfgeld an, und genau das macht sie paradoxerweise attraktiver für jemanden, der einen funktionierenden Exploit in der Hinterhand hat.

Das Beste an dem ganzen Stunt ist, dass er seinen Autor fast nichts gekostet und trotzdem echtes Signal erzeugt hat. Ein VPS, eine verwundbare PHP-Version, ein Flag-Binary und fünfhundert Dollar haben eine Messung ermöglicht, die der gesamte Diskurs dringend brauchte. Die Lücke zwischen „Exploit existiert“ und „Exploit ist überall“ ist der Ort, an dem Panik gedeiht. Und jetzt zählt mitten in dieser Lücke ein Timer still vor sich hin und fordert jeden heraus, sie zu schließen.