Was ist PHP2Shell? Kritische PHP-Sicherheitslücken (CVE-2026-109618 / 109619) und die Schutzmaßnahmen von Partnerfy

Kurz gesagt: PHP2Shell ist der Name für zwei kritische Sicherheitslücken im Kern von PHP, die am 21. Oktober 2026 geschlossen wurden: CVE-2026-109618 und CVE-2026-109619. Beide erhielten nach CVSS v4.0 eine Bewertung von 9.2 (kritisch). Im schlimmsten Fall kann ein Angreifer ganz ohne Benutzerkonto, allein mit speziell präparierten HTTP-Anfragen, Code auf dem Webserver ausführen (RCE). Das Problem steckt nicht in Ihrer Anwendung, sondern in PHP selbst. Selbst eine WordPress- oder Laravel-Installation mit makellosem Code oder eine schlichte „Hallo Welt“-Seite ist also gefährdet, sobald sie auf einer verwundbaren PHP-Version läuft. Die einzige vollständige Lösung: PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 (bzw. auf das gepatchte Paket Ihrer Distribution) aktualisieren und anschließend alle PHP-Worker neu starten. Wir bei Partnerfy haben nicht auf den offiziellen Patch gewartet: Etwa drei Stunden vor dessen Veröffentlichung haben wir auf unseren Servern die Übergangsmaßnahme aktiviert, vollständige Backups aller Konten erstellt und unsere Abwehr Schicht für Schicht verschärft. In diesem Beitrag erklären wir, wie die Lücke ans Licht kam, was technisch dahintersteckt, was Sie jetzt tun sollten und welche Schritte wir auf unserer Seite unternommen haben.

Dieser Beitrag richtet sich an Unternehmer und technische Teams, deren Website, E-Commerce-Plattform oder Individualsoftware auf PHP läuft. Die technischen Details stützen sich auf die offizielle Sicherheitsmeldung des PHP-Projekts, die GitHub-Sicherheitshinweise (GHSA) von PHP und die Veröffentlichungen der Sicherheitsforscher, die die Lücken entdeckt haben. Wo sich die Quellen widersprechen, weisen wir ausdrücklich darauf hin. Die Lage entwickelt sich rasant; dieser Beitrag gibt den Stand vom Abend des 21. Oktober 2026 wieder.

Was ist PHP2Shell und warum ist die Lücke so gefährlich?

PHP ist eine der am weitesten verbreiteten serverseitigen Sprachen im Web. WordPress, WooCommerce, Drupal, Joomla, Magento und Laravel laufen allesamt auf PHP. Drei Eigenschaften machen PHP2Shell so brisant:

• Keine Authentifizierung erforderlich. Der Angreifer muss sich weder auf Ihrer Website registrieren noch ein Passwort kennen oder ein Formular ausfüllen. Speziell präparierte Anfragen genügen.
• Auslösbar, bevor Anwendungscode läuft. Laut PHP-Projekt ist das Risiko bei Apache-mod_php-Installationen am höchsten. Dort wurde gezeigt, dass eine nicht authentifizierte Anfrage den Angriff auslöst, noch bevor irgendein Anwendungscode ausgeführt wird. Plugin-Updates, sauberer Code oder Sicherheitsprüfungen innerhalb der Anwendung versperren diesen Weg nicht.
• Enorme Reichweite. Gefährdet sind laut PHP-Projekt „alle PHP-Installationen, die Webanfragen bedienen“: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Nach Angaben von Wiz, einem der Teams, die die Lücken entdeckt haben, ist jede PHP-Version des letzten Jahrzehnts – bis zurück zu 5.4 – von mindestens einer der beiden Lücken betroffen. Diese Aussage zum Umfang stammt von Wiz; das offizielle PHP-Bulletin führt nur die unterstützten Zweige 8.2–8.5 auf.

Auch die Einschätzungen fallen drastisch aus. Wiz zählt die Funde „zu den schwerwiegendsten Sicherheitslücken, die in PHP entdeckt wurden“ (im Original: „among the most severe vulnerabilities discovered in PHP“). Medienberichten zufolge empfahl das britische National Cyber Security Centre (NCSC), Systeme, die sich nicht sofort patchen lassen, vom Netz zu nehmen. Auch CERT-EU riet dazu, aus dem Internet erreichbare Anwendungen bis zum Patch zu isolieren. Der Kommentar des Sicherheitsforschers Kevin Beaumont bringt die Lage auf den Punkt: „The PHP situation will lead to a mass of incidents“ – die PHP-Lage werde eine Vielzahl von Sicherheitsvorfällen nach sich ziehen.

Wie kam die Lücke ans Licht? Die Chronologie

Die Geschichte von PHP2Shell beginnt 2024 und mündet in eine der turbulentesten Cybersecurity-Wochen des Jahres 2026. Alle Uhrzeiten sind in UTC angegeben.

Zum Zeitpunkt der Veröffentlichung dieses Beitrags ist in öffentlich zugänglichen Quellen keine erfolgreiche Kompromittierung eines bestimmten Servers über diese Lücke bestätigt. Die Versuche haben jedoch begonnen, und Forscher rechnen mit einem langen Nachspiel. Oder, wie es Incident-Response-Experte Hal Pomeranz formuliert: „There will be a long tail for this one“ – das wird uns noch lange beschäftigen.

Der KI-Faktor: Zwischen Patch und Exploit liegen heute nur noch Stunden

Ein weiteres Detail macht PHP2Shell zu einem Fall, wie er typisch für 2026 ist: KI-Modelle spielten sowohl bei der Entdeckung der Lücke als auch beim Auffinden des Exploit-Wegs eine Rolle. Das Codex-Security-Team von OpenAI meldete einen der Funde unabhängig. Wiz schreibt: „Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit“ – Frontier-KI-Modelle hätten diese Hürde also erheblich gesenkt und einen seit Langem bestehenden Fehler in einen funktionierenden Exploit verwandelt. Ein Fehler, der 2024 noch Theorie war, wurde 2026 mit maschineller Hilfe zur Waffe. Die Botschaft an die Verteidiger ist unmissverständlich: Sobald ein Patch erscheint, läuft die Uhr – den Luxus „Das schauen wir uns am Wochenende an“ gibt es nicht mehr.

Was passiert technisch? Zwei Lücken, zwei unterschiedliche Ursachen

Bei beiden Lücken handelt es sich um Fehler in der Speichersicherheit. Beide hängen damit zusammen, wie PHP mit fatalen Fehlern umgeht, die bei der Verarbeitung einer Anfrage auftreten (insbesondere mit Out-of-Memory-Fehlern). Die Mechanismen unterscheiden sich jedoch.

CVE-2026-109618: „Halbfertige“ Daten im Moment des Speichermangels

Wird während einer Anfrage das Speicherlimit überschritten (Out-of-Memory, OOM), verlässt PHP den aktuellen Kontext über einen Mechanismus namens longjmp() schlagartig und bricht die Anfrage ab. Das offizielle Bulletin beschreibt das Problem so: An bestimmten Stellen wird Anfragespeicher zugänglich, bevor er vollständig vorbereitet ist. Schlägt genau in diesem Moment eine Speicherallokation fehl, berücksichtigt PHP diesen vorzeitigen Ausstieg nicht korrekt, und der Speicher bleibt in einem ungültigen Zustand zurück. Die Routine, die die Anfrage abschließt, liest anschließend diese halbfertigen Daten und handelt danach. Das Ergebnis ist Speicherkorruption – und bei geschickter Präparation Codeausführung.

Ein Vergleich: In einer Restaurantküche schreibt ein Kellner gerade einen Bestellzettel, wird plötzlich weggerufen, und der Zettel bleibt halb ausgefüllt liegen. Das Team, das später die Küche schließt, hält den Zettel für vollständig und führt aus, was daraufsteht. Kann ein Angreifer diesen halbfertigen Zettel nach Belieben ausfüllen, hat er plötzlich das Kommando über die Küche.

Wie trifft der Angreifer diesen Moment? Die im Bulletin aufgeführten Methoden beruhen auf dem Format multipart/form-data, das für Datei-Uploads verwendet wird:

• Multipart-Anfragen, die keine verwertbare Inhaltslänge angeben, können die erste post_max_size-Prüfung passieren.
• Ein Multipart-Teil kann beliebig viele Header enthalten.
• Leere Dateifelder zählen nicht zum max_file_uploads-Limit, erzeugen aber dennoch Arrays mit Dateimetadaten.
• Verschachtelte Feldnamen vervielfachen den Aufwand für die erzeugten Arrays.

Kurz gesagt: Der Angreifer baut eine Anfrage, die PHP genau im falschen Moment an die Speichergrenze treibt. Wie Wiz betont, parst PHP Multipart-Anfragen beim Start der Anfrage, noch bevor die normale Modulinitialisierung abgeschlossen ist. Apache mod_php wiederum führt die Abschlussroutine bedingungslos aus, selbst wenn der Anfragestart fehlschlägt. Deshalb kann die gesamte Kette durchlaufen, ohne dass auch nur eine einzige Zeile Ihres Anwendungscodes ausgeführt wird. Vollständige RCE wurde über HTTP gegen mod_php in der üblichen Prefork-Konfiguration mit mehreren Workern bestätigt – mit den Standardlimits von PHP für Eingaben und Speicher. Bei PHP-FPM ist die Lage anders, weil der Worker-Prozess beendet wird, wenn der Anfragestart fehlschlägt: Die Quellcodeanalyse zeigt, dass auch FPM betroffen sein kann, ein vollständiger Exploit gegen FPM wurde für diese Lücke bislang jedoch nicht demonstriert.

CVE-2026-109619: Der „Geist“ der vorherigen Anfrage

PHP-Worker-Prozesse beenden sich nicht nach einer einzigen Anfrage; derselbe Prozess bedient viele Anfragen nacheinander. PHP verwaltet globale Zustände, etwa für Fehler, Sessions, Objekte und Erweiterungen. Laut Bulletin wird ein Teil dieser Zustände vom Worker vorgehalten, verweist tatsächlich aber auf Speicher, der zu einer einzelnen Anfrage gehört. Endet eine Anfrage zu einem unerwarteten Zeitpunkt, bleiben diese Zeiger zurück. Die nächste Anfrage an denselben Worker greift auf diesen veralteten Zustand zu, bevor die normale Initialisierung ihn zurücksetzt. Das ist ein klassischer Use-after-free-Fehler (Zugriff auf bereits freigegebenen Speicher). Mit einem gezielt präparierten Heap-Layout kann er bis zur vollständigen Remote-Code-Ausführung führen.

Der Vergleich: Im Hotel funktioniert die Schlüsselkarte des vorherigen Gastes noch, und der neue Gast betritt das Zimmer, bevor es gereinigt wurde. Drinnen liegen noch die Sachen des Vorgängers.

Diese Lücke hat zudem eine Datenleck-Komponente. Laut Wiz kann die Speicheroffenlegung Passwörter, Authentifizierungstoken, API-Schlüssel und Zertifikate umfassen, die zu anderen Anfragen oder zum Server selbst gehören. Einer der bestätigten Wege führt über die Funktion Session Upload Progress (Upload-Fortschritt in der Session). Diese Funktion ist standardmäßig aktiviert, und die Anwendung muss nicht einmal session_start() aufrufen; die Session-Verarbeitung kann schon vor dem regulären Session-Start greifen. Als zweiten bestätigten Weg nennt das Bulletin den Pfad über Backtraces bei fatalen Fehlern (Fatal Error Backtraces) in PHP 8.5. RCE über den Session-Lebenszyklus wurde sowohl auf mod_php als auch auf PHP-FPM bestätigt.

Wichtiger Hinweis: Nach der offiziellen Definition von PHP betrifft CVE-2026-109618 die halbfertigen Daten im Moment des Speichermangels, CVE-2026-109619 dagegen den veralteten Zustand, der zwischen Anfragen zurückbleibt. Einige Quellen (darunter Wiz) ordnen die Angriffsmethoden den CVE-Nummern anders zu. Wir orientieren uns hier an den GitHub-Sicherheitshinweisen von PHP.

Wer ist betroffen? Die Versionsübersicht

Welche Anwendung Sie einsetzen, spielt keine Rolle. Wiz hat seine Demonstrationen auf den offiziellen Images von WordPress, Drupal und Joomla durchgeführt – nicht, weil diese Systeme selbst verwundbar wären, sondern weil sie alle auf PHP laufen. Ein Update des WordPress-Kerns oder Ihrer Plugins schließt diese Lücke nicht; aktualisiert werden muss PHP selbst auf dem Server.

Zur Einordnung der Größenordnung: Laut einer auf Shodan-Daten basierenden Analyse von Mallory gab es am 20. Oktober im Internet rund 884.000 Server, die im HTTP-Header PHP 8.1 oder älter meldeten. Diese Versionen erhalten keine offiziellen Patches. Das ist eine Zählung von Headern, keine Zahl bestätigt betroffener Systeme – sie zeigt aber, wie lang das Nachspiel ausfallen dürfte.

Was hat Partnerfy getan? Eine Abwehr in 6 Schichten – ohne auf den Patch zu warten

Als die Existenz der Lücke durchsickerte, war die Lage für uns glasklar: Der offizielle Patch war noch Stunden entfernt, die Angreifer bereiteten sich längst vor. Hinzu kam, dass weltweit alle gleichzeitig Updates ziehen wollten – in den Paket-Repositories kam es entsprechend zu massiven Engpässen und Blockaden. Deshalb hieß es bei uns nicht „Warten wir auf den Patch“, sondern: Abwehr aufbauen, Schicht für Schicht.

1. Frühe Reaktion: Übergangsmaßnahme Stunden vor dem offiziellen Patch

Unser DevOps-Team verfolgte die Meldungen über das Leak und die ersten technischen Einschätzungen genau und deaktivierte etwa drei Stunden vor Veröffentlichung des offiziellen Patches serverweit die Einstellung session.upload_progress.enabled. Genau das ist die Übergangsmaßnahme, die PHP selbst für CVE-2026-109619 empfiehlt. Und wir haben sie an der richtigen Stelle umgesetzt: Das PHP-Team verlangt, dass diese Einstellung nicht per ini_set() oder .user.ini, sondern auf Ebene der Hauptkonfiguration (php.ini / Serverkonfiguration) gesetzt wird. Unsere Änderung erfolgte exakt auf dieser Ebene und wurde in der Live-Konfiguration verifiziert.

2. Edge-Schicht: Angriffe filtern, bevor sie den Server erreichen

Unsere Unternehmenswebsite partnerfy.co und unsere Projekte, die hinter Cloudflare ausgeliefert werden, sind durch das Edge-Netzwerk von Cloudflare geschützt. Cloudflare hat in den frühen Morgenstunden des 21. Oktober standardmäßig einen ersten WAF-Regelsatz gegen die bekannten PHP2Shell-Vektoren aktiviert. Dadurch wird ein erheblicher Teil verdächtiger Anfragen herausgefiltert, bevor er überhaupt unsere Server erreicht. Da berichtet wurde, dass Angreifer ihre Payloads anpassen, um die ersten Regeln zu umgehen, verlassen wir uns nicht allein auf diese Schicht – dahinter stehen die weiteren Schichten bereit.

3. Gehärtete PHP-Konfiguration: Dem Angreifer den nächsten Schritt abschneiden

Die PHP-Konfiguration auf unseren Servern war schon lange vor dieser Krise gehärtet. Funktionen zum Ausführen von Systembefehlen (system, popen, proc_open und ähnliche) sind deaktiviert, ebenso das Einbinden entfernter Dateien (allow_url_include). Seien wir ehrlich: Eine RCE auf Speicherebene kann diese Beschränkungen theoretisch umgehen. In der Praxis besteht der erste Schritt eines Angreifers aber meist darin, eine Shell zu öffnen, Werkzeuge nachzuladen oder eine Web-Shell zu platzieren. Unsere Beschränkungen machen genau diese kritischen Schritte nach der Ausnutzung deutlich schwieriger – und deutlich lauter. Und wer Lärm macht, fliegt auf.

4. Kontoisolation: Selbst wenn eine Tür aufgeht, bleibt der Flur verschlossen

Jedes Konto auf unseren Servern läuft in einem eigenen, isolierten Dateisystem-„Käfig“. Selbst wenn bei einem Konto der schlimmste Fall eintritt, sind die Möglichkeiten eines Angreifers, sich seitlich auf Dateien und Prozesse anderer Konten auszubreiten (Lateral Movement), stark eingeschränkt. Reißt ein Glied, reißt noch lange nicht die ganze Kette.

5. Backups für den Ernstfall: Auf das Schlimmste vorbereitet

Vor dem Patch-Fenster haben wir vollständige Backups der Konten auf unseren Servern erstellt. Das Ziel ist einfach: Geht etwas schief, lautet die Frage nicht „Was haben wir verloren?“, sondern „Zu welchem sauberen Stand kehren wir zurück?“. Eine gute Sicherheitsstrategie verhindert nicht nur Angriffe – sie sorgt auch dafür, dass man selbst nach einem erfolgreichen Angriff schnell zu einem sauberen Zustand zurückkehren kann.

6. Patchen, Neustart und Spurensuche

Sobald die offiziellen gepatchten Pakete in den Distributionskanälen verfügbar sind, spielen wir sie auf unseren Servern ein und starten anschließend alle PHP-Worker neu. Der Neustart ist Pflicht: Alte Worker, die weiterlaufen, verwenden weiterhin den alten Code. Da der Patch eine neue harte Speichergrenze einführt, überprüfen wir in diesem Zuge auch unsere Speichereinstellungen.

Parallel dazu haben wir unsere Zugriffsprotokolle anhand der von den Forschern beschriebenen Indikatoren durchsucht. Ein konkretes Beispiel: Etwa drei Stunden nach Veröffentlichung des Patches ging von einer einzigen Cloud-IP-Adresse eine Serie von POST-Anfragen an das Stammverzeichnis unserer Website sowie an Pfade wie /api und /app – wobei sich der Absender abwechselnd als verschiedene Suchmaschinen- und KI-Bots ausgab (CCBot, Amazonbot, ClaudeBot und ähnliche). Sämtliche Anfragen wurden von der serverseitigen Sicherheitsschicht mit 403 abgewiesen, noch bevor sie unsere Anwendung erreichten. Ob es sich dabei um PHP2Shell-Versuche handelte, können wir nicht mit Sicherheit sagen; das Timing und das Muster gefälschter Identitäten passen jedoch zu den Massenscans, die nach dem Patch einsetzten. Zum Zeitpunkt der Veröffentlichung dieses Beitrags haben wir auf unseren Systemen keinerlei Anzeichen einer Kompromittierung festgestellt.

Der Ansatz von Partnerfy: Wir vertrauen die Sicherheit nicht einem einzigen Schloss an. Filter an der Edge, Härtung auf dem Server, Isolation der Konten, Backups im Rücken, schnelle Reaktion an vorderster Front. Fällt eine Schicht, greift die nächste.

Was sollten Sie tun? Die Checkliste Schritt für Schritt

1. Ermitteln Sie Ihre PHP-Version

Wenn Sie cPanel nutzen, können Sie die Version im „MultiPHP Manager“ oder unter „PHP-Version auswählen“ („Select PHP Version“) prüfen; haben Sie Zugriff auf den Server, genügt php -v. Achtung: Die PHP-Version auf der Kommandozeile kann von der Version abweichen, mit der Ihre Website läuft. Am zuverlässigsten ist es, Ihren Hosting-Anbieter nach der PHP-Version Ihrer Website zu fragen oder sie über eine temporäre phpinfo()-Seite anzuzeigen und diese sofort wieder zu löschen. Bei Shared Hosting ist das Update nicht Ihre Aufgabe, sondern die Ihres Hosting-Anbieters. Fragen Sie dort noch heute nach: „Haben Sie den PHP2Shell-Patch eingespielt?“

2. Aktualisieren und neu starten

Zielversionen: 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. In den Paketen von Linux-Distributionen kann die Versionsnummer abweichen. Wie auch Debian empfiehlt, sollten Sie sich nicht an der Versionsnummer orientieren, sondern im Changelog des Pakets nach der CVE-Nummer suchen. Starten Sie nach dem Update Apache, PHP-FPM und alle lang laufenden PHP-Worker neu.

3. Wenn Sie nicht sofort aktualisieren können: Übergangsmaßnahmen

Die Warnung des PHP-Projekts vorweg: Diese Maßnahmen „verringern die Exposition gegenüber bestimmten Angriffspfaden, machen eine Installation aber nicht sicher“ (im Original: „reduce exposure to specific attack paths but do not make an installation safe“). Die einzige vollständige Lösung ist das Update.

4. Wenn Sie eine alte PHP-Version nutzen: Das Upgrade duldet keinen Aufschub

PHP 8.1 und älter erhalten vom PHP-Projekt keine Updates mehr. Für eine Website auf diesen Versionen ist die eigentliche Lösung kein Patch, sondern ein Upgrade. Bedenken Sie: Auch der Support für PHP 8.2 endet am 31. Dezember 2026. Der Wechsel auf 8.2.35 rettet Sie heute; gehen Sie aber mit 8.2 ins Jahr 2027, erhalten Sie bei der nächsten Krise keinen Patch mehr. Läuft Ihre ältere Codebasis nicht auf neuen PHP-Versionen, ist das ein klares Zeichen, dass es Zeit für ein Projekt zur Software-Modernisierung ist.

5. Suchen Sie nach Angriffsspuren

Diese Indikatoren empfehlen die Forscher für die Zeit nach dem Patch:

• Ungewöhnliche Multipart-Anfragen, unmittelbar gefolgt von Speicherlimit-Fehlern oder einer Serie von HTTP-500-Antworten
• Unerwartet große oder beschädigte PHPSESSID-Cookies
• Unerklärliche Neustarts oder Abstürze von PHP-Workern
• php-fpm-, httpd- oder apache2-Prozesse, die Shells, Interpreter oder Download-Tools (etwa sh, bash, curl, wget) starten
• Neue Dateien im Web-Root (Web-Shells), neue Cronjobs, neue Benutzerkonten

Da der Angriff unterhalb der Anwendungsschicht abläuft, hinterlässt er in Ihren Anwendungslogs womöglich kaum Spuren. Prüfen Sie die Logs von Webserver und PHP. Bei einem Verdacht isolieren Sie den Server, sichern die Logs und analysieren erst dann. Da CVE-2026-109619 auch zur Offenlegung von Speicherinhalten führen kann, ist es im Verdachtsfall sinnvoll, zusätzlich Datenbankpasswörter, API-Schlüssel und Session-Secrets zu erneuern.

Die Lehre aus dieser Krise: Sicherheit ist kein Produkt, sondern ein Reflex

PHP2Shell hat drei Dinge unmissverständlich gezeigt. Erstens: Egal, wie sauber Ihre Anwendung ist – Sie sind nur so sicher wie die Plattform, auf der sie läuft. Zweitens: Im KI-Zeitalter ist die Zeitspanne zwischen Patch und Exploit auf Stunden geschrumpft. Drittens: Sobald es zu Leaks und Embargobrüchen kommt, bricht der Ansatz „Wir halten uns an den offiziellen Zeitplan“ in sich zusammen. Die Gewinner sind Teams, die die Nachricht in der ersten Stunde lesen, die Übergangsmaßnahme umsetzen, ihre Backups bereithalten und ihre Abwehr nicht einem einzigen Schloss anvertrauen.

Bei Partnerfy gehört genau dieser Reflex zum Standard unserer Leistungen in den Bereichen Managed Hosting und Serververwaltung, Cybersicherheit sowie Backup und Disaster Recovery. Als Softwareunternehmen mit Hauptsitz in Sakarya und Büros in der Türkei, in Deutschland, Russland und Irland klären wir gemeinsam mit Ihnen, auf welcher PHP-Version Ihre Website läuft, ob sie für PHP2Shell anfällig ist und wie Sie sich auf das Support-Ende von 8.2 vorbereiten. Nehmen Sie Kontakt mit uns auf – wir prüfen Ihre Website gemeinsam.

Quellen

• PHP: Sicherheitsmeldung vom 21. Oktober 2026
• GHSA-w8hw-w9fx-j79w: CVE-2026-109618 (RCE via OOM corruption)
• GHSA-6wmf-4rv5-p3rp: CVE-2026-109619 (RCE via stale global state)
• The PHP Foundation: Das heutige Sicherheitsrelease und der Plan zur Stärkung der PHP-Sicherheit
• Wiz: Forschungsbericht zu PHP2Shell
• Help Net Security: PHP2Shell-Patches veröffentlicht
• The Hacker News: PHP veröffentlicht Notfall-Patches für zwei kritische Lücken

Häufig gestellte Fragen (FAQ)