Massive PHP Lücke mit Folgen und Pflichten
Seit dem 21. Oktober 2026 sind weltweit Webseiten ausgefallen, darunter auch Seiten von Kommunen und Behörden, die häufig sehr schnell waren, ihre Server vom Netz zu nehmen…
Ursache sind zwei kritische Schwachstellen im PHP-Kern (CVE-2026-109618 und CVE-2026-109619, CVSS 9.2), die in der Presse als „PHP2Shell“ bezeichnet werden. Angreifer können damit aus der Ferne, ohne Anmeldung und ohne Nutzerinteraktion Schadcode auf Webservern ausführen. Betroffen sein können alle PHP-basierten Systeme, etwa WordPress, TYPO3, Drupal, Magento und Onlineshops.
Das BSI hat die Warnung mit „3 / Orange“ eingestuft und geht von einer kurzfristigen Ausnutzung verwundbarer Systeme aus. Patches für die verschiedenen PHP-Versionen stehen inzwischen bereit.
Auch durch KI-Einsatz werden Lücken in Systemen heute viel kreativer und drastisch schneller aufgespürt und angegriffen, als noch vor ein paar Jahren.
Patchen ist nötig, aber nicht genug
Patches sind Pflaster… Ein Update schließt die Lücke, es entfernt aber keine Angreifer, die schon vorher eingedrungen sind. Laut Medienberichten hat Cloudflare schon Stunden vor der offiziellen Veröffentlichung Millionen von Angriffsversuchen registriert. Wer einen Server übernimmt, hinterlässt in der Regel eine Webshell. Sie fällt kaum auf und übersteht jedes Update. Ein installierter Patch sagt daher nur, dass die Tür jetzt zu ist. Er sagt nicht, ob vorher schon jemand drin war.
Verantwortung liegt bei den Betreibern
Die Verantwortung für die Sicherheit einer Webanwendung liegt bei den Verantwortlichen selbst. Sie lässt sich nicht an das Hosting oder an ein Update abgeben. Ein „Das hat der Dienstleister gemacht“ ersetzt keine eigene Prüfung, auch wenn in einer Auftragsverarbeitung die Pflicht des Dienstleisters stehen muss, dass er bei Kenntnis von Vorfällen den Verantwortlichen informieren muss.
Das gilt besonders dort, wo kritische oder sensible Daten betroffener Personen verarbeitet werden, etwa Gesundheits-, Beschäftigten-, Kunden- oder Finanzdaten. Hier ist mehr zu tun als nur zu patchen. Art. 32 DSGVO verlangt Maßnahmen, die dem Risiko angemessen sind. Je höher das Risiko für die Betroffenen, desto gründlicher muss die Prüfung ausfallen.
Kurz gesagt: wer viele sensible Daten auf Servern verarbeitet (oder verarbeiten lässt) muss mehr tun, als andere.
Was jetzt zu tun ist
Patchstand prüfen: Lassen Sie sich von Ihrem Hosting- oder IT-Dienstleister bestätigen, dass eine gepatchte PHP-Version läuft. Verifizieren Sie das selbst, zum Beispiel mit php -v und einem Abgleich mit dem Advisory auf php.net. Steht kein Patch zur Verfügung, empfiehlt das BSI, eine vorübergehende Trennung des Webservers vom Internet zu erwägen.
Spuren sichern: Sichern Sie Server- und Zugriffsprotokolle ab dem 20. Oktober, bevor sie automatisch rotiert oder gelöscht werden.
Auf Kompromittierung prüfen: Suchen Sie nach unbekannten oder kürzlich geänderten PHP-Dateien, Webshells, neuen Admin-Konten und auffälligen Zugriffen oder Datenabflüssen.
Zugangsdaten austauschen: Ändern Sie vorsorglich Passwörter, API-Schlüssel und Zertifikate, die auf dem Server lagen oder von dort erreichbar waren.
Bei kritischen Daten forensisch prüfen lassen: Wo viele oder sensible personenbezogene Daten betroffen sein können, sollte eine IT-Forensik klären, ob etwas passiert ist. Ein Update mit Hoffnung auf das Beste genügt hier nicht.
Dokumentieren: Halten Sie Prüfung, Maßnahmen und Ergebnis schriftlich fest, auch wenn kein Befund vorliegt. So können Sie Ihre Sorgfalt gegenüber Aufsichtsbehörden und Vertragspartnern nachweisen.
Meldepflichten im Blick behalten
Eine Sicherheitslücke allein ist noch keine meldepflichtige Datenpanne. Ist die Vertraulichkeit oder Integrität der Daten möglicherweise verletzt worden? Gibt es aber Hinweise auf eine erfolgreiche Ausnutzung und einen möglichen Zugriff auf personenbezogene Daten, ist in der Regel binnen 72 Stunden die Datenschutzaufsicht zu informieren (Art. 33 DSGVO). Gegebenenfalls sind auch die Betroffenen zu benachrichtigen (Art. 34 DSGVO). Einrichtungen, die unter NIS-2 fallen, müssen bei einem erheblichen Sicherheitsvorfall bereits nach 24 Stunden eine Erstmeldung an das BSI abgeben (§ 32 BSIG).
Bei kritischen Infrastrukturen, Finanzsystemen oder besonders sensiblen Daten können weitere Pflichten hinzukommen. Wer Dienste für andere betreibt, etwa als Auftragsverarbeiter oder SaaS-Anbieter, haftet je nach Vertrag zusätzlich für unterlassene Updates oder Ausfälle.
Quellen und Unterstützung
Die Informationen des BSI sollten bekannt sein – auch bei Ihren IT-Dienstleistern. Die Warnung des BSI (BITS-H Nr. 2026-297981-1132, Version 1.1) wird bei neuen Erkenntnissen aktualisiert. näheres dazu hier:
Die Patches und das Advisory finden Sie unter php.net. Bei Fragen, ob Sie betroffen sind oder ein meldepflichtiger Vorfall vorliegen könnte, melden Sie sich gern bei uns.
Wir klären mit Ihnen, welche Pflichten greifen, und stimmen uns bei Bedarf mit Ihrer IT-Forensik ab.