PHP Sicherheitslücke Oktober 2026, was ihr jetzt tun müsst

Die PHP Sicherheitslücke vom Oktober 2026 ist offiziell gepatcht. Das PHP Team hat PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei kritische Lücken mit CVSS 9.2, über die Angreifer ohne Login eigenen Code auf euren Servern ausführen können. Die klare Ansage vom PHP Team: sofort updaten. Wir sammeln hier alles, was ihr wissen müsst, und aktualisieren den Beitrag laufend.

Was über die PHP Sicherheitslücke bekannt ist

Am 20. Oktober 2026 hat das PHP Security Team das Release vorab angekündigt. Kurz danach warnte die EU Sicherheitsstelle in ihrem Security Advisory 2026-018 von CERT-EU. Am 21. Oktober folgte das offizielle Security Advisory auf php.net mit allen Details.

Punkt	Stand
CVE Kennungen	CVE-2026-109618 und CVE-2026-109619
Bewertung	CVSS v4.0 9.2, kritisch
Folge	Remote Code Execution ohne Login
Gefixte Versionen	PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
Betroffen	Alle PHP Installationen, die Web Requests bedienen
Höchstes Risiko	Apache mit mod_php
PHP 8.1 und älter	Kein offizielles Release, nur Backports

Welche PHP Setups betroffen sind

Laut PHP Team ist jede Installation betroffen, die Web Requests verarbeitet. Das umfasst:

• PHP-FPM, zum Beispiel hinter Nginx
• Apache mit mod_php
• php-cgi
• FrankenPHP
• LiteSpeed

Am gefährlichsten ist mod_php. Dort gibt es laut PHP Team bereits einen funktionierenden Exploit. Eine einzige Anfrage ohne Login reicht, und der Angriff startet, bevor euer Anwendungscode überhaupt läuft. Eure Firewall Regeln im Framework helfen da also nicht.

Die zwei Lücken einfach erklärt

CVE-2026-109618, RCE durch Speicherfehler: Wenn PHP der Speicher ausgeht, kann ein Request mitten im Aufbau abbrechen. Interne Daten sind dann nur halb fertig. Beim Aufräumen behandelt PHP diese kaputten Daten trotzdem als gültig. Genau dort setzt der Angriff an.

CVE-2026-109619, RCE durch alten Zustand: Daten aus einem Request können überleben, obwohl ihr Speicher schon freigegeben ist. Bearbeitet derselbe Worker danach den nächsten Request, greift er auf diesen alten Zustand zu. So kann ein Angreifer Einfluss auf fremde Requests nehmen.

Die vollständigen technischen Details stehen in den GitHub Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp.

PHP2Shell, Angriffe laufen bereits

Die beiden Lücken laufen inzwischen unter dem Namen PHP2Shell. Ein Exploit Tool ist öffentlich, und Sicherheitsforscher melden erste Angriffe. Wer heute nicht gepatcht hat, muss davon ausgehen, dass automatisierte Scans bereits laufen. Wie der Angriff abläuft, welche Systeme betroffen sind und woran ihr ihn erkennt, erklären wir im Beitrag PHP2Shell Exploit, so schützt ihr eure PHP Server mit dem Update.

Was ein Angreifer mit Remote Code Execution machen kann

Remote Code Execution ist die schlimmste Klasse von Lücken. Ein Angreifer schickt eine präparierte Anfrage an euren Server. Danach läuft sein Code dort. Typische Folgen sind:

• Daten abgreifen: Zugangsdaten aus der Konfiguration lesen, Kundendaten exportieren
• Seiten manipulieren: Schadcode oder Skimmer in Shops einbauen
• Backdoors ablegen: Webshells, die auch nach dem Patch weiter funktionieren
• Server missbrauchen: Spam, Kryptomining oder Angriffe auf weitere Systeme
• Ransomware: Dateien und erreichbare Backups verschlüsseln

Wie weit ein Angreifer kommt, hängt von eurem Setup ab. Entscheidend sind die Rechte des PHP Prozesses, die Isolation über Container und welche Secrets auf dem Server liegen.

PHP Sicherheitslücke schließen, so geht ihr vor

Das PHP Team sagt deutlich: Es gibt keine vollständige Absicherung außer dem Update. So geht ihr das praktisch an:

1. Inventur machen: Welche Server, Container Images und Hosting Pakete laufen mit PHP? In welcher Version?
2. Update einspielen: Auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Linux Distributionen und LTS Anbieter haben die Patches vorab bekommen, prüft dort auf neue Pakete.
3. Alle Worker neu starten: PHP-FPM, Apache oder FrankenPHP müssen die neue Version wirklich laden.
4. Tests laufen lassen: PHPUnit und E2E Tests nach dem Update, damit nichts anderes kaputt geht.
5. Spuren prüfen: Logs und Webroot auf Auffälligkeiten checken.

Die installierte Version seht ihr schnell im Terminal, lokal oder im Container:

php -v
docker compose exec app php -v

Nach dem Patch lohnt ein Blick auf neue oder geänderte PHP Dateien im Webroot der letzten Tage:

find /var/www -name "*.php" -mtime -3 -ls

PHP Docker Images updaten

Die offiziellen PHP Docker Images mit den gefixten Versionen werden gerade ausgerollt. Das passiert pro Architektur nacheinander, amd64 und arm64 können also zu unterschiedlichen Zeiten verfügbar sein. Wichtig ist, dass ihr das neue Base Image wirklich zieht und nicht aus dem Cache baut:

docker compose build --pull --no-cache
docker compose up -d
docker compose exec app php -v

• Gepinnte Patch Tags wie php:8.3.35-fpm ziehen nichts Neues. Setzt sie auf die gefixte Version, also 8.3.36. Tags wie php:8.3-fpm bekommen das Update beim Pull automatisch.
• Gepinnte Digests mit sha256 genauso manuell anheben. Renovate macht dafür automatisch Pull Requests auf.
• Eigene Base Images, die auf dem offiziellen PHP Image aufbauen, zuerst neu bauen und pushen, danach die Projekte.
• Alle Container mit PHP neu starten, auch Worker, Queue Consumer und Cron Container.
• Danach prüfen: php -v muss 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 zeigen. Steht dort noch die alte Version, läuft ein alter Container oder Cache.

Wer nur das Dockerfile anpassen kann, setzt den Tag fest auf die gefixte Version. Durch den neuen Tag ist der Build Cache ungültig und die Pipeline muss das neue Image ziehen:

PHP Version	Gefixte Version	Docker Tag (Apache)
8.2	8.2.35	php:8.2.35-apache
8.3	8.3.36	php:8.3.36-apache
8.4	8.4.27	php:8.4.27-apache
8.5	8.5.12	php:8.5.12-apache
8.1 und älter	kein offizielles Release	kein neues Image

Für FPM statt Apache tauscht ihr nur die Endung, also -fpm statt -apache.

Best Practice für schnelle Sicherheit, Tag festsetzen

Ein beweglicher Tag wie php:8.2-apache hat einen Haken. Ist das neue Image für eure Plattform noch nicht da, baut die Pipeline still die alte, verwundbare Version. Alles sieht grün aus, die Lücke bleibt offen.

Mit einem festen Tag wie php:8.2.35-apache passiert das nicht. Fehlt das Image noch, bricht der Build mit einer klaren Meldung ab:

no match for platform in manifest: not found

Das heißt: Der Tag existiert, aber noch nicht für eure Architektur. Am Dockerfile müsst ihr nichts ändern. Startet den Job nach einer Weile einfach neu. Sobald er durchläuft, habt ihr garantiert die gefixte Version im Container.

PECL Extensions brechen beim Build ab

Mit dem neuen Base Image wird jede Extension neu gebaut. Dabei können zwei Fehler auftauchen.

Fehler 1, Extension lässt sich nicht kompilieren: pecl install bricht etwa bei imagick ab, danach meldet docker-php-ext-enable, dass das Modul nicht existiert. Die Lösung ist der docker-php-extension-installer. Er ist für die offiziellen PHP Images gebaut, installiert fehlende System Pakete und kennt bekannte Kompatibilitätsprobleme. Statt pecl install und docker-php-ext-enable schreibt ihr:

COPY --from=mlocati/php-extension-installer /usr/bin/install-php-extensions /usr/local/bin/
RUN install-php-extensions imagick redis apcu

Fehler 2, PECL Server antwortet nicht: Im Log steht dann etwas wie cannot download und HTTP/1.1 500 Internal Server Error von pecl.php.net. Das liegt nicht an eurem Dockerfile. Der Server ist überlastet, vermutlich weil gerade sehr viele Teams gleichzeitig neu bauen. Startet den Job nach ein paar Minuten neu.

Bleibt PECL down, holt ihr die Extensions direkt aus den GitHub Repositories. Der Installer kennt dafür die Schreibweise Repository@Tag. Prüft vorher kurz, welche Version ihr braucht:

RUN install-php-extensions Imagick/imagick@3.8.0 phpredis/phpredis@6.2.0 krakjoe/apcu@v5.1.28

Für PHP 8.1 und älter gibt es kein neues offizielles Image. Diese Projekte brauchen einen Backport, einen LTS Anbieter oder ein Update auf eine unterstützte Version.

Achtung bei Remi: Wer PHP Pakete aus dem freiwillig gepflegten Repository rpms.remirepo.net bezieht, bekommt heute laut PHP Team kein Update. Wechselt dafür auf Pakete eurer Distribution oder baut aus dem Quellcode.

Was hilft, wenn ihr nicht sofort updaten könnt

Das PHP Team nennt Maßnahmen, die einzelne Angriffswege blockieren. Sie machen eine Installation aber nicht sicher. Nutzt sie nur als Brücke bis zum Update.

Gegen den Speicherfehler CVE-2026-109618

• memory_limit=-1 setzen, und zwar so, dass Anwendungen es nicht überschreiben können, etwa per php_admin_value im FPM Pool oder in der Apache Konfiguration.
• post_max_size klein halten: 8M ohne Datei Uploads, 32M mit Uploads. upload_max_filesize bleibt darunter.
• Limits am Webserver oder Proxy für Request Größe, Anzahl der Felder, Header und Multipart Teile setzen.
• Container oder cgroup Limits als Schutz für die Verfügbarkeit nutzen, nicht RLIMIT_AS oder RLIMIT_DATA. Die lösen genau den gefährlichen Fehler aus.

Gegen den alten Zustand CVE-2026-109619

• session.upload_progress.enabled=0 setzen und alle Worker neu starten.
• Auf PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen.
• Ungültige oder veraltete Settings entfernen, die pro Request Warnungen auslösen. Warnungen nur auszublenden hilft nicht.
• Fatal Errors und Timeouts beheben, die Angreifer von außen auslösen können, etwa bei Uploads oder Importen.

Wichtig: Diese Settings gehören in die php.ini, den FPM Pool oder die Server Konfiguration. ini_set() im Code oder eine .user.ini greifen zu spät. Ein Beispiel für einen FPM Pool:

php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

Ohne Memory Limit kann ein einzelner Request deutlich mehr Speicher fressen. Setzt deshalb parallel ein Limit auf Container Ebene, sonst tauscht ihr eine Lücke gegen einen Ausfall.

PHP 8.1 und älter, was jetzt

Hier liegt das größte Risiko. PHP 8.1 und ältere Versionen bekommen vom PHP Projekt kein Release mehr. Wegen der Schwere hat das Security Team aber minimale Backports als Quellcode für PHP 8.1, 8.0 und 7.4 bereitgestellt. Die helfen, wenn ihr PHP selbst baut. Manche Distributionen und LTS Anbieter liefern eigene Fixes, fragt dort nach. Welche Versionen offiziell unterstützt werden, steht auf der Seite zu den unterstützten PHP Versionen.

Auch PHP 8.2 läuft bald aus. Laut PHP Team endet der Support am 31. Dezember 2026. Wer jetzt auf 8.2.35 updatet, sollte direkt das nächste PHP Update planen.

Unser Rat für alte Projekte: nicht im Legacy weiterflicken. Ein sauberes neues Projekt daneben ist oft der bessere Weg. Vorher sichern Quality Gates wie PHPUnit und PHPStan das Verhalten ab.

Warum schnelle Updates jetzt zählen

Seit dem Release sind die technischen Details öffentlich. Angreifer lesen dieselben Advisories wie ihr. Für mod_php gibt es schon einen funktionierenden Exploit. Wer erst in einer Woche patcht, spielt mit seinen Daten.

Langfristig hilft eine Pipeline, die Updates automatisch vorschlägt und mit Tests absichert. Wir setzen dafür Renovate in der CI ein. So wird ein Sicherheitsupdate zum Routine Merge statt zur Feuerwehrübung. Wie Tests dabei als Leitplanke wirken, lest ihr in Warum KI Guardrails mit jedem besseren Modell wertvoller werden. Was das aktuelle Update der statischen Analyse bringt, steht in PHPStan 2.3 Update.

Häufige Fragen zur PHP Sicherheitslücke

Was ist die kritische PHP Sicherheitslücke im Oktober 2026?

Es geht um zwei Lücken mit den Kennungen CVE-2026-109618 und CVE-2026-109619, beide mit CVSS v4.0 9.2. Sie erlauben Remote Code Execution ohne Login. Die eine entsteht durch Fehler bei Speichermangel, die andere durch Daten, die zwischen Requests im selben Worker überleben.

Welche PHP Versionen schließen die Lücke 2026?

Gefixt sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie sind seit dem 21. Oktober 2026 verfügbar. Linux Distributionen und LTS Anbieter haben die Patches vorab bekommen und liefern eigene Pakete aus.

Welche PHP Setups sind 2026 betroffen?

Alle Installationen, die Web Requests bedienen. Dazu zählen PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko hat mod_php, dort gibt es bereits einen funktionierenden Exploit.

Was bedeutet Remote Code Execution?

Ein Angreifer führt über das Netzwerk eigenen Code auf eurem Server aus. Ohne Login reicht dafür eine präparierte Anfrage. Danach kann er Daten lesen, Seiten manipulieren oder Backdoors einrichten.

Was tun, wenn ich nicht sofort updaten kann?

Das PHP Team nennt Übergangsmaßnahmen wie memory_limit=-1 per php_admin_value, kleine post_max_size Werte und session.upload_progress.enabled=0. Sie blockieren bekannte Angriffswege, machen das System aber nicht sicher. Das Update bleibt der einzige vollständige Schutz.

Bekommen PHP 8.1 und ältere Versionen einen Patch?

Ein offizielles Release gibt es nicht. Das Security Team hat aber minimale Quellcode Backports für PHP 7.4, 8.0 und 8.1 bereitgestellt. Manche Distributionen und LTS Anbieter liefern eigene Fixes. Der sichere Weg bleibt ein Update auf eine unterstützte Version.

Wie finde ich heraus, welche PHP Version läuft?

Im Terminal zeigt php -v die Version. Im Container nutzt ihr docker compose exec mit dem Servicenamen. Bei Shared Hosting steht die Version meist im Kundenbereich des Hosters. Prüft auch Cronjobs und Worker, die oft eine andere PHP Version nutzen.

Woran erkenne ich, ob mein Server angegriffen wurde?

Typische Spuren sind neue oder geänderte PHP Dateien im Webroot, unbekannte Prozesse, ungewöhnliche ausgehende Verbindungen und auffällige Anfragen in den Access Logs. Im Zweifel holt ihr euch Unterstützung von einem Incident Response Team.