Black October 2026: Triage-Leitfaden für PHP2Shell, LiteLLM und eMudhra

Neu bei PHP2Shell? Beginnen Sie hier. Dieser Leitfaden ergänzt unseren ausführlichen Beitrag PHP2Shell: Patch-Plan für zwei kritische PHP-Sicherheitslücken. Dort steht, was PHP behoben hat, wie Sie jede Laufzeitumgebung patchen und was Sie tun, wenn Sie heute nicht aktualisieren können. Lesen Sie ihn zuerst und kommen Sie dann hierher zurück, um alles andere zu prüfen, was in derselben Woche bekannt wurde.

Die kurze Antwort

„Black October” ist der inoffizielle Name für eine Häufung voneinander unabhängiger Sicherheitsmeldungen, die zwischen dem 19. und 22. Oktober 2026 öffentlich wurden. Berichte, die diese Behauptung geprüft haben, fanden keine Belege für eine Koordination der Vorfälle. Die nützliche Frage ist, welche davon Ihre Systeme betreffen: PHP2Shell, das bösartige Release LiteLLM 1.107.0, die Schlüssel der Zertifizierungsstelle eMudhra sowie die Fixes für Brotli in Node.js und für GitLab.

Das Wichtigste in Kürze

• Nutzen Sie die 60-Sekunden-Triage unten, um zu sehen, was Sie betrifft, und bearbeiten Sie dann jeden Punkt mit denselben vier Fragen: Betroffenheit, Zeitfenster, Reichweite und Nachweis.
• Das Risiko bei LiteLLM und eMudhra steckt in Lockfiles, CI-Logs, Trust Stores und langlebigen Secrets. Die Prüfungen unterscheiden sich daher von einem normalen Patch.
• Der Großteil der Triage lässt sich automatisieren, wobei Menschen alles freigeben, was die Produktion verändert.

Bin ich betroffen? Eine Triage in 60 Sekunden

Wenn Sie Folgendes betreiben oder nutzen …	Was Sie wissen sollten	Was zu tun ist
PHP in einer Laufzeitumgebung, die Webanfragen bedient (PHP2Shell, CVE-2026-109618 und CVE-2026-109619)	Am 21. Oktober behoben in 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und älter erhalten keine offiziellen Fixes (siehe die Hinweise zum Supportende von 8.1 in unserem Patch-Plan). PHP-Sicherheitshinweis	Jede Laufzeitumgebung patchen, auch in Containern und in Software, die PHP mitbringt; neu starten und prüfen; Logs bis zum 17. Oktober zurück auswerten
LiteLLM (litellm==1.107.0)	Am 21. Oktober auf PyPI von 11:39 bis 13:23 UTC und auf Docker Hub von 11:46 bis 14:20 UTC verfügbar, aus der GitHub Container Registry bis 13:51 UTC entfernt (Vorfallbericht)	Lockfiles, CI-Logs und Registry-Pulls prüfen. Nicht einfach deinstallieren und pip nicht zuerst ausführen. Neu aufbauen und alles rotieren, was der Host erreichen konnte
Zertifikate, die auf die eMudhra-Root zurückgehen (emSign ECC Root CA - G3)	Google und Mozilla haben die Root vorsorglich entfernt. Die Entfernung in Chrome war für den 27. Oktober vorgesehen (Google)	Zertifikatsketten prüfen, betroffene Zertifikate neu ausstellen und Trust Stores in Betriebssystemen, Laufzeitumgebungen und Images aktualisieren
Node.js (Brotli, CVE-2026-111497)	Am 21. Oktober behoben in 22.23.4, 24.22.1 und 26.12.1. Node.js 20 und älter erhalten keinen Fix (Node.js-Sicherheitshinweis)	Node.js aktualisieren und andere Werkzeuge prüfen, die Brotli mitbringen
Selbst betriebenes GitLab (CVE-2026-110264)	CVSS 10.0, am 21. Oktober in sieben Releases behoben (GitLab-Release-Beitrag). Server, die am 12. Oktober gepatcht wurden, sind weiterhin angreifbar	Auf das gefixte Release Ihres Zweigs aktualisieren
Jede Plattform, die in einer Datenpannen-Meldung eines Anbieters genannt wird	Manche Anbieter, etwa Railway, haben alle Kunden gebeten, ihre Secrets zu rotieren	Secrets bei jedem Werkzeug rotieren, das einen Vorfall gemeldet hat, die sensibelsten zuerst

Jede Sicherheitsmeldung mit vier Fragen prüfen

Die Namen der Vorfälle ändern sich. Die Methode nicht. Beantworten Sie diese vier Fragen für jede Meldung und halten Sie die Nachweise im Ticket fest.

Frage	Was Sie herausfinden	Festzuhaltender Nachweis
1. Betroffenheit: Betreiben wir es, wo und in welcher Version?	Betroffene Systeme	Inventarexport, Treffer in Lockfiles, Image-Digests
2. Zeitfenster: Wann war es ausnutzbar, und wann waren wir angreifbar?	Zu untersuchender Zeitraum	Release-Zeitfenster, Zeitstempel von Deployments und Pulls
3. Reichweite: Was hätte es erreichen können, wenn es gelaufen wäre?	Mögliches Schadensausmaß	Vom Host erreichbare Zugangsdaten, Berechtigungen der CI-Rollen
4. Nachweis: Was zeigt, ob wir sauber oder kompromittiert sind?	Eine belastbare Schlussfolgerung	Log-Abfragen, Dateiprüfungen, Nachweise über Neuaufbauten

Dann handeln, prüfen und dokumentieren. Gehen Sie mit dem Zeitfenster sorgfältig um: Der Tag, an dem eine Meldung öffentlich wird, ist nicht der Tag, an dem die Angriffe begonnen haben. Lesen Sie, warum das Zeitfenster für Patches geschrumpft ist, um zu sehen, wie sich dieser Abstand verändert hat.

PHP2Shell: Prüfen, ob die Lücke überall geschlossen ist

Unser Patch-Plan behandelt die gefixten Versionen, Übergangsmaßnahmen und Anzeichen einer Kompromittierung. Nutzen Sie nach dem Patchen diese Checkliste:

1. Gleichen Sie gepatchte Laufzeitumgebungen mit Ihrem Inventar ab, nicht mit Ihrem Gedächtnis. Was fehlt, ist der Ort, an dem der nächste Vorfall beginnt.
2. Prüfen Sie Software, die PHP mitbringt. Das NCSC-NL-Repository listet betroffene Herstellerprodukte, und der CERT-EU-Sicherheitshinweis 2026-018 verweist darauf.
3. Prüfen Sie PHP-Builds für Windows. Laut der Mitteilung von PHP vom 26. Oktober wurden die Windows-Builds mit einem gefixten Brotli neu gebaut, weil der Decoder über cURL erreichbar ist, wenn die automatische Dekomprimierung aktiv ist. Siehe die Mitteilungen von PHP.
4. Schließen Sie die Log-Auswertung ab. Halten Sie fest, welchen Zeitraum Sie geprüft haben und mit welchem Ergebnis.

Wenn sich ein System heute nicht patchen lässt, empfehlen CISA und NSA übereinstimmend, es vom Netz zu nehmen, bis es gepatcht werden kann. Die Aktualisierung von CERT-EU vom 23. Oktober nennt außerdem eine dritte PHP-Sicherheitslücke, CVE-2026-115560, zu der es noch keine öffentlichen Details gibt. Prüfen Sie den Hinweis daher erneut.

LiteLLM 1.107.0: Sicher prüfen und aufräumen

Der Vorfallbericht von LiteLLM nennt die Zeitfenster aus der Triage-Tabelle. Wiz beschreibt einen Credential Stealer, der es auf Browser-, Cloud- und KI-Secrets abgesehen hat, und beobachtete, dass gestohlene AWS-Rollen-Zugangsdaten etwa 4,5 Stunden nach der Exfiltration ausprobiert wurden. Die folgende Reihenfolge prüft die Betroffenheit, ohne etwas auszuführen, das die Schadsoftware starten könnte.

Schritt 1: Quellcode und Lockfiles durchsuchen (ohne Python oder pip).

# Requirements-style pins across a repo or monorepo
grep -rn "litellm==1.107.0" --include="requirements*.txt" --include="*.in" .

# poetry.lock and uv.lock: show the version line after each litellm entry
grep -rn -A1 'name = "litellm"' --include="poetry.lock" --include="uv.lock" .

Schritt 2: CI- und Registry-Logs prüfen auf Installationen oder Image-Pulls innerhalb der Zeitfenster, einschließlich nicht gepinnter Schritte wie pip install litellm und Images mit dem Tag latest.

Schritt 3: Wenn es gelaufen ist, nicht mit pip install beginnen. LiteLLM warnt, dass jeder Python-Start in einer betroffenen Umgebung, auch pip, die Schadsoftware erneut ausführt. Das Deinstallieren des Pakets bereinigt den Host also nicht. Löschen Sie zuerst die abgelegten Dateien, ohne Python zu starten, und bauen Sie die Umgebungen dann von Grund auf neu. Die Dateiliste steht im Vorfallbericht.

Schritt 4: Nach Reichweite rotieren, nicht nach Verdacht. Beginnen Sie mit allem, was der Host lesen konnte: Cloud-Schlüssel, Schlüssel von KI-Anbietern, CI-Secrets, Tokens und Umgebungsdateien.

So wird das nächste vergiftete Release zum Nicht-Ereignis

Das PyPI-Paket war weniger als zwei Stunden verfügbar, die Container-Tags blieben aber bis 14:20 UTC kompromittiert. Eine kurze Wartezeit vor neuen Versionen hätte das PyPI-Zeitfenster vermieden. Das ist unsere Schlussfolgerung, LiteLLM behauptet es nicht.

// renovate.json: wait a day before adopting a brand-new release
{
  "packageRules": [
    { "matchDatasources": ["pypi", "npm"], "minimumReleaseAge": "1 day" }
  ]
}

• Pinnen und prüfen: Pinnen Sie exakte Versionen, nutzen Sie pip install --require-hashes und pinnen Sie Container-Images per Digest, nicht per Tag.
• Veröffentlichung an die exakte Quelle binden: In der korrigierten Angriffskette von LiteLLM wurde der Release-Workflow auf einen täuschend ähnlichen Fork umgeleitet. Binden Sie Trusted Publishing an das exakte Repository, den Workflow und die Umgebung.
• Freigaben eingeschaltet lassen: LiteLLM weist darauf hin, dass eine strenge Release-Freigabe in jener Woche gelockert worden war. Erfassen Sie jede Lockerung mit einem Ablaufdatum.

eMudhra: Zertifikate und Trust Stores prüfen

Google berichtet, dass acht Zwischenzertifikate (sechs für TLS, zwei für Code Signing) unter der emSign ECC Root CA - G3 blockiert wurden und dass Google und Mozilla die Root vorsorglich entfernt haben. Die Entfernung in Chrome sollte die Geräte am Morgen des 27. Oktober erreichen, pazifischer Zeit. Gehen Sie also davon aus, dass Ketten zu dieser Root im aktuellen Chrome bereits scheitern.

Schritt 1: Zertifikate finden, die auf die Root zurückgehen.

# Replace example.com with each public hostname you operate
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | grep -i -E "emsign|emudhra"

Keine Ausgabe heißt, dass die ausgelieferte Kette eMudhra nicht erwähnt. Jeder Treffer heißt: bei einer anderen Zertifizierungsstelle neu ausstellen.

Schritt 2: Die Orte prüfen, an denen sich Zertifikate verstecken: Load Balancer, CDNs, API-Gateways, interne Dienste, Code-Signing-Pipelines und Endpunkte von Partnern.

Schritt 3: Trust Stores aktualisieren, nicht nur Browser. Betriebssysteme, Laufzeitumgebungen, Container-Basis-Images und Werkzeuge mit eigenen Zertifikatslisten brauchen das Update. Go, Mozillas NSS, Python-Werkzeuge, Java und Linux-Distributionen haben Updates ausgeliefert.

Schritt 4: Images neu bauen, auf aktualisierten Basis-Images, damit keine alten Trust Stores zurückbleiben.

Node.js Brotli und GitLab: Schnelle Prüfungen

Node.js. CVE-2026-111497 ist ein Schreibzugriff außerhalb der Speichergrenzen im mitgelieferten Brotli-Decoder. Prüfen Sie, was Sie betreiben:

node -v
node -p "process.versions.brotli"   # the Brotli version bundled with this build

Die gefixten Versionen sind 22.23.4, 24.22.1 und 26.12.1. Die Proof-of-Concepts kamen in zwei Schritten. Ein erster öffentlicher am 22. Oktober brachte den Prozess meist nur zum Absturz, und am selben Tag zeigte Imperva Codeausführung auf dem offiziellen Linux-arm64-Image von Node.js 24.22.0, wofür mehrere Versuche nötig waren. Imperva nannte es Node2Shell; die Analyse von Aikido zeigt, dass es auch als HTTP2Shell kursiert. Beide Namen meinen dieselbe CVE. Andere Software, die Brotli mitbringt, braucht die Bibliotheksversionen 1.0.10, 1.1.1 oder 1.2.1.

GitLab. CVE-2026-110264 ist ein Integer-Überlauf im Compiler für reguläre Ausdrücke von GitLab, der einem nicht angemeldeten Angreifer Codeausführung ermöglichen kann. Betroffen sind selbst betriebene CE- und EE-Instanzen ab Version 7.0, GitLab.com ist bereits gepatcht. Die gefixten Releases sind 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13. Analysen von Dritten führen den Einstiegspunkt auf das Rendern einer .org-Datei zurück. Server, die am 12. Oktober wegen CVE-2026-97229 gepatcht wurden, sind weiterhin angreifbar. Aktualisieren Sie also erneut.

Welche Secrets Sie zuerst rotieren sollten

Die Rotation gerät ins Stocken, weil niemand weiß, was erreichbar ist. Ordnen Sie die Arbeit nach Reichweite:

Priorität	Art der Zugangsdaten	Warum zuerst
1	Alles, was ein betroffener Host oder Prozess lesen konnte	Direkte Betroffenheit
2	Tokens mit Owner- und Admin-Rechten, besonders in Automatisierungen	Ein Token öffnet alles
3	Secrets für CI/CD und Release-Pipelines	Damit kann Software unter Ihrem Namen veröffentlicht werden
4	Langlebige Schlüssel ohne Ablaufdatum oder Verantwortlichen	Am schwersten einzuschätzen
5	Zugangsdaten für jede Plattform, die einen Vorfall gemeldet hat	Manche Anbieter, etwa Railway, haben alle Kunden gebeten zu rotieren

Führen Sie ein Secrets-Register (Zugangsdaten, Verantwortlicher, Geltungsbereich, Erstellung, Ablauf, Speicherort). Es ist das Gegenstück zum Inventar der PHP-Laufzeitumgebungen, nur für Zugangsdaten.

Triage mit agentischen Workflows automatisieren

Der Großteil dieser Arbeit wiederholt sich: Sicherheitshinweis lesen, Versionen und Zeitfenster herausziehen, mit dem Inventar abgleichen, Tickets anlegen und Nachweise festhalten. Hier verdient agentische Automatisierung ihren Platz, solange sie klar begrenzt bleibt.

triage_agent:
  mode: read_only              # reads inventory and advisories, writes tickets
  grounded_in: [primary advisories, lockfiles, registry, cert scans, secrets register]
  requires_human_approval: [patch_production, rotate_secret, revoke_token, take_offline]
  never: [run_python_or_pip_on_suspected_host]   # encodes LiteLLM's cleanup guidance
  audit_log: every_step

Automatisieren: Sicherheitshinweise in Datensätze zu betroffenen Versionen übersetzen, Lockfiles und Zertifikatsketten durchsuchen, Nachweisberichte erstellen, Tickets nachverfolgen und nach dem Fix erneut prüfen.

Mit menschlicher Freigabe: Produktion patchen, Zugangsdaten rotieren oder widerrufen, einen Dienst vom Netz nehmen, einen Vorfall für abgeschlossen erklären und mit Kunden oder Aufsichtsbehörden sprechen.

Ein Sieben-Tage-Plan zur Vorbereitung

Tag	Schwerpunkt	Ergebnis
1	Inventar der PHP-Laufzeitumgebungen, Container-Basis-Images und Abhängigkeiten	Eine Liste mit einem Verantwortlichen pro Eintrag
2	PHP und Node.js patchen und neu starten; prüfen, was Anfragen bedient	Geprüfte Versionen, dokumentiert
3	LiteLLM-Prüfung über Lockfiles, CI- und Registry-Logs	Sauber oder betroffen, mit Nachweis
4	Prüfung von Zertifikaten und Trust Stores	Liste der neu auszustellenden Zertifikate; aktualisierte Stores und Images
5	Secrets-Register und priorisierte Rotation	Rotationsprotokoll mit Verantwortlichen und Ablaufdaten
6	Die wiederholbaren Prüfungen automatisieren	Geplante Scans und automatisch angelegte Tickets
7	Dauerhafte Verantwortliche festlegen	Runbook und Bereitschaftsweg für die nächste Meldung

Die Regel für die Zukunft

Stellen Sie jeder Sicherheitsmeldung dieselben vier Fragen: Betroffenheit, Zeitfenster, Reichweite und Nachweis. Halten Sie die Nachweise fest, automatisieren Sie die Prüfungen und lassen Sie einen Menschen alles freigeben, was die Produktion verändert. Ein Team, das schon so arbeitet, verbringt seine erste Stunde mit Antworten, nicht mit der Frage, wo es anfangen soll.

So unterstützt Incresco

Incresco ist Claude- und Storyblok-Partner. Wir bauen und betreuen PHP- und Laravel-Anwendungen, Cloud-Systeme und KI-Agenten. Für Black October können wir Ihnen helfen:

• Die Triage mit Ihnen durchführen: Inventar, Prüfungen der Betroffenheit und Nachweise für PHP2Shell, LiteLLM, eMudhra, Node.js und GitLab.
• Die Lücken schließen: Laufzeitumgebungen und Container patchen und prüfen, Trust Stores aktualisieren und Secrets nach Priorität rotieren, mit unseren Teams für Cloud und DevOps und individuelle Plattformentwicklung.
• Die Automatisierung bauen: agentische Triage-Workflows auf Basis Ihres Inventars, mit Freigabeschritten und Audit-Logs, über unseren Bereich KI-Transformation.

Ihr kostenloses 30-minütiges Erstgespräch: der Ablauf

Das Gespräch ist eine Arbeitssitzung rund um Ihren Stack, mit einem Incresco-Engineer aus unserer Arbeit an PHP, Cloud und agentischer Automatisierung.

Schritt	Was passiert	Was Sie bekommen
1. Wir hören zuerst zu (etwa 5 Minuten)	Wir lernen, was Sie betreiben, wie Ihr Team ausliefert und patcht und was Sie an den Oktober-Meldungen am meisten beunruhigt	Ein gemeinsames Bild Ihres Setups und Ihrer Prioritäten, in Ihren Worten
2. Wir gehen Ihre Systemlandschaft durch (etwa 10 Minuten)	Wir gehen mit Ihnen Betroffenheit, Zeitfenster, Reichweite und Nachweis für PHP2Shell, LiteLLM, eMudhra, Node.js und GitLab durch, anhand Ihrer Laufzeitumgebungen, Pipelines, Zertifikate und Secrets	Ein klarer Blick darauf, was betroffen ist und wo die größten Risiken liegen
3. Wir arbeiten ein Beispiel live durch (etwa 10 Minuten)	Wir nehmen Ihren risikoreichsten Punkt und arbeiten ihn durch: die auszuführende Prüfung, die festzuhaltenden Nachweise, die Reihenfolge der Fixes und wo Automatisierung übernehmen würde	Ein konkreter Triage-Entwurf, mit dem Sie sofort arbeiten können
4. Wir vereinbaren das weitere Vorgehen (etwa 5 Minuten)	Wir empfehlen, was Sie zuerst tun sollten, wer welchen Schritt verantwortet und ob sich Automatisierung jetzt lohnt	Ein kurzer, priorisierter Plan, der Ihnen gehört, ohne Verpflichtung

Was Sie mitbringen können (optional): eine grobe Liste Ihrer Laufzeitumgebungen, Pipelines, öffentlichen Zertifikate und der Orte, an denen Secrets liegen. Wenn Sie nichts vorbereitet haben, fangen wir gemeinsam bei null an.

Buchen Sie ein kostenloses 30-minütiges Erstgespräch

Häufig gestellte Fragen

Was ist Black October 2026?

Eine inoffizielle Bezeichnung für eine Häufung von Sicherheitsmeldungen, die zwischen dem 19. und 22. Oktober 2026 öffentlich wurden. Es ist weder eine CVE noch der Titel eines Behördenhinweises. Die Vorfälle waren voneinander unabhängig, und keiner der von uns ausgewerteten Berichte zeigt eine Koordination.

Betrifft Black October 2026 meine Systeme?

Möglicherweise, wenn Sie PHP-Webdienste, Node.js, selbst betriebenes GitLab, LiteLLM oder Zertifikate betreiben, die auf die eMudhra-Root zurückgehen. Nutzen Sie die Triage-Tabelle oben und halten Sie für jede Antwort den Nachweis fest.

Wo fange ich bei PHP2Shell an?

Beginnen Sie mit unserem Patch-Plan und nutzen Sie dann die Checkliste hier, um zu bestätigen, dass Ihre gesamte Systemlandschaft abgedeckt ist.

Wie prüfe ich, ob ich LiteLLM 1.107.0 installiert habe?

Durchsuchen Sie Ihre Lockfiles mit den grep-Befehlen oben und prüfen Sie dann CI- und Registry-Logs gegen die veröffentlichten Zeitfenster. Starten Sie weder Python noch pip auf einem Host, auf dem es gelaufen sein könnte.

Kann ein KI-Agent die Sicherheits-Triage übernehmen?

Er kann die sich wiederholenden Teile übernehmen: Sicherheitshinweise lesen, Versionen abgleichen, Nachweise erstellen und Tickets anlegen. Behalten Sie eine menschliche Freigabe für alles, was die Produktion verändert.

Verwandte Artikel

• PHP2Shell: Patch-Plan für zwei kritische PHP-Sicherheitslücken
• API-Design für KI-Agenten: Leitfaden zur Agent Experience (AX)

Quellen: PHP-Sicherheitshinweis; CERT-EU 2026-018; NCSC-NL php2shell; SecureWorld; LiteLLM-Vorfallbericht; Wiz; Google Chrome and Android Security; Node.js; Sysdig; Aikido; Tanium; GitLab; SecurityToday.