Was die PHP-Warnung vom 21. Oktober bedeutet

Wir prüfen mit SpotLens Firmenwebsites darauf, was Google und KI-Systeme wie ChatGPT dort vorfinden und wie gut die Seiten gegen Angriffe geschützt sind. Am 21. Oktober 2026 hat das Bundesamt für Sicherheit in der Informationstechnik, kurz BSI, vor zwei schweren Sicherheitslücken in PHP gewarnt und geschrieben, das Update solle unverzüglich installiert werden.¹ Auf PHP laufen sehr viele Websites, darunter fast alle, die mit WordPress gebaut sind.

Die kurze Antwort auf die Frage, was du jetzt tun musst, lautet, dass PHP auf dem Server aktualisiert sein muss. Ein Update von WordPress oder von Plugins hilft dabei nicht, weil die Lücken eine Ebene tiefer liegen. Wer seine Website bei einem Hosting-Anbieter liegen hat, muss in vielen Fällen selbst nichts installieren, sollte aber nachfragen, ob das Update eingespielt ist, und bei alten PHP-Versionen genauer hinsehen.

In diesem Artikel gehen wir durch, was PHP ist, was die beiden Lücken so gefährlich macht und wie die Veröffentlichung abgelaufen ist. Danach geht es darum, wer bei welcher Art von Website handeln muss, was unsere eigene Erhebung über alte PHP-Versionen zeigt und was du nach dem Update noch prüfen solltest. Am Ende steht eine Liste mit den Schritten.

Was PHP ist

PHP ist eine Programmiersprache, die auf dem Server arbeitet, also auf dem Rechner, auf dem deine Website liegt. Jedes Mal, wenn jemand eine Seite aufruft, setzt PHP sie im Hintergrund zusammen. Es holt Texte und Bilder aus der Datenbank und verarbeitet ein abgeschicktes Kontaktformular. Der Besucher bekommt davon nur das Ergebnis zu sehen, die fertige Seite.

Weltweit nutzen laut dem Messdienst W3Techs 69,3 Prozent aller Websites PHP, deren serverseitige Technik sich erkennen lässt.² Das liegt vor allem an den bekannten Systemen, mit denen Firmen ihre Websites bauen und pflegen. WordPress, TYPO3, Joomla, Drupal und Shopsysteme wie Shopware laufen alle mit PHP.

In unserer eigenen Erhebung über 70.139 Firmenwebsites aus zwölf Branchen in Deutschland liefen 32.928 Websites erkennbar mit WordPress, TYPO3 oder Joomla, also knapp die Hälfte.³ Dazu kommen viele Seiten, deren System wir von aussen nicht bestimmen konnten und die ebenfalls mit PHP arbeiten dürften. Wie wir gemessen haben, steht im Artikel über die Erhebung.

Anders liegt der Fall bei Baukästen wie Wix, Jimdo, Webflow oder Squarespace. Dort betreibt der Anbieter die Technik selbst, und du hast keinen Zugriff auf den Server. In unserer Erhebung waren das zusammen 4.607 Websites, also etwa 7 von 100.³ Ob ein Baukasten-Anbieter betroffen war, kann nur er selbst sagen. Webflow etwa hat erklärt, seine Dienste seien nicht auf PHP gebaut und nicht betroffen.⁴

Was die beiden Lücken so gefährlich macht

Die beiden Lücken tragen die Nummern CVE-2026-109618 und CVE-2026-109619. In der Berichterstattung heissen sie PHP2Shell, angelehnt an Log4Shell, eine Lücke in einem verbreiteten Programmbaustein, die Ende 2021 weltweit Systeme betraf.¹ Über beide Lücken kann ein Angreifer aus der Ferne eigenen Programmcode auf dem Server ausführen. Er braucht dafür kein Passwort, und niemand auf der Website muss etwas anklicken.¹

Wie schwer eine Sicherheitslücke wiegt, geben Fachleute mit einer Punktzahl von 0 bis 10 an, dem sogenannten CVSS-Wert. Beide Lücken haben 9,2 Punkte.¹ Ein zuerst kursierender Wert von 10 war nach Angaben des PHP-Projekts falsch.⁵ Auch mit 9,2 liegen die Lücken im obersten Bereich der Skala. Das BSI führt die Warnung in seiner Übersicht mit der Kritikalität 3, „sehr hoch".⁶ In Medienberichten heisst diese Stufe meist Orange.

Wenn PHP bei einer Anfrage der Arbeitsspeicher ausgeht und die Verarbeitung an einer ungünstigen Stelle abbricht, räumt PHP nicht vollständig auf. Eine spätere Anfrage kann dann auf Speicher zugreifen, der eigentlich schon freigegeben war.⁷ Darüber lassen sich Daten aus anderen Anfragen mitlesen, etwa Passwörter oder Zugangsschlüssel, und im schlimmsten Fall eigener Code ausführen.⁸

Ausgelöst wird der Fehler über die Art von Anfrage, mit der eine Website Datei-Uploads entgegennimmt. Betroffen sind auch Server in der Grundeinstellung, und weil der Fehler in PHP selbst steckt, sind auch Websites mit sauber geschriebenem Code gefährdet.⁷ Die Forscher haben ihre Angriffe an aktuellen Fassungen von WordPress, Drupal und Joomla vorgeführt und betonen, dass die Ursache nicht in diesen Systemen liegt.⁸

Der fehlerhafte Code steckt laut den Entdeckern seit mehr als zehn Jahren in PHP.⁸ Betroffen sind alle Versionen ab PHP 5.4 aus dem Jahr 2012.⁷

Gefunden mit Hilfe von KI

Entdeckt hat die Lücken das Forschungsteam der Sicherheitsfirma Wiz, zusammen mit OpenAI und der Firma Calif.¹ Wiz schreibt, man habe dafür eigene Werkzeuge und die Sprachmodelle Gemini und GPT eingesetzt, und zwar beim Finden der Fehler, beim Bau des Angriffs und bei der Prüfung der Korrektur.⁸

Gefunden wurden die Lücken am 19. August 2026, gemeldet an das PHP-Sicherheitsteam am 24. August.⁸ Danach haben die Entwickler zwei Monate lang im Stillen an den Korrekturen gearbeitet. So ist das bei schweren Lücken üblich, damit Angreifer nicht vor den Verteidigern davon erfahren.

Wie die Veröffentlichung aus dem Takt geriet

Geplant war die Veröffentlichung für den 22. Oktober. Am Nachmittag des 20. Oktober tauchten die Kennnummern der Lücken aber bereits in Foren und sozialen Medien auf, zunächst mit einem falschen Datum und einem falschen Schweregrad. Am selben Abend veröffentlichte eine der beteiligten Firmen versehentlich ein Video, das einen Angriff zeigte. Es wurde gelöscht, Kopien verbreiteten sich trotzdem.⁵

Am Morgen des 21. Oktober stellte ein Software-Anbieter bereits fertige Pakete mit der Korrektur ins Netz, mehr als sechs Stunden vor dem vereinbarten Termin. Das PHP-Projekt hat das Update deshalb auf den 21. Oktober um 16 Uhr deutscher Zeit vorgezogen.⁵

Ob die Lücken schon vorher ausgenutzt wurden, ist bis heute nicht abschliessend geklärt. Das BSI sprach am 21. Oktober von unbestätigten Berichten über Angriffswerkzeuge.¹ Amazon hat nach einem Bericht von Help Net Security schon am 17. Oktober einen Angriffsversuch in seinen Fallen-Systemen registriert, vier Tage vor der Veröffentlichung.⁹ Cloudflare, ein Anbieter, über den viele Websites ihren Datenverkehr leiten, schreibt von Angriffsverkehr gegen seine Kunden und davon, dass Angreifer versucht hätten, die Schutzregeln zu umgehen.¹⁰

Was am 21. Oktober bei Hostern und Behörden passiert ist

Viele Hosting-Anbieter haben am 21. Oktober nicht auf das Update gewartet.¹¹ Mittwald hat um 14:16 Uhr zuerst Datei-Uploads auf den Websites seiner Kunden abgeschaltet und um 16:17 Uhr alle Systeme heruntergefahren, weil eine Gefährdung nicht auszuschliessen war. Um 22:52 Uhr waren die Korrekturen für PHP 7.2 bis 8.5 eingespielt und die Websites wieder erreichbar.¹²

IONOS hat am 21. Oktober um 17:44 Uhr eine Sicherheitswartung für alle Systeme angekündigt und den Abschluss innerhalb von 24 Stunden in Aussicht gestellt. Am Morgen des 22. Oktober lief die Behebung noch.¹³ Hetzner hatte die Korrekturen für PHP 7.4 und 8.0 bis 8.5 am 21. Oktober um 19:50 Uhr auf allen Webhosting- und Managed-Servern eingespielt, die für die alten Versionen PHP 5.6 und 7.3 am 22. Oktober um 06:32 Uhr.¹⁴

Auch Behörden, Hochschulen und Medien haben Seiten vom Netz genommen. In Deutschland hat nach Angaben der dpa etwa die Stadt Mainz ihre Online-Angebote vorsorglich abgeschaltet, und am Mittag des 22. Oktober meldete die Stadt auf ihrer Website, einzelne Angebote seien noch nicht wieder erreichbar.¹⁵ In der Schweiz hat der Kanton Basel-Stadt seine Websites vorsorglich heruntergefahren, und die Seiten der Universität Genf und der ETH Lausanne waren zeitweise nicht aufrufbar.¹⁶ In den Niederlanden gingen nach Angaben der Sicherheitsfirma Sansec unter anderem das Parlament, das nationale Cyber-Sicherheitszentrum und das Technikportal Tweakers vorübergehend offline.⁷

Wenn deine Website am Abend des 21. Oktober nicht erreichbar war, kann das also am Hosting-Anbieter gelegen haben. Eine Seite, die vorübergehend offline ist, heisst nicht, dass sie angegriffen wurde.¹⁷

Was ein Angreifer anrichten kann

Wer eigenen Code auf dem Server ausführen kann, hat im schlimmsten Fall die Kontrolle über die Website und über alles, was auf dem Server liegt.¹⁵ Was daraus folgt, hängt davon ab, was der Angreifer vorhat.

• Die Website zeigt fremde Werbung oder leitet Besucher auf andere Seiten weiter, etwa auf gefälschte Shops.
• Besuchern wird über die Seite Schadsoftware untergeschoben.
• Anfragen aus dem Kontaktformular mit Namen, Telefonnummern und Adressen werden mitgelesen, ebenso Passwörter und Zugangsschlüssel, die auf dem Server liegen.
• Über den Server werden Spam-Mails verschickt. Danach können auch die echten Mails der Firma beim Empfänger im Spam-Ordner landen.
• Der Angreifer richtet sich einen dauerhaften Zugang ein, über den er später wiederkommt, auch wenn die Lücke längst geschlossen ist.

Zwei Folgen treffen eine Firma auch dann, wenn der Angriff selbst schnell vorbei ist. Fliessen personenbezogene Daten ab, sieht die Datenschutz-Grundverordnung in Artikel 33 eine Meldung an die Aufsichtsbehörde vor, in der Regel innerhalb von 72 Stunden.¹⁸ Ob das im Einzelfall gilt, klärst du mit deiner Rechtsberatung. Und wenn Google auf einer Website gehackte Inhalte oder Schadsoftware erkennt, kann es in den Suchergebnissen einen Warnhinweis anzeigen, und Besucher sehen im Browser unter Umständen zuerst eine Warnseite.¹⁹

Warum ein WordPress-Update hier nichts bringt

Die Lücken stecken in PHP selbst, also in der Technik, auf der WordPress läuft. Ein Update im Verwaltungsbereich von WordPress tauscht WordPress und die Plugins aus, an PHP ändert es nichts. Cloudflare schreibt es ausdrücklich, Updates am Code der Website oder an Plugins beheben diese Lücken nicht.¹⁰

Aktualisiert werden muss PHP auf dem Server, und zwar auf eine dieser Versionen oder eine neuere.²⁰

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Die PHP-Entwickler schreiben dazu, es gebe keine vollständige Abhilfe ohne Update, das Update sei der einzige sichere Weg.²⁰

Wer handeln muss, hängt davon ab, wie deine Website betrieben wird

Viele kleine Firmen haben ihre Website bei einem Hosting-Anbieter und keinen eigenen Server. Wer dort was zu tun hat, hängt vom Paket ab.

• Webspace oder Webhosting-Paket. Der Hosting-Anbieter betreibt den Server und spielt das PHP-Update ein. Du musst nichts installieren, solltest aber nachfragen oder auf der Statusseite des Anbieters nachsehen, ob das Update eingespielt ist.¹⁰
• Managed WordPress. Das ist ein Paket, bei dem der Anbieter auch WordPress betreut. Auch hier ist der Anbieter für PHP zuständig.
• Eigener Server oder virtueller Server. Hier bist du selbst zuständig oder der Dienstleister, der den Server für dich betreut. Mehrere Hoster weisen ausdrücklich darauf hin, dass Kunden mit eigenen Servern selbst aktualisieren müssen.¹¹
• Baukasten wie Wix, Jimdo oder Webflow. Der Anbieter betreibt die gesamte Technik. Ob er betroffen war und was er getan hat, steht auf seiner Statusseite oder in seinen Mitteilungen.⁴

Wenn du nicht weisst, welches Paket du hast, steht es in deiner Rechnung oder im Kundenbereich des Anbieters. Hat eine Agentur deine Website gebaut, frag sie, wo die Seite liegt und wer sich um den Server kümmert.

Für alte PHP-Versionen gibt es kein fertiges Update

Die vier Versionen mit Korrektur gehören zu den Reihen 8.2 bis 8.5, und nur diese Reihen pflegt das PHP-Projekt noch.²⁰ Für PHP 8.1 und ältere Versionen gibt es kein fertiges Update. Für die Versionen 7.4 bis 8.1 haben die Entwickler nur Korrekturen im Quellcode bereitgestellt, die ein Hosting-Anbieter oder Entwickler selbst einbauen muss.⁹

Manche Hoster haben das getan. Mittwald hat die Korrekturen bis zurück zu PHP 7.2 eingespielt, Hetzner sogar für PHP 5.6 und 7.3.¹⁴ Darauf verlassen kannst du dich aber nicht, ohne nachzufragen.

Wie häufig alte PHP-Versionen sind, zeigt unsere Erhebung vom September. Bei 12.205 der 70.139 Firmenwebsites hat der Server die PHP-Version von sich aus angegeben, die übrigen halten sie verborgen.³ Von diesen 12.205 Websites liefen 37 von 100 auf einer PHP-Version, die laut php.net schon damals keine Sicherheitsupdates mehr bekam, genau waren es 4.483.³

Weil wir nur die Server sehen, die ihre Version verraten, ist das keine Hochrechnung auf alle Firmenwebsites. Weltweit kommt W3Techs auf ein ähnliches Bild. Von allen Websites mit PHP laufen dort 26,9 Prozent noch mit PHP 7 und 7,7 Prozent mit PHP 5.² Für keine dieser Versionen gibt es vom PHP-Projekt ein reguläres Update.

Auch PHP 8.2 bekommt nur noch bis zum 31. Dezember 2026 Sicherheitsupdates, das geht in den meisten Warnungen unter.²¹ Wer jetzt von einer alten Version auf 8.2 wechselt, steht in gut zwei Monaten wieder vor derselben Frage. Wenn ohnehin umgestellt wird, lohnt deshalb ein Blick auf PHP 8.3 oder neuer, das bis Ende 2027 gepflegt wird.²¹

Ein Umstieg auf eine neuere PHP-Version kann ältere Plugins oder Designvorlagen durcheinanderbringen, die mit der neuen Version nicht zurechtkommen. Deshalb sollte jemand die Website danach einmal durchklicken, vor allem Formulare und einen Shop, falls es einen gibt.

Hilft etwas, bis das Update eingespielt ist?

Bis zum Update hilft nur wenig. Cloudflare hat Schutzregeln ausgerollt, die bei Kunden auch im kostenlosen Tarif automatisch greifen, und schreibt dazu selbst, dass diese Regeln das Update nicht ersetzen.¹⁰ Wer seine Website über Cloudflare laufen lässt, hat also etwas Zeit gewonnen, das Update braucht er trotzdem.

Technische Notlösungen wie das Abschalten von Datei-Uploads auf dem Server gibt es, sie können aber Formulare und Shops lahmlegen und gehören in die Hände dessen, der den Server betreut.⁷ Das britische Cyber-Sicherheitszentrum NCSC rät, Systeme vom Netz zu nehmen, die sich nicht sofort aktualisieren lassen.⁹ Für eine Firmenwebsite kann das heissen, für ein paar Stunden eine einfache Wartungsseite anzuzeigen.

Nach dem Update auf Spuren achten

Das Update schliesst die Lücke. Hat sich ein Angreifer vorher schon einen eigenen Zugang angelegt, bleibt der aber bestehen. Deshalb lohnt in den Tagen nach dem Update ein zweiter Blick, auch wenn es keinen konkreten Verdacht gibt.

• Benutzerkonten. Gibt es im Verwaltungsbereich Administratoren, die niemand kennt?
• Inhalte. Zeigt die Seite Texte, Links oder Weiterleitungen, die nicht von dir stammen? Das fällt manchmal zuerst auf dem Handy oder in den Google-Ergebnissen auf.
• Google Search Console. Wenn du sie nutzt, zeigt dir der Bericht „Sicherheitsprobleme", ob Google auf deiner Seite gehackte Inhalte oder Schadsoftware gefunden hat.¹⁹ Was die Search Console ist, haben wir am Beispiel eines Website-Umbaus erklärt.
• Server. Unbekannte PHP-Dateien, geänderte Dateien im Theme und auffällig viele Fehlermeldungen in den Protokollen kann nur jemand mit Zugang zum Server prüfen.⁸

Häufige Fragen

Woran sehe ich, ob mein Hoster schon aktualisiert hat?

Am einfachsten an der genauen Versionsnummer. Zeigt WordPress unter „Werkzeuge", „Website-Zustand", „Bericht" und „Server" zum Beispiel PHP 8.3.36 oder höher an, ist die korrigierte Fassung installiert.²⁰ Eine kleinere Nummer heisst dagegen nicht sicher, dass das Update fehlt. Manche Anbieter bauen die Korrektur in ihre eigenen Pakete ein, ohne die Versionsnummer zu ändern, und bei alten Versionen wie PHP 7.4 geht es gar nicht anders. In diesen Fällen bleibt nur die Nachfrage beim Anbieter.

Betrifft das auch meinen Onlineshop?

Wenn der Shop mit PHP läuft, ja. Das gilt für WooCommerce, das auf WordPress aufsetzt, ebenso wie für Shopware und Magento. Sansec, eine Firma, die sich auf die Sicherheit von Onlineshops spezialisiert hat, hat unter anderem Magento getestet und nennt Onlineshops ausdrücklich als gefährdet.⁷ Bei Shops kommt dazu, dass ein Umstieg auf eine neue PHP-Version die Kasse oder den Versand betreffen kann. Eine Testbestellung nach dem Update ist deshalb Pflicht.

Ist das nur ein Problem für grosse Firmen?

Nein, Fachleute erwarten automatische Suchläufe, also Programme, die das Internet nach Servern absuchen, die noch nicht aktualisiert sind.¹⁵ Solche Programme fragen nicht, wie gross eine Firma ist oder ob es auf ihrer Website etwas Wertvolles gibt. Ein kleiner Server, der Spam-Mails verschickt oder Besucher auf gefälschte Shops weiterleitet, ist für Angreifer genauso nützlich.

Muss ich als Besucher von Websites etwas tun?

An deinen eigenen Geräten musst du wegen dieser Lücken nichts aktualisieren, sie betreffen die Server der Websites.¹⁷ Wenn eine Seite, die du sonst nutzt, plötzlich ungewohnte Inhalte zeigt, dich auf fremde Seiten weiterleitet oder ungewöhnlich oft nach einem Passwort fragt, verlass sie lieber und versuch es später noch einmal.

Was du jetzt tun kannst

1. Herausfinden, wo deine Website liegt. Webspace, Managed WordPress, eigener Server oder Baukasten. Das entscheidet, wer zuständig ist.
2. PHP-Version nachsehen. In WordPress findest du sie im Verwaltungsbereich unter „Werkzeuge", dann „Website-Zustand" und dort im Reiter „Bericht" unter „Server". Sonst steht sie meist im Kundenbereich deines Hosting-Anbieters.
3. Beim Anbieter nachfragen. Frag, ob PHP auf deinem Paket schon auf eine der vier Versionen oben oder eine neuere aktualisiert ist. Viele Anbieter melden das auf ihrer Statusseite.¹²¹³
4. Alte Versionen ersetzen. Läuft deine Seite auf PHP 8.1 oder älter, frag, ob der Anbieter die Korrektur nachgebaut hat, und plane den Umstieg auf PHP 8.3 oder neuer.²¹
5. Nach dem Umstieg testen. Ruf die wichtigsten Seiten auf, schick ein Kontaktformular ab und prüf, ob Bilder und Downloads funktionieren.
6. In den nächsten Wochen aufmerksam bleiben. Benutzerkonten, Inhalte und die Search Console im Blick behalten, wie im Abschnitt davor beschrieben.

Die Warnung des BSI mit allen Angaben steht auf der Seite der Cybersicherheitswarnungen (öffnet in neuem Tab). Wie wir Sicherheit und Datenschutz einer Website im Ganzen prüfen, beschreiben wir auf unserer Seite zum Website-Sicherheitscheck.

Quellen

1. PHP, Kritische Schwachstellen bedrohen Webanwendungen weltweit (öffnet in neuem Tab), Bundesamt für Sicherheit in der Informationstechnik, Cybersicherheitswarnung Version 1.1 vom 21. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text

2. Usage statistics of PHP for websites (öffnet in neuem Tab), W3Techs, Stand 22. Oktober 2026, Anteil an allen Websites mit bekannter serverseitiger Sprache, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text

3. 70.139 Firmenwebsites in Deutschland 2026, SpotLens, Jordan Wichert, Stand 22. September 2026, Rohdaten als CSV und JSON unter CC BY 4.0. Kennzahlen phpVersionSichtbar und phpOhneSupport sowie die Systemzeilen für WordPress, TYPO3, Joomla, Wix, Jimdo, Webflow und Squarespace Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text

4. PHP2Shell critical PHP flaw, what to do about WordPress (öffnet in neuem Tab), Digidop, 22. Oktober 2026, gibt die Aussage aus dem Trust Center von Webflow wieder, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text

5. Today's PHP Security Release, and How We're Strengthening PHP Security (öffnet in neuem Tab), The PHP Foundation, 21. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text Zurück zum Text

6. Cyber-Sicherheitswarnungen, Übersicht (öffnet in neuem Tab), Bundesamt für Sicherheit in der Informationstechnik, Eintrag vom 21. Oktober 2026 mit Kritikalität 3, gelesen am 22. Oktober 2026 Zurück zum Text

7. PHP2Shell, Critical PHP RCE (öffnet in neuem Tab), Sansec, 21. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text

8. PHP2Shell, AI uncovers critical RCE vulnerabilities (öffnet in neuem Tab), Wiz Research, 21. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text

9. PHP2Shell, Critical PHP vulnerabilities patched, update now (öffnet in neuem Tab), Help Net Security, 21. Oktober 2026 mit Ergänzungen vom 22. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text Zurück zum Text

10. Cloudflare deploys protections against php2shell vulnerability (öffnet in neuem Tab), Cloudflare, 21. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text

11. Wie deutsche Webhoster auf PHP2Shell reagiert haben (öffnet in neuem Tab), das BlogMagazin, Stand 22. Oktober 2026, Übersicht mit Verweisen auf die Statusseiten der Anbieter, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text

12. Statusmeldung zur PHP-Sicherheitslücke (öffnet in neuem Tab), Mittwald, Einträge vom 21. und 22. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text

13. Statusseite (öffnet in neuem Tab), IONOS, Einträge „Sicherheitswartung" vom 21. und 22. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text

14. PHP security issues CVE-2026-109618 and CVE-2026-109619 (öffnet in neuem Tab), Hetzner Statusseite, Eintrag ab 21. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text

15. Sicherheitslücke bei PHP, Millionen Webseiten bedroht (öffnet in neuem Tab), ZDFheute mit Material der dpa, 21. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text Zurück zum Text

16. Gravierende PHP-Sicherheitslücke bedroht Millionen Webseiten (öffnet in neuem Tab), SRF, 21. Oktober 2026, zu den Hochschulen mit Verweis auf Blick, gelesen am 22. Oktober 2026 Zurück zum Text

17. PHP2Shell, Why websites are going offline for emergency security updates (öffnet in neuem Tab), Malwarebytes, 21. Oktober 2026, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text

18. Verordnung (EU) 2016/679, Datenschutz-Grundverordnung (öffnet in neuem Tab), Artikel 33, Amtsblatt der EU, gelesen am 22. Oktober 2026 Zurück zum Text

19. Bericht „Sicherheitsprobleme" (öffnet in neuem Tab), Search Console-Hilfe, Google, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text

20. PHP-Releases vom 21. Oktober 2026 (öffnet in neuem Tab), php.net, Meldungen zu PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text Zurück zum Text Zurück zum Text

21. Supported Versions (öffnet in neuem Tab), php.net, gelesen am 22. Oktober 2026 Zurück zum Text Zurück zum Text Zurück zum Text