Seit dem 21. Oktober 2026 ist PHP2Shell das Thema in jedem Security-Kanal. Wir fassen hier kurz zusammen, worum es geht, und zeigen dann, was für unsere Kunden tatsächlich zählt: Wie Goldoak Spectacles die Angriffe automatisch abgewehrt hat und wie wir für jedes überwachte System klären konnten, ob PHP2Shell ausgenutzt wurde oder nicht.
PHP2Shell kurz erklärt: CVE-2026-109618 und CVE-2026-109619
PHP2Shell ist der Name für zwei Sicherheitslücken in PHP, die am 21. Oktober 2026 mit den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 geschlossen wurden. Beide sind Speicherfehler in der Behandlung von Out-of-Memory-Situationen während eines Requests. Ein Angreifer braucht keinen Login: Ein präparierter HTTP-Request genügt, um auf einem ungepatchten Server eigenen Code auszuführen oder Speicherinhalte wie Passwörter und API-Keys auszulesen.
Betroffen ist jede PHP-Anwendung, die aus dem Internet erreichbar ist, also WordPress, Typo3, Nextcloud, Laravel, Shopsysteme und alles, was auf PHP-FPM, PHP-CGI oder Apache mit PHP läuft. PHP 8.1 und älter bekommen keinen Fix mehr. Ausnutzungsversuche werden seit dem Tag der Veröffentlichung gemeldet.
Quellen:
Die einzige echte Lösung ist das Update auf eine gepatchte Version. Die Frage, die sich jedes Unternehmen stellt, lautet aber: Was ist in der Zeit zwischen Bekanntwerden und Patch passiert?
So hat Goldoak Spectacles unsere Kunden automatisch gegen PHP2Shell verteidigt
Goldoak Spectacles überwacht die Server unserer Kunden rund um die Uhr mit einem Agent, der jeden Prozessstart, jede Dateiänderung und jede Netzwerkverbindung sieht. Für PHP2Shell haben wir am Tag der Veröffentlichung gezielte Erkennungsregeln auf alle Kundensysteme ausgerollt. Sie schlagen an, sobald ein PHP-Prozess etwas tut, das er im Normalbetrieb nie tut: eine Shell öffnen, Werkzeuge nachladen, eine neue PHP-Datei im Webroot ablegen, einen Cronjob oder ein Benutzerkonto anlegen.
Erkennung allein reicht nicht. Spectacles isoliert ein betroffenes System bei einem Treffer automatisch vom Netzwerk. Der Server bleibt an und bleibt mit unserer Plattform verbunden, aber der Angreifer kommt nicht weiter: keine Ausbreitung auf andere Systeme, kein Datenabfluss, keine Ransomware. Zwischen Erkennung und Isolation vergehen Minuten, kein menschlicher Eingriff ist nötig.
Für unsere Kunden hiess das: Auch Server, die noch nicht gepatcht waren, wurden nicht zum Einfallstor ins Unternehmen. Der Patch konnte in Ruhe eingespielt werden, statt im Wettlauf gegen den Angreifer. Und das Ganze funktioniert ohne eigene Security-Abteilung, denn die Regeln, die Überwachung und die Reaktion kommen von uns.
Kurz gesagt: Goldoak Spectacles schützt vor PHP2Shell, indem es die Angriffsspuren auf dem Server erkennt und das betroffene System automatisch isoliert, bevor aus einer PHP-Lücke ein Sicherheitsvorfall wird.
So haben wir geklärt, ob unsere Kunden von PHP2Shell betroffen waren
Patchen schliesst die Tür. Es sagt aber nichts darüber, ob vorher jemand drin war. Genau das wollten unsere Kunden wissen, und genau das konnten wir beantworten.
Weil Spectacles alle Prozess-, Datei- und Netzwerkereignisse fortlaufend speichert, haben wir für jedes überwachte System rückwirkend geprüft, ob seit Bekanntwerden der Lücke typische Spuren einer Ausnutzung vorliegen:
- Hat ein PHP-Prozess eine Shell oder ein Download-Tool gestartet?
- Wurden PHP-Dateien im Webroot angelegt oder verändert, die nicht aus einem Deployment stammen?
- Gab es ungewöhnliche ausgehende Verbindungen aus dem PHP-Prozess?
- Wurden neue Cronjobs oder Konten angelegt?
Das Ergebnis ist eine klare Aussage pro System: nicht betroffen oder betroffen. Für nicht betroffene Systeme haben unsere Kunden einen belastbaren Nachweis gegenüber Geschäftsleitung, Auditoren und eigenen Kunden. Für betroffene Systeme liegt der vollständige Ablauf vor, von Request über Prozess bis Datei und Verbindung, als Grundlage für Bereinigung und, falls nötig, Meldung an Betroffene und Behörden.
Ohne eine solche Aufzeichnung bleibt nur Raten. Webserver-Logs zeigen vielleicht einen auffälligen Request, aber nicht, was danach auf dem System passiert ist. Und die meisten Logs sind nach wenigen Tagen rotiert.
Kurz gesagt: Mit Goldoak Spectacles lässt sich für jeden Server nachweisen, ob PHP2Shell ausgenutzt wurde, weil alle relevanten Ereignisse seit dem Tag der Veröffentlichung durchsuchbar sind.
Häufige Fragen zu PHP2Shell
Ist PHP2Shell gefährlich? Ja. Die Lücke ist ohne Login aus dem Internet ausnutzbar, erlaubt Codeausführung auf dem Server und kann Passwörter und API-Keys aus dem Speicher offenlegen. Sie gehört zu den kritischsten PHP-Lücken der letzten Jahre.
Welche PHP-Versionen sind sicher? PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Alles darunter ist verwundbar, PHP 8.1 und älter bleibt ohne Fix.
Was muss ich sofort tun? Patchen, danach Datenbankpasswörter, API-Keys und Tokens auf öffentlich erreichbaren PHP-Systemen rotieren, und prüfen, ob in den Tagen vor dem Patch bereits ein Angriff stattgefunden hat.
Wie finde ich heraus, ob ich betroffen war? Nur über eine Aufzeichnung dessen, was auf dem Server passiert ist: Prozessstarts, Dateiänderungen, Netzwerkverbindungen. Goldoak Spectacles liefert genau diese Aufzeichnung und beantwortet die Frage pro System.
Schützt eine WAF vor PHP2Shell? Sie hilft, ersetzt den Patch aber nicht. Umgehungen der WAF-Regeln wurden bereits beobachtet.
Fazit
PHP2Shell zeigt, worauf es bei einer kritischen Lücke ankommt: nicht nur schnell patchen, sondern wissen, was in der Zwischenzeit passiert ist, und sicher sein, dass ein einzelner verwundbarer Server nicht das ganze Unternehmen gefährdet. Beides hat Goldoak Spectacles für unsere Kunden geleistet.
Betreibst du PHP-Systeme und weisst nicht, ob sie betroffen waren? Kontaktiere uns, wir prüfen deine Systeme auf Spuren von PHP2Shell. Bei einem akuten Vorfall ist unser Incident-Response-Team rund um die Uhr erreichbar.