Moneeb Qureshi, 21. Oktober 2026, 6 Minuten Lesezeit

Am 21. Oktober 2026 hat das PHP-Projekt zwei Sicherheitslücken geschlossen, die unter dem Namen php2shell veröffentlicht wurden: CVE-2026-109618 und CVE-2026-109619. Beide sind mit CVSS v4.0 9.2 bewertet, und beide erlauben nicht authentifizierte Codeausführung aus der Ferne. Das Problem steckt nicht in einer einzelnen Anwendung, sondern in PHP selbst. Angriffe wurden beobachtet, bevor der Patch überhaupt verfügbar war.

Der Name php2shell stammt aus der Sicherheitsforschung. Das PHP-Projekt selbst führt die beiden Lücken schlicht unter ihren CVE-Nummern.

Dieser Artikel sagt Ihnen, was die Lücke technisch ist, wer betroffen ist, was jetzt zu tun ist, und wie wir mit solchen Meldungen für die von uns betreuten Umgebungen umgehen.

Was ist php2shell?#

Beide Lücken sind Use-after-free-Fehler in der PHP-Engine. Der Ablauf ist in beiden Fällen gleich aufgebaut. Ein fataler Fehler während eines Requests bricht PHP mitten im Programmlauf ab, typischerweise wenn ein Request die konfigurierte Speichergrenze überschreitet. Dabei wird der Speicher freigegeben, aber ein Zeiger darauf bleibt im globalen Zustand des Arbeitsprozesses stehen. Der nächste Request, der auf denselben Arbeitsprozess trifft, greift auf diesen Speicher zu. Wer kontrolliert, was dort inzwischen liegt, kontrolliert den Prozess.

Die beiden Varianten unterscheiden sich in dem Punkt, an dem der Zeiger hängen bleibt. CVE-2026-109618 betrifft den Unserializer der Upload-Fortschrittsanzeige, CVE-2026-109619 den zuletzt gespeicherten Backtrace eines fatalen Fehlers in Verbindung mit einer Typverwechslung in OPcache.

Drei Eigenschaften machen das gefährlich. Erstens braucht ein Angriff keine Anmeldung und keine Mitwirkung eines Benutzers. Zweitens genügt ein einzelner Request im Format multipart/form-data, also dasselbe Format, das jedes normale Datei-Upload-Formular verwendet. Und drittens greift der Angriff, bevor Ihr Anwendungscode läuft. Die Speicher-Auslese-Variante funktioniert auch dann, wenn die Anwendung niemals eine Session startet.

Als Wirkung sind Codeausführung aus der Ferne, das Auslesen von Serverspeicher, das Lesen beliebiger Dateien und abstürzende Arbeitsprozesse belegt.

Welche PHP-Versionen sind betroffen?#

Die kurze Antwort: praktisch jede Version seit PHP 5.4, und damit fast jeder, der PHP betreibt.

  • Betroffen ist mindestens eine der beiden Lücken in jeder PHP-Version seit 5.4, also in praktisch allem, was im letzten Jahrzehnt ausgeliefert wurde.
  • Betroffen sind nach Angabe des PHP-Projekts alle PHP-Installationen, die Webanfragen bedienen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.
  • Die Standardkonfiguration genügt. Es braucht keine ungewöhnlichen Einstellungen und keinen Fehler in der Anwendung.

Wichtig für die Einordnung: Ihre Anwendung ist nicht die Lücke. WordPress, TYPO3, Drupal, Joomla, Shopware und jede eigene Entwicklung laufen auf PHP und erben das Problem von dort. Ein Update des Content-Management-Systems behebt es deshalb nicht. Aktualisiert werden muss PHP.

Zur Größenordnung: PHP ist laut Erhebungen die serverseitige Sprache hinter rund 70 Prozent der Websites, bei denen diese Sprache bekannt ist.

Sind Sie betroffen?

Geben Sie Ihre PHP-Version ein, zum Beispiel 8.2.12. Die Prüfung läuft vollständig in Ihrem Browser, es wird nichts übertragen.

Patch-Versionen: 8.5.12, 8.4.27, 8.3.36, 8.2.35#

Das PHP-Projekt hat am 21. Oktober 2026 folgende Versionen veröffentlicht:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

PHP 8.1 und älter erhalten keinen offiziellen Fix mehr, weil diese Zweige aus der Wartung gefallen sind. Hier hilft nur ein Paket der eigenen Linux-Distribution mit zurückportiertem Fix oder der Wechsel auf eine unterstützte Version. Das ist der unangenehme Teil dieser Meldung, denn in der Praxis laufen viele Altanwendungen noch auf 7.4 oder 8.0.

Zeitlinie: Leak, erste Angriffe, Patch#

Die beiden Lücken sollten koordiniert offengelegt werden, kamen aber vor dem vereinbarten Termin heraus. Cloudflare hat daraufhin die Schutzregeln rund neun Stunden vor der öffentlichen Bekanntgabe scharf geschaltet: seit dem 21. Oktober um 03:02 UTC sind Kunden im kostenlosen wie im bezahlten WAF automatisch geschützt. Der Auslöser dafür war keine Vorsicht, sondern Angriffsverkehr, den Cloudflare gegen die eigenen Kunden beobachtet hat.

Das heißt für den Betrieb: Es gab kein ruhiges Fenster zum geordneten Planen. Wer jetzt noch nicht aktualisiert hat, arbeitet gegen laufende Angriffe.

Warum der php.ini-Einzeiler nicht reicht#

In der Nacht zum 21. Oktober kursierte eine Einzeiler-Empfehlung: session.upload_progress.enabled=0. Diese Einstellung nimmt drei von fünf beschriebenen Angriffswegen den Auslöser. Sie schließt die Lücke nicht. Das Haus, das sie ursprünglich vorgeschlagen hatte, hat inzwischen selbst darauf hingewiesen. Das PHP-Projekt nennt in seinen Sicherheitsreleases ohnehin nur einen Weg, und es formuliert ihn unmissverständlich: Alle Nutzer sollen dringend sofort aktualisieren.

Wer aus guten Gründen nicht sofort aktualisieren kann, gewinnt mit diesen Maßnahmen Zeit, aber nichts weiter:

  • Requests mit multipart/form-data auf Ebene des Webservers oder der Web Application Firewall blockieren. Das deaktiviert in der Regel Datei-Uploads und Formulare.
  • Betroffene Dienste vorübergehend auf GET und HEAD begrenzen, also lesend betreiben.
  • Vorhandene WAF-Regelsätze einschalten. Cloudflare hat dafür sieben Regeln im kostenlosen Regelsatz, sieben im Regelsatz der bezahlten Tarife und zusätzlich eine antwortbasierte Regel über alle Tarife ausgerollt.
  • Nicht benötigte Uploads abschalten und die zulässige Uploadgröße begrenzen. Das ist Cloudflares eigene Empfehlung für die Zeit bis zum Patch.

Wie wir Kunden bei php2shell absichern#

Eine Lücke in der Laufzeitumgebung lässt sich nicht wegorganisieren. Organisieren lässt sich die Zeit zwischen Veröffentlichung und eingespieltem Patch. Genau darum geht es in einem Managed Service, und so arbeiten wir:

Wir wissen, wo PHP läuft. Für jede betreute Umgebung führen wir eine Bestandsaufnahme, auch darüber, welche Dienste auf PHP aufsetzen und in welcher Version. Ohne diese Liste ist die erste Frage bei so einer Meldung nicht beantwortbar, und sie ist immer dieselbe: Betrifft uns das überhaupt?

Wir bewerten, statt Panik weiterzuleiten. Nicht jede kritische Meldung trifft jede Umgebung gleich hart. Ob ein Dienst aus dem Internet erreichbar ist, hinter einem VPN liegt oder nur intern antwortet, entscheidet über die Dringlichkeit. Diese Einordnung nehmen wir je Kunde vor, bevor wir irgendetwas anfassen.

Wir informieren aktiv, in beide Richtungen. Unsere Kunden hören von uns, wenn Handlungsbedarf besteht. Sie hören aber auch von uns, wenn das Ergebnis der Prüfung lautet, dass ihre Umgebung nicht betroffen ist. Diese zweite Nachricht ist genauso wichtig, denn sonst lesen Geschäftsführer eine Schlagzeile und bleiben mit der Frage allein.

Wir patchen im Wartungsfenster, bei laufenden Angriffen auch außerhalb. Welcher Fall vorliegt, sagen wir vorher, nicht nachher.

Wir schauen nach dem Patch weiter hin. Abstürzende Arbeitsprozesse und auffällige Fehlerbilder sind bei dieser Lücke ein Hinweis auf Angriffsversuche. Das ist Teil des Monitorings, nicht eine Sonderaufgabe.

php2shell patchen: Anleitung in sechs Schritten#

Falls Sie Ihre PHP-Systeme selbst betreiben, ist das die Reihenfolge:

  1. Version feststellen. php -v auf dem Server reicht nicht aus, wenn Kommandozeile und Webdienst unterschiedliche Versionen verwenden. Prüfen Sie die Version je FPM-Pool und je virtuellem Host.
  2. Patch einspielen. Ziel ist 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer. Bei Debian, Ubuntu, RHEL und ähnlichen Distributionen das Paket des Herstellers verwenden, dessen Versionsnummer weicht ab und enthält den Fix trotzdem.
  3. Arbeitsprozesse neu starten. Ein eingespieltes Paket allein genügt nicht, solange alte Prozesse weiterlaufen. PHP-FPM und Apache brauchen einen Neustart.
  4. Altversionen einplanen. Wo 8.1 oder älter läuft, braucht es jetzt einen Termin für das Upgrade, nicht irgendwann.
  5. Dienstleister fragen. Bei Webhosting und externen Agenturen liegt das Aktualisieren beim Anbieter. Fragen Sie nach dem Stand und lassen Sie sich die Antwort schriftlich geben.
  6. Protokolle prüfen. Auffällig sind gehäufte Abstürze von Arbeitsprozessen, Speicherfehler und ungewöhnliche multipart-Requests, besonders ab dem 20. Oktober.

Was der Fall für Patch-Management bedeutet#

Der verwundbare Code ist über zehn Jahre alt. Gefunden wurde er jetzt, und die Forscher sagen offen, warum: Sie haben aktuelle KI-Modelle für Analyse und Entwicklung des Angriffs eingesetzt. Was früher ein erfahrenes Team über Monate gekostet hätte, war damit für eine Person in etwa einer Woche machbar.

Das ist die Lehre, die über php2shell hinausreicht. Alter Code ist kein ruhendes Risiko mehr. Der Abstand zwischen "diese Lücke existiert seit Jahren unbemerkt" und "diese Lücke wird ausgenutzt" wird kürzer, und zwar für alle Software gleichzeitig. Patch-Management ist damit keine Hygienemaßnahme mehr, sondern eine Frage der Reaktionszeit.

Fazit#

php2shell ist ernst: unauthentifizierte Codeausführung, Standardkonfiguration genügt, Angriffe laufen, und betroffen ist praktisch jede PHP-Installation im Netz. Der Patch ist verfügbar, und er ist die einzige vollständige Antwort.

Die unangenehmere Frage kommt danach. Wenn Sie in Ihrem Haus nicht binnen einer Stunde beantworten können, welche PHP-Versionen auf welchen Systemen laufen, dann ist das die eigentliche Baustelle. Die nächste Meldung dieser Art kommt bestimmt. Wer dabei abwägt, ob er das selbst tragen will, findet die Argumente in unserem Vergleich MSP oder eigener IT-Admin.

Sie sind nicht sicher, ob und wo Sie betroffen sind? Sprechen Sie mit uns. Wir sehen nach und sagen Ihnen auch, wenn kein Handlungsbedarf besteht.

Quellen#

  • php.net, Sicherheitsreleases PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 vom 21. Oktober 2026
  • Cloudflare, Schutzregeln und beobachteter Angriffsverkehr
  • Wiz Research, technische Analyse und Offenlegung
  • Imperva, Einordnung der Behelfsmaßnahmen