In der Fliegerei heißt „Check Six“: den Bereich hinter sich im Auge behalten – die Sechs-Uhr-Position, die man von selbst nicht sieht. Für viele Unternehmen liegt dieser tote Winkel nicht im Lager oder in der Produktion, sondern in der eigenen Website. Genauer: in der Technik, auf der sie läuft.

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht. PHP ist die Programmiersprache, auf der ein großer Teil aller Websites, Onlineshops und Kundenportale läuft – oft, ohne dass die Geschäftsführung es weiß. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hatte Betreiber schon vorab aufgerufen, die Updates unmittelbar nach Erscheinen einzuspielen. BSI-Vizepräsident Thomas Caspers hielt eine großflächige Ausnutzung innerhalb weniger Stunden für wahrscheinlich und mahnte: „Es besteht also unverzüglicher Handlungsbedarf!“

Was bisher bekannt ist

Die Lage ist noch in Bewegung; die folgenden Punkte stützen sich auf die Warnung des BSI und auf Veröffentlichungen von Sicherheitsfachleuten vom 21. Oktober 2026.

  • Die Schwachstellen: Es handelt sich um zwei Lücken (CVE-2026-109618 und CVE-2026-109619), die jeweils mit 9,2 von 10 Punkten bewertet sind. Angreifer können damit aus der Ferne eigenen Programmcode auf dem Webserver ausführen – ohne Anmeldung und ohne dass jemand etwas anklicken muss. In Anlehnung an die Log4Shell-Lücke von 2021 werden sie „PHP2Shell“ genannt.
  • Betroffene Versionen: Nach bisherigen Angaben sind alle PHP-Versionen bis mindestens zurück zu PHP 5 verwundbar.
  • Die Updates: Abgesichert sind die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35, erschienen am 21. Oktober um 16 Uhr deutscher Zeit. PHP 8.1 und ältere Versionen werden vom PHP-Projekt nicht mehr regulär unterstützt. Neben Updates des jeweiligen Anbieters oder dem Umstieg auf eine unterstützte Version stellt das PHP-Sicherheitsteam für diese Lücken ausnahmsweise minimale Quellcode-Patches für PHP 7.4, 8.0 und 8.1 bereit, die für selbst erstellte PHP-Installationen gedacht sind.
  • Wo der Fehler sitzt: Die Lücken stecken in PHP selbst, nicht in der Website. Onlineshops und Content-Management-Systeme sind deshalb auch dann betroffen, wenn ihr eigener Code fehlerfrei ist. Behoben wird das Problem auf dem Server, nicht in der Website.
  • Vorlauf: Technische Details waren schon vor der Veröffentlichung der Updates durchgesickert.
  • Angriffe: Ob die Lücken bereits aktiv ausgenutzt werden, wird unterschiedlich bewertet. Das BSI sprach am 21. Oktober von unbestätigten Berichten über bereits existierenden Angriffscode; einzelne Sicherheitsfirmen berichten von ersten Angriffen.

Noch offen: wie schnell Hoster und Dienstleister die Updates flächendeckend einspielen – und wie viele Systeme bis dahin bereits kompromittiert wurden.

Warum das kein reines IT-Problem ist

Das Besondere an diesem Fall ist nicht die Technik, sondern die Uhr. Das BSI rechnet damit, dass Angreifer die Updates mit KI-gestützten Werkzeugen in kurzer Zeit auswerten und daraus Angriffe bauen. Zwischen Veröffentlichung und Angriffswelle liegen damit nicht Wochen, sondern Stunden. Das BSI hat Unternehmen deshalb ausdrücklich aufgefordert, für den Zeitpunkt der Veröffentlichung Personal bereitzuhalten.

Genau hier wird es für viele Mittelständler schwierig. Die Website hat eine Agentur gebaut, der Server steht bei einem Hoster, der Onlineshop läuft über einen weiteren Dienstleister, das Kundenportal über einen dritten. Wer davon PHP aktualisieren muss, wer es darf und bis wann – das ist oft nirgends festgehalten. Jeder geht davon aus, dass sich ein anderer kümmert.

Die möglichen Folgen sind dabei sehr handfest:

  • Daten: Über Kontaktformulare, Shops und Portale liegen auf vielen Webservern Kundendaten. Werden sie abgegriffen, muss der Verantwortliche die Datenschutzverletzung unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde melden – es sei denn, sie führt voraussichtlich zu keinem Risiko für die Rechte und Freiheiten der betroffenen Personen.
  • Vertrauen: Eine manipulierte Website, die Schadsoftware verteilt oder gefälschte Zahlungsseiten zeigt, trifft Kunden direkt – und den Ruf des Unternehmens.
  • Sprungbrett: Ein kompromittierter Webserver kann der Einstieg in weitere Systeme sein, wenn er mit Warenwirtschaft, Datenbanken oder internen Netzen verbunden ist.
  • Umsatz: Wer seinen Shop vorsorglich vom Netz nehmen muss, verkauft in dieser Zeit nichts.

Die eigentliche Lehre ähnelt der aus dem Angriff auf die Kühlanlagen französischer Supermärkte: Die Schwachstelle ist nicht nur ein Stück Software. Es ist eine Zuständigkeit, die niemand ausdrücklich übernommen hat.

Was jetzt zu tun ist – und was vorbeugend hilft

Die technische Umsetzung liegt bei IT, Hoster oder Dienstleister. Ob sie rechtzeitig passiert, ist aber eine Führungsfrage. Daran setzt Check Six an – nicht als Ersatz für IT-Sicherheit, sondern indem wir mit Ihrem Team klären, wer was entscheidet und was im Ernstfall passiert.

1. Wissen, wo PHP läuft

Am Anfang steht eine einfache Liste: Website, Onlineshop, Kundenportal, Bewerberportal, Intranet, Ticketsystem. Viele davon laufen auf PHP, etwa alles, was auf WordPress, Shopware oder WooCommerce aufbaut. Wer diese Liste nicht hat, kann heute niemanden gezielt fragen.

2. Für jedes System einen Namen festlegen

Zu jedem Eintrag gehört eine verantwortliche Person – intern oder beim Dienstleister – samt Erreichbarkeit. Entscheidend ist, was im Vertrag steht: Wie schnell spielt der Dienstleister kritische Sicherheitsupdates ein? Gilt das auch an einem Mittwochnachmittag um 16 Uhr – oder am Freitagabend?

3. Bestätigung einholen, nicht nur Zusagen

„Machen wir“ ist keine Bestätigung. Das BSI empfiehlt ausdrücklich, den Patchstand zu überprüfen. Bitten Sie Ihren Dienstleister um eine kurze schriftliche Rückmeldung: Welche PHP-Version läuft jetzt auf welchem System? Ist es eine der abgesicherten Versionen – oder hat der Anbieter für ältere Versionen ein eigenes Update geliefert?

4. Den Notfall vorher entscheiden

Was passiert, wenn ein Update nicht sofort möglich ist oder der Server bereits Auffälligkeiten zeigt? Wer darf entscheiden, die Website oder den Shop vorübergehend vom Netz zu nehmen? Wer informiert Kunden, wer prüft die Meldepflicht? Diese Fragen lassen sich in Ruhe beantworten – nicht erst, wenn die Uhr läuft. Was in der ersten Stunde nach einem Angriff geklärt sein muss, beschreibt unser Beitrag Die erste Stunde nach einem Cybervorfall.

5. Unter Belastung prüfen

Pläne zeigen erst in der Übung, ob sie tragen. In einer TacEval – unserer realitätsnahen Krisenübung – lässt sich genau diese Lage durchspielen: Eine kritische Lücke wird bekannt, das Update erscheint um 16 Uhr, der Dienstleister ist nicht erreichbar. Dabei wird sichtbar, wie lange es von der Warnung bis zur bestätigten Absicherung dauert – und wo es hakt.

Fragen, die Sie sich jetzt stellen sollten

  1. Welche Ihrer Systeme laufen auf PHP – und wer weiß das in Ihrem Haus?
  2. Wer spielt bei Ihnen Sicherheitsupdates für Website und Shop ein: IT, Hoster, Agentur – oder niemand ausdrücklich?
  3. Wie schnell muss Ihr Dienstleister bei kritischen Lücken reagieren, und steht das im Vertrag?
  4. Haben Sie bereits eine Bestätigung, dass die PHP2Shell-Lücken auf Ihren Systemen geschlossen sind?
  5. Wer darf entscheiden, Website oder Shop vorübergehend abzuschalten?
  6. Wann haben Sie eine solche Lage zuletzt geübt?

Fazit

Die PHP-Lücken sind ein technisches Problem mit einer technischen Lösung: einem Update. Riskant wird es dort, wo niemand genau weiß, wer dieses Update einspielt und bis wann. Wenn zwischen Warnung und Angriff nur noch Stunden liegen, entscheidet nicht die Qualität der Software, sondern die Klarheit der Zuständigkeiten. Die lässt sich vorher herstellen – mit einer Übersicht, festen Ansprechpartnern und einer Übung, die zeigt, ob alles trägt.

Wenn Sie wissen möchten, wo Ihr Unternehmen bei diesen Fragen steht, sprechen Sie uns an: Vertrauliches Erstgespräch.

Quellen