Aus dem Blog · IT-Sicherheit

PHP2Shell Lösung: So schließen Sie die kritischen PHP-Lücken

Zwei kritische Schwachstellen in PHP selbst, zusammen „PHP2Shell“ genannt, erlauben Angreifern, Code auf Webservern auszuführen: ohne Login und teilweise bevor überhaupt eine Zeile Ihrer Anwendung läuft. Die gute Nachricht: Es gibt eine Lösung. Hier lesen Sie, was passiert ist, wer betroffen ist und wie Sie Ihre Website Schritt für Schritt absichern.

Erstgespräch vereinbaren Zur Anleitung

Von Marvin de Vries, Geschäftsführer ADence · Veröffentlicht am · Lesezeit ca. 9 Minuten

Was ist passiert?

Was ist PHP2Shell?

PHP2Shell ist der Spitzname für zwei Sicherheitslücken im Kern der Programmiersprache PHP. Der Name beschreibt das Risiko: Ein Angreifer kann im schlimmsten Fall eine „Shell“, also eine Kommandozeile, auf Ihrem Server erhalten. Das PHP-Projekt hat am 20. Oktober 2026 ein Sicherheitsupdate angekündigt und es am 21. Oktober 2026 veröffentlicht. Stand der Tabelle: 22.10.2026.

CVE Ursache CVSS v4.0 Folge
CVE-2026-109618 Speicherfehler bei „Out of Memory“: PHP bricht eine Anfrage ab, während interne Daten erst halb angelegt sind; beim Aufräumen werden diese Daten trotzdem verwendet. 9,2 (kritisch) Code-Ausführung ohne Login
CVE-2026-109619 Veralteter globaler Zustand: Daten einer Anfrage überleben, obwohl ihr Speicher schon freigegeben ist, und werden von der nächsten Anfrage im selben Worker wiederverwendet. 9,2 (kritisch) Code-Ausführung ohne Login

Entscheidend ist: Die Lücken stecken nicht in WordPress, Joomla oder einem Plugin, sondern in PHP selbst. Ein gut gepflegtes CMS schützt Sie deshalb nicht automatisch.

Wer ist von PHP2Shell betroffen?

Betroffen ist laut PHP-Projekt jede PHP-Installation, die Webanfragen beantwortet, egal in welchem Betriebsmodus. Das umfasst PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei mod_php: Dort wurde gezeigt, dass schon eine einzige Anfrage ohne Anmeldung den Angriff auslösen kann, noch bevor Code Ihrer Anwendung ausgeführt wird.

Betroffene und sichere PHP-Versionen

PHP-Zweig Verwundbar Sichere Version Hinweis
PHP 8.5 kleiner 8.5.12 8.5.12 aktiv unterstützt
PHP 8.4 kleiner 8.4.27 8.4.27 aktiv unterstützt
PHP 8.3 kleiner 8.3.36 8.3.36 nur Sicherheitsupdates
PHP 8.2 kleiner 8.2.35 8.2.35 Supportende am 31.12.2026
PHP 8.1, 8.0, 7.4 und älter alle kein offizielles Release nur Backports von Distributionen/LTS-Anbietern oder minimale Quellcode-Patches

Typische Systeme, die Sie prüfen sollten:

  • Websites mit WordPress, TYPO3, Joomla oder Drupal
  • Onlineshops mit WooCommerce, Shopware oder Magento
  • Kundenportale, interne Tools und individuelle Anwendungen auf Basis von Laravel oder Symfony
  • Hosting-Oberflächen wie Plesk oder cPanel sowie Software, die PHP intern nutzt, ohne es offen zu zeigen

Für eingebettete Software pflegt das niederländische NCSC eine öffentliche Liste betroffener Drittprodukte auf GitHub, auf die auch CERT-EU verweist.

Warum ist die Lage so ernst?

Selten reagieren Behörden so deutlich: Die EU-Cybersicherheitsstelle CERT-EU rät, betroffene Systeme sofort zu patchen und internetfähige Anwendungen notfalls vom öffentlichen Netz zu trennen, bis das Update eingespielt und geprüft ist. Nach Angaben von CERT-EU kursieren bereits erste Proof-of-Concepts. Amazon beobachtete einen Angriffsversuch schon am 17. Oktober, vier Tage vor der Veröffentlichung. Cloudflare meldet laufende Angriffsversuche und hat Firewall-Regeln für alle Kunden aktiviert, bezeichnet diese aber ausdrücklich nur als Übergangslösung.

Viele Organisationen haben daraufhin vorsorglich abgeschaltet. In den Niederlanden gingen sogar die Website des Parlaments (Tweede Kamer), DigiD und MijnOverheid vom Netz. In Deutschland traf es unter anderem das Webportal der Stadt Mainz, die Websites der Berliner Charité, die Ruhr-Universität Bochum und den Rechnungsdienst easybill. Die Verbreitung ist enorm: Das Sicherheitsunternehmen CybelAngel zählt rund 2,24 Millionen öffentlich erreichbare PHP-Hosts, ein Großteil davon auf Versionen ohne offiziellen Fix.

Für Sie als Website-Betreiber heißt das: Die automatischen Updates von WordPress oder Ihrem CMS spielen keinen PHP-Patch ein. Klären Sie deshalb heute, wer bei Ihnen für PHP zuständig ist: Ihr Hoster, Ihre IT oder Ihre Agentur.

Anleitung

PHP2Shell Lösung: Anleitung in 7 Schritten

Die einzige vollständige Lösung ist das Update auf eine gepatchte PHP-Version. Die folgende Anleitung richtet sich an Administratoren und Entwickler. Wenn Sie Shared Hosting nutzen, springen Sie direkt zu Schritt 3b.

Schritt 1: Alle PHP-Systeme inventarisieren

Listen Sie jeden Server, jedes Hosting-Paket und jeden Container auf, auf dem PHP läuft, auch Staging-Umgebungen, alte Microsites und Kampagnenseiten. Vergessene Systeme sind bei solchen Lücken das größte Risiko. Beginnen Sie mit allem, was aus dem Internet erreichbar ist.

Schritt 2: Herkunft und Paketversion von PHP ermitteln

Entscheidend ist nicht die Versionsnummer, die php -v anzeigt, sondern woher PHP kommt und welche Paketversion installiert ist. Auf Debian und Ubuntu gibt es dabei zwei Quellen mit völlig unterschiedlichen Nummern: die Pakete der Distribution selbst und das Repository von Ondřej Surý (packages.sury.org bzw. ppa:ondrej/php), über das die meisten Server mit aktuellem PHP versorgt werden.

Terminal
# Installierte PHP-Pakete mit Paketversion (Debian/Ubuntu)
dpkg -l 'php*' | awk '/^ii/{print $2, $3}'

# Woher kommen die Pakete? (sury.org, ondrej/php oder Distribution)
apt-cache policy php8.3-fpm

# RHEL/AlmaLinux/Rocky
rpm -qa 'php*' | sort

# Docker-Container
docker exec <container> php -v

So lesen Sie das Ergebnis: Pakete von Ondřej Surý tragen bei den unterstützten Zweigen die Upstream-Version, sicher sind also 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Die Pakete der Distribution behalten dagegen ihre alte Nummer und bekommen den Fix als Backport, z. B. Ubuntu 24.04 mit 8.3.6-0ubuntu0.24.04.13 oder Debian 13 mit 8.4.27-1~deb13u1. Dort zählt die vollständige Paketversion, nicht die Zahl vorne. Dasselbe gilt für die Backports, die Ondřej Surý für ältere Zweige (8.1 bis 5.6) gebaut hat: Sie behalten ihre alte Versionsnummer, nachweisbar ist der Fix nur über das Changelog (Schritt 6).

Schritt 3a: PHP auf eigenen Servern aktualisieren

Terminal
# Debian/Ubuntu (Distribution oder Repository von Ondřej Surý)
sudo apt-get update
apt list --upgradable 2>/dev/null | grep php
sudo apt-get install --only-upgrade 'php8.3*'   # für jede installierte PHP-Version

# RHEL/AlmaLinux/Rocky (auch Remi)
sudo dnf clean metadata
sudo dnf upgrade 'php*'

# Docker: Basis-Image neu ziehen und Image neu bauen
docker compose build --pull --no-cache && docker compose up -d

Repository von Ondřej Surý: Der Debian-Entwickler hat am Veröffentlichungstag gepatchte Pakete für alle Zweige von PHP 5.6 bis 8.5 bereitgestellt, zunächst für amd64, die arm64-Pakete folgten später. Meldet apt-get update Fehler beim PPA, liefert packages.sury.org dieselben Pakete. Prüfen Sie nach dem Update, ob wirklich die neue Paketversion installiert ist (Schritt 2).

RHEL und Remi: Das Repository rpms.remirepo.net hatte am Veröffentlichungstag noch keine Updates, inzwischen stehen dort 8.2.35, 8.3.36, 8.4.27 und 8.5.12 bereit. Zeigt ein Mirror noch alte Versionen, hilft dnf clean metadata. Bei Docker enthalten die offiziellen php-Images den Fix, die Vorab-Tags 8.5.12RC1 und 8.4.27RC1 dagegen nicht. Für Windows stehen neue Binärdateien auf php.net bereit, wer selbst kompiliert, nutzt die Quellen von php.net.

Schritt 3b: Shared Hosting und Managed Hosting

Hier liegt das Update beim Hoster. Prüfen Sie im Kundenmenü, welche PHP-Version aktiv ist, und wechseln Sie, falls angeboten, auf die aktuell gepatchte Version. Fragen Sie im Zweifel schriftlich beim Support nach, ob die Patches für CVE-2026-109618 und CVE-2026-109619 eingespielt sind, und lassen Sie sich das bestätigen.

Schritt 4: Dienste neu starten

Ohne Neustart läuft weiter der alte, verwundbare PHP-Prozess im Speicher. Starten Sie deshalb alle betroffenen Dienste neu:

Terminal
sudo systemctl restart php8.3-fpm   # Version anpassen
sudo systemctl restart apache2     # bei mod_php (Debian/Ubuntu)
sudo systemctl restart httpd       # bei mod_php (RHEL/Alma)
sudo systemctl restart lsws        # LiteSpeed
# FrankenPHP: Container bzw. Dienst neu starten

# Laufen noch Prozesse mit dem alten PHP? (leere Ausgabe = alles neu)
sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps
sudo needrestart -b -r l   # Debian/Ubuntu: zeigt Dienste, die noch neu starten müssen

Wichtig bei Apache mit mod_php: Ein reload oder apachectl graceful reicht nicht, es muss ein vollständiger restart sein. Auch Queue-Worker und Daemons (z. B. Laravel-Queues) laufen mit dem alten PHP weiter, bis sie neu gestartet werden.

Schritt 5: Version über den Webserver prüfen

Prüfen Sie zusätzlich, was der Webserver wirklich ausliefert: Legen Sie kurz eine Datei version.php mit <?php echo PHP_VERSION; ins Webroot, rufen Sie sie im Browser auf und löschen Sie sie danach sofort wieder. Erwartet werden 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Zeigt sie eine ältere Nummer, stammt PHP aus einer Distribution oder einem Backport: Dann entscheidet die Paketversion aus Schritt 2, nicht diese Zahl.

Schritt 6: Backport nachweisen

Terminal
# Debian/Ubuntu: lokales Changelog des Pakets durchsuchen
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

# Ubuntu 18.04/20.04 mit Ubuntu Pro (ESM)
sudo pro fix CVE-2026-109618

# RHEL/AlmaLinux/Rocky
rpm -q --changelog php-fpm | head -5
dnf updateinfo list --security | grep php

Erscheinen beide CVE-Nummern im Changelog, ist der Fix installiert. Bei den Paketen von Ondřej Surý steht im Changelog der unterstützten Zweige oft nur „New upstream version“, dort gilt die Versionsnummer aus Schritt 2. Debian 11 bekommt den Fix nur noch über das kostenpflichtige Extended LTS.

Schritt 7: Veraltete PHP-Versionen planen

PHP 8.1 und älter erhält vom PHP-Projekt keine Updates mehr. Das PHP-Team hat wegen der Schwere zwar minimale Quellcode-Patches für 7.4, 8.0 und 8.1 bereitgestellt, das ist aber eine Notlösung. Planen Sie die Migration auf PHP 8.4 oder 8.5. Auch PHP 8.2 endet am 31. Dezember 2026. Gerade ältere Websites brauchen dafür oft Anpassungen an Theme, Plugins oder Code, und das sollte nicht unter Zeitdruck passieren.

Was tun, wenn Sie nicht sofort updaten können?

Die sicherste Übergangslösung ist die von CERT-EU empfohlene: Website vorübergehend vom Netz nehmen, auf eine statische Wartungsseite umleiten oder den Zugriff auf bekannte IP-Adressen bzw. VPN beschränken. Das PHP-Projekt nennt zusätzlich Konfigurationsänderungen, die einzelne bekannte Angriffswege blockieren. Sie machen eine Installation ausdrücklich nicht sicher, verschaffen aber Zeit.

php.ini bzw. FPM-Pool
; php.ini bzw. FPM-Pool (php_admin_value, damit Anwendungen es nicht überschreiben)
; gegen CVE-2026-109619 (bekannte Session-Pfade):
session.upload_progress.enabled = 0

; nur PHP 8.5:
fatal_error_backtraces = 0

; gegen CVE-2026-109618 (Angriffsfläche über große Anfragen verkleinern):
post_max_size = 8M         ; 32M, falls Uploads nötig sind
upload_max_filesize = 6M   ; immer kleiner als post_max_size

Ergänzend empfiehlt das PHP-Team unter anderem:

  • memory_limit=-1 nicht überschreibbar setzen (z. B. php_admin_value) und die Speichergrenze stattdessen über Container bzw. cgroups durchsetzen. RLIMIT_AS oder RLIMIT_DATA sind dafür ungeeignet. Diese Maßnahme nur mit Erfahrung umsetzen, da sie ohne Gegenmaßnahme Ausfälle begünstigen kann.
  • Auf Webserver- oder Proxy-Ebene Grenzen für Anfragegröße, Anzahl der Formularfelder, Multipart-Teile, Header und Verschachtelungstiefe setzen, auch für Anfragen ohne gültigen Content-Length-Header.
  • Ungültige oder veraltete Einstellungen entfernen, die vor der Initialisierung Warnungen erzeugen. Ausblenden über display_errors oder @ hilft nicht.

ini_set() und .user.ini greifen für diese Workarounds zu spät. Nach jeder Änderung müssen alle Worker neu gestartet werden. Eine Web Application Firewall wie Cloudflare kann zusätzlich bremsen, ersetzt das Update aber ebenfalls nicht.

Nach dem Patch: Prüfen, ob schon jemand drin war

Weil erste Angriffe gemeldet wurden, sollten Sie nach dem Update kurz kontrollieren, ob Ihr System bereits kompromittiert wurde:

  • Neue oder geänderte PHP-Dateien im Webroot und in Upload-Ordnern suchen, z. B. mit find /var/www -name "*.php" -newermt "2026-10-19".
  • Zugriffslogs auf ungewöhnlich große POST- oder Upload-Anfragen und Häufungen von Fehlern (HTTP 500) seit dem 19. Oktober prüfen.
  • Cronjobs, neue Admin-Konten im CMS und unbekannte Prozesse kontrollieren.
  • Bei Verdacht: Passwörter, API-Schlüssel und Datenbank-Zugänge wechseln und ein sauberes Backup von vor dem Vorfall einspielen. Personenbezogene Daten können eine Meldepflicht nach DSGVO auslösen.

Fazit: Updaten, neu starten, nachweisen

Die PHP2Shell-Lösung ist technisch klar: gepatchte PHP-Version installieren, alle PHP-Dienste neu starten und belegen, dass die Website wirklich die neue Version ausliefert. Schwierig wird es dort, wo niemand genau weiß, wer für PHP zuständig ist, wo alte Versionen laufen oder wo Systeme über Jahre gewachsen sind.

Genau hier unterstützen wir: ADence betreibt Websites, Shops und Software mit Hosting in Deutschland, Monitoring und regelmäßigen Sicherheitsupdates. Wenn Sie unsicher sind, ob Ihre Systeme betroffen sind, oder eine Migration auf eine aktuelle PHP-Version ansteht, sprechen Sie uns an.

Gut zu wissen

Häufige Fragen zu PHP2Shell

Was ist die Lösung für PHP2Shell?

Das Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. auf das gepatchte Paket Ihrer Linux-Distribution, gefolgt von einem Neustart von PHP-FPM oder Webserver. Workarounds senken nur das Risiko.

Ist meine WordPress-Website betroffen?

Wenn sie auf einer ungepatchten PHP-Version läuft, ja. Die Lücke liegt in PHP, nicht in WordPress. Die automatischen WordPress-Updates aktualisieren PHP nicht.

Reicht es, wenn mein Hoster das Update einspielt?

Bei Shared und Managed Hosting ist der Hoster zuständig. Lassen Sie sich trotzdem bestätigen, dass die Patches für CVE-2026-109618 und CVE-2026-109619 aktiv sind, und prüfen Sie die ausgelieferte PHP-Version.

Warum zeigt mein Server nach dem Update noch eine alte Versionsnummer?

Distributionen wie Debian und Ubuntu spielen den Fix als Backport ein, ohne die Versionsnummer zu ändern, ebenso das Repository von Ondřej Surý bei PHP 8.1 und älter. Maßgeblich ist dann die vollständige Paketversion (dpkg -l) bzw. das lokale Changelog mit den beiden CVE-Nummern. Zeigt auch das Paket den alten Stand, läuft der Dienst vermutlich noch mit dem alten Prozess: vollständig neu starten.

Was ist mit PHP 7.4 oder 8.1?

Diese Versionen bekommen kein offizielles Release mehr. Es gibt Backports einiger Distributionen und minimale Quellcode-Patches des PHP-Teams. Langfristig hilft nur die Migration auf eine unterstützte Version.

Schützt eine Firewall wie Cloudflare vor PHP2Shell?

Teilweise und vorübergehend. Cloudflare bezeichnet seine Regeln selbst als Übergangslösung. Das Update bleibt notwendig.

Quellen

  • PHP-Projekt: Security advisory und Releases 8.5.12, 8.4.27, 8.3.36, 8.2.35, 21.10.2026, php.net
  • CERT-EU: Security Advisory 2026-018 „Critical Vulnerabilities in PHP“, 21.10.2026, cert.europa.eu
  • GitHub Security Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp, github.com/php/php-src
  • NCSC-NL: Liste betroffener Drittsoftware, github.com/NCSC-NL/php2shell
  • Ondřej Surý: Status der gepatchten Pakete in deb.sury.org und ppa:ondrej/php, codeberg.org/oerdnj/deb.sury.org
  • Mattias Geniar: Paketversionen und Prüfbefehle je Distribution, ma.ttias.be
  • heise online: „PHP2Shell: Updates trudeln ein, viele Webseiten offline, Angriffe laufen“, heise.de
  • NOS: „Steeds meer websites offline gehaald vanwege lek“, 21.10.2026, nos.nl
  • CybelAngel: Lagebild zu CVE-2026-109618 und CVE-2026-109619, cybelangel.com

Alle Quellen abgerufen am 22. Oktober 2026. Wir aktualisieren diesen Beitrag, sobald neue Informationen vorliegen.

Marvin de Vries ist Geschäftsführer von ADence, der Online-Agentur aus Hamburg. Seit 2011 verantwortet er mit seinem Team Entwicklung, Hosting und Betrieb von über 400 Websites, Shops und Softwareprojekten. Marvin de Vries auf LinkedIn

Weiterlesen

Passende Leistungen

Hosting und Wartung

Betrieb in Deutschland mit Updates und Monitoring.

Individuelle Softwareentwicklung

Auch Modernisierung älterer PHP-Anwendungen.

Webdesign

Websites, die sicher betrieben werden.

Alle Leistungen

Software, Websites, Shops, Marketing und KI auf einer Seite.

Direkt sprechen

So erreichen Sie uns am schnellsten

Microsoft Teams Für den direkten Austausch und schnelle Antworten. Schreiben Sie uns, wir freuen uns auf Ihre Nachricht. Chat öffnen Videotermin Für eine persönliche Beratung ganz bequem von zu Hause aus. Suchen Sie sich einfach einen freien Termin aus. Termin finden Telefon Sie klären Dinge lieber direkt am Telefon, als umständlich per E-Mail oder WhatsApp? Kein Problem. Wir sind montags bis freitags von 9 bis 18 Uhr telefonisch zu erreichen. +49 (0) 40 756 817 83

Kontaktieren Sie uns

Ist Ihre Website betroffen?

Wir prüfen mit Ihnen im kostenlosen Erstgespräch, welche PHP-Version Ihre Systeme nutzen und was jetzt zu tun ist. Telefon: 040 756 817 83.

mail@adence.de QR-Code scannen Videotermin +49 (0) 40 756 817 83

Maria-Louisen-Straße 2A, 22301 Hamburg