PHP2Shell: Was du jetzt tun musst — und warum statische Seiten gelassen bleiben

Mein erstes eigenes CMS war ein PHP-Programm, und meine WordPress-Plugins sind es bis heute. Das jüngste, JPKCom Harden & Trim, härtet WordPress gegen eine ganze Reihe von Angriffswegen. Gegen PHP2Shell hilft es nicht. Kein WordPress-Plugin hilft dagegen, auch kein Update von WordPress, TYPO3 oder Drupal, denn der Angriff trifft PHP selbst, bevor auch nur eine Zeile Anwendungscode läuft.

Die Seiten dieser Knowledge Base dagegen musste ich nicht anfassen. Sie liegen als fertige Dateien auf einem Apache, bei ihrer Auslieferung startet kein PHP. Das ist keine Überlegenheit aus Prinzip, sondern eine Folge der Bauform, über die ich in Nachhaltige Websites und Warum 11ty schon geschrieben habe. PHP2Shell zeigt, warum sie in einer Woche wie dieser so viel wert ist — und wo ihre Grenze liegt: Den Server, auf dem die Dateien liegen, macht sie nicht automatisch sicher. Warum, steht weiter unten.

In diesem Artikel geht es um beides: zuerst um das, was jetzt dringend ist — Hintergrund, Lage, eine Schritt-für-Schritt-Anleitung für Admins, Hinweise für Seitenbetreiber und eine Checkliste. Danach um die Frage, was du für die Zukunft daraus ableitest. Wenn du gerade keine Zeit hast: Spring direkt zur Anleitung oder zur Checkliste.

Stand dieses Artikels ist der 22. Oktober 2026, einen Tag nach den Patches. Am 23. Oktober habe ich einen Nachtrag ergänzt: Die Ausnutzung ist schwerer als befürchtet, und zwei der gefixten Versionen haben einen Absturzfehler. Die Lage bewegt sich noch; wo Quellen sich widersprechen, sage ich das dazu.

Die Kurzfassung

Nachtrag vom 23. Oktober

Zwei Tage nach den Patches hat sich an zwei Stellen etwas getan, das für dich wichtig ist.

Die Ausnutzung ist schwerer als befürchtet. Neun Sicherheitsfirmen haben NBC News (öffnet in neuem Tab) (englisch) gesagt, dass sie bis zum Abend des 22. Oktober (US-Zeit) keinen erfolgreichen Angriff gesehen hatten: CrowdStrike, ESET, die Google Threat Intelligence Group, Huntress, Palo Alto Networks, Recorded Future, Secureworks, Sophos und Trail of Bits. Palo Alto untersucht nach eigener Aussage mehr als 200 Proof-of-Concepts, Sophos hält die Lücken für „harder to exploit than folks thought at first". Viele der öffentlichen Proof-of-Concepts funktionieren laut Elias Taylor (öffnet in neuem Tab) (englisch) nicht gegen ein Standard-PHP, sondern setzen eine weitere Lücke voraus, über die ein Angreifer lokale Dateien einbinden kann (Local File Inclusion). Das Threat-Intel-Forum IFIN (öffnet in neuem Tab) (englisch) hat seine Einstufung „exploited in the wild" am 22. Oktober zurückgezogen, weil keine direkten Belege vorlagen, nur Behauptungen Dritter.

Die US-Behörde CISA schrieb in ihrer Warnung (öffnet in neuem Tab) (englisch) vom 21. Oktober, sie habe keine Ausnutzung beobachtet. Das BSI kennt in Version 1.2 seiner Warnung (öffnet in neuem Tab) vom 22. Oktober keine bestätigt kompromittierten Systeme aus der regulierten Wirtschaft oder der Bundesverwaltung. Berichte, die Patches ließen sich umgehen, hält es für widerlegt: „Das Patchen der beiden Schwachstellen schützt vor der Ausnutzung dieser." watchTowr (öffnet in neuem Tab) (englisch) dagegen spricht von Ausnutzung beider CVEs in seinen Honeypots, sagt aber nicht, ob sie erfolgreich war.

Für mich ist das trotzdem keine Entwarnung. Für Apache mit mod_php verweist das PHP-Team selbst auf einen demonstrierten Exploit ohne Anmeldung. VulnCheck (öffnet in neuem Tab) (englisch) hat nach eigener Aussage seit dem 22. Oktober einen funktionierenden Exploit für CVE-2026-109618, der auf x86-64 mit aktivem ASLR und display_errors=off Code ausführt — also in einer typischen Produktionskonfiguration —, getestet mit PHP 8.4.10 bis 8.4.26. Veröffentlicht hat VulnCheck ihn nicht. Und die Sicherheitsfirma ELLIO (öffnet in neuem Tab) (englisch) sieht seit dem Morgen des 22. Oktober Angriffsanfragen, die funktionierende Schadsoftware mitbringen, darunter Web-Shells und DDoS-Bots; ob sie irgendwo Erfolg hatten, ist offen. Exploits werden mit der Zeit besser, nicht schlechter. Patchen bleibt Pflicht, nur der Anlass für Panik ist kleiner geworden.

Die gefixten Versionen 8.4.27 und 8.5.12 haben einen Absturzfehler. Ein gewöhnlicher Bugfix aus demselben Release, nicht der Sicherheitsfix, lässt den Garbage Collector unter bestimmten Umständen die Eigenschaftstabelle von SimpleXML-Objekten doppelt freigeben (php-src#24488 (öffnet in neuem Tab), englisch). Die Folge sind abstürzende Worker mit der Meldung zend_mm_heap corrupted. Auslöser ist Code, der die Eigenschaften eines SimpleXML-Objekts als Array abruft — etwa per json_encode(), get_object_vars() oder (array) —, während das Objekt an einem Referenzzyklus hängt, den der Garbage Collector aufräumt. 8.3.36 und 8.2.35 sind laut dem Docker-Issue (öffnet in neuem Tab) (englisch) nicht betroffen, die offiziellen Images mit 8.4.27 und 8.5.12 dagegen schon. Die Korrektur steckt seit dem 22. Oktober im Quellcode beider Zweige, ein neues Release gab es bis zum 23. Oktober nicht.

Ob dein PHP betroffen ist, hängt davon ab, woher es kommt. Debian 13 liefert mit 8.4.27-1~deb13u1 das komplette 8.4.27 aus und hat den Fehler damit an Bord; laut einem Nutzer im Issue gilt das auch für die Pakete von deb.sury.org. Ubuntus Sicherheitspakete mit 8.3.6 und 8.5.4 tragen dagegen laut Changelog nur den Sicherheitsfix zurück und sind nicht betroffen. Im Zweifel hilft das Changelog deines Pakets.

Wenn du solche Abstürze siehst: Geh nicht auf 8.4.26, 8.5.11 oder eine andere ältere Version zurück, wie es im Issue jemand für die eigenen CI-Tests getan hat — auf einem Produktivsystem ist damit PHP2Shell wieder offen. Als Übergang hat ein Nutzer im Issue zend.enable_gc = 0 erfolgreich getestet. Das schaltet die Erkennung von Referenzzyklen ab, sodass der Speicherbedarf langlebiger Worker wachsen kann. Behalte ihn im Blick und spiel das nächste Release ein, sobald es erscheint.

Außerdem habe ich in Schritt 1 Geräte und Control-Panels ergänzt, zu denen Hersteller oder das BSI inzwischen Meldungen veröffentlicht haben, und den Stand bei Remi und deb.sury.org nachgezogen.

Was PHP2Shell ist

Hinter dem Namen stecken zwei CVEs, die laut Wiz Research (öffnet in neuem Tab) (englisch) eigentlich vier Fehler bündeln. Gemeinsam ist ihnen die Wurzel: Wie PHP mit fatalen Fehlern mitten in der Verarbeitung einer Anfrage umgeht, vor allem mit dem Fehler „Speicher voll".

CVE-2026-109618 betrifft die Behandlung von Speichermangel. PHP springt bei einem Out-of-Memory-Fehler per longjmp() aus der laufenden Verarbeitung heraus. Passiert das, während interne Anfragedaten erst halb initialisiert sind, behandelt das Aufräumen am Ende der Anfrage die kaputten Daten als gültig. Das GitHub-Advisory (öffnet in neuem Tab) (englisch) beschreibt mehrere Wege, eine Anfrage gezielt in diesen Zustand zu treiben, und zwar innerhalb der scheinbaren PHP-Limits: fehlende oder unbrauchbare Längenangaben, beliebig viele Header pro Teil einer multipart/form-data-Anfrage, leere Dateifelder, die nicht unter max_file_uploads fallen, und verschachtelte Feldnamen, die die Array-Arbeit vervielfachen.

CVE-2026-109619 betrifft Zustand, der eine Anfrage überlebt. Ein PHP-Worker bearbeitet viele Anfragen nacheinander. Nach einem fatalen Fehler kann interner Zustand übrig bleiben, dessen Speicher längst freigegeben ist, und eine spätere Anfrage an denselben Worker benutzt ihn, bevor die normale Initialisierung ihn zurücksetzt — ein klassischer Use-after-free. Bestätigt sind laut Advisory (öffnet in neuem Tab) (englisch) zwei Wege: Diagnosemeldungen aus INI-Einstellungen vor der Initialisierung und die Fortschrittsanzeige für Session-Uploads. Unter PHP 8.5 kommt der Pfad über fatal_error_backtraces hinzu, laut Advisory der am stärksten demonstrierte Fall.

Das Gefährliche daran ist der Zeitpunkt. PHP zerlegt eine multipart/form-data-Anfrage, bevor irgendein Skript startet. Deine Anwendung muss also kein Upload-Formular haben; eine einzige präparierte Anfrage an irgendeine PHP-Datei kann genügen. Bei Apache mit mod_php läuft das Aufräumen laut Advisory sogar dann, wenn der Start der Anfrage scheitert. Das PHP-Team (öffnet in neuem Tab) (englisch) stuft das Risiko dort am höchsten ein und verweist auf einen demonstrierten Exploit, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, „before any application code runs". Bei PHP-FPM ist Codeausführung über den Session-Pfad von CVE-2026-109619 bestätigt, abhängig von einer passenden Funktion der Anwendung; für CVE-2026-109618 gibt es dort laut Advisory noch keinen vollständigen Exploit. Calif zeigt in seinem Write-up (öffnet in neuem Tab) (englisch) ein Video gegen nginx mit PHP-FPM.

Wie weit das zurückreicht, ist beachtlich: Laut Wiz ist jede PHP-Version der letzten zehn Jahre von mindestens einem der Fehler betroffen, zurück bis PHP 5.4. Der Name ist bewusst gewählt — er soll laut BSI (öffnet in neuem Tab) an Log4Shell erinnern.

Und warum trifft das so viele? PHP läuft laut W3Techs (öffnet in neuem Tab) (englisch) auf rund 69 % aller Websites, deren serverseitige Sprache bekannt ist. Das BSI nennt beispielhaft WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense. Calif listet bestätigte Codeausführung ohne Anmeldung unter anderem gegen WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel und Symfony.

Gefunden von KI — und vorher schon einmal fast

Die Lücken wurden mit KI-Unterstützung gefunden, und zwar von mehreren Teams unabhängig voneinander. Calif war Teil von OpenAIs Initiative „Patch the Planet", fand laut eigenem Write-up am 1. August mehrere unabhängige Wege zur Codeausführung und meldete den ersten Fehler am 11. August an PHP; OpenAI meldete laut PHP Foundation (öffnet in neuem Tab) (englisch) am selben Tag unabhängig dasselbe. Wiz fand den ersten Fehler am 19. August mit Gemini 4 Argon und GPT-5.6 Sol, bestätigte binnen zwei Tagen Codeausführung gegen Drupal und WordPress und meldete am 24. August.

Der eigentlich unbequeme Teil der Geschichte steht im Beitrag der PHP Foundation: Erste Anzeichen des Speicher-Problems hatte ein Core-Entwickler schon 2024 gefunden, als er einen Befund aus einem externen Audit durch Quarkslab behob. Ein Angriffsweg war damals nur theoretisch, und das Security-Team konnte sich monatelang nicht zwischen konkurrierenden Korrekturen entscheiden. Die Foundation nennt das selbst „a structural failure" und kündigt an, Entscheidungen künftig per Mehrheit treffen zu können und komplexe Fixes zu priorisieren. Dass sie das offen aufschreibt, finde ich bemerkenswert — und es ist eine Erinnerung daran, dass sicherheitskritische Infrastruktur oft von wenigen Freiwilligen getragen wird. Die Foundation bittet Unternehmen, Hoster, Distributionen und Regierungen ausdrücklich um dauerhafte Finanzierung.

Eine Offenlegung, die aus dem Takt geriet

Geplant war eine koordinierte Veröffentlichung am Donnerstag, 22. Oktober. Es kam anders. Die Zeiten in UTC, aus der Darstellung der PHP Foundation, des Register (öffnet in neuem Tab) (englisch), von Cloudflare (öffnet in neuem Tab) (englisch) und Amazon (öffnet in neuem Tab) (englisch):

Über Chainguard schreibt die PHP Foundation, das Unternehmen habe das Embargo „unilaterally" gebrochen; jeder habe den Fix danach in Binärform studieren können, während alle anderen noch auf das Release warteten. Chainguard-Chef Dan Lorenc bestreitet gegenüber dem Register die Zeitleiste nicht, sagt aber, es habe keinen Leak gegeben: Koordinierte Offenlegung gelte nur, solange es keine Hinweise auf aktive Ausnutzung gebe. Wer hier recht hat, kann ich von außen nicht entscheiden. Für dich als Admin zählt die Folge: Zwischen den ersten kursierenden CVE-Nummern und dem Patch lagen 23 Stunden, und laut heise (öffnet in neuem Tab) hat die vorgezogene Veröffentlichung „die Maintainer in Bredouille gebracht". Debian lieferte nach 21 Uhr deutscher Zeit, Fedora, Gentoo, Ubuntu und Red Hat ebenfalls noch am Release-Tag; Slackware und SUSE folgten später. Das verbreitete Fremd-Repository rpms.remirepo.net hatte laut PHP am Release-Tag gar keine Updates; sie kamen einen Tag später (öffnet in neuem Tab) (englisch). Laut DDEV (öffnet in neuem Tab) (englisch) fehlten bei deb.sury.org die Pakete für ARM64 — im Debian-Repository für PHP 8.1 bis 8.4 auch am 23. Oktober noch, während das Ubuntu-PPA ppa:ondrej/php sie seit dem Release-Tag hat.

Den frühen Versuch vom 17. Oktober ordnet Amazon selbst vorsichtig ein: Wie der Angreifer an die Information kam, sei unklar; heise hält auch einen Exploit-Versuch gegen eine andere Upload-Lücke für möglich.

Die Folgen: Seiten offline, Angriffe laufen

Das BSI empfahl in seiner Warnung (öffnet in neuem Tab), bei fehlender Patch-Möglichkeit „eine vorübergehende Trennung vom Internet zu erwägen, da alle Workarounds keinen vollständigen Schutz vor Angriffe [sic] bieten". Viele haben genau das getan. Laut heise (öffnet in neuem Tab) nahm die Charité ihre Webseiten komplett vom Netz, Teile von berlin.de wurden abgeschaltet, die Internetwache der Berliner Polizei war nicht erreichbar, ebenso Behörden- und Polizeiseiten in Bayern und Niedersachsen; die FU Berlin schränkte ihre IT-Dienste ein. Reuters nennt laut heise Dänemark, Finnland, Frankreich und die Niederlande, wo Regierungsseiten vom Netz gingen oder in den Wartungsmodus wechselten.

Zur Ausnutzung gehen die Aussagen auseinander, und das ist ehrlich gesagt normal am Tag danach. Amazon spricht inzwischen von breiten Angriffsversuchen „in the wild", Cloudflare hat laut heise unter Berufung auf Reuters Millionen Versuche gesehen, und laut WinFuture (öffnet in neuem Tab) (ohne eigene Quellenangabe) tauchten Exploit-Beispiele schon Stunden vor der offiziellen Bekanntgabe in einschlägigen Foren auf. Die PHP Foundation dagegen schreibt, sie habe zum Release-Zeitpunkt keine funktionierenden Exploits identifiziert, und ob die beobachteten Versuche gegen echte Systeme erfolgreich waren, ist laut Amazon offen. Für deine Entscheidung ändert das nichts: Öffentliche Proof-of-Concepts gibt es — viele davon funktionieren allerdings nur zusammen mit einer weiteren Lücke, siehe Nachtrag —, die Patches lassen sich analysieren, und das BSI geht von einer kurzfristigen Ausnutzung aus.

Ein Wort zu Quellen: In den ersten Stunden kursierten Analysen, die sich selbst widersprachen oder schlicht falsche Versionsnummern als „gefixt" nannten. Verlass dich für die Versionen auf das Advisory von php.net (öffnet in neuem Tab) (englisch) und die Sicherheitsmeldungen deiner Distribution, nicht auf Forenbeiträge.

Schritt für Schritt: PHP2Shell schließen

Diese Anleitung richtet sich an alle, die PHP selbst betreiben: eigener Server, VPS, Container, Docker-Hosts. Wenn du gehostet bist, findest du weiter unten die kürzere Fassung.

1. Bestandsaufnahme: Wo läuft überall PHP?

Das ist der Schritt, der am häufigsten zu kurz kommt. Denk nicht nur an die Website:

• Webserver und VPS, auch ältere, „die nur noch eine Weiterleitung machen".
• Mehrere PHP-Versionen auf einem Server: Viele Setups mit deb.sury.org oder Control-Panels haben 8.1, 8.2, 8.3 und 8.4 parallel, jede mit eigenem FPM-Dienst.
• Container: Jedes Image mit PHP ist ein eigener Patch-Fall.
• Admin-Werkzeuge: phpMyAdmin, Roundcube, Control-Panels wie ISPConfig oder Plesk, Monitoring-Oberflächen.
• Geräte: Router- und Firewall-Oberflächen (pfSense, OPNsense), NAS-Systeme, ein Raspberry Pi als Mini-Server — heise rät ausdrücklich, auch dort zu prüfen. Hier brauchst du ein Update des Herstellers, mal als Firmware, mal als Paket.
• Herstellermeldungen zu Geräten (Stand 23. Oktober): Palo Alto meldet in seinem Advisory (öffnet in neuem Tab) (englisch) die Management-Oberfläche von PAN-OS samt XML-API als betroffen, dazu Panorama und die WildFire-Appliances WF-500 und WF-500-B in allen Versionen. Hotfixes für PAN-OS sind für den 26. bis 30. Oktober angekündigt, für Panorama und WF-500 gibt es noch keinen Termin; bis dahin rät Palo Alto unter anderem, das Management nur von vertrauenswürdigen internen IP-Adressen aus erreichbar zu machen. Netgate hat aktualisierte PHP-Pakete für pfSense veröffentlicht, Synology hat mit SA-26-14 (öffnet in neuem Tab) Paket-Updates herausgegeben. QNAP führt seine Geräte in QSA-26-18 (öffnet in neuem Tab) als betroffen, hat aber noch keine korrigierten Versionen (beide Meldungen englisch). Das BSI nennt in seiner aktualisierten Warnung (öffnet in neuem Tab) außerdem Produkte von F5 und Citrix NetScaler als zumindest teilweise betroffen.
• Control-Panels mit eigenem PHP: Bei Plesk läuft die Oberfläche selbst mit einer eigenen PHP-Engine (sw-engine), die das Update der Website-PHP-Versionen nicht erfasst. Laut Plesk (öffnet in neuem Tab) (englisch) ist sie erst ab Plesk Obsidian 18.0.81 Update 4 bzw. 18.0.80 Update 11 geschlossen; welche Version du hast, zeigt dir plesk version. Auch cPanel führt das BSI als betroffen.
• Entwicklungsumgebungen, die öffentlich erreichbar sind (dazu unten mehr).

Auf einem Debian- oder Ubuntu-Server verschaffen dir diese Befehle einen schnellen Überblick:

# Installed PHP packages (all versions, incl. mod_php)
dpkg -l 'php*' 'libapache2-mod-php*' | awk '/^ii/ {print $2, $3}'

# FPM services (active and inactive) and Apache with mod_php
systemctl list-units --type=service --all 'php*-fpm*'
ls /etc/apache2/mods-enabled/ | grep -i php

# Containers and the images they run on
docker ps --format '{{.Names}}\t{{.Image}}'

2. Die Version richtig prüfen — php -v reicht nicht immer

Hier lauert die größte Falle. Distributionen pflegen Sicherheitskorrekturen oft in ihre eigene Version ein, ohne die PHP-Versionsnummer zu ändern. Ubuntu 24.04 LTS zum Beispiel liefert PHP 8.3.6, und laut Ubuntu-Sicherheitsseite (öffnet in neuem Tab) (englisch) ist das Paket 8.3.6-0ubuntu0.24.04.13 gefixt. php -v zeigt dort weiter „8.3.6" — gepatcht, obwohl die Zahl unter 8.3.36 liegt. Umgekehrt ist eine Zahl über der Grenze kein Beweis, wenn der Dienst noch nicht neu gestartet wurde.

Prüf deshalb die Paketversion gegen die Meldung deiner Distribution:

Für andere Systeme (Red Hat, SUSE, Alpine, Gentoo) gilt dasselbe Prinzip: Sicherheitsmeldung des Herstellers zu CVE-2026-109618 suchen, Paketversion vergleichen. Kompilierst du selbst, gelten die Upstream-Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

3. Aktualisieren — und alles neu starten

Das Update selbst ist meist unspektakulär:

sudo apt update && sudo apt upgrade

Willst du gezielt nur PHP aktualisieren, nenn mod_php ausdrücklich mit, denn sein Paket heißt nicht php…: sudo apt install --only-upgrade 'php*' 'libapache2-mod-php*'. Die Meldungen „not installed" für nicht installierte Pakete kannst du dabei ignorieren.

Wichtig ist der Teil danach. Ein laufender Prozess benutzt den alten Code im Speicher weiter, bis er neu startet. Starte deshalb jeden Dienst neu, der PHP lädt:

# Every installed FPM version, not just the default one
sudo systemctl restart 'php*-fpm.service'

# Apache with mod_php
sudo systemctl restart apache2

Dazu kommen langlebige Worker, die du selbst betreibst: FrankenPHP, Queue-Worker, Supervisor-Prozesse. Prüf anschließend, ob wirklich jeder laufende Prozess neu gestartet ist. php -v oder php-fpm8.3 -v helfen dabei nicht, denn sie starten das Binary von der Platte — und das ist nach dem Update schon neu, auch wenn der Dienst noch mit dem alten Code im Speicher läuft. Aussagekräftig ist die Startzeit des Dienstes oder ein Werkzeug wie needrestart:

# "Active: ... since" must be later than the update
systemctl status 'php*-fpm.service' apache2 | grep -E '●|Active:'

# Lists processes still running old library or binary code
sudo needrestart -r l

4. Container neu bauen, nicht nur neu starten

Ein docker restart startet das alte Image. Du musst das Basis-Image neu ziehen und neu bauen, und zwar ohne Cache, damit der Paket-Layer wirklich frisch ist:

docker build --pull --no-cache -t meine-app .
docker run --rm meine-app php -v

Prüf im fertigen Image, welche Version tatsächlich drinsteckt, bevor du es ausrollst. Bei Images, die PHP über Distributionspakete installieren, gilt wieder die Paketversion aus Schritt 2.

DDEV-Nutzer: Lokale Entwicklung ist laut DDEV-Blog (öffnet in neuem Tab) (englisch) nicht betroffen, weil das Projekt nur auf deinem Rechner lauscht. Gefährlich wird es mit ddev share oder wenn du DDEV öffentlich als Hosting nutzt. Für PHP 8.2 bis 8.5 beschreibt der Beitrag ein kleines Dockerfile unter .ddev/web-build/, das die Pakete aktualisiert, für 5.6 bis 8.1 genügt ddev restart --no-cache — danach muss ddev php -v ein Build-Datum ab dem 21. Oktober zeigen. Auf ARM64, also auch auf Apple-Silicon-Macs, musst du auf die Pakete von deb.sury.org oder DDEV 1.25.5 warten. Stand 23. Oktober ist beides noch nicht da.

5. Alte PHP-Versionen: Backport oder Abschalten

PHP 8.1 und älter bekommen vom PHP-Projekt kein Release mehr. Du hast drei Wege:

• Pakete deiner Distribution: Debian LTS, Ubuntu (22.04 direkt, 20.04 und älter über Ubuntu Pro) und kommerzielle LTS-Anbieter liefern Backports. Das TYPO3-Team (öffnet in neuem Tab) (englisch) rät grundsätzlich zu PHP 8.2 oder neuer und verweist nur ELTS-Kunden mit TYPO3 v10 und PHP 7.4 auf kommerzielle PHP-Updates, etwa über Ubuntu Pro.
• Quelltext-Backports: Das PHP-Security-Team stellt minimale Patches für 7.4, 8.0 und 8.1 bereit, verlinkt im Advisory. Daneben gibt es vom GitHub-Konto shivammathur, von dem auch die bekannte GitHub-Action setup-php stammt, mit php-src-backports (öffnet in neuem Tab) (englisch) einen Fork, der Sicherheitskorrekturen in nicht mehr gepflegte Zweige zurückträgt (laut README „Security backports for EOL versions of PHP"). Prüf vor dem Einsatz selbst, ob die PHP2Shell-Fixes für deinen Zweig enthalten sind.
• Abschalten: Wenn beides nicht geht, ist die Empfehlung eindeutig. Das BSI rät, eine vorübergehende Trennung vom Internet zu erwägen.

Ein Selbstbau aus Patches ist nur etwas für dich, wenn du PHP ohnehin selbst kompilierst. Und so oder so: Ein Backport ist eine Brücke, kein Zuhause. Plane das Upgrade auf eine unterstützte Version.

6. Wenn du nicht sofort patchen kannst: Notbremsen

Das PHP-Team nennt Maßnahmen, die einzelne bekannte Angriffswege verbauen, und betont, dass sie eine Installation nicht sicher machen. Sie sind für die Stunden gedacht, bis das Update läuft:

; php.ini or FPM pool — must apply before request parsing, then restart every worker
memory_limit = -1                    ; CVE-2026-109618: no limit to push against
post_max_size = 8M                   ; 32M if you need uploads
upload_max_filesize = 6M             ; must stay below post_max_size
session.upload_progress.enabled = 0  ; CVE-2026-109619: confirmed session path
fatal_error_backtraces = 0           ; PHP 8.5 only

Ein paar Details entscheiden, ob das überhaupt greift:

• memory_limit = -1 muss so gesetzt sein, dass keine Anwendung es überschreiben kann, also per php_admin_value[memory_limit] = -1 im FPM-Pool oder per php_admin_value memory_limit -1 in der Apache-Konfiguration bei mod_php. Prüf, dass keine Pool-, Verzeichnis- oder Anwendungseinstellung wieder ein endliches Limit setzt. Auch dann kann ein echter Speicherfehler den verwundbaren Pfad noch erreichen. Ersetze das Limit nicht durch RLIMIT_AS oder RLIMIT_DATA — die können laut PHP genau den verwundbaren Fehler auslösen. Als Schutz für die Verfügbarkeit taugt eine Grenze per Container oder cgroup.
• session.upload_progress.enabled = 0 hilft nur über php.ini, FPM-Pool oder Server-Konfiguration, nicht über ini_set() oder eine .user.ini.
• Diagnosemeldungen zu verstecken (display_errors, error_reporting, @) hilft nicht. Ungültige oder veraltete INI-Einstellungen, die vor der Initialisierung Warnungen erzeugen, musst du entfernen.
• Braucht deine Anwendung gar keine Uploads, kannst du multipart/form-data schon am Webserver oder Proxy blockieren. ISPConfig bietet dafür ein eigenes Hilfsskript (öffnet in neuem Tab) (englisch) an, das Multipart-Anfragen vor PHP abweist — mit dem Hinweis, dass dann alle Uploads auf den betroffenen Seiten nicht mehr funktionieren.
• Eine WAF wie die von Cloudflare blockiert bekannte Angriffsmuster, aber nur für Verkehr, der auch über sie läuft. Wer deinen Server direkt über die IP erreicht, geht daran vorbei.

Wenn du nach dem Patch zurückbaust: memory_limit wieder auf einen endlichen Wert setzen. session.upload_progress.enabled = 0 darfst du laut Advisory stehen lassen, wenn du die Funktion nicht brauchst — die meisten Anwendungen brauchen sie nicht.

7. Nachsehen, ob jemand schon drin war

Weil die ersten Versuche vor dem Patch lagen, empfiehlt Amazon, Untersuchungen beim 17. Oktober zu beginnen. Konkrete Spuren, die Wiz, Amazon und PHP nennen:

• POST-Anfragen mit multipart/form-data, die PHP_SESSION_UPLOAD_PROGRESS enthalten.
• Multipart-Anfragen, auf die Meldungen zum Speicherlimit oder gehäufte HTTP-500-Antworten folgen.
• Auffällig große oder kaputte PHPSESSID-Cookies in Antworten — laut Wiz gibt einer der Fehler Speicherinhalt genau über dieses Cookie preis.
• PHP-Worker, die ohne erkennbaren Grund abstürzen oder neu starten.
• Unerwartete Prozesse, die vom Webserver-Benutzer gestartet wurden, und neue oder geänderte Dateien im Webroot.

# Request bodies are not in the access log, but a burst of 500s
# after POSTs is a start (zgrep also reads rotated .gz logs)
sudo zgrep -E '"POST [^"]*" 500 ' /var/log/apache2/*access.log* | tail -50

# With FPM, PHP fatals end up in the web server's error log
sudo zgrep -i 'Allowed memory size' /var/log/apache2/*error.log* /var/log/nginx/error.log*

# Crashed FPM workers
sudo zgrep -E 'exited on signal|SIGSEGV' /var/log/php*-fpm.log*

# Files whose inode changed since 17 October (ctime, unlike mtime,
# cannot be reset with touch)
sudo find /var/www -newerct '2026-10-17' -type f \
  \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \
     -o -name '.htaccess' -o -name '.user.ini' \) | head -50

Pfade und Logdateien hängen von deinem Setup ab; Seiten mit eigenen Logs je Vhost musst du einzeln durchgehen. Updates von Core und Plugins seit dem 17. Oktober tauchen in der Dateiliste ebenfalls auf — gleich sie mit deinen eigenen Änderungen ab.

Die Spuren spielen sich unterhalb der Anwendung ab, deine Anwendungs-Logs zeigen also womöglich wenig. Wenn du nichts findest, ist das kein Beweis — das Advisory zu CVE-2026-109619 schreibt ausdrücklich, dass ein fehlender Log-Eintrag keine Sicherheit belegt, weil der Fehler auftreten kann, bevor PHP die Meldung schreibt. Und noch ein Punkt aus Amazons Liste: Die veröffentlichten IP-Adressen gehören zu geteilter Infrastruktur wie Anonymisierungsdiensten. Untersuche Verkehr von dort, aber sperr sie nicht pauschal.

Gab es einen erfolgreichen Einbruch, reicht Patchen nicht. Dann gilt das volle Programm: System neu aufsetzen, Zugangsdaten tauschen — Datenbank-Passwort, API-Schlüssel, alles, was im Speicher des PHP-Prozesses lag, denn genau den kann einer der Fehler auslesen.

Wenn du gehostet bist

Betreibst du deine Website bei einem Hoster und hast keinen Root-Zugang, ist die Liste kürzer:

1. PHP-Version nachsehen. Im Kundenmenü deines Hosters, in WordPress unter Werkzeuge → Website-Zustand → Bericht → Server, in TYPO3 in der Toolbar unter Systeminformationen.
2. Beim Hoster nachfragen, ob die gefixte Version eingespielt ist — vor allem, wenn bei dir eine ältere Version wie 8.1 oder 7.4 läuft. Frag konkret nach, statt anzunehmen, dass es schon passiert ist.
3. Selbst auf eine unterstützte Version umstellen, wenn dein Tarif die Auswahl erlaubt und du noch auf 8.1 oder älter bist. Vorher testen: Alte Themes und Plugins vertragen nicht jede Version.
4. Keine falsche Sicherheit durch Anwendungs-Updates. WordPress-, TYPO3- oder Plugin-Updates schließen PHP2Shell nicht. TYPO3 sagt das in seiner Sicherheitsmeldung (öffnet in neuem Tab) (englisch) ausdrücklich: „TYPO3 itself is not affected and does not need to be updated." Updaten solltest du deine Anwendung trotzdem, nur aus anderen Gründen.

Checkliste zum Abhaken

Die Checkliste steht als Markdown im Block unten. Kopier sie über den Button in der Leiste, etwa in ein Ticket, ein Wiki oder ein GitHub-Issue — dort werden die Kästchen zu echten Häkchen.

# PHP2Shell-Checkliste (CVE-2026-109618, CVE-2026-109619)

Quelle: https://www.jpkc.com/db/blog/php2shell/ — Stand 23. Oktober 2026

## Sofort

- [ ] Alle Systeme mit PHP aufgelistet — Server, Container, Admin-Tools, Geräte, öffentlich erreichbare Entwicklungsumgebungen
- [ ] Paketversion je System gegen die Meldung der Distribution geprüft, nicht nur `php -v`
- [ ] Update eingespielt
- [ ] Jeder PHP-Dienst neu gestartet: alle FPM-Versionen, Apache mit mod_php, langlebige Worker
- [ ] Startzeit jedes Dienstes nach dem Update geprüft (`systemctl status`, `needrestart`)
- [ ] Container-Images mit `--pull --no-cache` neu gebaut und ausgerollt
- [ ] Systeme ohne Patch (PHP ≤ 8.1 ohne Backport, alte Geräte-Firmware) vom Netz genommen oder hinter einen Zugriffsschutz gestellt

## Bis der Patch läuft

- [ ] Notbremsen aus `php.ini` gesetzt, über Pool oder Server-Konfiguration, Worker neu gestartet
- [ ] Multipart am Proxy blockiert, wo keine Uploads nötig sind
- [ ] WAF-Regeln aktiv (bei Cloudflare in kostenpflichtigen Tarifen: Managed Ruleset im Modus „Block")

## Danach

- [ ] Bei 8.4.27 oder 8.5.12: auf SimpleXML-Abstürze (`zend_mm_heap corrupted`) geachtet, kein Downgrade gemacht, nächstes Release eingeplant
- [ ] Logs ab dem 17. Oktober durchgesehen
- [ ] Webroot auf neue oder geänderte Dateien geprüft
- [ ] `memory_limit` wieder auf einen endlichen Wert
- [ ] Upgrade-Termin für alles unter PHP 8.3 eingeplant (8.2 endet am 31. Dezember 2026)

Warum statische Seiten gelassen bleiben

Jetzt zum zweiten Teil, und damit zurück zu dieser Knowledge Base. Für ihre Dateien gab es am 21. Oktober nichts zu tun. Der Grund ist banal: Wer https://www.jpkc.com/db/blog/ aufruft, bekommt eine fertige HTML-Datei. Apache liest sie und schickt sie los. Es gibt keinen PHP-Prozess, der eine multipart/form-data-Anfrage zerlegen würde, keinen Worker, in dem Zustand von einer Anfrage zur nächsten hängen bleibt, kein Speicherlimit, das ein Angreifer gezielt reißen könnte. Die gesamte Angriffsklasse von PHP2Shell hat schlicht keinen Ansatzpunkt.

Das ist dieselbe Eigenschaft, die ich in Warum 11ty beschrieben habe: Was nicht läuft, kann nicht angegriffen werden. Sie wirkt eben nicht nur gegen Lücken in Plugins oder im CMS, sondern auch gegen Lücken eine Ebene tiefer, in der Laufzeitumgebung selbst — dort, wo kein Härtungs-Plugin hinreicht.

Ehrlich bleiben muss ich an zwei Stellen:

• Statisch heißt: Diese URL startet kein PHP. Läuft auf demselben Server noch irgendwo PHP — ein Kontaktformular, phpMyAdmin, ein Control-Panel, ein Webmailer —, ist der Server trotzdem angreifbar, und ein Einbruch dort kann auch deine statischen Dateien verändern. Die Frage ist also nicht „Ist meine Website statisch?", sondern „Wo auf diesem Server ist PHP öffentlich erreichbar?".
• Die Arbeit verschwindet nicht, sie wandert. Meine Build-Werkzeuge mit Node.js und npm haben eigene Risiken, vor allem in der Lieferkette; wie ich sie absichere, steht in Node.js und npm absichern. Der Unterschied ist, dass diese Werkzeuge nur ein paar Minuten beim Build laufen und nicht rund um die Uhr öffentlich auf Anfragen warten.

WordPress behalten, aber nicht mehr öffentlich

Du musst dein CMS nicht aufgeben, um davon zu profitieren. In Nachhaltige Websites habe ich den statischen Export vorgestellt: Plugins wie Simply Static (öffnet in neuem Tab) oder Staatic (öffnet in neuem Tab) machen aus WordPress eine fertige Kopie, die Besucher bekommen. Die Redaktion arbeitet weiter im gewohnten Backend, aber das Backend selbst ist nicht mehr öffentlich.

PHP2Shell zeigt, worauf es dabei ankommt: wo der Zugriffsschutz sitzt. Die WordPress-Anmeldung schützt hier nicht, denn sie ist selbst ein PHP-Skript, und der Angriff passiert vor ihr. Was schützt, ist eine Sperre, die der Webserver prüft, bevor er die Anfrage an PHP weitergibt:

• Basic Auth auf Webserver-Ebene (Apache AuthType Basic, nginx auth_basic). Apache und nginx prüfen sie in einer Phase vor der Übergabe an PHP; eine Anfrage ohne gültige Zugangsdaten bekommt ein 401 und erreicht PHP nie. Simply Static beschreibt (öffnet in neuem Tab) (englisch) genau das als Absicherung.
• IP-Freigabe für die Redaktion (Require ip bei Apache, allow/deny bei nginx). Hinter einem Proxy oder CDN sieht der Webserver allerdings dessen Adresse, solange du die echte Client-IP nicht wiederherstellst (bei Apache mit mod_remoteip).
• VPN oder internes Netz: Das WordPress dahinter ist aus dem Internet gar nicht erreichbar.
• Lokal oder auf Abruf: Das CMS läuft nur beim Bearbeiten, etwa in DDEV, und schiebt danach die statische Kopie hoch.

Ob die Sperre wirklich vor PHP greift, entscheiden Details. Ist die 401-Fehlerseite selbst ein PHP-Skript (ErrorDocument 401 bzw. error_page 401), läuft PHP auch für Anfragen ohne Zugangsdaten. Satisfy Any kann die Sperre aushebeln, und ein <Limit GET> schützt nur Lesezugriffe — angegriffen wird per POST. Eine .htaccess ignoriert Apache unter AllowOverride None stillschweigend. Und bei nginx greift ein auth_basic in location /wp-admin/ nicht für .php-Dateien, wenn eine Regex-Location wie location ~ \.php$ gewinnt. Am sichersten schützt du den ganzen Host, nicht einzelne Pfade, und prüfst es von außen: Ein curl -X POST ohne Zugangsdaten muss ein 401 bekommen.

Das macht das Patchen nicht überflüssig — Zugangsdaten können abhandenkommen, und auch Redaktionsrechner sind Angriffsziele. Aber es nimmt den Zeitdruck heraus. Zwischen den ersten kursierenden CVE-Nummern und dem Patch lagen bei PHP2Shell 23 Stunden. Ein öffentlich erreichbares WordPress war in dieser Zeit exponiert; eines hinter Basic Auth oder im VPN nicht in derselben Weise.

Die statische Kopie als Notfallplan

Ein Gedanke, der mich in dieser Woche nicht loslässt: Viele Seiten, die das BSI-Szenario „vom Netz nehmen" umgesetzt haben, waren danach ganz weg. Für eine Klinik, eine Behörde oder eine Polizei-Website heißt das: Öffnungszeiten, Notfallnummern, Kontaktwege — nicht erreichbar, bis gepatcht ist.

Dabei sind die meisten dieser Inhalte reine Information, die sich nicht bei jedem Aufruf ändert. Eine statische Kopie, regelmäßig erzeugt und als Notfall-Ausgabe vorgehalten, hätte genau diese Inhalte weiter ausliefern können, während PHP abgeschaltet ist. Formulare, Suche und Logins wären für ein paar Stunden weggefallen, die Informationen nicht. Das ist kein Ersatz für Patch-Fähigkeit, aber ein Unterschied zwischen „eingeschränkt" und „offline". Wer ein großes CMS betreibt, sollte sich fragen, ob es einen solchen Plan B gibt — und wer ihn im Ernstfall umschaltet.

Abwägungen für die Zukunft

PHP2Shell wird nicht die letzte Lücke dieser Art sein. Ein paar Dinge, die ich daraus mitnehme und die du für deine Projekte prüfen solltest:

Patchzeit in Stunden, nicht in Tagen. Amazon empfiehlt, Patch- und Mitigationszeiten für kritische Lücken in öffentlich erreichbaren Systemen „in hours" zu messen; eine Frist von 7 oder 30 Tagen setze einen Aufschub voraus, den es nicht mehr gebe. Das heißt praktisch: Wer kann bei dir an einem Mittwochnachmittag innerhalb von zwei Stunden PHP auf allen Systemen aktualisieren? Gibt es eine Liste aller Systeme? Ist die Vertretung geklärt?

KI beschleunigt beide Seiten. Die Lücken haben KI-gestützte Teams gefunden, und auch die WordPress-Lückenkette „wp2shell" im Juli 2026 wurde laut Wiz (öffnet in neuem Tab) (englisch) mit einem KI-Modell entdeckt. Die PHP Foundation hat seit dem 1. Juli 15 CVEs veröffentlicht und mehr als 100 Meldungen als ungültig, doppelt oder nicht reproduzierbar aussortiert. Das BSI schreibt in seiner Warnung, dass Angreifer mit KI-gestützten Werkzeugen Patches „innerhalb kurzer Zeit" analysieren und Exploits erzeugen können. Rechne also mit mehr Sicherheits-Releases und mit kürzeren Abständen zwischen Patch und Angriff.

Unterstützte Versionen sind keine Kür. Auf PHP 8.1 oder älter warst du diese Woche auf Backports von Dritten angewiesen. PHP 8.2 (öffnet in neuem Tab) (englisch) bekommt nur noch bis zum 31. Dezember 2026 Sicherheitsupdates. Wenn du jetzt noch auf 8.2 bist, plane das Upgrade für November, nicht für Januar.

Woher dein PHP kommt, entscheidet über die Geschwindigkeit. Distributionen bekamen die Patches vorab, und die meisten lieferten noch am Release-Tag. Fremd-Repositories, die neuere PHP-Versionen anbieten, als die Distribution hat, sind praktisch — aber Remi lieferte erst einen Tag nach dem Release, und im Debian-Repository von sury.org fehlten für ARM64 auch zwei Tage danach noch die meisten gefixten Versionen. Das PHP-Team empfiehlt Nutzern von Remi ausdrücklich, auf Distributionspakete umzusteigen oder selbst zu bauen. Das ist eine echte Abwägung zwischen neuester Version und schnellster Sicherheitskorrektur.

Hosting selbst machen oder abgeben. Wer PHP nicht selbst betreibt, muss bei so einer Lücke auch nicht selbst um 16 Uhr patchen. Wer hinter einer WAF wie der von Cloudflare lag, hatte schon Stunden vor dem Release Schutzregeln, und Distributionen und LTS-Anbieter bekamen den Patch vorab. Selbst betreiben lohnt sich, wenn du die Bereitschaft dafür organisieren kannst — nicht, wenn es niemand übernimmt.

Angriffsfläche bewusst klein halten. Gehört phpMyAdmin wirklich ins öffentliche Netz? Das Control-Panel? Die Testinstallation von 2019? PHP2Shell braucht nur irgendein erreichbares PHP-Skript. Jedes, das nicht öffentlich sein muss, gehört hinter Basic Auth, eine IP-Freigabe oder ein VPN.

Ausliefern und Bearbeiten trennen. Wo es inhaltlich passt — Unternehmensseiten, Blogs, Dokumentation, Vereins- und Behördenseiten mit überwiegend Information —, ist die statische Auslieferung die robusteste Antwort: entweder direkt mit einem Generator wie 11ty oder als Export aus dem bestehenden CMS. Wo es nicht passt, etwa bei Shops, Kundenportalen oder Communitys, bleibt die Verteidigung in der Tiefe: schnell patchen, Worker begrenzen (pm.max_requests), Speicherlimits über cgroups, AppArmor oder SELinux, eine WAF davor. Und oft auch dort eine Trennung: Die Seiten, die alle sehen, statisch; nur der personalisierte Teil dynamisch.

FAQ

Ist meine statische Website von PHP2Shell betroffen?

Die statischen Seiten selbst nicht, denn bei ihrer Auslieferung läuft kein PHP. Betroffen ist der Server aber, sobald dort irgendwo anders PHP öffentlich erreichbar ist — ein Formular-Skript, phpMyAdmin, ein Control-Panel. Prüf also den ganzen Server, nicht nur die Website.

Muss ich WordPress, TYPO3 oder meine Plugins aktualisieren?

Wegen PHP2Shell nicht. Die Lücke steckt in PHP, und nur ein PHP-Update schließt sie. TYPO3 und Cloudflare sagen das ausdrücklich. Deine Anwendung solltest du trotzdem aktuell halten, aber das ist ein anderes Thema.

Reicht eine Web Application Firewall?

Nein. Sie blockiert bekannte Angriffsmuster und verschafft dir Zeit, aber nur für Verkehr, der über sie läuft, und Angreifer verändern ihre Anfragen gezielt, um Regeln zu umgehen — Cloudflare beschreibt das selbst. Eine WAF ergänzt das Update, sie ersetzt es nicht.

Ist meine lokale Entwicklungsumgebung gefährdet?

Solange sie nur auf deinem Rechner lauscht, nicht. Sobald du sie öffentlich teilst, etwa mit ddev share oder einem Tunnel, gilt sie als exponierter Server und braucht das Update vorher.

Gibt es noch Fixes für PHP 7.4 oder 8.1?

Vom PHP-Projekt gibt es nur Quelltext-Patches für 7.4, 8.0 und 8.1. Fertige Pakete liefern Distributionen und LTS-Anbieter, etwa Ubuntu für 22.04 und über Ubuntu Pro für ältere Releases. Wenn du keine dieser Quellen hast, nimm das System vom Netz und plane das Upgrade.

Hilft session.upload_progress.enabled = 0 allein?

Nein. Es verbaut die bestätigten Wege über die Upload-Fortschrittsanzeige, nicht andere Varianten, und gegen CVE-2026-109618 wirkt es nicht. Auch ISPConfig schreibt, dass die Einstellung allein nicht ausreicht. Sie ist eine Notbremse von mehreren, nicht die Lösung.

Seit dem Update stürzen meine PHP-Worker ab. Soll ich zurück auf die alte Version?

Nein. Unter 8.4.27 und 8.5.12 kann ein Fehler im Zusammenspiel von SimpleXML und Garbage Collector zu zend_mm_heap corrupted führen. Mit der alten Version wäre aber PHP2Shell wieder offen. Bis ein korrigiertes Release erscheint, hilft als Übergang zend.enable_gc = 0; Details stehen im Nachtrag.

Fazit

PHP2Shell ist eine der Lücken, die eine ganze Woche prägen: zwei Fehler tief in der Laufzeitumgebung, ein Angriff ohne Login und ohne Formular, eine Offenlegung, die aus dem Takt geriet, und Webseiten von Kliniken und Behörden, die vorsorglich vom Netz gingen. Die dringende Aufgabe ist klar und lässt sich abhaken: alle PHP-Systeme finden, Paketversion richtig prüfen, aktualisieren, jeden Dienst neu starten, Container neu bauen, Logs ab dem 17. Oktober ansehen.

Die längerfristige Lehre ist eine Architekturfrage. Jede öffentlich erreichbare PHP-Installation ist eine Stelle, an der du bei der nächsten Lücke dieser Art innerhalb von Stunden handeln musst. Je weniger davon es gibt — weil Seiten statisch ausgeliefert werden, weil das CMS hinter einer Sperre arbeitet, weil Admin-Werkzeuge nicht im offenen Netz stehen —, desto ruhiger wird die nächste Woche dieser Art. Für die Dateien dieser Knowledge Base gab es nichts zu patchen. Das war kein Glück, sondern die Bauform.

Weiterlesen

Warum ich 2020 von WordPress zu einem statischen Generator gewechselt bin und was das an Wartung spart, steht in Warum 11ty. Den statischen Export für WordPress und schlanke Webserver für fertige Dateien beschreibt Nachhaltige Websites. Wie ich die Build-Seite gegen Lieferketten-Angriffe absichere, zeigt Node.js und npm absichern. Und was WordPress unabhängig von PHP an Härtung verträgt, steht im Guide zu JPKCom Harden & Trim.

Primärquellen: PHP-Advisory (öffnet in neuem Tab) · GHSA-w8hw-w9fx-j79w (öffnet in neuem Tab) · GHSA-6wmf-4rv5-p3rp (öffnet in neuem Tab) · BSI-Sicherheitshinweis (öffnet in neuem Tab) · PHP Foundation (öffnet in neuem Tab) · CISA-Warnung (öffnet in neuem Tab) · NCSC-NL: betroffene Produkte (öffnet in neuem Tab) (alle englisch außer BSI)