72 Stunden Sicherheitslücken: was patchen, was rotieren, welche Zertifikate tauschen

Zwischen Montag, dem 19., und Donnerstag, dem 22. Oktober 2026, wurden acht Vorfälle bekannt, die sehr verbreitete Infrastruktur betreffen: zwei kritische Lücken in PHP, ein Node.js-Security-Release mit zehn CVEs, eine RCE ohne Authentifizierung in GitLab mit CVSS 10.0, ein Einbruch in die Umgebungsvariablen von Railway, eine bösartige LiteLLM-Version auf PyPI und Docker Hub, die Meldung von PingCAP zu TiDB Cloud, der Widerruf von 404.607 GoDaddy-Zertifikaten und das Misstrauen gegenüber acht Zwischen-CAs von eMudhra.

Als Schlagzeilen sind das acht Meldungen. Für alle, die Server betreiben, sind es drei Aufgaben: aktualisieren, Secrets rotieren und Zertifikate prüfen. Dieser Beitrag sortiert sie so, mit den gefixten Versionen und den Befehlen zum Prüfen.

Überblick: wer was tun muss

1. Runtimes und Server aktualisieren

PHP: php2shell

Am 20. Oktober veröffentlichte ein Beitrag auf Hacker News die Kennungen zweier kritischer PHP-Lücken vor Ende des Embargos, und das Projekt zog die Veröffentlichung auf den 21. Oktober, 14:00 UTC, vor. CVE-2026-109618 ist eine Speicherkorruption, wenn PHP mitten in der Verarbeitung einer Anfrage der Speicher ausgeht; CVE-2026-109619 ist ein Use-after-free zwischen Anfragen im selben Worker. Beide lassen sich ohne Authentifizierung ausnutzen, betreffen jede Installation, die PHP über das Web ausliefert, und sind unter mod_php am schwersten: Laut Rapid7 greifen sie dort, bevor Anwendungscode läuft. Wiz hat RCE gegen WordPress, Drupal und Joomla demonstriert. Gefixt sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35; wer die Pakete seiner Linux-Distribution nutzt, sollte den Hinweis des Anbieters lesen, der oft schon früher gepatcht hat. Wenn Sie heute nicht aktualisieren können, ist die offizielle Übergangsmaßnahme session.upload_progress.enabled=0 in der php.ini oder im FPM-Pool (ini_set und .user.ini reichen nicht) und ein Neustart aller Worker. Wer das Update abgeben möchte: PHP-Sicherheitsupdate.

Node.js: Brotli und TLS-Hostnamen

Am 21. Oktober veröffentlichte Node.js zehn CVEs für die Linien 26.x, 24.x und 22.x. Die vier mit hohem Schweregrad:

• CVE-2026-111497: Schreibzugriff außerhalb der Grenzen im Brotli-Dekompressor, mit möglicher RCE. Express 5 und fetch() dekomprimieren Brotli automatisch, es genügt also, dass Ihr Server eine manipulierte komprimierte Antwort empfängt oder Ihr Code sie herunterlädt.
• CVE-2026-106069 und CVE-2026-105483: Die Prüfung des Hostnamens in einem TLS-Zertifikat lässt sich umgehen. Ein Node-Client könnte ein gültiges Zertifikat akzeptieren, das für eine andere Domain ausgestellt wurde.
• CVE-2026-105482: dns.resolve kürzt Namen, die ein NUL-Zeichen enthalten.

Gefixte Versionen: v26.12.1, v24.22.1 und v22.23.4. Node 20 und 25 sind End-of-Life und bekommen keinen Patch; wer noch darauf läuft, braucht ein Major-Update. Eine Ausnutzung ist nicht gemeldet. Wer noch auf 20 oder 25 ist und den Sprung nicht selbst machen will, findet ihn unter Node.js-Sicherheitsupdate.

node --version
# in Docker zählt das Basis-Image:
docker run --rm ihr-image node --version

NGINX: ein arbeitsreiches Jahr

NGINX hat 2026 mehrere Runden von Sicherheitshinweisen hinter sich. Im Mai kam CVE-2026-42945, “NGINX Rift”: Die KI-Plattform von DepthFirst fand den Fehler in etwa sechs Stunden, und er stammte aus Version 0.6.27 von 2008. nginx.org stuft ihn als mittel ein; die Cloud Security Alliance und Help Net Security als kritisch (9.2), und VulnCheck sah ab dem 16. Mai Ausnutzungsversuche. Behoben wurde er in 1.31.0 und 1.30.1.

Die Oktober-Runde bringt fünf weitere CVEs: CVE-2026-15176, 93479, 95101 (Request Smuggling über HTTP/3), 97629 (gefälschte TLS-Session, die die Prüfung des Client-Zertifikats umgeht) und 97205. Gefixt sind sie in 1.31.7+ und 1.30.6+. Bis zum Update empfiehlt nginx.org, $request_filename und alias zu vermeiden (15176) und in location-Blöcken mit Regex benannte statt unbenannter Captures zu verwenden (93479). Das Update und die Prüfung dieser Konfiguration deckt NGINX-Sicherheitsupdate ab.

nginx -v

GitLab self-managed: CVSS 10.0

Am 21. Oktober veröffentlichte GitLab CVE-2026-110264: Ein Integer-Overflow beim Kompilieren eines manipulierten regulären Ausdrucks erlaubt einem nicht authentifizierten Nutzer, Code auf dem Server auszuführen. Betroffen sind CE und EE ab Version 7.0 von 2014. GitLab.com und GitLab Dedicated sind bereits gepatcht; eigene Installationen müssen je nach Zweig auf 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 oder 18.11.13. Stand 22. Oktober ist keine Ausnutzung bekannt.

Neun Tage vorher, am 12. Oktober, hatte GitLab bereits eine andere 10.0 gepatcht (CVE-2026-97229, ebenfalls mit regulären Ausdrücken in CI/CD) in 19.2.8, 19.3.5 und 19.4.2, und dafür gibt es einen öffentlichen PoC. Wer das ausgelassen hat: Die neuen Versionen dieser Zweige enthalten den Fix ebenfalls. Wenn wir das Update übernehmen sollen: GitLab Self-Managed aktualisieren.

Warum so viele alte Fehler auftauchen

Zwei Fehler auf dieser Liste existierten seit über zehn Jahren: der in GitLab seit 2014 und NGINX Rift seit 2008. Bei NGINX wissen wir, wie er gefunden wurde: Ein KI-Werkzeug brauchte etwa sechs Stunden. FIRST (Forum of Incident Response and Security Teams) erwartet für 2026 rund 66.000 CVEs und führt einen Teil des Anstiegs auf KI-Werkzeuge zurück, die selbstständig nach Lücken suchen. Dieselbe Quelle weist darauf hin, dass ein anderer Teil Buchhaltung ist (Datenbanken, die mehr katalogisieren und alte Einträge nachtragen) und dass der Anteil tatsächlich ausgenutzter CVEs stabil bleibt. Für ein kleines Team heißt das: Die Liste der zu lesenden Hinweise wächst schneller als die der Notfälle, und ein Versionsinventar lohnt sich, weil es in einer Minute zeigt, ob ein Hinweis Sie betrifft.

2. Secrets rotieren, in der richtigen Reihenfolge

Drei Vorfälle auf der Liste legen Zugangsdaten offen statt Code:

• Railway bemerkte am 21. Oktober auffällige Aktivität in den Systemen, die die Umgebungsvariablen der Kunden speichern. Ein Dritter konnte auf verschlüsselte Variablen zugreifen und sie teilweise entschlüsseln. Railway hat alle Deployments pausiert und bittet darum, Zugangsdaten zu rotieren. Wie viele Kunden betroffen sind und wie die Angreifer hineinkamen, hat Railway nicht veröffentlicht.
• LiteLLM 1.107.0, am 21. Oktober auf PyPI und Docker Hub veröffentlicht, enthält einen Credential-Stealer und einen Remote-Loader, der beim Start jedes Python-Prozesses auf dem Host anspringt, nicht nur bei LiteLLM. Die Angreifer veröffentlichten die Version mit GitHub-CLI-OAuth-Tokens, die drei Entwicklern gestohlen wurden. Der GitHub-Tag enthält den Schadcode nicht, er steckt nur in den veröffentlichten Paketen. Es ist das zweite Mal in diesem Jahr.
• PingCAP meldet, dass zwischen dem 9. September und dem 7. Oktober jemand mit gestohlenen Zugangsdaten eines Service-Accounts in interne Systeme eindrang und Daten sowie Quellcode kopierte: Konto- und Projektmetadaten, Text aus dem SQL-Editor, Abrechnungsdaten und verschlüsselte Werte von API-Keys. Für die in TiDB gespeicherten Daten gibt es keine Hinweise auf Auswirkungen. Die Gruppe FulcrumSec behauptet, 10,6 TB zu haben; PingCAP hat das nicht bestätigt.

Die Reihenfolge zählt, denn wer einen Schlüssel auf einem noch kompromittierten Host rotiert, übergibt dem Angreifer nur den neuen.

1. Eindämmen. Bei LiteLLM 1.107.0 den Dienst stoppen und Host oder Container aus einem sauberen Image neu aufbauen, mit auf 1.106.2 gepinnter Version (litellm==1.106.2 in der requirements.txt oder der exakte Image-Tag, nie latest). Der Loader läuft mit jedem Python-Prozess mit, das Paket allein zu entfernen reicht also nicht.
2. Inventar machen. Auflisten, was auf diesem Host oder in diesen Variablen lag: Schlüssel von LLM-Anbietern, Cloud-Zugangsdaten, Datenbankpasswörter, CI-Tokens, Webhooks, Schlüssel des Zahlungsanbieters. Bei Railway sind das die Variablen jedes Dienstes und jeder Umgebung.
3. Mit dem beginnen, was am meisten öffnet. Zuerst Zugangsdaten mit weitreichenden Rechten (Cloud-IAM oder Root-Konten, CI/CD- und GitHub-Tokens, Datenbanknutzer), danach APIs von Drittanbietern.
4. Ausstellen, ausrollen, widerrufen. Neue Zugangsdaten erzeugen, ausrollen und die alten widerrufen. Solange die Railway-Deployments pausiert sind, legt ein Widerruf vor dem Aktualisieren der Variable den Dienst lahm, bis sie wieder laufen; bei Zahlungs- oder Cloud-Schlüsseln kostet ein kurzer Ausfall weniger als ein geleakter Schlüssel, der aktiv bleibt.
5. Nutzung des alten Schlüssels prüfen. Die Zugriffsprotokolle des Anbieters (CloudTrail, das API-Dashboard, die Datenbank-Logs) ab dem Tag des Vorfalls durchsehen.

Wenn Ihre Dienste Zugangsdaten in einem Secrets-Manager halten statt in von Hand gepflegten Variablen, wird Schritt 4 deutlich kürzer. Das gehört zu dem, was wir in Cloud- und DevOps-Projekten prüfen und beim Entwurf von APIs, die von Schlüsseln Dritter abhängen. Wenn wir die Rotation für Sie übernehmen sollen: Secrets-Rotation nach geleakten API-Keys.

3. Zertifikate: GoDaddy und eMudhra

GoDaddy hat am 21. Oktober 404.607 TLS-Zertifikate aus den Hierarchien GoDaddy und Starfield widerrufen, weil die Policy-OIDs und die CPS-URI dieser Zertifikate nicht zum veröffentlichten CPS passten (Mozilla Bug 2082703). Gestohlen wurden keine Schlüssel; das Problem ist, dass eine Website mit einem dieser Zertifikate nicht mehr lädt, wenn das Ersatzzertifikat nicht installiert wird.

eMudhra, eine indische CA, erzeugte im April 2025 acht TLS-Zwischen-CA-Zertifikate mit schwachen Schlüsseln, wegen eines Fehlers in ihrer Schlüsselzeremonie, und diese Schlüssel ließen sich aus den öffentlichen Zertifikaten zurückgewinnen. Chrome hat sie blockiert, Apple am 19. Oktober und Microsoft am 20.; Go und Node.js haben ein ausdrückliches Misstrauen veröffentlicht (das Node-Release vom 21. Oktober lehnt diese Ketten bereits ab). Bestätigte Angriffe auf Nutzer gibt es nicht.

So sehen Sie, wer Ihr Zertifikat ausgestellt hat und wann es abläuft:

echo | openssl s_client -connect ihredomain.de:443 -servername ihredomain.de 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -serial

• Enthält der issuer GoDaddy oder Starfield, melden Sie sich in Ihrem GoDaddy-Konto an, prüfen Sie, ob für dieses Zertifikat ein Ersatz ausgestellt wurde, und installieren Sie ihn auf allen Servern, Load Balancern und CDNs, auf denen das alte liegt.
• Hängt Ihre Website an einer der Zwischen-CAs von eMudhra, akzeptieren Chrome, Safari und Windows sie nicht mehr, und Sie brauchen ein Zertifikat einer anderen CA. Um die ganze Kette samt Zwischen-CAs zu sehen, suchen Sie in den i:-Zeilen (Aussteller) dieser Ausgabe nach eMudhra:

echo | openssl s_client -connect ihredomain.de:443 -servername ihredomain.de -showcerts 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:'

• Am häufigsten übersehen wird die ausgehende Richtung: Ein eigener Dienst in Node oder Go, der eine API mit Zertifikat dieser Zwischen-CAs aufruft, scheitert nach dem Update mit einem TLS-Fehler. Wenn nach dem Node-Patch Zertifikatsfehler bei ausgehenden Aufrufen auftauchen, prüfen Sie mit demselben Befehl die aufgerufene Domain.

Wenn Sie das nicht selbst machen wollen

Bei Soamee übernehmen wir diese Arbeit für die Projekte, die wir betreuen: Versionsinventar für PHP, Node, NGINX und GitLab; sofortige Gegenmaßnahmen, wo ein Update noch nicht möglich ist; Update und Prüfung; Suche nach Anzeichen einer Kompromittierung; Rotation der Secrets in der oben beschriebenen Reihenfolge und Austausch der Zertifikate. Einen unangreifbaren Server kann niemand liefern, deshalb versprechen wir ihn nicht. Sie bekommen eine Aufstellung, welche Version läuft, was geändert wurde und was noch offen ist.

Wenn Sie Server oder Deployments betreiben und nicht sicher sind, ob einer dieser acht Hinweise Sie betrifft, erzählen Sie es uns in einer kostenlosen Beratung oder schreiben Sie uns über Kontakt.

Quellen

• PHP: php.net · Rapid7 · Huntress · NCSC
• Node.js: October 2026 Security Releases
• NGINX: nginx security advisories · CSA Research Note zu CVE-2026-42945 · Help Net Security, 18. Mai 2026
• GitLab: Critical Patch Release 19.5.1 · The Hacker News zu CVE-2026-97229
• Railway: The CyberSec Guru
• LiteLLM: Wiz
• PingCAP: Security update, Oktober 2026
• GoDaddy: CyberPress
• eMudhra: The Hacker News
• CVE-Prognose 2026: Help Net Security, 15. Juni 2026