Juli 30, 2026
OpenAI-Agent und Hugging Face: Was Unternehmen und Entscheider jetzt wissen sollten Ein autonomer KI-Agent von OpenAI soll während eines Cybersecurity-Tests
Am 21. Oktober 2026 hat PHP zwei kritische Schwachstellen geschlossen, die unter dem Namen PHP2Shell bekannt wurden. Noch am selben Tag nahmen das Land Baden-Württemberg, die Unikliniken Freiburg, Heidelberg und Mannheim, die Charité und weitere Einrichtungen ihre Webauftritte vorsorglich vom Netz. Das BSI stuft die Lage mit Warnstufe 3 (Orange) ein.
Für CEOs, CIOs und CISOs ist der Fall keine Frage einer einzelnen Website, denn PHP läuft unter WordPress, Typo3, Drupal, Moodle, Shopsystemen und vielen Eigenentwicklungen. Wer PHP einsetzt, und das tun die meisten Unternehmen irgendwo, ist potenziell betroffen.
Deshalb ist es entscheidend zu wissen, auf welchen Systemen in Ihrem Haus PHP läuft, in welcher Version, und wer sie betreut?
(Informationsstand: 22.10.2026, vormittags. Die Lage entwickelt sich weiter.)
Es handelt sich um zwei Speicherfehler in PHP selbst, nicht in einem einzelnen CMS. Beide lassen sich laut PHP-Sicherheitsteam ohne Anmeldung und ohne Nutzerinteraktion aus der Ferne ausnutzen. Bei Apache mit mod_php greift der Angriff, bevor Anwendungscode überhaupt läuft.
Das PHP-Sicherheitsteam bewertet beide Lücken mit CVSS 4.0 von 9,2. Ein vorab kursierender Wert von 10,0 war falsch.
Aktueller Untersuchungsstand: Amazon beobachtet inzwischen eine breite Ausnutzung durch mehrere Akteure, Cloudflare und watchTowr melden Angriffsversuche. Ein erfolgreicher Einbruch ist öffentlich bisher nicht bestätigt. Ob ein funktionierender Exploit existiert, ist umstritten: Die PHP Foundation fand zum Release keinen, Help Net Security berichtet von einem.
Die Lücken wurden zweimal unabhängig voneinander entdeckt, und beide Male mit KI-Unterstützung:
Welche der beiden CVEs auf welchen Fund zurückgeht, nennt keine der Quellen.
Die Fehler steckten lange im Code. Laut Wiz reichen die zugrunde liegenden Architekturentscheidungen mehr als zehn Jahre zurück, der älteste betroffene Code stammt aus PHP 5.4 von 2012. OpenAI schränkt ein, dass die Lücken nur nach eigenem Kenntnisstand vorher unbekannt waren.
Die Lehre daraus: KI findet Lücken, die ein Jahrzehnt lang übersehen wurden. Das hilft Verteidigern, aber dieselben Werkzeuge stehen auch Angreifern zur Verfügung. Dass trotz Embargo schon vier Tage vor dem Patch angegriffen wurde, zeigt, wie knapp das Zeitfenster geworden ist.
CVE-2026-109618 ist ein Fehler beim Umgang mit knappem Speicher. Geht PHP der Speicher aus, während die Daten einer Anfrage noch nicht vollständig vorbereitet sind, räumt PHP diese halbfertigen Daten trotzdem so auf, als wären sie gültig. Ein Angreifer kann diesen Zustand gezielt herbeiführen.
CVE-2026-109619 ist ein sogenannter Use-after-free. Ein Rest aus einer Anfrage verweist auf Speicher, der bereits freigegeben ist. Eine spätere Anfrage an denselben PHP-Prozess kann diesen Speicher ausnutzen. Zusätzlich bestätigt PHP, dass sich so Speicherinhalte auslesen lassen.
Für die Unternehmenspraxis heißt das: Eine einzige präparierte Webanfrage kann reichen, um auf dem Server eigenen Code auszuführen. Danach stehen dem Angreifer Datenbankzugänge, Konfigurationsdateien und Kundendaten offen, und der Webserver wird zum Ausgangspunkt für weitere Schritte ins Netz.
Betroffen ist jede PHP-Installation, die Webanfragen beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko besteht bei mod_php. Den ältesten betroffenen Code fand das Forschungsteam von Calif in PHP 5.4.0 (2012), also rund 14 Jahre alt. Die oft zitierten „20 Jahre“ beziehen sich nicht auf den ausnutzbaren Code, sondern auf die zugrunde liegende Fehlerklasse, die bis 2004 zurückreicht.
| Version | Status |
| 8.5.x | gepatcht ab 8.5.12 |
| 8.4.x | gepatcht ab 8.4.27 |
| 8.3.x | gepatcht ab 8.3.36 |
| 8.2.x | gepatcht ab 8.2.35 |
| 7.4 bis 8.1 | kein offizielles Release, nur minimale Source-Backports und Pakete der Distributionen |
| 5.4 bis 7.3 | End-of-Life, kein Fix von PHP |
Linux-Distributionen und LTS-Anbieter erhielten die Patches vor der Veröffentlichung. Wer PHP aus Distributionspaketen bezieht, sollte dort nach aktualisierten Paketen schauen und nicht allein auf die PHP-Versionsnummer.
BSI: Das BSI hat Warnstufe 3 (Orange) ausgerufen und rät, eine vorübergehende Trennung des Webservers vom Internet zu erwägen, wenn der Patch nicht sofort eingespielt werden kann.
Baden-Württemberg: Das Land nahm zahlreiche Webauftritte der Landesverwaltung vom Netz, darunter Seiten von Ministerien und Regierungspräsidien. Das Innenministerium stuft die Lücke als hochkritisch ein und betont, dass kein erfolgreicher Angriff vorlag. Die Systeme kommen nach dem Update durch den Landesdienstleister BITBW schrittweise zurück.
Kliniken und Hochschulen: Die Unikliniken Freiburg, Heidelberg und Mannheim nahmen ihre Websites vom Netz, in Freiburg auch die Seite der Patienten-App. Alle drei betonen, dass die Patientenversorgung nicht beeinträchtigt ist. An der Universität Freiburg waren die Lernplattform ILIAS und der Webzugang zu studentischen E-Mail-Konten betroffen.
Weitere Einrichtungen laut dpa: In Berlin die Charité, die Berliner Feuerwehr und die Berliner Tafel; FU und HU Berlin warnten vor Einschränkungen. In Brandenburg die Universität Potsdam, das Ernst-von-Bergmann-Klinikum und der Landkreis Dahme-Spreewald. In Mainz das Stadtportal mainz.de.
Eine vollständige offizielle Liste gibt es nicht.
Die Abschaltungen zeigen, wie teuer fehlende Transparenz ist. Wer nicht weiß, welche Systeme betroffen sind, muss vorsorglich alles vom Netz nehmen, was PHP sein könnte. Wer ein gepflegtes Inventar hat, patcht gezielt und bleibt erreichbar.
Hinzu kommen zwei Punkte, die über den Einzelfall hinausgehen:
Ein übernommener Webserver liefert genau die Daten, mit denen Kriminelle Geld verdienen: Kundendaten für glaubwürdiges Phishing, Mail-Zugangsdaten für Business-E-Mail-Compromise, Datenbankpasswörter für den nächsten Schritt. Ist die Website mit CRM, ERP oder Single Sign-on verbunden, wird sie zur Grenze zwischen Internet und internen Geschäftsprozessen.
Die Welle an Angriffsversuchen zeigt das typische Muster: Erst wird breit gescannt, dann werden die interessanten Treffer gezielt weiter ausgebaut. Wer heute einen Zugang hinterlässt, wird ihn später vielleicht an einen anderen Akteur verkauft sehen.
1. Bestand klären
2. Patchen
3. Überbrücken, wo ein Patch noch nicht möglich ist
4. Altversionen ersetzen
5. Auf Kompromittierung prüfen
Ein eingespielter Patch ist noch kein Nachweis, dass ein System sauber ist. Entscheidend ist, ob alle betroffenen Systeme gefunden wurden und ob vor dem Patch schon jemand drin war.
PHP2Shell trifft fast jede Organisation, die Webanwendungen betreibt. Die Einrichtungen, die gestern alles vom Netz nehmen mussten, hatten kein Patchproblem, sondern ein Inventarproblem.
Wer weiß, wo PHP läuft, patcht gezielt und bleibt erreichbar. Wer es nicht weiß, muss abschalten und kann trotzdem nicht sicher sein, ob vorher jemand eingedrungen ist.
PHP2Shell ist der Name für zwei kritische Schwachstellen in PHP (CVE-2026-109618 und CVE-2026-109619), über die Angreifer ohne Anmeldung Code auf Webservern ausführen können. Der Name lehnt sich an Log4Shell an.
Ja, wenn WordPress auf einer ungepatchten PHP-Version läuft. Die Lücke steckt in PHP selbst, nicht im CMS. Ein WordPress-Update allein schließt sie nicht.
Ein Programmfehler, bei dem Software auf Speicher zugreift, der bereits freigegeben wurde. Angreifer können diesen Speicher mit eigenen Daten füllen und so den Programmablauf übernehmen.
Das Update schließt die Lücke, aber nur nach einem Neustart der PHP-Worker. Da Angriffe schon vor dem Patch liefen, sollten Sie zusätzlich prüfen, ob das System bereits kompromittiert wurde.
Für PHP 5.4 bis 7.3 gibt es keinen Fix. Für 7.4 bis 8.1 gibt es nur minimale Backports. Diese Systeme sollten ersetzt oder vom Netz genommen werden.
OpenAI-Agent und Hugging Face: Was Unternehmen und Entscheider jetzt wissen sollten Ein autonomer KI-Agent von OpenAI soll während eines Cybersecurity-Tests
WordPress Supply-Chain-Angriff, IT Security für Unternehmen, Plugin-Sicherheit, Cybersecurity, Lieferkettenangriff Was auf den ersten Blick wie ein WordPress-Plugin-Problem wirkt, ist in
Staatlich unterstützte Cyberangriffe auf Linux-Infrastrukturen Eine neu entdeckte Linux-Malware namens „Showboat“ wurde über Jahre hinweg unbemerkt in kritischen Telekommunikationsinfrastrukturen im