php2shell: PHP-Sicherheitslücken in Webanwendungen schließen

Zwei kritische PHP-Sicherheitslücken erlauben es Angreifern, ohne Anmeldung eigenen Programmcode auf einem Webserver auszuführen. Das PHP-Team hat die Schwachstellen CVE-2026-109618 und CVE-2026-109619 am 21. Oktober 2026 veröffentlicht und Korrekturen bereitgestellt. Unternehmen sollten jetzt klären, welche ihrer Webanwendungen PHP verwenden und wer die Aktualisierung übernimmt. Das betrifft auch extern betreute Internetseiten und Portale.

Für die Geschäftsführung zählt dabei eine konkrete Auskunft: Ist die tatsächlich eingesetzte PHP-Umgebung bereits abgesichert? Ein aktuelles Redaktionssystem oder eine funktionierende Website beantwortet diese Frage nicht.

Was bei php2shell nachgewiesen wurde

PHP verarbeitet auf dem Server Formulare, Anmeldungen und dynamische Webseiten. Die unter dem Namen php2shell beschriebenen Fehler betreffen diese Laufzeitumgebung selbst, nicht eine einzelne Anwendung.

Beide Schwachstellen sind nach CVSS 4.0 mit 9,2 von 10 Punkten bewertet. Aus dem Bewertungsvektor geht hervor, dass für eine Ausnutzung weder eine Anmeldung noch eine Nutzerinteraktion erforderlich ist. Die veröffentlichten Advisories enthalten technische Nachweise der Ausnutzbarkeit.

Diese Nachweise belegen, dass ein Angriff möglich ist. Sie sind kein Nachweis einer laufenden Angriffswelle gegen Unternehmen. Für das Einspielen der Korrekturen ist ein solcher Nachweis auch nicht erforderlich.

Wie die PHP-Sicherheitslücken in mod_php und PHP-FPM wirken

Bei CVE-2026-109618 kann ein Speichermangel die Verarbeitung unterbrechen, während interne Daten noch unvollständig vorbereitet sind. Beim anschließenden Aufräumen verarbeitet PHP unter Umständen ungültige Speicherinhalte. Für Apache mit mod_php ist eine Codeausführung über HTTP nachgewiesen, teilweise bevor überhaupt Anwendungscode startet.

CVE-2026-109619 betrifft interne Zustände, die eine Anfrage überdauern, obwohl der zugehörige Speicher bereits freigegeben wurde. Eine spätere Anfrage an denselben Arbeitsprozess kann diesen Zustand ausnutzen. Hier ist die Codeausführung sowohl für mod_php als auch für PHP-FPM bestätigt. PHP-FPM verwaltet die Prozesse, die Webanfragen bearbeiten.

Dieser Unterschied ist praktisch bedeutsam: Die zweite Lücke trifft damit auch Serverkonfigurationen, die mod_php gar nicht einsetzen. Eine Entwarnung allein aufgrund der Betriebsart ist deshalb nicht möglich.

Welche Systeme Unternehmen jetzt prüfen sollten

Das PHP-Team richtet seine Warnung an alle PHP-Installationen, die Webanfragen verarbeiten. Genannt werden unter anderem mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Die Angriffsvoraussetzungen unterscheiden sich, und nicht für jede Betriebsart ist jeder Angriffspfad praktisch demonstriert.

Öffentlich erreichbare Webanwendungen

Zur Bestandsaufnahme gehören die Unternehmenswebsite, Kunden- und Mandantenportale, Webshops sowie Buchungs- und Anfrageformulare. Bei einer Praxis oder Pflegeeinrichtung kann ein separat betriebenes Anfrageportal relevant sein. Daraus folgt keine pauschale Betroffenheit der jeweiligen Praxis- oder Pflegesoftware. Maßgeblich ist, ob PHP beteiligt ist und in welcher Version.

Container, Geräte und interne Anwendungen

Auch Container und Geräte mit webbasierten Verwaltungsoberflächen gehören auf die Liste. Ein aktualisierter Host schützt einen Container nicht: Dessen PHP-Laufzeit wird getrennt versorgt und muss eigenständig aktualisiert oder neu bereitgestellt werden. Interne Anwendungen haben meist eine geringere öffentliche Angriffsfläche, sollten aber ebenfalls erfasst werden. Eine Markenliste allein belegt keine Verwundbarkeit; entscheidend sind die enthaltene PHP-Version und die Herstellerinformationen zum konkreten Produkt.

Warum ein Update der Anwendung allein nicht genügt

Die Fehler liegen in der PHP-Laufzeitumgebung, nicht in WordPress, TYPO3, Joomla oder einem Shopsystem. Ein Anwendungsupdate schließt sie deshalb nicht. Umgekehrt ist eine aktuelle PHP-Version kein Ersatz für die Pflege der Anwendungen selbst.

Beide Ebenen gehören getrennt betrachtet und getrennt dokumentiert. Wer nur die Anwendung aktualisiert, hält eine Verwundbarkeit offen, die im Administrationsbereich der Anwendung nicht sichtbar ist. Für die laufende IT-Sicherheit ist das unangenehm: Die Oberfläche meldet nichts.

Welche Folgen ein erfolgreicher Angriff haben kann

Eingeschleuster Code läuft zunächst mit den Rechten des Webserverprozesses. Gefährdet sind damit zuerst die Daten, auf die dieser Prozess zugreifen darf. Möglich sind veränderte Webseiten, ausgelesene Zugangsdaten einer Anwendung oder manipulierte Formularziele. Vollständige Administratorrechte entstehen daraus nicht automatisch.

Ein Beispiel verdeutlicht die Tragweite: Ein PHP-basiertes Mandantenportal speichert hochgeladene Unterlagen und besitzt Zugang zu einer Datenbank. Wird der Webserverprozess übernommen, könnten diese Berechtigungen den Zugriff auf vertrauliche Dokumente ermöglichen. Welche weiteren Systeme erreichbar wären, hängt von Netztrennung, gespeicherten Zugangsdaten und Berechtigungen ab.

Bereits eine vorübergehende Abschaltung kann den Betrieb erheblich treffen. Klären Sie deshalb, wie Anfragen und Dokumente während einer Wartung entgegengenommen werden.

Welche Updates die PHP-Sicherheitslücken schließen

Die korrigierten Veröffentlichungen sind PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Innerhalb dieser Versionsreihen müssen ältere Ausgaben aktualisiert werden. Für die Reihen 7.4, 8.0 und 8.1, die vom PHP-Projekt nicht mehr versorgt werden, hat das Sicherheitsteam zusätzlich Quellcode-Korrekturen bereitgestellt.

Bei Linux-Distributionen kann eine Sicherheitskorrektur in ein Paket mit älterer PHP-Basisversion zurückübertragen werden. Dieser Vorgang heißt Backport. Maßgeblich ist dann die Sicherheitsmeldung des Paketlieferanten mit der korrigierten Paketversion. Die sichtbare PHP-Versionsnummer allein reicht zur Bewertung deshalb nicht aus.

PHP 8.2 erhält regulär nur noch bis zum 31. Dezember 2026 Sicherheitsunterstützung. Für PHP 8.3 endet sie Ende 2027, für PHP 8.4 Ende 2028 und für PHP 8.5 Ende 2029. Das kurzfristige Sicherheitsupdate sollte deshalb durch eine geplante Migration ergänzt werden, die einen Kompatibilitätstest mit Anwendung und Erweiterungen einschließt.

Was Unternehmen jetzt konkret tun sollten

Zuständigkeit und Aktualisierung klären

Erfassen Sie für jede betroffene Anwendung den Betreiber, die PHP-Umgebung und den Wartungsverantwortlichen. Bitten Sie Hoster oder Dienstleister um eine Bestätigung, dass beide CVEs behoben sind. Eine allgemeine Auskunft wie „Der Server ist aktuell“ ist dafür zu ungenau.

Öffentlich erreichbare Systeme gehören zuerst bearbeitet. Vor dem Update sind eine aktuelle Sicherung und ein geprüfter Wiederherstellungsweg wichtig – geprüft, nicht nur vorhanden. Anschließend müssen die betroffenen Prozesse neu gestartet und die tatsächlich laufenden Versionen kontrolliert werden.

Prüfen Sie danach die geschäftlich wichtigen Funktionen: Anmeldung, Formularversand und Dokumentenupload. Dokumentieren Sie System, Paketstand, Zeitpunkt und Testergebnis. So bleibt nachvollziehbar, welche Anwendungen abgesichert sind – und die nächste Sicherheitsmeldung trifft eine vorbereitete Serverbetreuung.

Verzögerungen fachkundig überbrücken

Ist ein Update kurzfristig nicht möglich, sollte der Verantwortliche den Zugriff auf gefährdete Dienste einschränken oder besonders exponierte Funktionen vorübergehend abschalten. Die PHP-Entwickler beschreiben ergänzende Konfigurationsmaßnahmen, betonen aber deren begrenzte Wirkung: Zuverlässigen Schutz bietet allein das Update.

Besonders sorgfältig ist die vorgeschlagene Einstellung memory_limit=-1 abzuwägen. Sie entfernt PHPs Speicherbegrenzung pro Anfrage, bietet keinen vollständigen Schutz und erfordert zusätzliche Kontrolle des Ressourcenverbrauchs. Eine unüberlegte Übernahme kann die Verfügbarkeit gefährden. Solche Übergangsmaßnahmen gehören in fachkundige Hände.

Bei verdächtigen Änderungen, unerklärlichen Prozessen oder auffälligen Zugriffen reicht ein Update nicht aus. Dann sollten Protokolle gesichert und ein möglicher Sicherheitsvorfall untersucht werden. Eine bereits erfolgte Kompromittierung macht der Patch nicht rückgängig.

Häufige Fragen zu php2shell und PHP-Sicherheitslücken

Reicht ein Update von WordPress oder des Shopsystems?

Nein. Die Lücken liegen in PHP selbst und nicht in der Anwendung. Zusätzlich zu Anwendungsupdates muss die verwendete PHP-Laufzeit auf eine korrigierte Fassung gebracht und der zugehörige Dienst neu gestartet werden.

Schützt die Anmeldung am Portal vor dem Angriff?

Darauf sollte sich niemand verlassen. Für mod_php ist ein Angriff nachgewiesen, der bereits vor dem Anwendungscode ansetzt. Eine im Portal programmierte Anmeldung schützt diesen Verarbeitungsschritt nicht, weil sie erst später greift.

Genügt es, den Server zu aktualisieren, wenn Anwendungen in Containern laufen?

Nein. Ein Container bringt seine eigene PHP-Laufzeit mit und wird vom Update des Hosts nicht erfasst. Das Abbild muss die Korrekturen enthalten und neu bereitgestellt werden; danach gehört die laufende Version im Container geprüft.

Muss ich als Hostingkunde selbst PHP installieren?

Bei verwaltetem Hosting übernimmt das üblicherweise der Anbieter. Lassen Sie sich den korrigierten Paketstand Ihrer konkreten Umgebung bestätigen und prüfen Sie anschließend die wichtigen Websitefunktionen wie Anmeldung und Formularversand.

Ersetzt eine Web Application Firewall das Update?

Nein. Filter können bekannte Angriffsmuster abfangen, liefern aber keinen Nachweis, dass die PHP-Fehler geschlossen sind. Die Herstellerempfehlung bleibt das Sicherheitsupdate; eine Firewall ist allenfalls eine Überbrückung bis zum Patch.

Sind ältere PHP-Versionen mit Sonderpatch wieder langfristig sicher?

Ein Sonderpatch verlängert keinen regulären Support. Für PHP 8.1 und ältere Reihen sollten Betreiber die Versorgung durch ihren Anbieter klären und den Wechsel auf eine unterstützte Versionsreihe einplanen.

Fazit: zügig patchen, geordnet dokumentieren

php2shell erfordert eine zeitnahe Prüfung aller PHP-Umgebungen und das Einspielen der verfügbaren Korrekturen. Entscheidend sind klare Zuständigkeiten, ein geprüfter Wiederherstellungsweg und eine dokumentierte Funktionskontrolle. Wer heute weiß, welche Anwendung auf welcher PHP-Version läuft, ist beim nächsten Fall deutlich schneller.

Quellen

• PHP Group – Sicherheitsmeldungen und Veröffentlichungen 2026 (abgerufen am 21. Oktober 2026)
• PHP – Advisory zu CVE-2026-109618 (RCE via OOM corruption)
• PHP – Advisory zu CVE-2026-109619 (RCE via stale global state)
• PHP – Unterstützte Versionsreihen und Supportfristen
• PHP – Offizielle Downloads
• Ubuntu Security – CVE-2026-109618 und die korrigierten Paketversionen
• NCSC-NL – Sammlung betroffener Produkte (laufend aktualisiert)

PHP-Umgebungen prüfen lassen – wir unterstützen Sie

Sie möchten wissen, ob Ihre Webanwendungen betroffen sind und welcher Paketstand bei Ihnen läuft? Wir nehmen die eingesetzten PHP-Umgebungen auf, holen verbindliche Auskünfte bei Hostern und Herstellern ein und begleiten die Aktualisierung samt Funktionsprüfung. Auf unseren eigenen Systemen haben wir die Korrekturen am Tag der Veröffentlichung eingespielt und anschließend Host und Container gegen den korrigierten Stand geprüft. Rufen Sie uns an unter 0211 9779958 oder schreiben Sie uns über unser Kontaktformular.