Was ist am 21. Oktober passiert?
PHP ist die Programmiersprache, auf der ein großer Teil des Webs läuft, darunter TYPO3, WordPress und Laravel. Am 21. Oktober 2026 hat das PHP-Team Updates für zwei kritische Sicherheitslücken veröffentlicht (CVE-2026-109618 und CVE-2026-109619). Über diese Lücken konnten Hacker auf fremden Servern eigene Befehle ausführen und im schlimmsten Fall die Kontrolle über eine Website übernehmen.
Warum war das trotz der Updates so gefährlich? Ein Update schließt eine Lücke nur dort, wo es eingespielt wird. Gleichzeitig macht es öffentlich, wo die Schwachstelle liegt. Ab diesem Moment suchen Hacker automatisiert nach Servern, die noch nicht aktualisiert sind. Gefährlich ist also die Zeit zwischen Veröffentlichung und Einspielen, und die ist bei jeder Website unterschiedlich lang.
Wie ernst die Lage war, zeigen zwei Einstufungen. Nach dem CVSS (Common Vulnerability Scoring System), dem internationalen Standard zur Bewertung von Sicherheitslücken, erreichten beide Lücken 9,2 von 10 Punkten. Damit gelten sie als kritisch.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) rief Warnstufe Orange aus. Sie ist die zweithöchste von vier Stufen und bedeutet: Die Lage ist geschäftskritisch, der normale Betrieb kann massiv beeinträchtigt werden. Die höchste Stufe Rot vergibt das BSI nur selten, etwa 2021 bei der Lücke in Log4j.
Die Updates standen um 16 Uhr bereit. Erste Ausnutzungsversuche hatte Amazon schon Tage vorher beobachtet, ab dem 22. Oktober zählte Cloudflare Millionen Angriffsversuche. Viele Betreiber nahmen ihre Seiten deshalb vorsorglich vom Netz, darunter Behörden in mehreren Bundesländern. Zwei Tage später folgte eine weitere Lücke, für die es zunächst nur Übergangslösungen gab.
Das Abschalten war vielerorts die verantwortungsvolle Entscheidung. Wer nicht schnell aktualisieren kann, schützt so seine Daten und seine Nutzer:innen. Es zeigt aber auch, wie viel davon abhängt, wie schnell ein Update überall ankommt.
Warum häufen sich solche Sicherheitsvorfälle?
Wir beobachten solche Vorfälle inzwischen in kürzeren Abständen (zuletzt etwa React2Shell im Dezember 2025, eine kritische Lücke in der verbreiteten Web-Technologie React, oder die Angriffe auf die Geräteverwaltung Ivanti EPMM Anfang 2026). Dafür gibt es zwei Gründe.
Der erste: Die Zeit zwischen Bekanntwerden und Ausnutzung einer Lücke schrumpft. KI-Werkzeuge helfen Hackern, verwundbare Stellen schneller zu finden und Angriffe zu automatisieren. Bei php2shell lag zwischen dem Update und den ersten Massenangriffen kaum ein Tag.
Der zweite: Websites werden komplexer. Eine moderne Website ist selten ein einzelnes System. Sie verbindet ein Content-Management-System mit Schnittstellen zu CRM, Shop oder Suche, mit Erweiterungen von Drittanbietern und zunehmend mit KI-Diensten. Jeder dieser Bausteine bringt eigene Software mit, und jeder kann eine Lücke enthalten.
Wir gehen deshalb davon aus, dass Unternehmen künftig häufiger mit solchen Vorfällen zu tun haben werden. Entscheidend ist, wie gut sie darauf vorbereitet sind.
Wie lief der Tag bei MOGIC und unseren Kunden?
Für Fälle wie diesen haben wir einen festen Ablauf. Er beginnt mit der Information, oft bevor überhaupt ein Update erscheint, und endet erst, wenn jedes betreute Projekt aktualisiert ist. Am 21. Oktober lief er in vier Schritten:
Früh im Bild. Das PHP-Team hatte die Updates am Vortag angekündigt. Die Meldung lief bei uns direkt bei der Technik auf, am Morgen war die Lage bewertet.
Vorbereitet, bevor das Update kam. Wir haben geprüft, welche der von uns betreuten Websites und Plattformen betroffen sind, was in jedem Projekt im Einzelnen zu tun ist und wer welches Projekt übernimmt. Als die Updates um 16 Uhr erschienen, stand der Plan.
Einmal zentral aktualisiert. PHP ist bei uns nicht in jedem Projekt einzeln installiert. Unsere Projekte bauen auf einer gemeinsamen Vorlage auf, die PHP bereits enthält. Diese Vorlage haben wir zuerst aktualisiert. So musste das Update nur an einer Stelle eingespielt und geprüft werden.
Projekt für Projekt ausgerollt. Danach ging das Update über unsere automatisierten Deployments in jedes einzelne Projekt.
Dass das ruhig lief, hat einen einfachen Grund: Unser Deployment, also das Einspielen neuer Versionen auf die Server, ist vollständig automatisiert und jeden Tag im Einsatz. Ein Sicherheitsupdate ist damit kein Sonderfall, für den man Abläufe erst zusammensuchen muss. Es ist ein weiterer Lauf eines Prozesses, der täglich funktioniert. Die Fehlerquote lag entsprechend nahe null.
Welche Fragen sollten Sie Ihrer Agentur oder internen IT stellen?
Ob Ihre Website von einer Agentur oder von Ihrer internen IT betreut wird: Diese vier Fragen zeigen schnell, wie gut eine Plattform auf den Ernstfall vorbereitet ist.
Wie erfahren Sie von einer kritischen Lücke, und wer entscheidet, was zu tun ist? Gut ist, wenn es feste Quellen gibt und einen festen Kreis, der eine Lücke sofort bewertet und den Umgang damit festlegt. Unabhängig davon, ob schon ein offizielles Update vorliegt.
Wie oft gibt es ein Deployment auf Ihrer Plattform? Wer nur alle paar Monate ein Update einspielt, muss im Ernstfall Abläufe erst wiederbeleben. Wer täglich Deployments durchführt, nutzt einen erprobten Weg.
Wer informiert Sie, und wann? Sie sollten am selben Tag wissen, ob Ihre Plattform betroffen ist und was gerade passiert, nicht erst aus der Presse.
Was passiert, wenn es noch kein Update gibt? Wie bei der Folgelücke im Oktober: Gibt es eine Übergangslösung, wer setzt sie um, und muss eine Seite vorübergehend vom Netz?
Sie müssen diese Fragen nicht selbst beantworten können. Ihre Agentur oder Ihre interne IT sollte es aber können, und zwar so, dass Sie verstehen, was los ist, was jetzt passieren muss und welcher Schritt als Nächstes kommt.
Was wir daraus mitnehmen
Sicherheit ist kein Projekt mit Enddatum, sondern ein Zustand im Betrieb. Investitionen in Automatisierung wirken an normalen Tagen unspektakulär. An Tagen wie dem 21. Oktober entscheiden sie, ob es einen geordneten Arbeitstag gibt oder eine Website, die vom Netz muss. Deshalb investieren wir genau dort: in Abläufe, die wir jeden Tag nutzen, damit sie im Ernstfall tragen.
Sie möchten wissen, wie gut Ihre Plattform auf den nächsten Ernstfall vorbereitet ist? Sprechen Sie uns an, wir sehen uns Ihren Betrieb gemeinsam mit Ihnen an.
