PHP-Sicherheitslücke: Was PHP2Shell für Unternehmen bedeutet

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Sicherheitsupdates gegen zwei kritische Schwachstellen. Unter dem Namen PHP2Shell werden CVE-2026-109618 und CVE-2026-109619 zusammengefasst. Die PHP Foundation erläutert die Meldung und fordert zur Aktualisierung auf. Unter passenden Bedingungen kann ein Angreifer ohne Anmeldung eigenen Code auf dem Server ausführen.

Beide Fehler liegen in PHP selbst. Beim ersten Fehler kann Speicherknappheit einen ungültigen internen Zustand hinterlassen. Beim zweiten Fehler kann ein späterer Aufruf noch auf freigegebene Daten eines früheren Aufrufs zugreifen. Ein Worker ist dabei ein Serverprozess, der Anfragen verarbeitet. Für Unternehmen ist vor allem relevant, welche PHP-Umgebung ihre Website tatsächlich ausführt.

Diese Meldung ist kein Nachweis, dass eine bestimmte Website bereits angegriffen oder übernommen wurde. Sie ist aber ein konkreter Anlass zum Handeln. Eine erreichbare Startseite und ein aktuelles WordPress-Plugin beantworten die Frage nach dem PHP-Patchstand noch nicht. PHP bildet eine eigene technische Schicht unter der Anwendung.

Der Beitrag ordnet diesen Sicherheitsfall mit Stand vom 30. Oktober ein. Die langfristige Planung eines Versionswechsels behandelt separat unser Artikel zum PHP-Supportende. Hier geht es um die aktuelle Meldung, die passenden Nachweise und die Zusammenarbeit bei ihrer Behebung.

Die beiden verlinkten PHP-Sicherheitsmeldungen nennen folgende erste reparierte Upstream-Versionen. Upstream bezeichnet hier die unveränderte Veröffentlichung des PHP-Projekts. Die Tabelle ist keine Liste der auf Dauer neuesten Versionen und keine vollständige Sicherheitsfreigabe für einen Server.

Hersteller können Korrekturen auch in ihre eigenen Pakete zurückübernehmen. Ein solcher Backport behält möglicherweise eine ältere PHP-Versionsnummer. Beispielsweise führt Ubuntu in USN-8948-1 für Ubuntu 24.04 LTS das korrigierte PHP-8.3-Paket 8.3.6-0ubuntu0.24.04.13 auf. Entscheidend sind deshalb Paketquelle, vollständiger Build und die zugehörige Sicherheitsmeldung.

Auch ein Verwaltungsmenü kann mehrere PHP-Umgebungen enthalten. Die Plesk-Meldung zu PHP2Shell unterscheidet unter anderem Website-PHP und die eigene Engine der Verwaltungsoberfläche. Sie nennt für ältere Linux-Zweige außerdem korrigierte Builds unter unveränderter Versionsnummer. Eine einzelne Zahl im Hostingmenü ersetzt daher keine Zuordnung zum betroffenen Bestandteil.

Für die Prüfung sollte am Ende ein kurzer, verständlicher Nachweis vorliegen: Welche Umgebung wurde betrachtet, welches Herstellerpaket schließt die beiden Lücken und welcher Stand verarbeitet jetzt die Webanfragen? Wenn diese Angaben fehlen, bleibt der Prüfauftrag offen.

Das offizielle PHP-Meldungsarchiv enthält zwei zusätzliche Hinweise. Am 23. Oktober beschreibt PHP einen weiteren, ungewöhnlichen Session-Sonderfall unter CVE-2026-115560. Er setzt eine bestimmte Kombination aus konfiguriertem Session-Serializer, einem Wechsel dieses Verfahrens im Anwendungscode und aktiviertem Session-Uploadfortschritt voraus. Bis zur angekündigten regulären Korrektur empfiehlt PHP, den Session-Uploadfortschritt abzuschalten. Diese Einstellung muss fachlich passend und an der wirksamen Stelle umgesetzt werden.

Am 26. Oktober folgten neue Windows-Pakete mit dem Zusatz -1. Sie aktualisieren die enthaltene Brotli-Bibliothek wegen CVE-2026-111497. Die PHP-Laufzeitnummer bleibt dabei gleich. Der betreffende Dekompressionsweg kann über cURL erreicht werden, wenn automatische Antwortdekompression aktiviert ist.

Für ein Unternehmen ergibt sich daraus eine praktische Anforderung an die Betreuung: Der Auftrag sollte einen aktuellen Prüfstand benennen. „Wir haben letzte Woche aktualisiert“ lässt sonst offen, ob spätere Hinweise und enthaltene Bibliotheken berücksichtigt wurden. Der Nachweis muss zur verwendeten Plattform passen; eine Windows-Paketmeldung wird nicht pauschal auf eine Linux-Installation übertragen.

Beginnen Sie mit der Website-Adresse, der Meldung und dem bekannten Hostinganbieter. Die zuständige Fachperson ermittelt die tatsächlich verwendete Web-Laufzeit, weitere PHP-Anwendungen und verfügbare Herstellerupdates. Eine Kommandozeilenprüfung allein genügt nicht, wenn Webanfragen über eine andere Installation laufen. Diagnosen gehören in einen geschützten Arbeitsbereich und nicht als öffentlich erreichbare Informationsseite auf die Website.

Im Red-Hat-Sicherheitsbulletin wird ausdrücklich zwischen installierter Software und den noch laufenden Workern unterschieden. Die betroffenen Prozesse müssen neu gestartet werden; ein Reload reicht nach diesen Herstellerhinweisen nicht aus. In Containerumgebungen müssen die laufenden Container beziehungsweise Pods ersetzt werden. Der passende Ablauf richtet sich nach dem tatsächlichen Produkt.

Konfigurationsänderungen können bestimmte Angriffspfade begrenzen, ersetzen aber nicht die Korrekturen der beiden ursprünglichen Lücken. Ein unbesehen kopierter Tipp zur Speicherbegrenzung kann außerdem die Verfügbarkeit beeinträchtigen. Deshalb sollte die beauftragte Person Herstellerhinweise, Anwendung und Betriebsgrenzen gemeinsam bewerten. Eine längere allgemeine Umstellungsplanung darf ein dringendes Sicherheitsupdate nicht unnötig verzögern.

1. Betroffenheit festhalten: Anwendung, ausführende PHP-Umgebung und zuständigen Anbieter zuordnen.
2. Maßnahme abstimmen: Passendes Herstellerupdate, erforderlichen Neustart und mögliche Unterbrechung klären.
3. Wiederherstellung vorbereiten: Verwendbare Sicherungen und den Weg bei einem fehlgeschlagenen Wechsel abstimmen.
4. Ergebnis prüfen: Aktiven Paketstand und die wichtigsten Kundenfunktionen kontrollieren.
5. Restpunkte benennen: Nachträge, zusätzliche Komponenten und ungeklärte Befunde mit Verantwortlichen festhalten.

Die Liste ist eine eigene redaktionelle Arbeitshilfe. Sie hilft bei der Beauftragung, ist aber kein universelles Serverrezept. Technische Eingriffe und Erreichbarkeitszeiten müssen zum konkreten Hosting- und Betreuungsvertrag passen.

Ein Unternehmen muss die internen Speicherfehler von PHP nicht selbst analysieren, um einen sinnvollen Auftrag zu erteilen. Es braucht eine verständliche Antwort auf drei Fragen: Betrifft das unsere Systeme? Wer setzt die nötigen Schritte um? Woran erkennen wir, dass der vereinbarte Zustand erreicht ist? Eine fachliche Betreuung verbindet die Sicherheitsmeldung mit diesen betrieblichen Fragen.

Ruhrstack beschreibt im Bereich Website-Sicherheit die gemeinsame Prüfung von Software, Einstellungen, Benutzerrechten und Sicherungen. Bei PHP2Shell kann daraus ein begrenzter Auftrag entstehen: den vorhandenen Stand einordnen, erforderliche Maßnahmen mit dem Hostinganbieter abstimmen und die vereinbarten Funktionen anschließend prüfen. Umfang, notwendige Zugriffe und Zuständigkeiten werden vorab geklärt.

Der erste Nutzen ist Orientierung. Sie erhalten eine konkrete Einordnung Ihrer Website, statt selbst Meldungen über verschiedene Produkte zusammenzusuchen. Der zweite Nutzen ist Koordination. Wenn Hostinganbieter und Anwendungsbetreuung unterschiedliche Aufgaben übernehmen, wird festgehalten, wer welchen Nachweis liefert. Dadurch lassen sich offene Punkte gezielt nachverfolgen.

Der dritte Nutzen betrifft Ihre Kundenwege. Nach einem technischen Wechsel sollte beispielsweise geprüft werden, ob eine Anfrage weiterhin angenommen wird oder eine Anmeldung funktioniert. Für Ihr Team ist ein erfolgreicher Paketwechsel erst dann betrieblich hilfreich, wenn die benötigte Anwendung wieder den vereinbarten Zweck erfüllt. Welche Wege dazugehören, lässt sich vorab anhand Ihrer tatsächlichen Website festlegen.

Im Bereich Hosting und Betrieb klärt Ruhrstack außerdem, wer Updates, Backups und die Überwachung auf Ausfälle übernimmt. Eine laufende Betreuung wird gesondert vereinbart. Daraus folgt weder eine automatische Rund-um-die-Uhr-Bereitschaft noch die Zusage, dass niemals eine Sicherheitslücke auftritt. Sie gewinnen einen benannten Ansprechpartner und einen nachvollziehbaren Arbeitsstand für den beauftragten Umfang.

Ein kleiner Servicebetrieb erhält über seine Website Reparaturanfragen. Nach der PHP2Shell-Meldung möchte die Geschäftsführung wissen, ob die Website betroffen ist. Der Hostinganbieter verwaltet die Serverpakete, eine externe Betreuung kennt das Formular. Im Betrieb selbst kann eine benannte Person bestätigen, ob eine kontrollierte Testanfrage angekommen ist.

Der Arbeitsauftrag hält diese Grenzen fest. Der Anbieter bestätigt den korrigierten Hersteller-Build und den Neustart der zugeordneten Webprozesse. Die Betreuung prüft nach der Umstellung den vereinbarten Formularweg. Der Betrieb kontrolliert das benannte Zielpostfach. Eine Testnachricht ist klar gekennzeichnet und wird nicht als echter Kundenauftrag behandelt.

Für die Geschäftsführung wird dadurch verständlich, was erledigt und was noch ungeklärt ist. Der Stand lässt sich bei einer späteren Rückfrage wiederfinden. Das Beispiel verspricht keinen unterbrechungsfreien Wechsel; es zeigt, wie eine begrenzte Maßnahme überprüfbar wird. Die weitergehende Planung solcher Kontrollen erläutert unser Beitrag zum Website-Monitoring.

Aus der technischen Wirkung eines Updates folgt keine rückwirkende Entwarnung: Es schließt die betreffende Schwachstelle, beweist aber nicht, dass zuvor niemand Zugriff hatte. Das ist eine fachliche Schlussfolgerung für den Prüfauftrag, keine Behauptung über einen Angriff auf Ihre Website. Ohne Untersuchung darf aus einer allgemeinen Warnung ebenso wenig ein konkreter Einbruch abgeleitet werden.

Falls ungewöhnliche Dateien, neue unbekannte Konten oder andere nachvollziehbare Auffälligkeiten vorliegen, benötigt der Verdacht eine eigene Einordnung. Eine sofortige Bereinigung ohne Abstimmung kann wichtige Hinweise verändern. Unser Artikel Website gehackt? Erste Schritte bei einem Verdacht behandelt diesen gesonderten Fall.

Gezielte Angriffstests und forensische Untersuchungen sind zusätzliche Leistungen mit eigenem Umfang und entsprechend qualifizierten Fachleuten. Sie sind nicht automatisch in einem normalen Updateauftrag enthalten. Eine ehrliche Betreuung benennt diese Grenze und hält fest, welche Aussage der ausgeführte Check tatsächlich trägt.

Nennen Sie Ihre Website-Adresse, den Hostinganbieter und die erhaltene Sicherheitsmeldung. Wenn bekannt, ergänzen Sie die eingesetzte Anwendung und einen geschäftlich wichtigen Ablauf. Die Versionsnummer oder Herstellerantwort darf mitgeschickt werden, soweit sie keine vertraulichen Informationen enthält. Unbekannte Angaben können als offen markiert bleiben.

Für das Gespräch sind vier Fragen hilfreich: Wer bestätigt den Paketstand? Wer prüft die Anwendung nach der Änderung? Wie werden mögliche Unterbrechungen abgestimmt? Welche Nachträge und Restpunkte bleiben offen? Daraus lässt sich ein konkreter Umfang ableiten. Das ist hilfreicher als die unprüfbare Zusage, eine Website pauschal „sicher zu machen“.

Bei Ruhrstack können Sie die technische Ausgangslage besprechen und passende nächste Schritte abstimmen. Sie erhalten eine Einordnung dessen, was geprüft werden soll und wer daran beteiligt ist. Notwendige Zugänge werden erst für einen vereinbarten Auftrag und über einen geeigneten Weg geklärt.

Redaktion

Ruhrstack, Dortmund

Veröffentlicht

30. Oktober 2026

Quellen geprüft

30. Oktober 2026

1. PHP Foundation: Today’s PHP Security Release: Einordnung der beiden kritischen Laufzeitlücken und der Veröffentlichung vom 21. Oktober. Abgerufen am 30. Oktober 2026.
2. PHP: RCE via OOM corruption: Offizielle Sicherheitsmeldung zu CVE-2026-109618 und den ersten reparierten Upstream-Versionen. Abgerufen am 30. Oktober 2026.
3. PHP: RCE via stale global state: Offizielle Sicherheitsmeldung zu CVE-2026-109619 und den Grenzen einzelner Konfigurationsmaßnahmen. Abgerufen am 30. Oktober 2026.
4. PHP: Meldungsarchiv 2026: Sicherheitsmeldung vom 21. Oktober sowie Session-Hinweis vom 23. und Windows-Paketmeldung vom 26. Oktober. Abgerufen am 30. Oktober 2026.
5. Ubuntu: USN-8948-1: Beispiel für herstellerspezifische Korrekturpakete mit vollständigen Buildnummern. Abgerufen am 30. Oktober 2026.
6. Red Hat: RHSB-2026-013: Betriebshinweise zu betroffenen Workern, Neustarts, Containern und Grenzen von Übergangsmaßnahmen. Abgerufen am 30. Oktober 2026.
7. Plesk: PHP2Shell-Sicherheitsmeldung: Getrennte PHP-Komponenten und korrigierte Hersteller-Builds bei gleicher Versionsnummer. Abgerufen am 30. Oktober 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.