PHP Update am 21. Oktober: Was Unternehmen bei den kritischen PHP-Sicherheitslücken jetzt tun müssen

• Seit dem 21. Oktober 2026, 16:00 Uhr MESZ, steht ein außerplanmäßiges PHP Update gegen zwei kritische Sicherheitslücken mit der Bewertung CVSS 9,2 bereit.
• Die korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, alle älteren Stände dieser Zweige sind betroffen.
• Die Lücken CVE-2026-109618 und CVE-2026-109619 (PHP2Shell) erlauben das Ausführen von Schadcode auf dem Server ohne Anmeldung, gefährdet sind unter anderem PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed.
• Die Lücken werden bereits aktiv ausgenutzt, ein erster Angriffsversuch wurde schon am 17. Oktober beobachtet, vier Tage vor der Veröffentlichung.
• Nach dem PHP Update müssen alle laufenden PHP-Prozesse neu gestartet und öffentlich erreichbare Systeme mindestens ab dem 17. Oktober auf Angriffe geprüft werden.

Das PHP-Sicherheitsteam hat am Mittwoch, den 21. Oktober 2026, um 16:00 Uhr deutscher Zeit ein außerplanmäßiges PHP Update veröffentlicht. Es schließt zwei kritische Sicherheitslücken im Kern von PHP, die beide mit CVSS v4.0 9,2 bewertet sind und Angriffe ohne Anmeldung ermöglichen. Die korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Inzwischen werden die Lücken aktiv ausgenutzt. Unternehmen sollten das Update sofort einspielen und ihre Systeme anschließend auf Spuren eines Angriffs prüfen.

Aktualisiert am 22. Oktober 2026: korrigierte Versionen, bestätigte Angriffe und eine neue Einschätzung zur Übergangsmaßnahme ergänzt. Erstveröffentlichung am 21. Oktober 2026, 11 Uhr.

Die beiden Lücken werden unter CVE-2026-109618 und CVE-2026-109619 geführt, auch CERT-EU, das Cyber-Notfallteam der EU-Institutionen, hat dazu eine eigene Sicherheitswarnung herausgegeben. Laut offiziellem Advisory beruht CVE-2026-109618 auf einer Speicherbeschädigung bei Speichermangel, CVE-2026-109619 auf veraltetem globalem Zustand im Interpreter. In beiden Fällen kann ein Angreifer eigenen Code auf dem Server ausführen.

Eigentlich sollten die Details bis zum Patch unter Verschluss bleiben. Am Nachmittag des 20. Oktober tauchten jedoch erste Informationen öffentlich auf. Die Sicherheitsfirma watchTowr bestätigte daraufhin, dass es sich um Lücken zur Codeausführung aus der Ferne (Remote Code Execution) handelt, und konnte eine davon nachstellen.

Parallel kursiert ein Video eines Angriffswerkzeugs mit dem Namen PHP2Shell, unter dem die Lücken inzwischen allgemein bekannt sind. Es zeigt erfolgreiche Angriffe auf Testinstallationen verbreiteter Anwendungen, darunter WordPress, Drupal, Joomla, Magento, MediaWiki, phpBB, Laravel, Symfony und WHMCS. Eine Anmeldung ist in den gezeigten Angriffen nicht zu sehen, ausgeführt wird der Code mit den Rechten des Webserver-Benutzers.

Bemerkenswert ist die Entstehung: Nach Angaben der Sicherheitsfirma Wiz steckten die Fehler seit Jahrzehnten im Code. Die Angriffskette war jedoch so aufwendig, dass sie für menschliche Forscher kaum praktisch umsetzbar war. Erst moderne KI-Modelle haben diese Hürde deutlich gesenkt.

Ja. Mehrere Sicherheitsfirmen melden aktive Angriffe auf beide Lücken. Amazon Threat Intelligence hat in seinem Honeypot-Netz einen ersten Angriffsversuch bereits am 17. Oktober 2026 registriert, also vier Tage vor der Veröffentlichung, und spricht inzwischen von einer breiten Ausnutzung. Auch watchTowr und Patchstack berichten von Angriffen, der Dienstleister Hadrian beobachtet sie in großem Umfang. Nicht alle sehen dasselbe Bild: Huntress und die US-Behörde CISA hatten am 21. Oktober noch keine Ausnutzung festgestellt. Die Richtung ist trotzdem eindeutig.

Für Unternehmen heißt das: Systeme können schon kompromittiert worden sein, bevor überhaupt ein Update verfügbar war. Auch wer am 21. Oktober schnell aktualisiert hat, sollte öffentlich erreichbare PHP-Systeme prüfen.

Betroffen sind alle PHP-Versionen vor den korrigierten Ständen. Je nach eingesetztem Zweig sollten Sie mindestens diese Version installieren:

• PHP 8.5: 8.5.12
• PHP 8.4: 8.4.27
• PHP 8.3: 8.3.36
• PHP 8.2: 8.2.35 (Supportende am 31. Dezember 2026, ein Umstieg sollte bereits geplant werden)

Für PHP 8.1 und älter gibt es kein offizielles Release. Für PHP 7.4, 8.0 und 8.1 stellt das PHP-Team lediglich minimale Korrekturen im Quellcode bereit, die selbst übersetzt werden müssen. Ansonsten bleiben nur Backports der Linux-Distribution oder eines Anbieters mit Langzeitsupport oder der Umstieg auf eine unterstützte PHP-Version.

Gefährdet sind alle gängigen Betriebsarten: PHP-FPM, mod_php unter Apache (hier ist das Risiko am höchsten), php-cgi, FrankenPHP und LiteSpeed. Wichtig bei Distributionen: Viele Hersteller übernehmen den Fix als Backport in ihre bestehenden Pakete. Die angezeigte PHP-Versionsnummer bleibt dann niedriger, entscheidend ist der Paketstand laut Sicherheitshinweis des Herstellers.

Weil die Lücken im PHP-Interpreter selbst liegen, ist nicht die Anwendung entscheidend, sondern die PHP-Installation darunter. Wichtig für die Einschätzung:

• Die öffentlich gezeigten Angriffe funktionieren sowohl mit Apache und mod_php als auch mit PHP-FPM. Der Betrieb über FPM ist also keine Entwarnung.
• Aktuelle Versionen von WordPress, TYPO3, Shopware oder Plugins schützen nicht, denn die Lücken liegen im PHP-Interpreter selbst und nicht im Code der Anwendung.
• Der Fix lässt sich nicht in der Anwendung einspielen, sondern nur auf Ebene des Servers, der Paketquelle oder des Container-Images.

In Unternehmen läuft PHP selten nur auf der Website. Typische Fundstellen sind Intranet und Wiki, Ticket- und Helpdesk-Systeme, Nextcloud, Matomo, Monitoring- und Dokumentationswerkzeuge, Kunden- und Lieferantenportale, Webmail sowie Verwaltungsoberflächen von Hosting-Servern. Gerade ältere Installationen, für die sich niemand mehr zuständig fühlt, sind das größte Risiko.

1. Inventur: Wo läuft bei Ihnen PHP?

Erstellen Sie eine Liste aller Systeme mit PHP, mit Version, Betriebsart (mod_php, PHP-FPM, Container) und Paketquelle (Distribution, Plesk, Zusatz-Repository, eigener Build, Hoster). Diese Zuordnung entscheidet darüber, woher Sie den Fix bekommen. Wenn Ihre Server in Microsoft Defender for Endpoint eingebunden sind, hilft das Software-Inventar beim Auffinden installierter PHP-Pakete. Wie Sie solche Abgleiche dauerhaft automatisieren, beschreiben wir in unserem Beitrag zum Schwachstellenmanagement mit Microsoft 365.

2. Hoster und Dienstleister fragen

Bei Managed Hosting oder extern betreuten Webanwendungen sollten Sie jetzt schriftlich klären, ob das PHP Update bereits eingespielt ist, wie der Abschluss bestätigt wird und ob die Systeme auf Angriffe geprüft wurden.

3. Systeme, die nicht sofort aktualisiert werden können

Eine verlässliche Übergangslösung gibt es nicht. Ein System, das sich nicht sofort aktualisieren lässt, sollte bis zum Update vom Internet getrennt oder nur noch intern erreichbar sein.

Die zunächst empfohlene Einstellung session.upload_progress.enabled = Off in der php.ini ist kein ausreichender Schutz. watchTowr stuft Abhilfen über Änderungen an ini-Dateien als unwirksam ein, und auch die Firma, die die Einstellung ursprünglich ins Spiel gebracht hatte, rechnet inzwischen mit Umgehungen. Über diesen Weg laufen zwar viele der beobachteten Angriffe, er ist aber nicht der einzige. Auch das Sperren von Shell-Funktionen über disable_functions schützt nicht verlässlich vor Fehlern im Interpreter. Notfall-Regeln einer Web Application Firewall, wie sie etwa Cloudflare für seine Kunden ausgerollt hat, können die Zeit bis zum Update überbrücken, ersetzen es aber nicht.

1. Das Advisory mit Ihrer Inventur abgleichen und das passende Fixpaket Ihrer Paketquelle bestätigen. Bei Distributionen kommt der Fix oft als Backport, die Upstream-Versionsnummer allein ist dann nicht aussagekräftig.
2. Das Update einspielen und alle laufenden PHP-Prozesse ersetzen: PHP-FPM-Dienste, Apache und dauerhaft laufende Worker. Ein neues Paket auf der Platte schützt nicht, solange alte Prozesse weiterlaufen.
3. Bei Containern ein neues Image bauen und ausrollen. Ein Neustart mit dem alten Image ändert nichts.
4. Die laufende PHP-Version im Web-Kontext prüfen, kritische Funktionen testen und Paketstand, Handler und Zeitpunkt dokumentieren.

PHP2Shell zeigt beispielhaft, warum Sicherheitsupdates immer häufiger und kurzfristiger kommen: KI-Modelle machen auch alte, gut versteckte Fehler ausnutzbar. Warum ein strukturiertes Patch Management heute Pflicht ist, haben wir gesondert eingeordnet.

Das PHP Update schließt die Lücke, entfernt aber keine bereits abgelegten Dateien und macht gestohlene Zugangsdaten nicht ungültig. Weil erste Angriffe schon am 17. Oktober beobachtet wurden, sollte die Prüfung mindestens ab diesem Datum ansetzen und nicht erst beim Patch-Termin.

Prüfen Sie öffentlich erreichbare PHP-Systeme auf neue oder veränderte Dateien im Webverzeichnis, auf ungewöhnliche ausgehende Verbindungen und auf auffällige Prozesse des Webserver-Benutzers. Ein deutliches Warnsignal sind Shells oder Skripte, die von php-fpm, php-cgi oder Apache gestartet werden. Da der Angriff greift, bevor überhaupt Anwendungscode läuft, finden sich in den Protokollen der Anwendung oft keine Spuren. Bei konkreten Hinweisen sollten Sie Datenbank- und API-Zugangsdaten aus den Konfigurationsdateien austauschen. Mit Microsoft Defender XDR lassen sich solche Auffälligkeiten auch auf Linux-Servern zentral erkennen, etwa durch Alarme, wenn ein PHP-Prozess eine Shell startet.

Als Microsoft Solutions Partner für Security unterstützt die InSys AG^® Unternehmen dabei, Schwachstellen wie diese im eigenen Bestand schnell zu finden und einzuordnen. Mehr zu unserem Ansatz finden Sie unter Microsoft 365 Security und Managed Security. Sie erreichen uns telefonisch unter +49 (521) 260105-0 oder über das Kontaktformular am Ende dieser Seite.