PHP2Shell: Was wir geprüft und gepatcht haben

Am Anfang stand ein Video in der Timeline. Es warnte vor einer „riesigen PHP-Lücke“, blieb aber vage: keine CVE-Nummern, keine Versionen, keine technischen Details.

Genau so beginnen viele Sicherheitsthemen heute. Dieser Artikel zeigt, was an PHP2Shell belegt ist, wie wir unseren eigenen Server geprüft haben und was du daraus mitnehmen kannst. Stand: 22.10.2026.

Was PHP2Shell ist

PHP2Shell ist der Name für zwei Schwachstellen im PHP-Kern. Beide erlauben eine Remote Code Execution (RCE), also das Ausführen von fremdem Code auf dem Server – über das Netz und ohne Anmeldung.

Die eine Lücke betrifft die Behandlung von Speichermangel (out of memory): PHP kann dabei mitten in einer Anfrage unterbrochen werden, während interne Daten erst halb vorbereitet sind. Die andere betrifft Zustände, die nach dem Freigeben ihres Speichers weiterleben (ein sogenannter Use-after-free).

Laut Help Net Security reicht eine einzige Anfrage ohne Anmeldung, und der Angriff läuft, bevor überhaupt Anwendungscode ausgeführt wird. Ob deine Anwendung selbst sauber programmiert ist, spielt also keine Rolle.

Die Fakten auf einen Blick

• Schwere

  PHP bewertet beide Lücken mit CVSS v4 9.2 (kritisch). CVSS ist eine Skala von 0 bis 10 für die Schwere einer Lücke. Im Vorfeld kursierten auch Angaben bis 10.0.

• Betroffen

  Alle Web-Schnittstellen von PHP (SAPIs): PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Laut Wikipedia reichen die betroffenen Versionen von PHP 5.4 bis 8.5.

• Zeitlinie

  Öffentlich bekannt am 20.10.2026, teils durch vorzeitig durchgesickerte Details. Patches erschienen am 21.10.2026, einen Tag vor dem ursprünglich geplanten Termin.

• Fix

  PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für die nicht mehr unterstützten Versionen 7.4, 8.0 und 8.1 gibt es nur Quellcode-Patches, keine offiziellen Pakete.

• Gefunden von

  Ryan Austin von Calif und Forschenden von Wiz. Beide nutzten KI-Modelle, unter anderem von OpenAI (Initiative „Patch the Planet“).

• Ausnutzung

  Die Angaben gehen auseinander. Huntress sah bis zum Nachmittag des 21.10. keine Angriffe bei seinen Kunden, Wikipedia berichtet von Angriffen ab dem 21.10. Für dich heißt das: nicht abwarten, patchen.

Wie wir vorgegangen sind

Bei FORGE arbeiten KI-Agenten im Team, also mehrere spezialisierte KI-Programme mit klaren Aufgaben. Sie haben das Video transkribiert und jede Behauptung gegen Fachquellen geprüft. Ergebnis: Das Thema war echt, das Video aber vage und ohne technische Details.

Danach ging es an den eigenen Server. Die Agenten fanden eine PHP-Anwendung, die betroffen war. Sie prüften im Changelog des Distributionspakets, ob das verfügbare Update den Fix für CVE-2026-109618 wirklich enthält.

Erst dann wurde gepatcht und der PHP-Dienst (php-fpm) neu gestartet. Der Ausfall dauerte wenige Sekunden. Neo, unser Gründer, hat jeden Schritt freigegeben – die Agenten haben vorbereitet, der Mensch hat entschieden.

Aufräumen nebenbei: Altlasten finden

Beim Inventar aller PHP-Endpunkte fiel ein alter Admin-Endpunkt auf. Er wurde nicht mehr gebraucht und war schlicht vergessen worden.

Wir haben ihn abgeschaltet. In den vorhandenen Logs der letzten rund 14 Tage gab es keine fremden Zugriffe darauf.

Der Patch schließt die bekannte Lücke. Das Inventar findet die, von denen du nichts mehr weißt.

Die Versionsfalle bei Linux-Paketen

Viele Linux-Distributionen übernehmen Sicherheits-Fixes in ihre bestehende Version, statt auf die neue PHP-Version zu springen. Das nennt man Backport.

Auf Ubuntu 24.04 heißt das Paket zum Beispiel 8.3.6-0ubuntu0.24.04.13. „8.3.6“ wirkt veraltet, denn der offizielle Fix ist 8.3.36. Das Changelog zeigt aber: Genau dieses Paket enthält den Patch für CVE-2026-109618 und CVE-2026-109619.

Wer nur auf php -v schaut, zieht also leicht den falschen Schluss. Prüfe stattdessen das Changelog deines Pakets:

# Debian/Ubuntu
apt changelog php8.3-fpm | grep CVE-2026-109618

# RHEL/Alma/Rocky
rpm -q --changelog php-fpm | grep CVE-2026-109618

Taucht die CVE-Nummer auf, ist der Fix drin. Passe den Paketnamen an deine Version an.

Checkliste: Was du jetzt tun solltest

• Prüfen

  Läuft irgendwo PHP für Webanfragen? Welche Version, welches Paket? Bei Distributionspaketen: Changelog statt Versionsnummer.

• Patchen

  Update einspielen und den PHP-Dienst neu starten (php-fpm oder Webserver). Ohne Neustart läuft der alte Code weiter.

• Notfall

  Geht Patchen nicht sofort? Das britische NCSC rät, betroffene Systeme vom Netz zu nehmen. Huntress nennt für alte Versionen session.upload_progress.enabled = Off als Notlösung.

• Inventar

  Liste alle PHP-Anwendungen und Endpunkte auf, auch Test- und Admin-Seiten. Was niemand kennt, patcht niemand.

• Aufräumen

  Entferne, was nicht mehr gebraucht wird. Jede abgeschaltete Altlast ist eine Angriffsfläche weniger.

• Beobachten

  Huntress empfiehlt, auf PHP-Prozesse zu achten, die Shells oder Werkzeuge wie curl und wget starten. Prüfe deine Logs auf Auffälligkeiten.

• Quellen

  Prüfe Behauptungen aus Videos und Social Media gegen Primär- und Fachquellen. Ohne CVE-Nummer und Versionsangaben ist eine Warnung kein Handlungsplan.

Die Rolle von KI – auf beiden Seiten

PHP2Shell zeigt, wie stark KI die Sicherheitsarbeit gerade verändert. KI-Modelle halfen, die Lücken zu finden. Laut Help Net Security senken sie zugleich die Hürde, solche Lücken auszunutzen.

Bei uns hat KI die Fleißarbeit übernommen: transkribieren, Quellen abgleichen, den Server prüfen, das Changelog lesen. Das ging schnell und war nachvollziehbar dokumentiert.

Die Entscheidung, wann gepatcht und was abgeschaltet wird, blieb beim Menschen. Das halten wir für die richtige Arbeitsteilung.

Quellen

• Help Net Security: PHP2Shell vulnerabilities patched (21.10.2026)
• The Hacker News: PHP2Shell – two critical PHP flaws
• Huntress: PHP2Shell – leaked critical PHP vulnerabilities
• Wikipedia: PHP2Shell

Transparenz: Recherche, Serverprüfung und dieser Text entstanden mit Unterstützung unserer KI-Agenten. Alle Fakten sind gegen die verlinkten Quellen geprüft, die Freigabe erfolgte durch einen Menschen.