Heute gingen in Deutschland reihenweise Websites offline. Universitäten, Behörden, Krankenhäuser. Und jede Menge Entwickler-Teams – unseres eingeschlossen – haben den gesamten Tag mit Notfall-Updates verbracht.
Wer heute die Nachrichten verfolgt hat, stieß unweigerlich auf Schlagzeilen wie „kritische PHP-Sicherheitslücke“ und kryptische Versionsnummern, die niemandem etwas sagen, der nicht täglich damit arbeitet.
Also: Was ist da eigentlich passiert? Warum schaltet man eine Website vorsorglich ab, noch bevor sie überhaupt angegriffen wurde? Und warum reicht es nicht, einfach WordPress zu aktualisieren und weiterzumachen?
Das Problem lag tief in der Software, die unter Millionen von Websites läuft. Ein Angreifer konnte eine Schwachstelle nutzen, um ohne jegliche Anmeldung eigenen Programmcode auf dem Server auszuführen. Das PHP-Projekt hat am 21. Oktober 2026 Sicherheitsupdates für gleich zwei Schwachstellen veröffentlicht: CVE-2026-109618 und CVE-2026-109619, in Fachkreisen auch unter dem Namen PHP2Shell bekannt. Offizielle PHP-Mitteilung.
Schauen wir uns an, was das in der Praxis bedeutet.
Was ist PHP, und ist deine Website betroffen?
PHP ist sowohl die Programmiersprache als auch die Server-Laufzeitumgebung hinter einem riesigen Teil des Internets. Magento nutzt PHP für komplexe Onlineshops. WordPress (mit WooCommerce) und TYPO3 (mit Aimeos oder individuellen Setups) betreiben genauso riesige Onlineshops, Content-Portale und Unternehmensplattformen. Kunden stöbern im Katalog und bestellen; PHP erledigt im Hintergrund auf dem Server die eigentliche Arbeit.
Die heutigen Schwachstellen stecken genau in dieser Basisinfrastruktur. Dein CMS, deine Plugins oder dein Shop-Theme zu aktualisieren, bringt in diesem Fall absolut gar nichts: Die PHP-Installation auf dem Server selbst muss gepatcht werden. Für Magento wies Sansec ausdrücklich darauf hin, dass die Korrektur auf Infrastrukturebene erfolgen muss.
Die entscheidende Frage an dein Team oder deinen Hoster lautet also nicht: „Haben wir das CMS aktualisiert?“. Die richtige Frage lautet: Hat der PHP-Server, auf dem unsere Website läuft, beide Sicherheitsfixes erhalten?
Was die Shodan-Zahlen zeigen: Millionen Server, größtenteils veraltet
Wer sich fragt, wie groß das Problem weltweit ist, muss sich nur die Daten von Scannern wie Shodan ansehen: Zwischen 1,5 und 2,2 Millionen öffentlich erreichbare Hosts im Internet weisen sichtbare PHP-Spuren auf.
Und jetzt kommt der beunruhigende Teil: Von den Servern, die ihre Versionsnummer preisgeben, laufen rund 59% (etwa 884.000 Server) auf PHP 8.1 oder älter. Das sind Versionen, die ihr End-of-Life (EOL) längst erreicht haben und vom PHP-Kernteam schon lange keine offiziellen Sicherheitsupdates mehr bekommen.
Aber hier kommt das noch viel größere Problem: Selbst die modernsten, aktuellsten PHP-Versionen hatten diese Sicherheitslücke. Lies das noch einmal genau: Bis zum heutigen Notfall-Patch war jede einzelne aktive PHP-Version im Internet – 8.2, 8.3, 8.4 und das brandneue 8.5 – von dieser kritischen Schwachstelle betroffen. Niemand war geschützt, nur weil er auf der neuesten Version lief.
Die Länder mit den meisten exponierten PHP-Instanzen auf Shodan sind die USA, China, Japan und Deutschland. Wichtig dabei: Shodan zählt IP-Adressen und Server-Ports, keine einzelnen Websites. Da auf einem einzigen Shared-Hosting-Knoten oder Cloud-Server oft Dutzende oder Hunderte Websites und Onlineshops liegen, ist die tatsächliche Zahl betroffener Websites um ein Vielfaches höher.
Wie kann ein Request den Arbeitsspeicher fressen?
Ein Request ist das, was dein Browser an den Server schickt, wenn du eine Seite aufrufst oder ein Formular abschickst. PHP reserviert Arbeitsspeicher, um diese Daten auszupacken und zu verarbeiten. Aber die empfangenen Daten und ihre Struktur im Speicher von PHP belegen keineswegs denselben Platz.
Ein Angreifer kann dieses Missverhältnis gezielt ausnutzen. Die PHP-Sicherheitswarnung beschreibt speziell manipulierte Upload-Anfragen, deren Header und Felder im Inneren von PHP ein Vielfaches an Speicherstrukturen anfordern, als die winzige Netzwerkübertragung vermuten ließe. Die technische Erklärung von PHP erläutert die Details.
Bei Servern mit Apaches mod_php-Modul konnten Forscher demonstrieren, dass der Angriff noch vor dem eigentlichen Anwendungscode greift. Dein Login-Formular und deine Sicherheits-Plugins bekommen nicht einmal die Gelegenheit zu reagieren. CVE-2026-109618 Advisory.
Die zweite Schwachstelle betrifft Speicherüberreste zwischen verschiedenen Anfragen: Ein Worker-Prozess konnte Verweise auf bereits freigegebenen Speicher behalten und bei einer späteren Anfrage eines anderen Besuchers wiederverwenden. Unter den passenden Bedingungen ermöglicht auch das die Code-Ausführung – sowohl unter mod_php als auch unter PHP-FPM. CVE-2026-109619 Advisory.
Bedeutet das, dass jede PHP-Website sofort gehackt werden konnte? Nein. Die Serverkonfiguration, das Webserver-Modul und die Umgebung spielen eine entscheidende Rolle. Aber es bedeutet eben auch: Sauberer eigener Anwendungscode schützt nicht vor einer Lücke im Interpreter selbst.
Gelingt die Code-Ausführung, erlangt der Angreifer die Berechtigungen des Webserver-Prozesses. Im Kontext eines Onlineshops oder einer Unternehmensplattform ist das nicht bloß „ärgerlich“ – das ist ein absoluter Albtraum. Ein Angreifer kann die intimsten Kundendaten abgreifen: Bestellhistorien, Vorlieben, E-Mail-Adressen und private Wohnanschriften. Stell dir vor, was ein Krimineller, bewaffnet mit modernen KI-Werkzeugen und Agenten, mit solchen Daten anstellen kann: maßgeschneidertes Phishing, Identitätsdiebstahl und automatisierte Angriffe im Minutentakt. Und dabei rede ich noch gar nicht von DSGVO-Strafen oder behördlichen Konsequenzen – hier geht es schlicht um deine Verantwortung gegenüber den Kunden, die dir vertraut haben.
Warum gingen so viele deutsche Websites offline?
Weil eine temporäre, kontrollierte Nichterreichbarkeit für ein Unternehmen immer noch das deutlich kleinere Übel ist als ein massiver Datenabfluss oder fremdgesteuerte Server.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) rief zu sofortigen Updates auf und warnte davor, dass Angreifer veröffentlichte Patches analysieren und binnen kürzester Zeit funktionierende Angriffe entwickeln können. (Und ganz ehrlich: Was will man auch tun? Den Patch heimlich veröffentlichen? Ein Update herausbringen und sagen „Bitte verratet es den Hackern nicht“? Wir stecken hier in einer verdammt miesen Zwickmühle: In der Sekunde, in der der Fix publik wird, beginnt das Wettrennen gegen die Uhr.)
Behörden, Universitäten und Kliniken schalteten ihre Portale vorsorglich ab. RBB-Bericht zur BSI-Warnung und betroffenen Institutionen.
Die Universität Leipzig beispielsweise kappte den externen Internetzugriff auf Website, Lern- und Prüfungsplattformen und ließ diese nur noch über das interne Campusnetz und VPN erreichbar, während man auf Patches wartete. Hinweis der Universität.
Eine Fehlermeldung bedeutete heute also meistens nicht, dass eine Website erfolgreich gehackt wurde – sondern dass die Administratoren die Notbremse zogen, um das System bis zum Eintreffen der Updates zu schützen.
Was empfahlen Österreich und die Schweiz?
Österreichs nationales Notfallteam CERT.at empfahl Betreibern frühzeitig ein Wartungsfenster für 16:00 Uhr einzuplanen und Systeme notfalls abzuschalten. CERT.at warnte zudem treffend vor der zeitlichen Lücke zwischen dem offiziellen PHP-Release und der Bereitstellung fertiger Pakete in den Linux-Repositories der Hoster. Genau diese Verzögerung bestimmte schließlich den gesamten Nachmittag. Warnung von CERT.at.
Das Schweizer Bundesamt für Cybersicherheit (BACS) drängte auf sofortige Updates und betonte, nicht nur öffentliche Websites zu prüfen: Auch interne Anwendungen, Administrations-Oberflächen und Appliances laufen oft mit PHP. Zudem stellte das BACS klar, dass eine Web Application Firewall (WAF) allein keinen verlässlichen Schutz bietet. Empfehlung des BACS.
Den Preis für praktischen Humor gewann jedoch das niederländische NCSC: Es nahm seine eigene Hauptwebsite vorsorglich vom Netz und wich für Statusmeldungen auf sein Community-Forum aus. Hinweis des niederländischen NCSC.
Wenn die Cybersicherheitsbehörde eine zweite Website braucht, um zu erklären, warum ihre erste Website wegen einer Sicherheitslücke offline ist, zeigt das immerhin eins: Sie nehmen ihre eigenen Ratschläge ernst.
MaxCluster: Aus „kurz offline“ wurde der halbe Tag
Der deutsche E-Commerce-Hoster MaxCluster kündigte an, Kundenshops vorsorglich in den Wartungsmodus zu versetzen – veranschlagt war zunächst rund eine Stunde. Doch das Statuslog füllte sich schnell mit den üblichen Hürden: Paketverzögerungen der Linux-Distributoren, unterschiedliche Release-Zeiten je nach Betriebssystem und PHP-Version. Am Abend hieß es schließlich, dass einige ältere Versionen mit Extended Support noch 24 bis 48 Stunden auf Patches warten könnten. Wartungsprotokoll von MaxCluster.
IONOS, Infomaniak und Hetzner: Unterschiedliche Strategien
IONOS kündigte ein 24-Stunden-Rollout an, warnte vor kurzzeitigen Ausfällen und schaltete vorsorglich betroffene Managed-Nextcloud-Instanzen ab. Wichtiger Hinweis im Statusbericht: Kunden mit unmanaged Root-Servern oder VPS mussten selbst patchen – Managed-Services greifen dort naturgemäß nicht. IONOS Hosting-Status; Nextcloud-Meldung.
Infomaniak verteilte Patches für die Versionen 7.4 bis 8.5 und forderte Betreiber älterer Versionen zum sofortigen Upgrade auf. Als Schutzmaßnahme wurden Datei-Uploads und Fortschrittsanzeigen in kSuite, SwissTransfer und Ticketsystemen temporär deaktiviert und phpMyAdmin in Wartung gesetzt. Infomaniak Statusbericht.
Das zeigt, wie unterschiedlich Wahrnehmung sein kann: „Die Website funktioniert“ bedeutet für einen Besucher etwas völlig anderes als für einen Redakteur, der Bilder hochladen möchte, oder ein ERP-System, das Bestelldaten überträgt.
Hetzner bestätigte die betroffenen Versionen und meldete die Verfügbarkeit der Patches im Status-Dashboard. Hetzner Vorfallmeldung.
Am einfachsten war es bei den Cloud-Servern, die wir selbst verwalten: Dort konnten wir die Updates nahezu unsichtbar für die Endkunden einspielen.
Wobei... eigentlich stimmt das gar nicht. Am allerentspanntesten war es für die Systeme, die überhaupt kein PHP nutzen. Alle unsere Kunden mit Node.js- und Go-Backends haben nicht einmal mitbekommen, dass etwas passiert ist – außer vielleicht diejenigen, die in der Mittagspause versucht haben, sich an der Uni Leipzig oder der RWTH Aachen für Prüfungen anzumelden oder ein Bürgeramt-Portal aufzurufen!
Womit wir heute den Tag verbracht haben (Spoiler: verdammt viel Arbeit)
Machen wir uns nichts vor: Wir haben den gesamten Tag an vorderster Front verbracht. Den kompletten Tag über haben wir Shop- und Servicestatus überwacht, Cloud-Server aktualisiert und Kubernetes-PHP-Container neu gebaut. Es war ein absolut verrückter Tag.
Kurzer Selbsttest: Könntest du für dein Unternehmen innerhalb von 60 Sekunden aus dem Kopf aufzählen, welcher Kunde auf welcher Technologie, welcher PHP-Version und welchen Schnittstellen läuft? Für die allermeisten Firmen artet so etwas in eine panische Excel-Suchaktion aus. Wir hatten zumindest den Vorteil, dass wir eine zentrale Wissensdatenbank für unsere KI-Agenten nutzen – Kernote mit RAG (Retrieval-Augmented Generation). Unsere Agenten konnten sofort die exakten Architekturen, Umgebungen und Repositories aus den dokumentierten Fakten abrufen.
Aber selbst wenn das Nachschlagen dank Kernote relativ einfach war: Heute war ein verdammt harter Tag. Das eigentliche Update-Paket herunterzuladen dauert fünf Sekunden. Doch sicherzustellen, dass komplexe Checkouts, ERP-Konnektoren und Zahlungs-Gateways nach dem Update noch laufen, frisst den ganzen Tag. Ich kann dir gar nicht sagen, wie viele Millionen KI-Token wir heute verbrannt haben, um nicht-triviale Aufgaben zu bewältigen und unsere automatisierten Test-Suites im Eiltempo an dieses Update anzupassen.
(Über Kernote und wie wir autonome Agenten im Agenturalltag einsetzen, schreiben wir in Kürze einen ausführlichen separaten Artikel. Bleib dran.)
Was du jetzt tun solltest
Erstens: Frage die Verantwortlichen deiner IT-Infrastruktur, ob die PHP-Server, die den tatsächlichen Webtraffic verarbeiten, die heutigen Sicherheitsupdates erhalten haben. Werde konkret: Frage nach deinem Magento-Shop, deiner TYPO3-Website, deinen WordPress-Portalen, internen Tools und Staging-Umgebungen.
Die offiziell korrigierten PHP-Versionen lauten 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Linux-Distributoren und Hoster backporten Fixes oft in eigene Paketversionen – lass dir also die Behebung der Schwachstellen bestätigen, anstatt dich nur auf die Versionsziffer zu verlassen. WAF-Regeln sind nützliche Pflaster, aber kein Ersatz für den Patch. Offizielle PHP-Releasehinweise.
Zweitens: Teste die geschäftskritischen Prozesse. Funktioniert der Checkout? Klappt der Kunden-Login? Gehen Formulare durch? Befindet sich ein System im Wartungsmodus, verlange klare Zeitschätzungen, damit dein Support-Team die Kunden informieren kann.
Und drittens: Wenn der Sturm vorüber ist, analysiere, was dir heute Handlungsspielraum verschafft hat. Bei uns war es ein vorab getestetes Upgrade von PHP 8.2 auf 8.3, das aus einem Blocker eine sofortige Lösung machte.
Du kannst nicht planen, wann die nächste Zero-Day-Lücke aufschlägt. Aber du kannst dafür sorgen, dass du beim nächsten Mal nicht mit deinen eigenen Altschulden kämpfst, während die Statusseite deines Hosters zur meistbesuchten Website deines Unternehmens wird.
Verfasst am 21. Oktober 2026. Die Angaben zu den Hostern spiegeln den Stand zum Zeitpunkt der Veröffentlichung wider. Unsere Erfahrungen mit MaxCluster beziehen sich auf die von uns eingesetzten Serverumgebungen.
