Top 5 Cybersicherheit-News

Die Top 5 Cybersicherheit-News vom 30. Oktober 2026 handeln diese Woche von Annahmen, die niemand erneut geprüft hat. Ein japanischer Hosted-Desktop-Dienst hielt die gespeicherten Trading-Zugänge seiner Kunden auf Servern vor, die Angreifer erreichen konnten, nachdem eigene Mitarbeiter Schwachstellen gemeldet hatten. Eine VMware-ESXi-Lücke mit CVSS 2,7 diente als Zero-Day, um Administratoraktionen aus den Logs herauszuhalten. Eine PeopleSoft-Vertrauensregel, die die eigene Serveradresse willkommen hieß, machte aus einer CVE drei Schwachstellen. Ein im Mai in ein öffentliches Repository eingecheckter Schlüssel wurde nie widerrufen und half fünf Monate später, ein manipuliertes LiteLLM-Release zu veröffentlichen. Und Dahua-Kameras ohne offenen Port blieben über die Cloud des Herstellers erreichbar. Fünf Angriffsflächen, eine Frage an jede Führungskraft: Welche Annahme in Ihrer Umgebung hat seit der Einrichtung niemand mehr getestet?

1) Eine japanische Trading-Desktop-Cloud ging vom Netz, und die Angreifer nahmen die Broker-Konten der Kunden ins Visier

GMO Internet stellte am 20. Oktober fest, dass ein Dritter auf Kundenservern seiner Onamae.com Desktop Cloud Schadprogramme installiert hatte, einem Dienst, der Windows-Desktops für den Devisenhandel hostet. Ab dem 21. Oktober fuhr das Unternehmen die Server aller Tarife herunter und zählt 26.739 Server als potenziell betroffen, was nicht der Zahl bestätigter Einbrüche entspricht. Am 24. Oktober bestätigte es unbefugten Zugriff und den Abfluss von Kundendaten. Am 21. Oktober ging eine Erpressungsforderung über rund 8 Milliarden Yen (etwa 50 Millionen US-Dollar) ein; GMO will nicht zahlen und eröffnete am 28. Oktober ein Belohnungsprogramm von bis zu 1 Million US-Dollar für Hinweise, die zu einer Festnahme führen. In seinen Berichten bis zum 29. Oktober hatte GMO nicht mitgeteilt, wie die Angreifer eingedrungen sind.

Der Schaden reicht über GMO hinaus. Alles, was Kunden auf den Servern gespeichert hatten, kann eingesehen worden sein, darunter in der Trading-Software gespeicherte Zugangsdaten, und ab dem 21. Oktober meldeten Kunden unbekannte Trades. OANDA Japan bestätigte, dass sich ein Dritter mit ID-Passwort-Paaren in einige Kundenkonten eingeloggt hatte, die nach Einschätzung des Brokers von den GMO-Servern stammen. GMO riet Kunden, Passwörter von einem Gerät zu ändern, das nie für den Handel genutzt wurde, und alle aktiven Sitzungen zu beenden, weil manche Trading-Apps Sitzungen nach einer Passwortänderung offen halten. Die Angreifer drohten zudem mit Konten bei mehr als 70 Wertpapier- und Devisenhäusern. Am 28. Oktober teilte GMO mit, die Analyse der Kundengeräte habe bislang keine Spuren von Malware oder Ransomware ergeben.

GMOs Chef schrieb am 25. Oktober, die konzerneigenen White-Hat-Hacker hätten Verbesserungsbedarf aufgezeigt, die Reaktion habe jedoch an Tiefe und Tempo gefehlt. Die Angreifer behaupten laut ITMedia-Berichterstattung, die The Hacker News aufgreift, ein Administratorkonto sei über alle Server geteilt worden; GMO hat das nicht bestätigt. So oder so gilt die Lehre für gehostete Desktops allgemein. Ein vom Anbieter betriebener Desktop ist der Computer eines anderen, auf dem Ihre Zugangsdaten liegen, seine Schwächen werden also zu Ihren. Fragen Sie, was der Anbieter zwischen Kunden teilt und wie schnell er eigene Befunde abarbeitet, und stellen Sie sicher, dass gespeicherte Zugangsdaten schnell widerrufen werden können.

Read more on: GMO Internet Disclosure · The Register

2) Eine VMware-ESXi-Lücke mit Wertung 2,7 diente als Zero-Day, um Administratoraktionen aus den Logs herauszuhalten

Die CISA nahm CVE-2026-41709 am 28. Oktober in ihren Known-Exploited-Vulnerabilities-Katalog auf, mit einer Frist für US-Bundesbehörden bis zum 11. November, laut CISA-Katalog. Die Schwachstelle ist eine Insufficient-Logging-Lücke in VMware ESX, die es einem Administrator erlaubt, bestimmte Operationen ohne Protokollierung auszuführen. Broadcoms Advisory VMSA-2026-0006 vom 29. Juli stuft sie mit CVSS 2,7 als niedrig ein, nennt keinen Workaround und nennt Ian Barton von CrowdStrike als Melder. Laut dem CrowdStrike-Bericht zur Bedrohungslage der Rechtsbranche 2026 nutzte die China-nahe Gruppe Warp Panda sie bei Einbrüchen in US-Organisationen, darunter mehrere Anwaltskanzleien, 2025 und noch Anfang 2026 als Zero-Day. Behobene Builds sind unter anderem ESXi 8.0 U3j (ESXi80U3j-25429389) und ESXi-9.0.2.0100-25595025.

Die Lücke verschafft für sich genommen keinen Zugang; ihr Wert liegt in der Verschleierung. In der von CrowdStrike beschriebenen Kette dringen Angreifer über ein exponiertes Edge-Gerät ein, setzen sich in der Virtualisierungsschicht fest, blenden mit dieser Lücke die Logs aus und greifen dann mit gestohlenen Session-Tokens auf Microsoft-365-Umgebungen zu; in mindestens einem Fall registrierten sie ein eigenes MFA-Gerät. Für ein mittelständisches Unternehmen heißt das praktisch: Der Audit-Trail eines Hypervisors kann für die Zeit vor dem Patch lückenhaft sein, eine Untersuchung darf sich also nicht allein darauf stützen. Zuerst kommt das Patchen von ESX. MFA-Registrierungen prüfen und Cloud-Sitzungen sensibler Konten widerrufen gehört auf dieselbe Liste.

Ein Schweregrad bewertet eine Lücke isoliert, Angreifer bewerten sie nach ihrem Nutzen für die Kette. Eine 2,7, die Spuren beseitigt, kann für einen Spionageakteur mehr wert sein als eine laute kritische Lücke, die Alarm auslöst. Nach unserer Einschätzung bleibt diese Klasse von Schwachstellen in Programmen, die allein nach CVSS sortieren, am Ende der Warteschlange, und die Weiterleitung von Logs an ein externes System kann Ereignisse nicht wiederherstellen, die nie erzeugt wurden. Es bleibt eine Patch-Disziplin, die die Sichtbarkeitsschicht, also Logs, Audit-Einstellungen und Detektionswerkzeuge, so sorgfältig schützt wie die Systeme, die sie überwachen.

Read more on: Broadcom Advisory VMSA-2026-0006 · GBHackers

3) Eine PeopleSoft-CVE verbarg drei Schwachstellen, und eine Standard-Vertrauensregel erledigte den Rest

Die PeopleSoft-Lücke, die ShinyHunters seit Mai ausnutzt, besteht aus drei Schwachstellen und nicht aus einer, sagt Bobby Gould von der Zero Day Initiative, deren Team sie an Oracle gemeldet hat. Oracle behob alle drei unter einer Kennung, CVE-2026-35273 (CVSS 9,8, PeopleTools 8.61 und 8.62), in einem außerplanmäßigen Alert am 10. Juni; ZDI arbeitet nach eigenen Angaben mit Oracle an eigenen CVEs. Die Kette beginnt mit einer Server-Side Request Forgery im Integration Gateway, die eine interne Verwaltungsschnittstelle, PSEMHUB, erreicht, weil deren Standard-Datei für vertrauenswürdige Hosts die Loopback-Adresse 127.0.0.1 enthält. Mandiant ordnet die Ausnutzung vom 27. Mai bis 9. Juni, überwiegend gegen Universitäten, ShinyHunters zu.

Mandiant meldete später eine erneute Welle im September in Technologie, IT-Diensten, Gesundheitswesen, Landwirtschaft, Transport und Verwaltung, mit Dutzenden betroffenen Systemen weltweit. Angreifer umgingen Web-Application-Firewall-Regeln, die den Pfad /PSEMHUB/ blockierten, indem sie ein einzelnes Zeichen URL-codierten. ZDI beschreibt zwei Wege zur Codeausführung: eine Web Shell, die über einen Logging-Befehl geschrieben wird, und eine manipulierte XML-Datei, die beim nächsten Dienststart gelesen wird und für Standarderkennung weniger Spuren hinterlässt. Die von The Hacker News wiedergegebene Empfehlung lautet: patchen, jeden Host mit Web Shell als kompromittiert behandeln, von der PeopleSoft-Ebene erreichbare Zugangsdaten rotieren und sich auf Erpressung vorbereiten. Ob ein Patch einen bereits eingedrungenen Angreifer entfernt, ist nicht geklärt.

Eine Vertrauensprüfung, die die eigene Serveradresse durchlässt, hält nur, bis sich irgendeine Funktion dazu bringen lässt, Anfragen von diesem Server aus zu senden, und laut ZDI machte der Loopback-Standard die Prüfung wirkungslos, sobald die Forgery existierte. DIESEC hat über die Ausnutzung im Juni berichtet; neu ist, wie viel vom Gesamtbild eine einzelne CVE-Nummer verborgen hat. Nach unserer Einschätzung kann ein Patch-Tracker, der eine Kennung für drei Schwachstellen führt, nicht zeigen, ob jeder Pfad geschlossen wurde. Die Daten hinter der Anwendung monetarisiert ShinyHunters laut Mandiant durch Erpressung, der Preis eines übersehenen Pfads wird also später fällig.

Read more on: Oracle Security Alert · The Hacker News

4) LiteLLMs manipuliertes Release begann mit einem im Mai eingecheckten Schlüssel, der nie widerrufen wurde

Am 27. Mai wurde eine Konfigurationsdatei mit einem Administrator-Schlüssel für eine interne LiteLLM Agent Platform in ein öffentliches Repository eingecheckt. Die Datei wurde etwa drei Stunden später gelöscht, der Schlüssel aber nie widerrufen. Am 10. Oktober nutzte ein Angreifer ihn, um die API der Plattform zu lesen, die das GitHub-CLI-Token eines GitHub-Organisationsinhabers zurückgab. Mit Inhaberrechten griff der Angreifer über kurzlebige Workflows die Tokens zweier Maintainer ab. Am 21. Oktober wurde der Release-Workflow auf einen täuschend ähnlichen Fork umgelenkt, ein Token löste das Release aus und ein weiteres genehmigte es, und ein manipuliertes litellm 1.107.0 erschien um 11:39 UTC auf PyPI, danach auch in Container-Registries. PyPI stellte es bis 13:23 UTC unter Quarantäne.

LiteLLMs Ursachenbericht nennt die Schwachstellen. Das gestohlene Token war nicht auf wenige Repositories begrenzt, sondern der Kommandozeilen-Login des Inhabers, für den GitHub die Re-Authentifizierung bei anderen sensiblen Organisationsaktionen nicht verlangt. Eine Regel, die sonst die Freigabe durch ein an ein physisches Gerät gebundenes Konto vorsah, war früher in der Woche gelockert worden, sodass zwei beliebige Entwickler ein Release freigeben konnten. Der Angreifer umging den Branch-Schutz mit dem Inhaber-Token, löschte Run-Protokolle und setzte die Historie per Force-Push zurück. Die kompromittierten Artefakte waren etwa zwei Stunden lang verfügbar. LiteLLM widerruft nach eigenen Angaben jedes Token auf jedem internen System, und die erste Erklärung, aus Logs gestohlene Tokens, sei falsch gewesen.

Der Angriff brauchte keine Softwareschwachstelle. Er brauchte ein Geheimnis, das mehr als vier Monate gültig blieb, nachdem das Unternehmen wusste, dass es offengelegt war. LiteLLMs eigener Bericht nennt das ein starkes Beispiel für das Risiko, einen offengelegten Schlüssel nicht zu rotieren. Es ist zudem das zweite Mal in diesem Jahr, dass ein LiteLLM-Paketrelease kompromittiert wurde; DIESEC hat über den Vorfall im März berichtet. Organisationen, die KI-Gateways und ähnliche Pakete nutzen, sollten installierte Versionen festschreiben und prüfen. Für alles, was sie selbst veröffentlichen, gilt: „Aus dem Repository gelöscht“ und „widerrufen“ sind verschiedene Ereignisse.

Read more on: LiteLLM Root-Cause Report · The Hacker News

5) Dahua-Kameras ohne offenen Port blieben erreichbar, weil die Kamera sich bei der Cloud des Herstellers anmeldet

Das ukrainische CERT-UA warnte in einer am 23. Oktober veröffentlichten Meldung, dass auf Dahua-IP-Kameras und Videorekorder unbefugt zugegriffen werde. Angreifer sahen den Videostream, änderten die Gerätekonfiguration und legten eigene Konten an. Einfallstor ist Easy4IP, Dahuas Peer-to-Peer-Cloud-Zugriff, bei dem ein Gerät sich selbst bei der Cloud des Herstellers anmeldet und sich per Seriennummer registriert. CERT-UA zufolge haben die Seriennummern einen vorhersehbaren Aufbau und werden vermutlich durch massenhaftes Durchprobieren gesammelt und dann in der Cloud abgeglichen; gefährdet ist daher jedes Gerät mit aktivem P2P. Der Login hängt dann von schwachen oder bekannten Passwörtern ab oder von den alten Authentifizierungslücken CVE-2021-33044 und CVE-2021-33045 in veralteter Firmware. Die Meldung nennt weder Opfer noch Gerätezahlen noch Angreifer.

„Kein offener Port“ hieß deshalb nicht „nicht erreichbar“. CERT-UA formuliert selbst, dass die Annahme einer geheimen Seriennummer kein Grund sei, ein Gerät für sicher zu halten. Hinweise auf eine Kompromittierung sind unbekannte Konten, geänderte Einstellungen und Audit-Log-Einträge zum herstellereigenen Protokoll von der lokalen Adresse 127.0.0.1, ein Zeichen für P2P-Zugriff. Hunt.io, das im Sommer eine ähnliche Kampagne verfolgte, meldete 14.530 kompromittierte Dahua-Kameras, davon 1.923 mit einem Backdoor-Konto, das Passwortwechsel und bei den meisten Firmwares auch Werksresets übersteht; eine Verbindung zu den CERT-UA-Fällen ist nicht belegt. CERT-UA rät, P2P abzuschalten, wenn es nicht gebraucht wird, Geräte vom Internet fernzuhalten und die Firmware zu aktualisieren.

Für mittelständische Unternehmen liegt die Gefahr dort, wo niemand inventarisiert: Kameras in Werken, Lagern und Filialen, von einem Dienstleister installiert und oft nicht in IT-Bestandslisten. Das ist unsere Annahme; die Meldung sagt nicht, wie Organisationen diese Geräte verwalten. Der übergeordnete Punkt: Das Relay eines Herstellers kann ein Gerät hinter der Firewall zu einem aus dem Internet erreichbaren Dienst machen, und eine Prüfung der Firewall-Regeln zeigt das nicht. Die niederländischen Nachrichtendienste warnten im Juli, russische Staatsakteure kompromittierten IP-Kameras, um militärische Informationen zu sammeln; Kameras sind also auch ein Aufklärungswerkzeug. Geräteinventare müssen festhalten, wohin sich jedes Gerät selbst verbindet.

Read more on: CERT-UA · The Record

Wenn diese Woche etwas zeigt, dann dies:

Jeder der fünf Vorfälle dreht sich um etwas, das einmal konfiguriert und danach für vertrauenswürdig gehalten wurde. Ein gehosteter Desktop galt als abgeschottet von den darin gespeicherten Zugangsdaten. Ein Hypervisor-Log galt als vollständig. Eine Loopback-Adresse galt als freundlich. Ein offengelegter Schlüssel galt als tot, weil die Datei gelöscht war. Eine Kamera galt als privat, weil kein Port offen war. Dafür war keine neue Angriffsklasse nötig, nur jemand, der die Annahme vor ihrem Besitzer getestet hat. Die strukturelle Angriffsfläche ist die Lücke zwischen „wir haben das richtig eingerichtet“ und „wir haben es seitdem geprüft“.

Für Vorstände und CISOs lautet die nützliche Frage nicht, ob diese fünf Produkte im Bestand sind. Sie lautet, welche Zusicherungen, etwa Isolation beim Anbieter, Vollständigkeit der Logs, Standard-Vertrauenslisten, Schlüsselwiderruf und Netzwerkerreichbarkeit, einen benannten Verantwortlichen und ein Datum der letzten Prüfung haben und welche allein auf der ursprünglichen Einrichtung beruhen. Eine kurze Liste solcher Annahmen, geprüft wie ein Risikoregister, beantwortet das zu einem Bruchteil der Kosten eines Vorfalls.

Wenn Ihnen eine dieser Annahmen aus der eigenen Umgebung bekannt vorkommt, bespricht das DIESEC-Team sie gerne mit Ihnen, erreichbar über unsere Kontaktseite.