PHP-Sicherheitslücke php2shell: Was KI damit zu tun hat

Die PHP-Sicherheitslücke php2shell zählt zu den schwersten Schwachstellen der letzten Jahre: Zwei Fehler im PHP-Kern erlauben es Angreifer:innen, ohne Anmeldung Code auf Webservern auszuführen – unabhängig davon, wie sicher die eigene Anwendung programmiert ist. Gefunden und ausnutzbar gemacht wurden sie mithilfe von KI. Was das für Ihre Website, Ihren Online-Shop oder Ihre Webanwendung bedeutet und was jetzt zu tun ist, lesen Sie hier.

Stand: 22. Oktober 2026. Die Lage entwickelt sich schnell – maßgeblich ist immer die offizielle Sicherheitsmeldung auf php.net.

Was ist passiert?

Am 21. Oktober 2026 hat das PHP-Projekt außerplanmäßig die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei Lücken, die beide mit 9,2 von 10 Punkten (CVSS v4.0) als kritisch eingestuft sind:

• CVE-2026-109618 – Codeausführung über Speicherfehler: Läuft PHP während einer Anfrage in einen Speicherengpass, können interne Daten nur halb initialisiert sein. Die anschließende Aufräumroutine behandelt diese ungültigen Daten dann als gültig.
• CVE-2026-109619 – Codeausführung über veralteten Zustand: Interne Daten einer Anfrage können weiterleben, obwohl ihr Speicher bereits freigegeben wurde. Eine spätere Anfrage im selben Prozess kann diesen veralteten Zustand verwenden.

Laut PHP-Sicherheitsmeldung ist jede PHP-Installation gefährdet, die Webanfragen beantwortet – ob PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Am höchsten ist das Risiko bei mod_php: Dort reicht nachweislich eine einzige Anfrage ohne Anmeldung, und der Angriff läuft, bevor überhaupt Code der Anwendung ausgeführt wird. Laut The Hacker News können Angreifer:innen zudem Speicher des PHP-Prozesses auslesen, in dem Passwörter, Tokens, API-Schlüssel oder Zertifikate anderer Anfragen liegen können.

Brisant war auch der Ablauf: Details sickerten am 20. Oktober vor der geplanten Veröffentlichung durch, PHP zog die Updates daraufhin um einen Tag vor. Amazon Threat Intelligence registrierte laut Help Net Security bereits am 17. Oktober einen Angriffsversuch auf ein Honeypot-System – vier Tage vor der Veröffentlichung.

Welche Rolle spielte KI?

Hier wird php2shell über den Einzelfall hinaus interessant. Gefunden wurden die Lücken von Wiz Research, dem Sicherheitsunternehmen Calif und dem Codex-Security-Team von OpenAI; an der Behebung arbeiteten das PHP-Sicherheitsteam und das Gemini-Team von Google mit.

Die zugrunde liegenden Fehler steckten seit über einem Jahrzehnt im PHP-Code. Dass sie bisher niemand ausgenutzt hat, lag an der enormen Komplexität: Wiz beschreibt die nötige Angriffskette als „an der Grenze dessen, was menschliche Forscher praktisch leisten können“ – aktuelle KI-Modelle hätten diese Hürde deutlich gesenkt. Laut den Forscher:innen konnte eine einzelne Person mit KI-Unterstützung in rund einer Woche erledigen, wofür sonst ein Team Monate gebraucht hätte.

Gleichzeitig betont Calif, dass menschliche Expertise weiterhin entscheidend war: Das Wissen um die Vorgeschichte von PHP-Speicherfehlern, die bis ins Jahr 2004 zurückreicht, war der Ausgangspunkt. Aktuelle Modelle starten laut Calif nicht zuverlässig von selbst bei solchen obskuren, jahrzehntealten Ansätzen.

Was das bedeutet

KI ist in der Softwaresicherheit ein zweischneidiges Werkzeug. Dieselben Fähigkeiten, die Verteidiger:innen beim Finden von Fehlern helfen, stehen auch Angreifer:innen zur Verfügung. Für Unternehmen heißt das vor allem eines: Die Zeit zwischen dem Bekanntwerden einer Lücke und ihrer Ausnutzung schrumpft. Wer erst Tage oder Wochen später reagiert, ist zu spät – das zeigt auch der Angriffsversuch vor der offiziellen Veröffentlichung.

Was Sie jetzt konkret tun sollten

Wenn Ihre Website, Ihr Shop oder Ihre Webanwendung mit PHP läuft – und das trifft auf WordPress, Shopware, WooCommerce, Typo3, Joomla, Drupal und viele Individuallösungen zu –, gehen Sie diese Schritte durch:

1. Bestand erfassen: Wo läuft überall PHP? Denken Sie auch an Kundenportale, interne Tools, alte Microsites und Software von Drittanbietern, in der PHP versteckt ist.
2. PHP-Laufzeit aktualisieren: auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Wichtig: Ein Update von WordPress oder Ihres Shop-Systems aktualisiert nicht PHP selbst. Das kommt vom Server-Paket, vom Hoster oder aus dem Container-Image.
3. Distributionspakete richtig prüfen: Linux-Distributionen haben die Korrekturen vorab erhalten und liefern sie teils unter alt wirkenden Versionsnummern aus. Prüfen Sie im Changelog des Pakets, ob die beiden CVE-Nummern behoben sind – nicht nur die Versionsnummer.
4. Alle PHP-Prozesse neu starten: Apache, PHP-FPM und lang laufende Worker. Erst danach ist das Update wirksam.
5. Speichereinstellungen kontrollieren: Das Update führt ein neues hartes Speicherlimit ein. Prüfen Sie memory_limit und post_max_size gegen das, was Ihre Anwendung tatsächlich braucht.
6. Veraltete Versionen abschotten: PHP 8.1 und älter erhält vom PHP-Projekt keine regulären Updates mehr. Für 7.4, 8.0 und 8.1 gibt es nur minimale Quell-Backports. Solche Systeme sollten nicht offen im Internet stehen; das britische NCSC empfiehlt, nicht sofort patchbare Systeme notfalls vom Netz zu nehmen. Und: PHP 8.2 erreicht am 31. Dezember 2026 sein Lebensende.
7. Zugangsdaten erneuern, wenn Sie spät dran sind: Weil Speicherinhalte ausgelesen werden können, sollten Sie bei verspätetem Update Passwörter, API-Schlüssel und Tokens austauschen und Logdateien auf Auffälligkeiten prüfen.

Wenn ein sofortiges Update nicht möglich ist

Das PHP-Projekt nennt einige Maßnahmen, die einzelne Angriffswege erschweren, betont aber ausdrücklich: Nur das Update ist eine vollständige Lösung. Zu den Übergangsmaßnahmen zählen unter anderem:

Lücke	Übergangsmaßnahme laut PHP
CVE-2026-109618	memory_limit=-1 so setzen, dass Anwendungen es nicht überschreiben können; post_max_size niedrig halten; Größenlimits am Webserver oder Proxy erzwingen
CVE-2026-109619	session.upload_progress.enabled=0 setzen und alle Worker neu starten; unter PHP 8.5 zusätzlich fatal_error_backtraces=0

Die oft geteilte Einstellung session.upload_progress.enabled=0 blockiert nur bestätigte Angriffswege einer der beiden Lücken – gegen die andere hilft sie gar nicht.

Was wir daraus für die Softwareentwicklung lernen

php2shell ist kein Einzelfall, sondern ein Vorgeschmack. Wenn KI das Finden und Ausnutzen von Schwachstellen beschleunigt, müssen auch Betrieb und Wartung schneller werden. Drei Punkte halten wir für entscheidend:

• Updates müssen Routine sein, nicht Projekt. Eine CI/CD-Pipeline, die Software automatisch baut, testet und ausrollt, macht aus einem Notfall-Update einen Vorgang von Minuten statt Tagen. Automatisierte Tests geben die Sicherheit, dass nach dem Update noch alles funktioniert.
• KI auch für die Verteidigung nutzen. Dieselben Werkzeuge, die Angreifer:innen helfen, unterstützen beim Code-Review, beim Aufspüren riskanter Stellen und beim Überblick über Abhängigkeiten – mehr dazu in unserem Beitrag über KI im Code-Review. Die Verantwortung bleibt aber beim Menschen.
• Angriffsfläche verkleinern. Nicht jede Website braucht eine Laufzeitumgebung auf dem Server. Eine statische Website liefert nur fertige Dateien aus – ohne PHP, ohne Datenbank und damit ohne Angriffsfläche für Lücken wie php2shell. Wo dynamische Funktionen nötig sind, gehört eine laufende Projektbetreuung mit klaren Update-Prozessen dazu.

Häufige Fragen

Bin ich betroffen, wenn meine Website mit WordPress läuft?

Sehr wahrscheinlich, sofern die PHP-Version auf dem Server noch nicht aktualisiert ist. Die Lücke liegt in PHP selbst, nicht in WordPress. Fragen Sie Ihren Hoster oder Ihre IT nach der installierten PHP-Version und ob die CVE-Nummern 2026-109618 und 2026-109619 behoben sind.

Reicht es, die Website-Software zu aktualisieren?

Nein. Updates von WordPress, Shopware oder Laravel ändern nichts an der PHP-Laufzeit auf dem Server. Diese muss separat aktualisiert und anschließend neu gestartet werden.

Hat KI diese Lücke verursacht?

Nein. Die Fehler steckten seit über zehn Jahren im PHP-Code. KI hat geholfen, sie zu finden und ihre Ausnutzbarkeit nachzuweisen – und diese Forschung hat dazu geführt, dass sie jetzt geschlossen sind.

---

Sie sind unsicher, ob Ihre Website, Ihr Shop oder Ihre Webanwendung betroffen ist, oder möchten Ihre Update-Prozesse für die Zukunft absichern? Wir unterstützen bei der Website-Entwicklung ebenso wie bei individueller Softwareentwicklung und Betreuung. Sprechen Sie uns an.