SICHERHEIT · PHP · UPDATE 22.10.2026

PHP2Shell: Kritische PHP-Sicherheitslücken gefährden Websites und Server

Zwei kritische Sicherheitslücken im PHP-Kern sorgen für Alarm: PHP2Shell, geführt als CVE-2026-109618 und CVE-2026-109619. Unter bestimmten Voraussetzungen können Angreifer aus der Ferne und ohne Anmeldung Code auf einem verwundbaren System ausführen. Betroffen sind PHP-Versionen ab 5.4, also auch viele ältere Installationen.

PHP2SHELL · 2 CVES

● Updates seit 21.10.2026

9,2

CVSS 4.0, kritisch

Ohne Login

Remote-Codeausführung

ab 5.4

Betroffene Versionen

PHP 8.5 ✓ 8.5.12

PHP 8.4 ✓ 8.4.27

PHP 8.3 ✓ 8.3.36

PHP 8.2 ✓ 8.2.35

PHP 8.1 und älter ● kein Upstream-Fix

Entscheidend: korrigierte Version installieren, PHP-Prozesse neu starten und prüfen, was tatsächlich läuft.

✓ Korrigierte PHP-Versionen seit 21. Oktober 2026

✓ Betroffen: mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed

✓ Kein vollständiger Schutz ohne Update

✓ Mit Praxisbefehlen und Übergangsmaßnahmen

UPDATE 22.10.2026

Neue Erkenntnisse zur Angriffslage

Seit unserer ursprünglichen Veröffentlichung liegen weitere technische Informationen zu PHP2Shell vor. Die Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 sind inzwischen genauer dokumentiert. Außerdem haben Sicherheitsforscher und Sicherheitsorganisationen ihre Einschätzungen zur möglichen Ausnutzung veröffentlicht.

Die wichtigste Nachricht bleibt: Die PHP-Projektseite stellt korrigierte Versionen bereit, und betroffene Systeme sollten aktualisiert werden. Darüber hinaus sollten Betreiber prüfen, ob ihre Systeme bereits vor der Aktualisierung verdächtige Aktivitäten gezeigt haben.

Was ist inzwischen über mögliche Angriffe bekannt?

Sicherheitsforscher haben die Schwachstellen technisch untersucht, und es sind Berichte zu Exploit-Ansätzen im Umlauf. Das PHP-Projekt erklärte laut Tenable allerdings, in den ihm bekannten Proof-of-Concepts zum Zeitpunkt der Veröffentlichung keine funktionsfähigen Exploits gefunden zu haben. Angeblicher Exploit-Code im Netz sollte nicht unbesehen ausgeführt werden, er kann selbst Schadsoftware enthalten.

Zu tatsächlichen Angriffen unterscheiden sich die Berichte: Amazon Threat Intelligence meldet erste Angriffsversuche gegen sein Honeypot-Netz bereits am 17. Oktober 2026, also rund vier Tage vor der Veröffentlichung, und weitere Versuche am 21. Oktober von offenbar mehreren Akteuren. watchTowr berichtet von aktiven Ausnutzungsversuchen, Cloudflare von Angriffsverkehr gegen Kundensysteme. Ob die Versuche bei echten Systemen erfolgreich gewesen wären, ist nach Angaben von Amazon offen. Ein bestätigter erfolgreicher Angriff auf ein konkretes produktives System ist uns nicht bekannt.

Ein öffentlich verfügbarer Exploit, ein erfolgreicher Test im Labor und ein bestätigter Angriff auf ein produktives System sind drei unterschiedliche Dinge. Für Betreiber bedeutet das: Die Gefahr sollte nicht unterschätzt werden. Aus den bisherigen Meldungen lässt sich aber auch nicht ableiten, dass jeder verwundbare Server tatsächlich angegriffen wurde.

🔧

Warum die verwendete PHP-Umgebung wichtig ist

Die Sicherheitslücken betreffen die PHP-Laufzeit selbst und nicht nur ein bestimmtes Content-Management-System oder Plugin. Deshalb reicht es nicht, ausschließlich WordPress, TYPO3 oder eine andere Anwendung zu aktualisieren.

Laut dem PHP-Projekt sind unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed relevant. Das PHP-Team stuft insbesondere Apache-Konfigurationen mit mod_php als risikoreich ein: Ein präparierter Request kann dort die Schwachstelle auslösen, bevor der eigentliche Anwendungscode ausgeführt wird.

Auch PHP-Runtimes, die in Containern, Verwaltungsoberflächen oder Drittanbieterprodukten gebündelt sind, müssen separat berücksichtigt werden. Ein aktualisiertes PHP-Paket auf dem Host bedeutet nicht automatisch, dass jede mitgelieferte Runtime ebenfalls korrigiert ist.

📦

Neuer Stand bei den Distributionen

Seit der ersten Veröffentlichung sind weitere Korrekturen erschienen. Laut den Herstellerseiten (Stand 22.10.2026):

Debian 12 Bookworm: 8.2.35-1~deb12u1 (DLA-4848-1)
Debian 13 Trixie: 8.4.27-1~deb13u1 (DSA-6574-1)
Ubuntu 22.04 LTS und 24.04 LTS: korrigierte Pakete (USN-8948-1 und USN-8948-2)
Debian Unstable/Testing: zum Prüfzeitpunkt noch nicht korrigiert

Details stehen im Abschnitt „Korrigierte Versionen“ weiter unten.

Gepatcht bedeutet nicht automatisch, dass es vorher keinen Angriff gab

Wir haben unsere Systeme am 21. Oktober 2026 um 18:00 Uhr auf den korrigierten Stand gebracht. Damit haben wir die notwendigen Aktualisierungen zeitnah nach Veröffentlichung der Sicherheitskorrekturen umgesetzt.

Ein Patch schließt die bekannte Schwachstelle in der aktualisierten Runtime. Er kann jedoch nicht rückwirkend ausschließen, dass ein System vor dem Update bereits angegriffen wurde oder dass ein Angreifer zuvor Dateien, Konten oder andere Zugänge verändert hat. Amazon empfiehlt deshalb, Untersuchungen nicht erst ab dem Tag der Veröffentlichung zu beginnen, sondern ab dem 17. Oktober 2026, dem frühesten bekannten Angriffsversuch.

Bei einem konkreten Verdacht sind zusätzlich die verfügbaren Webserver- und PHP-Logs, Prozessaktivitäten und Dateiänderungen zu untersuchen. Auffälligkeiten müssen zeitlich eingeordnet und mit regulären Deployments sowie Wartungsarbeiten abgeglichen werden. Umgekehrt gilt auch: Wenn keine verdächtigen Einträge gefunden werden, ist das allein noch kein Beweis dafür, dass es keinen Angriff gab.

Zum Zeitpunkt dieser Aktualisierung liegen uns keine Erkenntnisse vor, die wir als Beleg für eine erfolgreiche Ausnutzung auf unseren Systemen veröffentlichen könnten. Das ist ausdrücklich keine allgemeine Garantie, dass eine frühere Ausnutzung allein durch das Einspielen eines Updates ausgeschlossen wäre.

Was Administratoren jetzt zusätzlich prüfen sollten

Neben dem Update der PHP-Runtime empfehlen wir, die eigene Umgebung systematisch zu kontrollieren:

Alle PHP-Runtimes erfassen: Dazu gehören auch alternative PHP-Versionen, PHP-FPM-Pools, Container und in Drittanbieterprodukten gebündelte Laufzeiten.
Laufende Version kontrollieren: Prüfen, ob die korrigierte Version tatsächlich von den Webanwendungen verwendet wird und ob betroffene Prozesse nach dem Update neu gestartet wurden.
Webserver- und PHP-Logs prüfen: Auffällige Requests, ungewöhnliche Fehlerhäufungen und zeitlich zusammenhängende Ereignisse können Ansatzpunkte für eine Untersuchung liefern. Einzelne HTTP-Fehler sind für sich genommen kein Beweis für einen Angriff.
Prozesse und Dateien kontrollieren: Ungewöhnliche Kindprozesse von PHP oder dem Webserver, unerwartete Skripte im Webverzeichnis, neue geplante Aufgaben oder unbekannte Dienste sollten untersucht werden.
Bei konkretem Verdacht Beweise sichern: Logs und relevante Systeminformationen sollten gesichert werden, bevor Bereinigungsmaßnahmen Spuren verändern. Bei belastbaren Hinweisen sollte das betroffene System nach einem geeigneten Incident-Response-Verfahren isoliert und untersucht werden.

Ausführliche Anleitung: Wie du Logs, Prozesse, Dateien und Netzwerkverbindungen prüfst, welche Befehle helfen und wo die Grenzen liegen, zeigen wir in unserem Folgebeitrag PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab.

Es gibt keine einzelne Logzeile und keinen einfachen Test, der zuverlässig beweist, dass PHP2Shell ausgenutzt wurde oder nicht. Die Bewertung muss mehrere Datenquellen und den konkreten Aufbau des Systems berücksichtigen.

Fazit des Updates

PHP2Shell bleibt eine kritische Sicherheitsmeldung, die eine schnelle Aktualisierung und eine sorgfältige Prüfung der betroffenen Umgebungen erfordert. Die korrigierten PHP-Versionen sind verfügbar; zusätzlich sollten Betreiber mögliche frühere Angriffe nicht allein deshalb ausschließen, weil das Update inzwischen installiert ist.

Wir unterscheiden dabei bewusst zwischen der Behebung der bekannten Schwachstelle und der separaten Frage, ob es vor dem Update Hinweise auf eine Ausnutzung gab.

EINORDNUNG

Was ist passiert?

Besonders brisant: Die Schwachstellen liegen im PHP-Laufzeitsystem selbst, nicht in einem einzelnen Plugin oder einer einzelnen Website. Damit können Webserver, Content-Management-Systeme und Anwendungen betroffen sein, bei denen PHP im Hintergrund läuft.

📅

20. Oktober 2026: Vorankündigung

Das PHP-Projekt kündigt ein außerplanmäßiges Sicherheitsupdate für zwei kritische Schwachstellen an. Zuvor waren Hinweise auf die Lücken vorzeitig öffentlich aufgetaucht, die Veröffentlichung wurde deshalb vorgezogen.

✅

21. Oktober 2026: Details und Updates

Das PHP-Projekt veröffentlicht die Details und die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Schweregrad und Ausnutzung

Das PHP-Projekt bewertet beide Schwachstellen mit CVSS 4.0 9,2 (kritisch). Auch CERT-EU und das BSI nennen 9,2. Die Bewertung weist darauf hin, dass für einen Angriff weder eine Anmeldung noch eine Interaktion eines Nutzers nötig ist.

Zur Ausnutzung hat sich die Lage seit der Veröffentlichung weiterentwickelt. Die aktuellen Erkenntnisse fassen wir im Update vom 22. Oktober 2026 weiter oben zusammen.

Der Name PHP2Shell ist ein griffiger Begriff aus der Sicherheitsbranche, den das PHP-Projekt selbst nicht verwendet. Technisch maßgeblich sind die beiden CVE-Nummern.

DIE SCHWACHSTELLEN

Zwei Fehler im PHP-Kern

💥

CVE-2026-109618: Speichermangel

Wenn PHP während der Vorbereitung eines Requests nicht genug Speicher hat, kann der Request abgebrochen werden, obwohl interne Daten noch nicht vollständig initialisiert sind. Die anschließende Bereinigung behandelt diese Daten dann, als wären sie gültig. Das kann zu einer Speicherbeschädigung und im Ergebnis zu Codeausführung führen.

Das PHP-Projekt hat die Ausnutzung ohne Anmeldung über HTTP gegen mod_php mit Standardeinstellungen bestätigt.

🔄

CVE-2026-109619: veralteter Zustand

Interner Zustand eines Requests kann erhalten bleiben, obwohl der zugehörige Speicher bereits freigegeben wurde. Eine spätere Anfrage desselben Workers kann diesen veralteten Zustand verwenden, bevor er zurückgesetzt wird.

Mögliche Folgen sind Codeausführung mit den Rechten des Webserver-Prozesses und das Auslesen von Speicherinhalten, etwa Zugangsdaten oder Tokens aus anderen Requests.

Die genauen Voraussetzungen unterscheiden sich, deshalb muss nicht jede Installation auf identische Weise betroffen sein. Besonders hoch ist das Risiko laut PHP-Projekt bei Apache mit mod_php. Aber auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed müssen überprüft werden.

BETROFFENE VERSIONEN

Sind wirklich 20 Jahre PHP betroffen?

Der mögliche Versionsbereich reicht sehr weit zurück. Wiz und Sansec nennen PHP-Versionen ab 5.4 bis einschließlich 8.5.11 als betroffen. CERT-EU sprach in seiner Meldung allgemein von PHP ab Version 5. Das umfasst einen Zeitraum von etwa zwei Jahrzehnten.

Das heißt nicht, dass jede jemals veröffentlichte PHP-Version heute noch läuft oder auf gleiche Weise aktualisiert werden kann. Wichtig ist die Unterscheidung zwischen betroffen, noch unterstützt und bereits korrigiert:

Für die unterstützten Zweige PHP 8.2 bis 8.5 hat das PHP-Projekt Updates veröffentlicht. PHP 8.2 wird nur noch bis zum 31. Dezember 2026 mit Sicherheitsupdates versorgt.
Für PHP 8.1 und älter gibt es vom PHP-Projekt keine regulären Updates. Für 7.4, 8.0 und 8.1 hat das Sicherheitsteam allerdings minimale Quellcode-Backports bereitgestellt, gedacht für Nutzer, die PHP selbst bauen und keinen LTS-Anbieter haben.
Einige Linux-Distributionen und LTS-Anbieter liefern eigene Korrekturen. Ob eine konkrete Installation abgesichert ist, muss anhand des Paketstands und des Anbieters geprüft werden.

Gerade bei älteren Websites, gewachsenen Kundenprojekten und Anwendungen, die seit Jahren unverändert laufen, lohnt sich deshalb ein genauer Blick auf die eingesetzte PHP-Version.

KORRIGIERTE VERSIONEN

Welche PHP-Versionen schließen die Lücken?

Das PHP-Projekt hat am 21. Oktober 2026 diese Versionen veröffentlicht. Sie beheben CVE-2026-109618 und CVE-2026-109619:

PHP-Zweig	Korrigierte Version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Wer PHP selbst kompiliert oder über eigene Runtime-Images bereitstellt, muss sicherstellen, dass die korrigierte Version tatsächlich in das laufende System übernommen wird. Das gilt auch für Container, deren Image neu gebaut und ausgerollt werden muss.

🌀

Debian: Korrigierte Pakete verfügbar

Bei Debian kann die Korrektur in einem eigenen Paket stecken, dessen Versionsnummer von der Upstream-Version abweicht. Laut Debian Security Tracker (Stand 22.10.2026) gilt:

Debian 13 Trixie: PHP 8.4 ist mit 8.4.27-1~deb13u1 korrigiert (DSA-6574-1)
Debian 12 Bookworm: PHP 8.2 ist mit 8.2.35-1~deb12u1 korrigiert (DLA-4848-1)
Debian Unstable/Testing: PHP 8.4 war zum Prüfzeitpunkt noch nicht korrigiert

Der Stand kann sich ändern. Maßgeblich ist der Debian Security Tracker.

💡

Ubuntu: Korrekturen für unterstützte Releases

Ubuntu stuft CVE-2026-109618 mit der Priorität „Critical“ ein und hat am 21. Oktober 2026 die Sicherheitshinweise USN-8948-1 und USN-8948-2 veröffentlicht. Laut Ubuntu Security (Stand 22.10.2026) gibt es Korrekturen unter anderem für:

Ubuntu 22.04 LTS: PHP 8.1 mit 8.1.2-1ubuntu2.28
Ubuntu 24.04 LTS: PHP 8.3 mit 8.3.6-0ubuntu0.24.04.13
Ältere Releases (20.04 und früher): nur über Ubuntu Pro (ESM) bzw. Legacy Support

Maßgeblich ist die Seite Ubuntu Security.

📦

Drittanbieter-Repositories

Das ehrenamtlich gepflegte Repository rpms.remirepo.net wird zum Release keine Updates haben. Das PHP-Projekt empfiehlt in solchen Fällen Distributionspakete oder einen Build aus dem Quellcode.

Wer PHP über ein Drittanbieter-Repository, ein Hosting-Panel oder ein fertiges Image bezieht, sollte beim jeweiligen Anbieter den Stand erfragen.

BETROFFENE ANWENDUNGEN

Welche Websites und Anwendungen können betroffen sein?

PHP steckt in zahlreichen Content-Management-Systemen, Webanwendungen und Diensten. Auch wenn die Anwendung selbst aktuell ist, kann eine verwundbare PHP-Laufzeit ein Risiko darstellen. Dazu können beispielsweise gehören:

WordPress-Websites und deren Backend
Drupal-, Joomla- und TYPO3-Installationen
Nextcloud- und ownCloud-Umgebungen
MediaWiki und DokuWiki
Shopsysteme und individuell entwickelte PHP-Anwendungen
PHP-basierte Dienste in Docker-Containern
Weitere Webanwendungen, die PHP-FPM, mod_php oder eine andere betroffene Laufzeit verwenden

Die Liste ist nicht vollständig. Entscheidend ist, welche PHP-Version eine Anwendung tatsächlich verwendet und wie sie bereitgestellt wird. Ein Update des CMS allein reicht nicht, solange der PHP-Prozess eine verwundbare Version ausführt. Bei Containern muss zusätzlich das Image aktualisiert und die Anwendung damit neu bereitgestellt werden.

MASSNAHMEN

Was Betreiber jetzt tun sollten

Die Sicherheitsmeldungen empfehlen, betroffene Installationen unverzüglich zu aktualisieren. Ist das nicht sofort möglich, sollten öffentlich erreichbare Anwendungen bis zur Korrektur möglichst vom Netz genommen oder in ihrer Erreichbarkeit eingeschränkt werden.

Alle PHP-Installationen erfassen

Nicht nur der Hauptwebserver zählt. Auch zusätzliche PHP-FPM-Pools, alternative PHP-Versionen, Container, Verwaltungsoberflächen, Hosting-Panels und ältere Kundenanwendungen müssen berücksichtigt werden.

Tatsächlich verwendete Version prüfen

Die PHP-Version auf der Kommandozeile muss nicht der Version entsprechen, die eine Website über PHP-FPM oder Apache nutzt. Maßgeblich ist die Runtime, die den Webanfragen zugeordnet ist.

Sicherheitsupdate einspielen

Für unterstützte Upstream-Zweige stehen die oben genannten Releases bereit. Bei distributionsverwalteten Installationen die Updates des jeweiligen Anbieters verwenden.

Prozesse und Container neu starten

Ein installiertes Paket bedeutet nicht, dass alle laufenden Prozesse die korrigierte Version nutzen. Je nach Bereitstellung müssen PHP-FPM, Apache oder Container neu gestartet bzw. neu ausgerollt werden.

Ergebnis kontrollieren

Nach der Aktualisierung prüfen, welche Version tatsächlich läuft. Bei mehreren Hosts oder getrennten Umgebungen darf die Prüfung nicht auf einem einzelnen System enden.

Veraltete Versionen gesondert behandeln

Bei PHP 8.1 oder älter klären, ob ein bestätigter Backport des Anbieters verfügbar ist. Ist das nicht der Fall, eine Migration auf einen unterstützten Zweig einplanen.

PRAXIS

Praxisbefehle: Welche PHP-Version läuft wirklich?

Die Befehle sind Beispiele für Debian/Ubuntu-Systeme mit Paketinstallation. Bitte an die eigene Umgebung anpassen (PHP-Version, Dienstnamen) und Neustarts nur nach Wartungsplanung durchführen.

🔍

Installierte Versionen finden

Zeigt die CLI-Version und alle installierten PHP-Pakete. Die CLI-Version sagt noch nichts über die Webumgebung:

Bash

php -v
dpkg -l | grep -E '^ii\s+php'
ls /usr/sbin/php-fpm* 2>/dev/null

🖥

Laufende Webprozesse prüfen

Zeigt, welche PHP-Prozesse tatsächlich laufen, und ob sie noch das alte Binary nutzen. Steht hinter dem Pfad „(deleted)“, läuft der Prozess noch mit der Version vor dem Update:

Bash

ps aux | grep -E 'php-fpm|apache2|httpd' | grep -v grep
ls -l /proc/$(pgrep -o php-fpm)/exe
apache2ctl -M 2>/dev/null | grep -i php

🔄

Update einspielen und Dienste neu starten

Beispiel für PHP 8.4 mit PHP-FPM. Dienstnamen je nach Version und Setup anpassen:

Bash

apt update
apt list --upgradable 2>/dev/null | grep -i php
apt full-upgrade

# Dienste neu starten (nur nach Wartungsplanung):
systemctl restart php8.4-fpm
systemctl restart apache2   # bzw. nginx

# Prozesse mit veralteten Bibliotheken anzeigen:
needrestart

📦

Container prüfen

Zeigt, welche Container laufen und welche PHP-Version darin verwendet wird. Ein reines Update im Host reicht nicht, das Image muss neu gebaut und der Container neu gestartet werden:

Bash

docker ps --format '{{.Names}}  {{.Image}}'
docker exec <CONTAINER> php -v

ÜBERGANGSMASSNAHMEN

Wenn ein Update nicht sofort möglich ist

Das PHP-Projekt stellt klar: Es gibt keinen vollständigen Schutz außer dem Update. Die folgenden Punkte verringern höchstens die Angriffsfläche und ersetzen die Aktualisierung nicht. Datadog weist zudem darauf hin, dass die Einstellung session.upload_progress.enabled=0 gegen CVE-2026-109618 nicht schützt. Maßnahmen sollten vor dem Einsatz geprüft werden, weil sie Nebenwirkungen haben können.

Für CVE-2026-109619

session.upload_progress.enabled=0 in php.ini, im FPM-Pool oder in der Serverkonfiguration setzen und alle Worker neu starten. ini_set() und .user.ini genügen dafür nicht.
Bei PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen und die Worker neu starten. Das blockiert nur einen bestätigten Pfad.

Für CVE-2026-109618

Anfragegrößen begrenzen, etwa post_max_size und upload_max_filesize, sowie auf dem Webserver oder Proxy die Zahl der Felder, Multipart-Teile und Header.
Das PHP-Projekt nennt außerdem memory_limit=-1 (vorzugsweise per php_admin_value) in Kombination mit einer Container- oder cgroup-Begrenzung, die nur den betroffenen Worker beendet. RLIMIT_AS und RLIMIT_DATA sollten nicht verwendet werden, weil sie den verwundbaren Fehlerfall auslösen können.

Zusätzlich

Nicht patchbare Anwendungen vom Internet trennen oder hinter VPN bzw. eine Web Application Firewall stellen. Einige Anbieter wie Cloudflare haben erste WAF-Regeln für bekannte Angriffswege bereitgestellt.

ERKENNUNG

Woran man einen Angriff erkennen könnte

Die Lücken liegen unterhalb der Anwendungsebene, Anwendungslogs zeigen deshalb oft wenig. Hinweise können laut Wiz und Huntress sein:

Ungewöhnliche Multipart-Anfragen, auf die Fehlermeldungen zum Speicherlimit folgen
Wiederholte HTTP-500-Antworten und ungewöhnlicher Neustart-Wechsel bei PHP-Workern
Ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies
Formular-Uploads (POST-Requests), die die Zeichenfolge PHP_SESSION_UPLOAD_PROGRESS enthalten (Hinweis von Amazon Threat Intelligence)
PHP-Worker oder Webserver-Prozesse, die Shells, Interpreter oder Download-Werkzeuge starten
Neue Dateien im Webroot, unerwartete Cron-Jobs oder neue Benutzerkonten

Bei einem Verdacht: System isolieren, Web- und PHP-Logs sichern und auf Webshells prüfen. Die Auswertung sollte nicht allein auf einem erfolgreichen Update beruhen, weil eine Kompromittierung schon vorher erfolgt sein kann.

BEI RDDZ

Was wir bei RDDZ unternommen haben

Wir haben unsere Systeme am 21. Oktober 2026 um 18:00 Uhr auf den korrigierten Stand gebracht.

Dabei betrachten wir nicht nur die offensichtlichen Webanwendungen, sondern auch die darunterliegenden Laufzeitumgebungen. PHP kann direkt auf einem Host, in einer getrennten Runtime oder innerhalb eines Containers installiert sein. Eine einzelne Aktualisierung deckt deshalb nicht automatisch jede Anwendung ab.

Das Einspielen der Korrektur ersetzt nicht die Frage, ob es vor dem Update Hinweise auf eine Ausnutzung gab. Dazu mehr im Update weiter oben. Bei produktiven Systemen prüfen wir nach Updates außerdem den ordnungsgemäßen Betrieb der Anwendungen.

FAZIT

Jetzt aktualisieren, nicht auf den Wartungstermin warten

PHP2Shell ist kein gewöhnliches Update-Thema. Die beiden kritischen Schwachstellen CVE-2026-109618 und CVE-2026-109619 können unter bestimmten Voraussetzungen eine Codeausführung ohne Anmeldung ermöglichen. Der große Versionsbereich und der Einsatz von PHP in unzähligen Webanwendungen machen eine systematische Prüfung wichtig.

Die korrigierten Versionen stehen bereit. Betreiber sollten ihre PHP-Runtimes und Anwendungen unverzüglich prüfen, passende Updates installieren und sicherstellen, dass die korrigierte Version tatsächlich läuft. Bei alten oder nicht mehr unterstützten Installationen muss zusätzlich geklärt werden, ob eine belastbare Sicherheitskorrektur verfügbar ist, oder eine Migration auf einen unterstützten Zweig anstehen.

QUELLEN

Weiterführende Quellen

PHP-Server und Webseiten sicher betreiben?

PHP-Versionen, Updates und Neustarts nicht allein im Blick behalten? Sprechen Sie uns an, wir unterstützen bei Betrieb, Wartung und Absicherung.

PHP2Shell: Kritische PHP-Sicherheitslücken gefährden Websites und Server

Neue Erkenntnisse zur Angriffslage

Was ist inzwischen über mögliche Angriffe bekannt?

Warum die verwendete PHP-Umgebung wichtig ist

Neuer Stand bei den Distributionen

Gepatcht bedeutet nicht automatisch, dass es vorher keinen Angriff gab

Was Administratoren jetzt zusätzlich prüfen sollten

Fazit des Updates

Was ist passiert?

20. Oktober 2026: Vorankündigung

21. Oktober 2026: Details und Updates

Schweregrad und Ausnutzung

Zwei Fehler im PHP-Kern

CVE-2026-109618: Speichermangel

CVE-2026-109619: veralteter Zustand

Sind wirklich 20 Jahre PHP betroffen?

Welche PHP-Versionen schließen die Lücken?

Debian: Korrigierte Pakete verfügbar

Ubuntu: Korrekturen für unterstützte Releases

Drittanbieter-Repositories

Welche Websites und Anwendungen können betroffen sein?

Was Betreiber jetzt tun sollten

Alle PHP-Installationen erfassen

Tatsächlich verwendete Version prüfen

Sicherheitsupdate einspielen

Prozesse und Container neu starten

Ergebnis kontrollieren

Veraltete Versionen gesondert behandeln

Praxisbefehle: Welche PHP-Version läuft wirklich?

Installierte Versionen finden

Laufende Webprozesse prüfen

Update einspielen und Dienste neu starten

Container prüfen

Wenn ein Update nicht sofort möglich ist

Für CVE-2026-109619

Für CVE-2026-109618

Zusätzlich

Woran man einen Angriff erkennen könnte

Was wir bei RDDZ unternommen haben

Jetzt aktualisieren, nicht auf den Wartungstermin warten

Weiterführende Quellen

PHP-Server und Webseiten sicher betreiben?

Das könnte dir auch gefallen: