PHP-Sicherheitslücke PHP2Shell: Ist deine Website betroffen?

Seit dem 21. Oktober gibt es Patches für zwei kritische Sicherheitslücken in PHP, der Programmiersprache hinter gut zwei Dritteln aller Websites, darunter praktisch jede WordPress-Seite und viele Online-Shops. Die Lücken mit dem Namen PHP2Shell lassen Angreifer ohne Login eigenen Code auf dem Webserver ausführen, und sie werden bereits massenhaft ausprobiert. Ob deine Website betroffen ist, klärst du in zehn Minuten: Hier stehen die drei Prüfschritte, ein ChatGPT-Prompt samt Skill zum Kopieren und der Grund, warum diesmal Stunden zählen und nicht Wochen. Stand: 22. Oktober 2026, mittags.

Was passiert ist

Die beiden Lücken stecken nicht in WordPress, Shopware oder einem Plugin, sondern in PHP selbst: in der Speicherverwaltung und Fehlerbehandlung, die fast jede Anfrage an den Webserver durchläuft. Ein Angreifer braucht weder ein Konto noch die Mithilfe eines Nutzers, präparierte Anfragen reichen. Am stärksten gefährdet sind laut PHP-Projekt Server mit Apache und mod_php, wo der Angriff ausgelöst wird, „bevor irgendein Anwendungscode läuft“. Betroffen sind aber alle Installationen, die Webanfragen verarbeiten, auch PHP-FPM, FrankenPHP und LiteSpeed. Zusätzlich lässt sich über die Lücken Arbeitsspeicher auslesen, in dem Passwörter, Sitzungsschlüssel und API-Schlüssel liegen können.

Die Forscher haben die Angriffe gegen aktuelle Versionen von WordPress, Drupal, Joomla, Magento, Nextcloud, phpMyAdmin und weiteren Anwendungen vorgeführt. Ein WordPress- oder Plugin-Update hilft deshalb nicht. Schutz bringt nur eine reparierte PHP-Version. Ungewöhnlich ist auch der Ablauf: Eigentlich sollten die Details bis zum Patch geheim bleiben. Stattdessen sickerten sie durch, und die ersten Angriffsversuche kamen, bevor die meisten Betreiber überhaupt patchen konnten.

Ist deine Website betroffen? Die Kurzantwort nach Setup

Ob du handeln musst, hängt weniger an deiner Website als daran, wer den Server betreibt. Such dir deine Zeile:

Die letzte Zeile wird am häufigsten übersehen. PHP steckt nicht nur in der Website, sondern auch in Werkzeugen, die nebenher laufen. Die Forscher haben unter anderem die Cloud-Ablage Nextcloud, das Webmail-Programm Roundcube und die Datenbank-Oberfläche phpMyAdmin erfolgreich angegriffen. Dazu kommen Geräte mit eingebautem PHP, etwa die Firewalls pfSense und OPNsense, die das BSI ausdrücklich nennt. Weil die Lücke in PHP sitzt, ist jede PHP-Anwendung auf einem ungepatchten Server ein eigener Eingang.

In zehn Minuten prüfen: drei Schritte

Du brauchst dafür keinen Server-Zugang. Wer sich die Lage lieber von einer KI erklären lässt: Prompt und Skill für ChatGPT stehen weiter unten.

1. Beim Hoster nachsehen. Große Hoster informieren im Kundencenter, auf einer Statusseite oder im Blog, ob sie gepatcht haben. Steht dort eine Meldung mit Datum, ist der wichtigste Teil erledigt. Steht dort nichts, ist das kein gutes Zeichen, sondern ein Anlass für die Mail weiter unten.
2. Die PHP-Version auslesen. Bei WordPress geht das ohne Technik: im Dashboard unter Werkzeuge, Website-Zustand, Reiter Bericht, Abschnitt Server. In Webhosting-Paketen steht die Version in den PHP-Einstellungen des Kundencenters. Mit Server-Zugang zeigt sie der Befehl php -v.
3. Mit der Liste der reparierten Versionen abgleichen. Repariert sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie alle neueren. Für 8.1, 8.0 und 7.4 gibt es kein offizielles Update, nur Quellcode-Korrekturen für alle, die PHP selbst bauen, und Nachlieferungen einzelner Anbieter. Vorsicht, Versionsnummern täuschen: Ubuntu 24.04 zeigt nach dem Update weiter „8.3.6“ an, obwohl die Korrektur drin ist, weil Distributionen sie in die alte Version einbauen. Dann zählt der Paketstand oder die schriftliche Bestätigung des Anbieters, dass beide CVE-Nummern geschlossen sind.

<?php echo PHP_VERSION, ' | ', PHP_SAPI;

Ein Blick von außen hilft nur begrenzt. Manche Server verraten ihre PHP-Version im Antwort-Header X-Powered-By, die meisten gut eingerichteten nicht. Fehlt der Header, heißt das also nicht, dass alles in Ordnung ist, sondern nur, dass der Server schweigt.

Jede dritte WordPress-Seite läuft auf PHP ohne Support

WordPress veröffentlicht laufend, mit welchen PHP-Versionen die Installationen weltweit arbeiten. Die Zahlen von heute zeigen das eigentliche Problem hinter PHP2Shell: Ein großer Teil der Seiten läuft auf Versionen, für die das PHP-Projekt keine Sicherheitsupdates mehr liefert.

„Ohne Support“ heißt nicht automatisch ungepatcht. Manche Hoster und Distributionen liefern für alte Versionen weiter Korrekturen, wie cPanel in dieser Woche. Verlassen kannst du dich darauf aber nur, wenn es dir jemand schriftlich bestätigt. Wenn nicht, ist PHP2Shell der Anlass, die Version endlich anzuheben. Bei WordPress ist das meist ein Klick im Kundencenter, vorher ein Backup und danach ein Test der wichtigsten Seiten und Formulare. Und wer gerade auf PHP 8.2 wechselt, sollte gleich eine Stufe weiter gehen: Für 8.2 enden die Sicherheitsupdates am 31. Dezember.

Warum KI das Zeitfenster auf Stunden schrumpfen lässt

PHP2Shell ist ein KI-Fall, und zwar von beiden Seiten. Gefunden haben die Lücken Sicherheitsforscher mit KI-Hilfe: die Firma Calif im Rahmen von OpenAIs Programm „Patch the Planet“ mit einem Sprachmodell als „Audit-Kumpel“, die Cloud-Sicherheitsfirma Wiz mit Gemini 4 Argon und GPT-5.6 Sol, und unabhängig davon OpenAIs eigener Prüf-Agent. Wiz schreibt, ein einzelner Forscher habe mit Frontier-Modellen in einer Woche geschafft, wofür früher ein Team aus Spitzenleuten Monate gebraucht hätte. Der älteste Angriffsweg steckte seit 2012 im Code. 2024 hatte ein Audit das Speicherproblem schon gestreift, aber keinen konkreten Angriffsweg gefunden.

Dieselbe Abkürzung steht Angreifern offen. PHP ist Open Source, und mit dem Update wird sichtbar, an welcher Stelle im Code repariert wurde. Der Patch ist damit auch eine Wegbeschreibung zur Lücke. Früher brauchten Experten Tage bis Wochen, um daraus einen funktionierenden Angriff zu bauen. Heute nehmen KI-Werkzeuge einen großen Teil dieser Arbeit ab. Das BSI schreibt es in seiner Warnung ohne Umschweife:

Wie stark sich das Zeitfenster verkürzt hat, zeigen die Messungen der Google-Tochter Mandiant. Sie erfasst, wie lange es im Schnitt dauert, bis eine bekannt gewordene Lücke ausgenutzt wird:

Wie billig der Schritt vom Fehlerbericht zum Angriff geworden ist, zeigen Studien. An der Universität von Illinois nutzte ein Agent auf Basis von GPT-4 schon 2024 13 von 15 bekannten Lücken aus, wenn er deren Beschreibung bekam. Das Forschungsprojekt CVE-Genie baute 2025 für rund die Hälfte von 841 aktuellen Lücken einen funktionierenden Exploit nach, im Schnitt für 2,77 Dollar pro Lücke.

Auch weitgehend selbstständige Angriffe sind keine Theorie mehr. Anthropic hat im November 2025 eine Spionagekampagne einer staatlich unterstützten chinesischen Gruppe offengelegt, bei der das KI-Modell Claude laut Anthropic 80 bis 90 Prozent der Arbeit selbstständig erledigte: Ziele erkunden, Schwachstellen suchen, Zugangsdaten sammeln. Rund 30 Organisationen waren das Ziel, in einigen wenigen Fällen gelang der Einbruch. Die Grenze dokumentiert der Bericht gleich mit: Die KI übertrieb ihre Funde teilweise und meldete Zugangsdaten, die gar nicht funktionierten.

Das heißt nicht, dass jetzt jede Lücke von KI ausgenutzt wird. Mandiant schreibt im aktuellen Bericht ausdrücklich, 2025 sei noch nicht das Jahr gewesen, in dem Einbrüche direkt auf KI zurückgingen; die meisten erfolgreichen Angriffe nutzen weiter menschliche und organisatorische Fehler. KI macht Angriffe nicht magisch, sondern billiger und schneller. Für kleine Betriebe ist genau das der Punkt: Die Zeit, in der eine Lücke unbemerkt blieb, weil sich der Aufwand für eine kleine Website nicht lohnte, ist vorbei. Automatisierte Scans fragen jede erreichbare Adresse ab, egal wie klein. Was KI-Agenten heute selbstständig erledigen und wo ihre Grenzen liegen, steht im Guide KI-Agenten 2026.

Die gute Nachricht steckt in derselben Geschichte. Gefunden haben PHP2Shell Verteidiger mit KI, lange bevor die Details durchsickerten. Und dieselben Werkzeuge helfen dir beim Prüfen.

Der ChatGPT-Check: Prompt und Skill zum Kopieren

Ein KI-Assistent kann deinen Server nicht prüfen, und er sollte es auch nicht. Was er gut kann: die aktuelle Lage bei deinem Hoster im Web nachschlagen, deine Angaben einordnen, die nächsten Schritte in eine sinnvolle Reihenfolge bringen und die Mail an Hoster oder Agentur formulieren. Für Nicht-Techniker ist das oft der Unterschied zwischen „wird schon passen“ und einer Antwort, die man schwarz auf weiß hat.

Du bist IT-Sicherheitsberater für kleine Unternehmen. Prüfe mit mir, ob meine Website von den PHP-Sicherheitslücken „PHP2Shell“ (CVE-2026-109618 und CVE-2026-109619, Patches vom 21.10.2026) betroffen sein kann.

Meine Angaben:
- Website: [deine-domain.de]
- System: [z. B. WordPress, Shopware, Joomla, Baukasten, weiß nicht]
- Hosting: [Hoster und Tarif, eigener Server, Agentur betreut, weiß nicht]
- PHP-Version: [z. B. 8.3.24 oder weiß nicht]
- Weitere Tools auf demselben Hosting: [z. B. Nextcloud, Webmail, keine, weiß nicht]

So gehst du vor:
1. Suche im Web die aktuell reparierten PHP-Versionen und eine Meldung meines Hosters zu PHP2Shell. Nenne Quelle und Datum.
2. Ordne meinen Fall ein: betroffen, wahrscheinlich betroffen, wahrscheinlich nicht betroffen oder unklar. Begründe in zwei Sätzen. Fehlt eine Angabe, erkläre mir, wie ich sie in zwei Minuten herausfinde.
3. Beachte: Hoster und Linux-Distributionen bauen Patches oft ein, ohne die Versionsnummer zu ändern. Eine ältere Nummer heißt nicht automatisch ungepatcht, eine fehlende Angabe nicht sicher.
4. Gib mir die nächsten drei Schritte in der richtigen Reihenfolge, verständlich für Nicht-Techniker.
5. Formuliere eine kurze Mail an meinen Hoster oder meine Agentur mit den richtigen Fragen.

Frag mich nie nach Passwörtern, Zugangsdaten oder einer vollständigen phpinfo-Ausgabe. Wenn du etwas nicht sicher weißt, sag es.

Entscheidend ist Schritt 1. Ohne Websuche antwortet das Modell aus seinem Trainingswissen, und darin kommt PHP2Shell noch nicht vor. Prüf deshalb, ob die Antwort Quellen mit Links und Datum enthält: Dann hat das Modell wirklich gesucht. Der Prompt funktioniert genauso in Claude oder Gemini.

Als Skill speichern. Wer mehrere Websites betreut, legt den Check einmal als Skill an. Skills sind wiederverwendbare Arbeitsanweisungen, die ChatGPT von selbst nutzt, wenn eine Aufgabe passt, oder auf Zuruf per @-Erwähnung. So geht es laut OpenAI: einen neuen Chat öffnen, „Bau mir einen Skill aus dieser Vorlage“ schreiben und die Vorlage unten einfügen, den Entwurf prüfen und auf „Install“ klicken. Danach genügt ein Satz wie „@php-patch-check prüf kunde-xy.de“. Skills sind noch in der Beta: In Firmen-Workspaces muss der Workspace-Owner sie in den Einstellungen freischalten, und nicht jeder Tarif bietet sie. Ohne Skill-Zugang funktioniert der Prompt oben genauso gut, du fügst ihn nur jedes Mal neu ein.

---
name: php-patch-check
description: Prüft, ob eine Website von einer bekannten PHP-Sicherheitslücke betroffen sein kann (z. B. PHP2Shell, CVE-2026-109618/109619), und liefert Einordnung, nächste Schritte und eine Mail an Hoster oder Agentur. Verwenden bei Fragen wie „Ist meine Website betroffen?“, „PHP-Lücke“, „PHP2Shell“, „Muss ich PHP updaten?“.
---

# PHP-Patch-Check

1. Frage nur nach: Domain, System (CMS oder Shop), Hosting-Art und Anbieter, PHP-Version (falls bekannt), weitere PHP-Tools auf demselben Hosting. Frage nie nach Passwörtern, Zugangsdaten oder einer vollständigen phpinfo-Ausgabe.
2. Recherchiere im Web: aktuell reparierte PHP-Versionen (php.net), Warnung des BSI, Statusmeldung des genannten Hosters. Jede Angabe mit Quelle und Datum.
3. Ordne den Fall in eine von vier Stufen ein: betroffen / wahrscheinlich betroffen / wahrscheinlich nicht betroffen / unklar, mit kurzer Begründung. Distributionen und Hoster patchen oft ohne neue Versionsnummer; ein fehlender X-Powered-By-Header beweist nichts.
4. Benenne PHP-Versionen ohne offiziellen Support (8.1 und älter) immer als Risiko und empfiehl, die Version anzuheben. Weise bei PHP 8.2 auf das Supportende am 31.12.2026 hin.
5. Gib drei nächste Schritte in Reihenfolge, für Nicht-Techniker formuliert. Bei Hinweisen auf einen erfolgten Angriff: Website vom Netz nehmen, Fachleute einschalten, Passwörter und Schlüssel erneuern, Meldepflichten (Art. 33 DSGVO, ggf. NIS2) nennen.
6. Entwirf eine kurze Mail an Hoster oder Agentur: Patch-Stand mit Datum, weitere PHP-Anwendungen, Auffälligkeiten in den Logs seit 17.10.2026, Stand der Backups.
7. Benenne Unsicherheit offen. Liefere keine Angriffs- oder Exploit-Details.

Die Forscher von Calif haben bei der Suche nach PHP2Shell übrigens genau so gearbeitet: Ihr Sprachmodell hat ein gefundenes Fehlermuster zu einer SKILL.md verallgemeinert, also zu genau diesem Format, und damit eine weitere Lücke aufgespürt.

Für Entwickler: OpenAIs offizieller Prüf-Skill. OpenAI hat zur Veröffentlichung zwei Skills für Codex bereitgestellt, seinen Programmier-Agenten. phpcheck-url prüft eine Adresse von außen, phpcheck-server die PHP-Version auf dem eigenen Server. Installiert werden beide in Codex mit $skill-installer install both skills from https://github.com/openai/php2shell-checker, aufgerufen etwa mit $phpcheck-url check https://deine-domain.de. Das Ergebnis lautet OK, VULNERABLE oder UNKNOWN. Die Grenzen schreibt OpenAI selbst dazu: Der Check liest nur die Versionsangaben aus den Antwort-Headern, „OK“ ist ein reiner Versionsvergleich, und „UNKNOWN“ heißt ausdrücklich nicht, dass die Seite gepatcht ist.

Die Grenze gilt für jeden dieser Wege: Ein Assistent bewertet, was du ihm gibst und was er im Netz findet. Ob auf deinem Server schon jemand war, sieht er nicht. Und er kann sich irren, besonders bei Hoster-Meldungen, die sich stündlich ändern. Deshalb verlangt der Prompt Quellen mit Datum, und deshalb endet er mit einer Mail an den, der es wirklich weiß. Wie du KI-Antworten generell gegenprüfst, steht im Guide KI-Halluzinationen erkennen.

Wenn du nicht sofort patchen kannst

Notfalls vom Netz nehmen. Das empfiehlt das BSI ausdrücklich, weil alle Übergangslösungen keinen vollständigen Schutz bieten. Die Stadt Mainz, die Charité und die Ruhr-Universität Bochum haben genau das getan. Eine Wartungsseite für einen Tag ist billiger als ein übernommener Server, über den danach Spam, Schadsoftware oder Phishing laufen.

Eine Web-Firewall vorschalten. Cloudflare hat seit dem 21. Oktober, 5 Uhr deutscher Zeit, Schutzregeln aktiv, laut Cloudflare automatisch auch im kostenlosen Tarif. Akamai und andere Anbieter haben nachgezogen. Das ist eine zusätzliche Schicht, kein Ersatz: Cloudflare beobachtet selbst, wie Angreifer ihre Anfragen abwandeln, um die Regeln zu umgehen, und geschützt ist nur, was tatsächlich über Cloudflare läuft.

Übergangseinstellungen für Admins. Das PHP-Projekt nennt Einstellungen, die die bekannten Angriffswege erschweren, unter anderem session.upload_progress.enabled=0, ein nicht überschreibbares memory_limit=-1 und ein niedriges post_max_size, danach alle PHP-Prozesse neu starten. Das BSI betont: alle Maßnahmen zusammen umsetzen, und auch dann nur zur Überbrückung. Wer PHP aus dem ehrenamtlich gepflegten Remi-Repository bezieht, soll laut PHP-Projekt auf Pakete der Distribution wechseln oder selbst bauen, weil dort die Updates später kommen.

Backup sichern, das getrennt vom Server liegt. Ein Backup auf demselben Server nützt nichts, wenn der Server übernommen ist. Bevor du etwas umstellst, gehört eine aktuelle Kopie an einen anderen Ort.

Ab dem 17. Oktober nachsehen. Amazon rät, mindestens ab diesem Datum nach Spuren zu suchen. Hinweise auf einen Angriff sind neue Admin-Konten, unbekannte PHP-Dateien im Upload-Ordner, auffällig viele Serverfehler oder Neustarts von PHP-Prozessen und plötzlich viel ausgehender Mailverkehr. Weil sich über die Lücken auch Speicher auslesen lässt, gehören bei jedem Verdacht Passwörter, API-Schlüssel und laufende Sitzungen erneuert. Dann gilt: Website vom Netz, Fachleute holen, nichts löschen, was später als Beweis dient.

Die Mail an Hoster oder Agentur

Viele kleine Betriebe wissen nicht genau, wer für die Website-Technik zuständig ist. Die folgende Mail klärt das nebenbei. Vier Fragen, die jede ordentliche Agentur und jeder Hoster heute beantworten kann:

Was Betriebe aus dieser Woche mitnehmen sollten

Eine Liste aller Systeme, die aus dem Internet erreichbar sind. Website, Shop, Formulare, Webmail, Cloud-Ablage, Firewall, jeweils mit Zuständigkeit und Version. Wer diese Liste hat, beantwortet die Frage „Sind wir betroffen?“ in Minuten statt in Tagen. Wie eine Software-Stückliste dabei hilft, steht im Guide SBOM.

Reaktionszeiten für kritische Patches im Vertrag. „Wir kümmern uns um Updates“ reicht nicht. Gebraucht wird eine Frist für kritische Lücken, gemessen in Stunden, und eine Rückmeldung, wenn sie eingehalten wurde.

Automatische Sicherheitsupdates, wo es geht. Bei Hostern ist das meist Standard, auf eigenen Servern eine Einstellung. Der Rest des Betriebs merkt davon nichts, außer dass Wochen wie diese ruhiger verlaufen.

Den nächsten Termin kennst du schon. Am 31. Dezember 2026 endet der Support für PHP 8.2, auf dem fast jede vierte WordPress-Seite läuft. Wer die Version jetzt ohnehin anfasst, geht direkt auf 8.4 oder 8.5 und spart sich den nächsten Notfall.

Häufige Fragen

Quellen: php.net: Security Release, 21.10.2026 · BSI-Cybersicherheitswarnung, 21.10.2026 · Amazon Threat Intelligence, 21.10.2026

Paul Niebler – Gründer der Scaly Academy. Über zehn Jahre IT-Consulting mit Schwerpunkt KI, unter anderem bei IBM und mit seinem zweiten Unternehmen Pexon Consulting. Er setzt die hier beschriebenen Werkzeuge selbst täglich ein und schreibt auf, was davon im Betrieb trägt – und was nicht. Einschätzung, keine Rechtsberatung. Paul auf LinkedIn