„Keine Schäden festgestellt“ bedeutet nicht, dass alles sicher ist – PHP-Sicherheitslücke führt zur Abschaltung von Websites, was passiert gerade?

Die Website, die Sie immer nutzen, ist plötzlich nicht mehr erreichbar. Doch was, wenn der Grund dafür nicht die Zerstörung durch einen Cyberangriff, sondern eine präventive Abschaltung zum Schutz vor einem Angriff war? Wie würden Sie darauf reagieren?

Eine schwerwiegende Sicherheitslücke in der Programmiersprache PHP, die Websites und Webanwendungen unterstützt, wurde bekannt. In Deutschland haben Behörden vorsorglich ihre Websites abgeschaltet.

Laut einem AFP-Artikel vom 22. Oktober, veröffentlicht von BUSINESS-PANORAMA, erklärte das Bundesamt für Sicherheit in der Informationstechnik (BSI), dass es zu diesem Zeitpunkt keine Fälle von Missbrauch dieser Sicherheitslücke festgestellt habe. Allerdings wurde die Möglichkeit eines erfolgreichen Angriffs nicht ausgeschlossen.

Wichtig beim Lesen dieser Nachricht ist zu verstehen, dass „keine Schäden festgestellt“ nicht gleichbedeutend mit „Sicherheit bestätigt“ ist.

Die Ankündigung des BSI ist keine „Entwarnung“

Laut dem Originalartikel warnte das BSI am Nachmittag des 21. Oktober vor der Sicherheitslücke in PHP und kündigte ein Sicherheitsupdate für 16 Uhr desselben Tages an.

Die Besorgnis bestand darin, dass nach der Veröffentlichung der Aktualisierungsinhalte Angriffe zunehmen könnten. Sobald das Problem durch die Korrektur bekannt wird, könnten Angreifer diese Informationen analysieren und ungeschützte Systeme ins Visier nehmen. Der Artikel äußert auch Bedenken, dass diese Analyse durch KI erleichtert werden könnte.

Am folgenden Tag, dem 22. Oktober, erklärte das BSI, dass die meisten der vorsorglich abgeschalteten Websites der Bundesbehörden wiederhergestellt wurden. Es wurde darauf hingewiesen, dass die Tatsache, dass keine kompromittierten Systeme gemeldet wurden, darauf hindeuten könnte, dass viele Betreiber die empfohlenen Updates durchgeführt haben.

Dies ist jedoch eine Bewertung, die auf den verfügbaren Informationen basiert. Es bedeutet nicht, dass alle Websites untersucht wurden und keine Eindringlinge vorhanden waren.

Die Wiederherstellung der Websites ist eine gute Nachricht für die Nutzer, aber es ist zu früh, um daraus zu schließen, dass das gesamte Problem gelöst ist.

Das Problem liegt im „Fundament“ der Websites

PHP hat zwei schwerwiegende Sicherheitslücken, bekannt als „PHP2Shell“, behoben. Die Identifikationsnummern sind CVE-2026-109618 und CVE-2026-109619. Die CVSS v4.0-Bewertung der Schwere liegt bei 9,2 und wird als „Kritisch“ eingestuft.

Die PHP Foundation gab am 21. Oktober bekannt, dass sie ein Problem behoben hat, bei dem ein nicht authentifizierter Angreifer unter bestimmten Bedingungen Code auf einem Server ausführen kann, der PHP betreibt.

Für den normalen Nutzer ist PHP eine unsichtbare Präsenz. Es ist nicht das Design des Bildschirms oder der Artikel selbst, sondern es übernimmt die Verarbeitung im Hintergrund.

Daher reicht es nicht aus, nur auf das Erscheinungsbild der Website oder das Verwaltungsdashboard zu achten, wenn man die aktuelle Situation betrachtet. Es ist notwendig, den Status der Korrekturen der Plattform zu überprüfen, die die Anwendung betreibt.

Die von der PHP Foundation veröffentlichten korrigierten Versionen sind PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Betreiber müssen den Status der Korrekturen überprüfen, einschließlich der Anweisungen der Anbieter, die ihre Umgebung bereitstellen.

Verwechseln Sie nicht „Angriffsversuch“ mit „erfolgreichem Eindringen“

Zusätzlich zum Originalartikel über das BSI sollte auch der Beobachtungsbericht von AWS berücksichtigt werden.

AWS gab bekannt, dass es mit dem System „MadPot“ zur Beobachtung von Angriffen den Versuch der Ausnutzung von PHP2Shell am 17. Oktober festgestellt hat. Dies war vor der Veröffentlichung der Details zur Sicherheitslücke.

Andererseits erklärt AWS, dass unklar ist, ob die beobachteten Versuche in realen Systemen erfolgreich waren.

Das bedeutet, dass die Berichterstattung über das BSI, das „keine Fälle von Missbrauch festgestellt“ hat, und der Bericht von AWS über die „Beobachtung von Angriffsversuchen“ unterschiedliche Ziele und Inhalte haben. Es ist nicht möglich, nur auf einer Seite zu schließen, dass „es keine Angriffe gab“ oder dass „ein großflächiger Eindringungsschaden bestätigt wurde“.

Sowohl als Nutzer als auch als Betreiber ist es wichtig, die Existenz von Sicherheitslücken, die Beobachtung von Angriffen, den Erfolg von Eindringlingen und die Bestätigung von Informationslecks getrennt zu betrachten.

In sozialen Netzwerken gibt es auch Stimmen, die die schnelle Korrektur loben

In sozialen Netzwerken und Online-Communities gibt es nicht nur ein Gefühl der Dringlichkeit, sondern auch Meinungen darüber, wie die Berichterstattung aufgenommen wird.

Im Reddit-PHP-Community-Beitrag „Has PHP2Shell borne fruit?“ werden neben Artikeln, die Angst schüren, und Kritik an PHP auch Meinungen geäußert, die die schnelle Korrektur und die Reaktion der wichtigsten Linux-Distributionen loben.

Dies ist eine Auffassung, die darauf hinweist, dass neben der Schwere der Sicherheitslücke auch die Reaktion der Entwickler und Distributoren berücksichtigt werden sollte. Allerdings zeigt die Bewertung der Schadenssituation durch den Beitragsersteller nicht die Sicherheit der gesamten Welt.

In einem anderen Reddit-Beitrag über den E-Mail-Alias-Dienst addy.io wurde geteilt, dass das Websystem als Reaktion auf PHP2Shell vorübergehend gestoppt wurde. Es wurde erklärt, dass die E-Mail-Zustellung fortgesetzt wird, und es wurde eine Ankündigung veröffentlicht, dass das System nach der Anwendung der Korrektur wiederhergestellt wurde.

Anstatt einfach zu sagen, „der Dienst ist nicht verfügbar“, wird mitgeteilt, was gestoppt wurde, was verfügbar ist und wann es wiederhergestellt wurde. Solche Informationsaustausche können dazu beitragen, die Ängste der Nutzer zu verringern.

Es sei darauf hingewiesen, dass die hier vorgestellten Beiträge individuelle Beiträge sind und keine Mehrheitsmeinung oder Umfrageergebnisse in sozialen Netzwerken darstellen.

Auch die Entscheidung, eine Website zu stoppen, erfordert Erklärungen

Eine präventive Abschaltung bringt Unannehmlichkeiten für die Nutzer. Wenn Anfragen nicht bearbeitet werden können, Verfahren nicht fortschreiten oder Produkte nicht gekauft werden können, entsteht auch eine Belastung für die Betreiber.

Dennoch hat die Einschränkung des Zugriffs von außen, bis die Korrekturen abgeschlossen sind, den Zweck, die Angriffsfläche zu reduzieren. CERT-EU empfiehlt auch, dass, wenn eine sofortige Korrektur nicht möglich ist, in Betracht gezogen werden sollte, die im Internet veröffentlichten Anwendungen vom öffentlichen Netzwerk zu isolieren.

Daher ist es schwierig, die Qualität des Betriebs nur anhand der Frage zu beurteilen, ob eine Abschaltung erfolgt ist.

Entscheidend ist vielmehr, ob der Grund für die Abschaltung erklärt wurde, welche Funktionen betroffen sind und wo die nächste Ankündigung zu finden ist.

Eine Website, die ohne Erklärung verschwindet, wird anders wahrgenommen als eine, die Maßnahmen zum Schutz der Nutzer kommuniziert.

Für Betreiber in Japan ist dies keine „Nachricht aus dem Ausland“

Das PHP-Problem betrifft nicht nur deutschsprachige Websites. Wenn die gleiche Technologie verwendet wird, müssen auch japanische Unternehmen dies überprüfen.

Die erste Herausforderung könnte darin bestehen, herauszufinden, wer die eigene Website verwaltet, anstatt sofort technische Änderungen vorzunehmen.

Wird die Website von einem Produktionsunternehmen betreut? Aktualisiert der Hosting-Anbieter die Plattform? Oder muss ein interner Mitarbeiter die Maßnahmen ergreifen?

Die zu überprüfenden Punkte können wie folgt zusammengefasst werden:

• Wird PHP in der Betriebsumgebung der Website verwendet?
• Wurde die Korrektur für die aktuelle Sicherheitslücke angewendet?
• Sind die Verantwortlichen für die Aktualisierung und die Methode zur Bestätigung des Abschlusses festgelegt?
• Wer trifft die Entscheidung, die Veröffentlichung einzuschränken, wenn eine sofortige Korrektur nicht möglich ist?

Zwischen „Der Auftragnehmer sollte es erledigen“ und „Ich habe die Bestätigung erhalten, dass es erledigt ist“ besteht ein großer Unterschied.

CERT-EU weist auch darauf hin, dass für die vor PHP 8.1 eingestellten Serien keine Updates vom PHP-Projekt bereitgestellt werden. Wenn alte Umgebungen weiterhin verwendet werden, muss überprüft werden, ob der Anbieter dieser Umgebung Korrekturen bereitstellt und ob eine Migration erforderlich ist.

Schutzmaßnahmen sind nicht unbedingt ein Ersatz für Updates

Es gibt Situationen, in denen man denken möchte, dass alles in Ordnung ist, weil ein Schutzsystem eingeführt wurde.

AWS stellt jedoch klar, dass im aktuellen Problem die Maßnahmen durch WAF eine ergänzende Maßnahme zur Reduzierung der Gefährdung sind und kein Ersatz für PHP-Updates.

Wichtiger als die Tatsache, dass irgendein Schutzprodukt verwendet wird, ist, wie weit diese Maßnahmen das aktuelle Problem abdecken.

Der Originalartikel beschreibt auch, dass das BSI die allgemeinen Nutzer auffordert, den Router nicht in einem Zustand zu belassen, in dem er von außerhalb zugänglich ist, und beim Herunterladen und Bereitstellen vertraulicher Informationen vorsichtig zu sein.

Dies bedeutet nicht, dass alle Benutzergeräte oder Router direkt von der aktuellen Sicherheitslücke betroffen sind. Die Maßnahmen der Betreiber und die alltägliche Vorsicht der Nutzer sollten getrennt betrachtet werden.

Es gibt Arbeit, die „Nichts ist passiert“ unterstützt

Wenn nach einer großen Warnung keine sichtbaren Schäden gemeldet werden, könnten einige denken, dass es übertrieben war.

Der Grund, warum keine Schäden sichtbar sind, könnte in einer frühzeitigen Aktualisierung oder präventiven Abschaltung liegen, oder es könnte sein, dass sie noch nicht erkannt wurden. Auf der Grundlage der aktuellen Informationen kann keine der beiden Möglichkeiten ausgeschlossen werden.

Die aktuelle PHP-Sicherheitslücke zeigt, dass die Verantwortung des Betriebs nicht nur darin besteht, die Website weiterhin zu veröffentlichen. Es ist auch eine Aufgabe, die Dienste unterstützt, sie bei Bedarf zu stoppen, zu korrigieren, den Zustand zu überprüfen und den Nutzern zu erklären.

Die Nachricht „Keine Schäden festgestellt“ ist kein Grund, die Maßnahmen einzustellen. Erst wenn überprüft wurde, wie die eigene Umgebung aussieht, kann das Lesen der Nachrichten zu einer tatsächlichen Vorbereitung führen.

Quellen

1. BUSINESS-PANORAMA/AFP (22. Oktober 2026)
   BSI hat keine Missbrauchsfälle festgestellt, die Möglichkeit eines Eindringens nicht ausgeschlossen, den Wiederherstellungsstatus der Regierungswebsites und die Grundlage für die Warnung der allgemeinen Nutzer.
   https://business-panorama.de/news.php?newsid=6715602

2. PHP Foundation „Today's PHP Security Release, and How We're Strengthening PHP Security“
   Veröffentlichung der korrigierten Version am 21. Oktober und offizielle Erklärung zu den durch die Sicherheitslücke verursachten Gefahren.
   https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/thephp.foundation

3. CERT-EU „Critical Vulnerabilities in PHP“
   CVE-Nummern, Schweregrad, betroffene Umgebungen, eingestellte Serien, offizielle Ratschläge zu Korrekturen und Isolation.
   https://www.cert.europa.eu/publications/security-advisories/2026-018Critical Vulnerabilities in PHP

4. AWS Security Blog: MadPot-Beobachtungsbericht zu PHP2Shell
   Versuche von Angriffen vor der Veröffentlichung und Erklärung, dass der Erfolg in realen Umgebungen unklar ist. Grundlage zur Unterscheidung zwischen „Beobachtung von Angriffen“ und „Bestätigung von Schäden“.
   https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/aws.amazon.com

5. AWS Security Blog: WAF-Maßnahmen gegen PHP2Shell
   Offizielle Dokumentation zur Rolle von WAF und der Notwendigkeit von PHP-Updates.
   https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/aws.amazon.com

6. Reddit・r/PHP „Has PHP2Shell borne fruit?“
   Zweifel an der Berichterstattung und individuelle Reaktionen, die die schnelle Korrektur loben. Die Bewertung der Schäden im Beitrag wird nicht als bestätigte Tatsache übernommen.
   https://www.reddit.com/r/PHP/comments/1xchgrv/has_php2shell_borne_fruit/reddit.com

7. Reddit