php2shell: Wie zwei PHP-Lücken das halbe Web lahmlegten, und was Sie jetzt tun müssen

Mittwoch, 21. Oktober 2026, später Nachmittag. Beim Basler Hoster cyon gehen alle Webhostings und Server vom Netz, über 100'000 Websites sind auf einen Schlag nicht mehr erreichbar. Die Universitäten Basel und Genf, die ETH Lausanne, der Kanton Basel-Stadt, die Baubewilligungsplattform des Kantons Bern und die Verwaltungssoftware der Schweizer Feuerwehren folgen. In Deutschland nehmen die Charité, die Freie Universität Berlin und die Berliner Polizei ihre Portale offline. Das Bundesamt für Cybersicherheit BACS stuft die Lage als kritisch ein und fordert alle Betreiber auf, «sofort» zu aktualisieren.

Ausgelöst hat das alles ein Fehler, der seit 2012 in der Programmiersprache PHP schlummerte. Zwei Fehler, genau genommen, die unter dem Namen «php2shell» bekannt geworden sind: CVE-2026-109618 und CVE-2026-109619, beide mit der Höchstwertung «kritisch» (CVSS 9.2). Wir möchten Ihnen in diesem Beitrag ohne Fachchinesisch erklären, was da passiert ist, warum es so viele trifft, und vor allem, was Sie als Betreiberin oder Betreiber einer Website jetzt konkret tun sollten.

Warum eine PHP-Lücke fast jeden betrifft

PHP ist die Programmiersprache, in der ein Grossteil des Webs geschrieben ist. WordPress, das System hinter rund vierzig Prozent aller Websites, läuft darauf. Ebenso TYPO3, Joomla, Drupal, die Shopsysteme Magento und Shopware, Nextcloud, Moodle, phpBB-Foren und unzählige individuell gebaute Firmenwebsites. Schätzungen gehen davon aus, dass rund siebzig Prozent aller Websites PHP einsetzen. Wer eine Website hat, hat mit hoher Wahrscheinlichkeit PHP, auch wenn er das Wort noch nie gehört hat.

Das Besondere an php2shell: Die Lücke liegt nicht in WordPress oder einem Plugin, sondern im Kern von PHP selbst, also in der Schicht darunter. Es spielt keine Rolle, wie sauber die Website programmiert ist. Ein Angreifer schickt eine präparierte Anfrage an den Server, und der Fehler schlägt zu, bevor überhaupt eine einzige Zeile der eigentlichen Website ausgeführt wird. Betroffen sind alle PHP-Versionen seit 5.4 aus dem Jahr 2012 und alle gängigen Betriebsarten: mod_php unter Apache, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed.

Wie es dazu kam: Eine Chronologie

• August 2026: Eine KI findet, was Menschen 14 Jahre übersehen habenDie Sicherheitsfirma Calif untersucht den PHP-Quellcode im Rahmen einer von OpenAI finanzierten Prüfung mit dem Sprachmodell GPT-5.6. Das Modell stösst auf eine Fehlerkette, die bisher niemandem aufgefallen war. Wenige Wochen später findet das Forschungsteam von Wiz unabhängig davon dieselbe Lücke, ebenfalls mit Hilfe von KI-Modellen. Beide melden den Fund vertraulich an das PHP-Sicherheitsteam. Calif selbst warnt vor Übertreibung: Kein Modell deckt «einfach alle Fehler mit einem Prompt» auf, es brauchte erfahrene Menschen, die die Ergebnisse einordneten. Aber die Arbeit, die früher ein Team monatelang beschäftigt hätte, erledigte eine einzelne Person in einer Woche.
• September 2026: Das PHP-Team bestätigt und bereitet die Korrektur vorDie Korrektur ist technisch anspruchsvoll, weil sie tief im Speichermanagement von PHP ansetzt und für vier aktive Versionszweige gleichzeitig gebaut und getestet werden muss. Die koordinierte Veröffentlichung wird auf den 22. Oktober festgelegt, damit Hoster und Linux-Distributionen ihre Pakete vorbereiten können.
• 17. Oktober 2026: Erste Angriffsversuche, vier Tage vor dem PatchAmazon beobachtet in seinen Honeypots die ersten Anfragen, die auf die noch unveröffentlichte Lücke zielen. Wie die Angreifer davon wussten, ist bis heute nicht geklärt. Zu diesem Zeitpunkt gibt es für niemanden auf der Welt ein Update.
• 20. Oktober 2026: Die Details werden öffentlich, einen Tag zu frühTechnische Einzelheiten tauchen auf Hacker News auf, am selben Abend kursiert ein funktionierender Beispielcode. Damit ist der Wettlauf eröffnet: Jeder, der will, kann die Lücke nachbauen, aber noch niemand kann sie schliessen. Erste Betreiber in Europa nehmen ihre Websites vorsorglich vom Netz.
• 21. Oktober 2026, 16:00 Uhr: Der Patch kommt, Cloudflare meldet Millionen AngriffeDas PHP-Team zieht die Veröffentlichung um einen Tag vor und liefert die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 aus. Cloudflare hatte seine Schutzregeln bereits um fünf Uhr morgens scharf geschaltet und zählt innert Stunden Angriffsversuche in Millionenhöhe. Hostpoint hat seine 340'000 Websites bis 17:30 Uhr aktualisiert, cyon entscheidet sich für die Vollbremsung und schaltet alles ab, bis jeder Server gepatcht ist. Bis zu zehn Mitarbeitende arbeiten dort bis vier Uhr morgens. Infomaniak meldet um 00:28 Uhr Vollzug.
• 22. bis 24. Oktober 2026: NachbebenDebian, Ubuntu, Red Hat, SUSE und die übrigen Distributionen liefern Pakete nach. Das BACS, das deutsche BSI, die amerikanische CISA und die EU-Behörden veröffentlichen Warnungen. Sicherheitsforscher zählen rund 884'000 öffentlich erreichbare Server mit PHP-Versionen, für die es gar keinen offiziellen Fix mehr gibt, und weitere 740'000, die ihre Version verbergen.

Was technisch passiert ist, verständlich erklärt

Stellen Sie sich einen Sachbearbeiter vor, der für jede Anfrage einen frischen Schreibtisch bekommt: Formulare hervorholen, Anfrage bearbeiten, alles wegräumen, nächster Kunde. PHP arbeitet genau so. Für jede Anfrage eines Besuchers richtet es einen Arbeitsbereich ein, führt die Website aus und räumt danach auf. Beide Lücken nutzen aus, was passiert, wenn dieses Aufräumen zur falschen Zeit angestossen wird.

• CVE-2026-109618: Der Speicher geht zur falschen Zeit ausJede Anfrage darf nur eine bestimmte Menge Arbeitsspeicher belegen, standardmässig 128 Megabyte. Wird die Grenze überschritten, bricht PHP die Bearbeitung mit einer Art Notbremse ab. Ein Angreifer kann diese Notbremse gezielt auslösen, während der Arbeitsbereich erst halb eingerichtet ist. Das anschliessende Aufräumen findet dann Daten vor, die es für vollständig hält, obwohl sie es nicht sind. Mit einer sorgfältig gebauten Anfrage lässt sich darüber eigener Code auf dem Server ausführen. Besonders gefährlich ist das bei Apache mit mod_php, weil dort das Aufräumen auch dann läuft, wenn das Einrichten gescheitert ist.
• CVE-2026-109619: Reste der letzten Anfrage bleiben liegenPHP-Prozesse bearbeiten nacheinander viele Anfragen. Dabei gibt es Verwaltungsinformationen, die zwischen zwei Anfragen zurückgesetzt werden müssen. Bricht die erste Anfrage mit einem schweren Fehler ab, bleibt ein Teil dieser Informationen stehen und zeigt auf Speicher, der längst freigegeben ist. Die nächste Anfrage, vom Angreifer geschickt, trifft auf diese Reste und kann sie missbrauchen. Drei der fünf bekannten Angriffswege nutzen dafür die Fortschrittsanzeige für Datei-Uploads, eine Funktion, die PHP schon verarbeitet, bevor die eigentliche Website überhaupt startet.

Das Resultat ist in beiden Fällen dasselbe: Ein Unbekannter kann ohne Passwort, ohne Konto und ohne Mitwirkung eines Nutzers Programme auf dem Webserver starten. Daher der Name php2shell, «von PHP zur Kommandozeile». Von dort aus liest er die Datenbank mit Kundendaten, baut Hintertüren ein, verteilt Schadsoftware an Besucher oder nutzt den Server als Sprungbrett ins Firmennetz. Das BACS weist zudem darauf hin, dass PHP oft unbemerkt in Geräten steckt: in Routern, Netzwerkspeichern, Druckern und Verwaltungsoberflächen von Firewalls. Synology, QNAP, pfSense und OPNsense haben eigene Updates veröffentlicht.

Die Lage in Zahlen

Die letzte Zahl ist die beunruhigendste. PHP 8.1 und alle älteren Versionen haben das Ende ihrer Lebensdauer erreicht und erhalten offiziell keine Sicherheitsupdates mehr. Das PHP-Sicherheitsteam hat für 7.4, 8.0 und 8.1 zwar inoffizielle Quellcode-Korrekturen bereitgestellt, und einige Hoster wie Hetzner oder Hostpoint haben sie bis hinunter zu PHP 5.6 eingebaut. Wer aber einen eigenen Server mit einer alten Version betreibt, steht ohne fertiges Paket da. Für diese Systeme empfiehlt die amerikanische CISA ohne Umschweife: vom Netz nehmen, bis sie aktualisiert sind.

Wie Sie sich schützen: Die Reihenfolge zählt

• 1. Herausfinden, ob und welches PHP Sie einsetzenUnser kostenloser Website-Check liest die PHP-Version, die Ihr Server nach aussen meldet, und vergleicht sie mit den Fix-Versionen. Zeigt er «Version verborgen», ist das gut eingestellt, bedeutet aber auch, dass Sie den Patchstand selbst nachfragen müssen. Vergessen Sie dabei nicht die Systeme, die keine Website sind: Intranet, Nextcloud, Ticketsystem, NAS, Router.
• 2. Beim Hosting-Paket: Bestätigung vom Hoster, PHP-Version im Kundencenter prüfenDie grossen Schweizer Hoster haben die Korrektur am 21. und 22. Oktober eingespielt. Prüfen Sie trotzdem im Kundencenter, welche PHP-Version für Ihre Website eingestellt ist, und wechseln Sie auf 8.2 oder neuer, falls dort noch 7.4 oder 8.1 steht. Das BACS empfiehlt ausdrücklich, sich die Behebung vom Hoster schriftlich bestätigen zu lassen.
• 3. Beim eigenen Server: Update einspielen und PHP neu startenDebian, Ubuntu, Red Hat und SUSE haben Pakete veröffentlicht. Wichtig: Diese Distributionen behalten nach dem Sicherheits-Backport die alte Versionsnummer bei, ein Debian-Server kann also «8.2.29» melden und trotzdem geschützt sein. Massgebend ist das Datum des Pakets, nicht die Nummer. Nach dem Update müssen PHP-FPM beziehungsweise Apache neu gestartet werden, sonst läuft der alte Code weiter. Container-Images (Docker) brauchen ein neues Basis-Image und einen Neustart.
• 4. Alte PHP-Versionen migrieren, nicht flickenWer noch PHP 7.4, 8.0 oder 8.1 einsetzt, hat mit php2shell einen zwingenden Anlass für den Wechsel. Die nächste Lücke kommt bestimmt, und dann gibt es wieder keinen offiziellen Fix. Die meisten WordPress-Websites laufen mit aktuellen Plugins problemlos unter PHP 8.3. Wir helfen beim Test auf einer Kopie, bevor die Live-Website umgestellt wird.
• 5. Wenn das Update warten muss: Die NotbremsenDas PHP-Team nennt Einstellungen, die das Risiko senken, aber keine Sicherheit garantieren: session.upload_progress.enabled=0, memory_limit=-1 (nur zusammen mit Speicherbegrenzung durch Container oder Webserver), fatal_error_backtraces=0 bei PHP 8.5 und bei PHP-FPM pm.max_requests=1. Dazu eine Web Application Firewall, etwa die Cloudflare-Regeln, die seit dem 21. Oktober aktiv sind. Alles zusammen ersetzt den Patch nicht, kauft aber Zeit.
• 6. Prüfen, ob schon jemand drin warDie Lücke wurde vier Tage vor dem Patch ausgenutzt. Das BACS betont: Ein Update schliesst die Tür, bringt aber niemanden hinaus, der bereits im Haus ist. Suchen Sie nach neuen oder veränderten PHP-Dateien in Upload-Verzeichnissen, nach unbekannten Administratorkonten, nach ungewöhnlichen Einträgen im Zugriffsprotokoll seit dem 17. Oktober und nach Prozessen, die nicht zum Server gehören. Shop-Betreiber sollten zusätzlich Bestellungen aus dem Zeitraum der Abschaltung kontrollieren, weil Zahlungsbestätigungen verloren gegangen sein können.
• 7. Im Zweifel: Zugangsdaten wechselnWer Hinweise auf einen Einbruch findet oder die Lücke mehrere Tage offen hatte, behandelt alle Geheimnisse auf dem Server als bekannt: Datenbankpasswort, API-Schlüssel, SMTP-Zugang, die Salts in der WordPress-Konfiguration. Das ist in einer Stunde erledigt und nimmt einem Angreifer die Hintertür, die er sich vielleicht schon gebaut hat.
• 8. Backup prüfen, bevor man es brauchtGibt es eine Sicherung von vor dem 17. Oktober, die nicht auf demselben Server liegt? Lässt sie sich wiederherstellen? Diese zwei Fragen entscheiden darüber, ob ein Einbruch ein Ärgernis oder eine Katastrophe ist. Was ein Tag Stillstand kostet, rechnet unser Ausfallkosten-Rechner vor.

Hosting-Paket oder eigener Server: Wer muss was tun?

Was wir aus php2shell lernen

Drei Dinge bleiben von dieser Woche. Erstens: Die Lücke war 14 Jahre lang da, und gefunden hat sie eine KI. Das ist kein Einzelfall mehr, sondern der neue Normalzustand. Wir haben vor wenigen Tagen beschrieben, wie KI-Agenten Angriffe selbständig führen. php2shell zeigt die andere Seite derselben Medaille: KI findet auch die Lücken, und zwar schneller, als Menschen sie schliessen können. Der Abstand zwischen Bekanntwerden und Ausnutzung lag hier bei null, die Angriffe begannen vor dem Patch.

Zweitens: Wer auf veralteten Versionen sitzt, hat in solchen Momenten keine Option ausser Abschalten. Fast 900'000 Server weltweit stehen heute genau dort. Eine Website auf einer unterstützten Version zu halten, ist keine Kür, sondern die Voraussetzung dafür, dass es überhaupt ein Update gibt, wenn es zählt.

Drittens: Die Hoster, die am besten durch diese Woche gekommen sind, hatten ihre Prozesse vorbereitet. Hostpoint brauchte neunzig Minuten. Wer seine Websites selbst betreibt, braucht denselben Reflex, nur im Kleinen: wissen, was läuft, wissen, wie man es aktualisiert, und ein Backup, das man nicht erst im Ernstfall zum ersten Mal ausprobiert.