PHP2Shell Sicherheitslücke: CVE-2026-109618 trifft fast jeden Webserver

Hinweis: Dieser Beitrag wurde mit KI-Unterstützung erstellt und automatisiert veröffentlicht.

Die PHP2Shell Sicherheitslücke ist der schwerste Treffer, den die Websprache seit Jahren einstecken musste. Am 21. Oktober 2026 hat das PHP-Projekt Sicherheits-Releases veröffentlicht, die zwei kritische Schwachstellen schließen: CVE-2026-109618 und CVE-2026-109619. Beide sind mit CVSS 4.0 9.2 bewertet. Angreifer brauchen weder ein Konto noch einen Klick des Nutzers – wenige unauthentifizierte Anfragen genügen, denn der Angriff nutzt den Reststatus einer früheren Anfrage im selben Worker-Prozess.

Was bei der PHP2Shell Sicherheitslücke passiert ist

Gefunden hat die Fehler das Forschungsteam von Wiz – gemeinsam mit Calif.io, OpenAI und Quarkslab, so die Nennung bei Cloudflare; Wiz datiert die Erstentdeckung auf den 19. August 2026. Technisch handelt es sich um Speicherfehler, die auftreten, wenn PHP mitten in einer Anfrage in einen fatalen Fehler läuft – typischerweise, wenn der Speicher ausgeht. Danach bleibt interner Zustand zurück, den eine spätere Anfrage im selben Worker wiederverwendet. Daraus entsteht entweder ein Speicherleck oder eine Codeausführung.

• CVE-2026-109618 steckt laut Wiz in der Upload-Progress-Verarbeitung der Session-Erweiterung. Wiz demonstrierte damit nicht nur eine anwendungsunabhängige Speicherpreisgabe, sondern Remote Code Execution vor jeder Anmeldung auf WordPress, Drupal und Joomla.
• CVE-2026-109619 kombiniert einen Use-after-free im Backtrace fataler Fehler mit einer Typverwechslung in OPcache. Auch hier zeigte Wiz eine RCE ohne Login.

Betroffen ist laut Wiz praktisch jede PHP-Version des letzten Jahrzehnts, zurück bis 5.4. Das BSI hat eine eigene Cybersicherheitswarnung herausgegeben. Bemerkenswert ist der zweite Teil der Geschichte: Die fehlerhafte Logik lag über zehn Jahre im Code. Erst mit KI-Werkzeugen gelang es, daraus funktionierende Exploits zu bauen – nach Angaben von Wiz schaffte ein einzelner Forscher in einer Woche, was vorher ein Spitzenteam Monate gekostet hätte.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Ich werte aus, ob du den Newsletter öffnest und Links anklickst, um ihn zu verbessern. Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Was das für dich bedeutet

Ich ordne das ohne Alarmismus ein, aber deutlich: Das ist kein Plugin-Problem, das man aussitzen kann. Der Fehler sitzt unter der Anwendung, deshalb nützt sauberer eigener Code nichts. Wer eine WordPress-Seite, ein Nextcloud oder ein Shopsystem selbst betreibt, hat die Lücke mit hoher Wahrscheinlichkeit auf dem Server. Am riskantesten ist laut PHP-Projekt mod_php unter Apache, weil der Angriff dort greift, bevor überhaupt Anwendungscode läuft.

Zwei Punkte sind aus meiner Erfahrung als Admin die eigentliche Falle. Erstens: Die Speicherpreisgabe läuft über das Antwort-Cookie PHPSESSID und funktioniert auch dann, wenn die Anwendung nie session_start() aufruft. Zweitens: Was dabei ausgelesen wird, sind Passwörter, Tokens, API-Keys und Zertifikate aus fremden Anfragen. Ein Patch allein bereinigt das nicht. Für PHP 7.4, 8.0 und 8.1 gibt es vom PHP-Security-Team wegen der Schwere minimale Quell-Backports; regulär gepatchte Pakete kommen aber vom Distributor.

Konkret jetzt tun

• Updaten, heute: PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 einspielen. Linux-Distributionen und LTS-Anbieter haben die Patches vorab erhalten, also zuerst beim eigenen Paketquellen-Anbieter nachsehen.
• Version richtig prüfen, nicht annehmen: php -v zeigt nur die CLI. Maßgeblich ist der Interpreter des Webservers, also php-fpm -v bzw. die SAPI-Version. Wichtig: Distributionen backporten den Fix oft ohne Versionssprung – prüfe deshalb den Paket-Changelog auf die CVE-IDs, etwa mit apt changelog php8.3 | grep -E "CVE-2026-10961[89]" oder rpm -q --changelog.
• Alle Worker neu starten: FPM-Pools, Apache, FrankenPHP, LiteSpeed und persistente Laufzeiten wie Octane, RoadRunner oder Swoole. Alte Prozesse laufen sonst weiter mit dem verwundbaren Code im Speicher.
• Danach Geheimnisse rotieren, wenn der Server exponiert war: Datenbank-Zugänge, API-Keys, Session-Salts, WordPress-Secrets in der wp-config.php.
• Wenn du nicht sofort patchen kannst, nennt das PHP-Projekt Teilmaßnahmen – unter anderem memory_limit=-1 per php_admin_value, ein niedriges post_max_size sowie Container- oder cgroup-Limits statt RLIMIT_AS. Ausdrücklich gilt: Das verringert die Angriffsfläche, macht die Installation aber nicht sicher. Zur viel zitierten Einstellung session.upload_progress.enabled=0 ist der Stand uneindeutig: heise online hielt sie am Morgen des 21. Oktober, also vor Veröffentlichung der Details, für unwirksam; das PHP-Advisory führt sie seit dem Nachmittag als Teilmaßnahme zu CVE-2026-109619, die „die bestätigten Session-Pfade, nicht aber andere Varianten“ blockiert. (Die Zählung weicht zwischen den Quellen ab – Wiz ordnet den Upload-Progress-Bug CVE-2026-109618 zu.)
• In die Logs schauen: Wiz nennt als Indikatoren auffällige Multipart-Anfragen gefolgt von Memory-Limit-Fehlern oder gehäuften HTTP 500, ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies und unerklärliches Neustarten von PHP-Workern.
• Vorgelagerten Schutz nutzen: Cloudflare hat seine Managed Rules am 21. Oktober ausgerollt, nach eigenen Angaben auch für Free-Kunden. Das ersetzt den Patch nicht, kauft aber Zeit.

Wer seine Dienste zu Hause oder auf einem kleinen Server selbst hostet, merkt an so einem Tag schnell, wie viel von der eigenen Update-Disziplin abhängt. Wie ich eine solche Umgebung aufsetze, habe ich im Ratgeber zu NAS und Heimserver für Selfhosting beschrieben. Und dass Angriffe am Tag des Patches beginnen, war schon bei der WordPress-Lücke CVE-2026-87902 das Muster.

Einordnung: der eigentliche Bruch liegt woanders

Der Patch ist Routine, die Vorgeschichte nicht. Wiz vergleicht PHP2Shell mit Heartbleed und Log4Shell und nennt den Fall einen Wendepunkt für die KI-Ära. Daran ist etwas: Wenn der Aufwand, einen komplizierten Speicherfehler in einen stabilen Exploit zu verwandeln, von Monaten auf Tage sinkt, verliert das Argument „theoretisch ausnutzbar“ seinen Wert. Für die Risikobewertung heißt das, dass alte, als unpraktikabel abgelegte Schwachstellen neu zu bewerten sind. Ein Gegenpunkt der Fairness: Dieselben Werkzeuge haben die Lücke gefunden und den Patch verifiziert – gefunden haben sie Verteidiger, nicht Angreifer. Ob das so bleibt, ist offen. Bestätigte Ausnutzungen waren zum Zeitpunkt der BSI-Warnung nicht bekannt; Cloudflare berichtet allerdings, die Lücke sei vor dem offiziellen Termin geleakt und man habe Angriffsverkehr gegen eigene Kunden beobachtet.

Quellen

• BSI, Cybersicherheitswarnung: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit (21.10.2026)
• php.net, Security advisory: Critical remote code execution vulnerabilities, update now (21.10.2026)
• Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities (21.10.2026)
• Cloudflare, Deploying protections against the php2shell vulnerability (21.10.2026)
• heise online, Wichtige PHP-Updates am 21. Oktober beheben Codeeinschleusung-Schwachstellen (21.10.2026)