Am 25. Oktober 2026 hat ein im Vereinigten Königreich ansässiger Pentester die PHP-Lücke namens PHP2Shell auf einem Server ausgenutzt, den der Forscher James Pavur absichtlich ungepatcht gelassen hatte, mit dem Schlüssel einer Bitcoin-Wallet als Köder. Die Challenge «Steal My Bitcoin» fiel etwas mehr als 19 Stunden nach ihrem Start, vier Tage nach der Veröffentlichung der Patches. Für die Sicherheit der Server von Schweizer KMU, die eine PHP-Website hosten, zeigt das Experiment, wie schnell eine bekannte Lücke ausnutzbar wird.

Wie wurde die Challenge «Steal My Bitcoin» gewonnen?

James Pavur, Forscher für Informationssicherheit, hat die Website stealmybitcoin.com am Samstag, 24. Oktober 2026, online gestellt. Laut Cybernews lief sein Server absichtlich mit PHP 8.4.26, einer Version vor den Patches vom 21. Oktober. Wer als Erster darauf aus der Ferne Code ausführen konnte, durfte den Schlüssel einer Bitcoin-Wallet holen.

Die Regel passte in einen Satz, berichtet BankInfoSecurity: ein vollständiger Angriff, nachgespielt in einer einzigen Python-Datei, geschrieben mit der Standardbibliothek. Die Belohnung, anfangs rund 500 Dollar, wurde durch Spenden der Community vervierfacht. Sie erreichte 0,02511679 Bitcoin, also rund 2'000 Dollar.

Der Gewinner heisst Jaydip Modhwadia, ein 26-jähriger Pentester, der auf GitHub unter dem Pseudonym KillaBoi bekannt ist. Er erreichte die Codeausführung am Sonntag, 25. Oktober 2026, um 15:47 UTC. Der Zähler der Website zeigte damals 19,28 Stunden an.

Diese Zahl überschätzt die tatsächliche Angriffszeit. Beim Start führte die Adresse der Challenge auf eine statische Seite. Laut BankInfoSecurity liess Pavur sie erst am Sonntag gegen 13:00 UTC auf eine dynamische PHP-Seite verweisen. Modhwadia sagt laut Journal du Coin, er habe insgesamt rund drei Stunden daran gearbeitet.

Die Wallet wurde vom Angreifer übrigens nicht geleert. Pavur räumte ein, auf dem Server den Schlüssel der übergeordneten Wallet hinterlegt zu haben und nicht jenen der Unter-Wallet, die das Guthaben enthielt. Er überprüfte das Eindringen in seinen Logs und zahlte die Prämie dann selbst aus.

Was macht der Exploit, einfach erklärt?

Der Angriff stützt sich auf die beiden PHP2Shell-Lücken CVE-2026-109618 und CVE-2026-109619. Modhwadia hat die Details auf GitHub veröffentlicht, mit einem Skript, das höchstens 20 HTTP-Anfragen benötigt. Das Prinzip, beschrieben in seinem von BankInfoSecurity zitierten Bericht, lässt sich in drei Schritten zusammenfassen:

  • ein Upload von 32 KB bringt PHP dazu, weit mehr Speicher zu verbrauchen, bis zu seiner Grenze von 128 MiB;
  • wenn der Speicher ausgeht, hinterlässt PHP einen veralteten Zustand in einem wiederverwendeten Prozess, und nachfolgende Anfragen lassen über die Session-Cookies zwei Speicheradressen durchsickern;
  • eine letzte Anfrage platziert eine gefälschte interne Struktur, die PHP anschliessend als Systembefehl ausführt.

Die beiden Adressen dienen dazu, ASLR (Address Space Layout Randomization) zu umgehen, den Schutz, der Code und Daten eines Programms an zufälligen Stellen im Speicher ablegt. Alon Gal, technischer Direktor des Threat-Intelligence-Unternehmens Hudson Rock, bezeichnete den Exploit als «beeindruckend», insbesondere weil er die Grenze von 1 MB pro Anfrage des Webservers Nginx einhält.

Was das Experiment beweist und was nicht

Die gesicherte Tatsache steckt in einer Chronologie. Die Patches erschienen am 21. Oktober 2026. Ein funktionierender, öffentlicher Exploit existierte am 25. Oktober. Am selben Wochenende verzeichnete Adel Ka, Verantwortlicher für Erkennung und Reaktion auf Vorfälle bei Perplexity, auf sechs Honeypots 35 erfolgreiche Ausnutzungen von zwei IP-Adressen aus. Der Administratorzugriff (root) folgte 1,6 Millisekunden später.

Die US-Cybersicherheitsbehörde CISA hat die beiden Lücken laut Journal du Coin am 26. Oktober 2026 in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen. Sie gab den US-Bundesbehörden bis zum 29. Oktober Zeit für die Behebung.

Die Fachleute ziehen unterschiedliche Schlüsse. Der Forscher Matthew Hickey ist der Ansicht, dass der leicht anpassbare Exploit das Update dringend macht. Der britische Forscher Daniel Card relativiert: Jeder Server ist anders gebaut, konfiguriert und geschützt, was viele andere Ziele schwerer angreifbar macht als diesen Demonstrationsserver.

Unsere Analyse: Die Challenge beweist nicht, dass alle ungepatchten Server in drei Stunden fallen. Sie beweist, dass ein exponierter Server mit einer Standardversion ohne Patch vier Tage nach der Veröffentlichung des Patches fallen kann, mit einem inzwischen öffentlichen Werkzeug. Der Server von Pavur war nur eine Version im Rückstand: 8.4.26 statt 8.4.27.

Was 2clics bereits über PHP2Shell veröffentlicht hat

Die korrigierten Versionen (8.5.12, 8.4.27, 8.3.36 und 8.2.35) und die vorübergehenden Einstellungen sind in unserem Artikel über die PHP-Lücke PHP2Shell beschrieben. Am 22. Oktober 2026 waren laut der Erhebung von Risikomonitor, die in unserem Artikel über die Cybersicherheit von KMU angesichts von PHP2Shell vorgestellt wurde, noch mehr als 23'000 Server mit Bezug zur Schweiz verwundbar.

Seither ist ein Element hinzugekommen. Am Freitag, 23. Oktober 2026, meldete das PHP-Projekt laut BankInfoSecurity eine dritte Lücke zur Codeausführung, CVE-2026-115560. Es hält deren Ausnutzung in der Praxis für unwahrscheinlich und wird sie in seiner nächsten regulären Version beheben, ohne Notfall-Patch. Bis dahin empfiehlt es, session.upload_progress.enabled=0 zu setzen. Ein Server, der diese Einstellung bereits gegen PHP2Shell angewendet hat, muss für diese dritte Lücke nichts weiter tun.

Was empfiehlt das BACS einem KMU, das eine PHP-Website hostet?

Das Bundesamt für Cybersicherheit (BACS) hat am 21. Oktober 2026 eine Warnung zu diesen Lücken veröffentlicht. Es beschränkt die Kontrolle nicht auf die öffentliche Website: PHP kann auch in einer Administrationsoberfläche, einer internen Fachanwendung, einem Container oder einem Gerät laufen. Seine Empfehlungen, in dieser Reihenfolge:

  • Erfassen der PHP-Installationen, ihrer Versionen, ihrer Erreichbarkeit und ihrer Verantwortlichen, auch bei Dienstleistern; zuerst behandeln, was aus dem Internet erreichbar ist oder sensible Daten betrifft.
  • Aktualisieren ohne Verzug und vom Hoster oder Hersteller die Bestätigung einholen, dass der Patch eingespielt ist.
  • Neu starten der PHP-Dienste nach dem Update; Container müssen unter Umständen neu gebaut werden.
  • Prüfen der tatsächlich aktiven Version: Eine Linux-Distribution kann den Patch integrieren, ohne die Versionsnummer zu ändern; massgebend ist das vom Anbieter angegebene Paket.
  • Kontrollieren der Logs: ungewöhnliche Anfragen, Abstürze, veränderte Dateien, unerwartete Prozesse. Ein Update repariert kein bereits erfolgtes Eindringen.

Ist das Update nicht sofort möglich, verlangt das BACS, den Zugriff auf die Personen und Systeme zu beschränken, die ihn benötigen. Bei einer kritischen Anwendung ist eine vorübergehende Trennung vom Internet in Betracht zu ziehen. Übergangsmassnahmen wie das Deaktivieren der Upload-Fortschrittsanzeige oder das Blockieren von Multipart-Anfragen verringern nur bestimmte Angriffswege. Das Amt hält fest, dass eine Web Application Firewall allein nicht genügt.

Was das für ein KMU ändert: Seit dem 25. Oktober ist die Kontrolle der Logs keine theoretische Vorsichtsmassnahme mehr. Eine Website, die nach diesem Datum gepatcht wurde, war einem öffentlichen Exploit ausgesetzt und verdient diese Überprüfung. Über die Dringlichkeit hinaus bietet der IKT-Minimalstandard des Bundes einen Rahmen, um das Inventar aktuell zu halten.

Was man noch nicht weiss

  • Welcher Anteil der auf den Honeypots beobachteten Versuche auf echten, besser geschützten Servern zum Erfolg führt, wurde nicht gemessen.
  • James Pavur hat angedeutet, dass er eine neue Challenge lancieren könnte, ohne Form oder Datum zu nennen.

Quellen