Was passiert ist

Am 3. November 2026 hat mSeven Software, der US-Hersteller des Passwort-Managers mSecure, eine E-Mail an aktuelle und ehemalige Kunden verschickt. Laut The Register, dem die Mail vorliegt, hat das Unternehmen „vor Kurzem verdächtige Aktivität“ im Zusammenhang mit der App bemerkt. Es habe eine Untersuchung begonnen, „Schritte zur Eindämmung“ unternommen und externe Sicherheitsfachleute hinzugezogen.

Nutzer sollen „umgehend“ alle vertraulichen Daten schützen, die in mSecure gespeichert sind. Als mögliche Schritte nennt die Mail: Passwörter ändern, Zwei-Faktor-Authentifizierung (2FA, also der zweite Anmeldeschritt per Code oder App) zurücksetzen oder neu einrichten und bestehende Passkeys entfernen. Passkeys sind kryptografische Anmeldeschlüssel, die das Passwort ersetzen.

Was die Mail nicht sagt, ist die längere Liste. Laut The Hacker News und heise fehlen:

• worin die verdächtige Aktivität bestand und wann sie stattfand,
• ob sie beendet ist,
• ob Tresor-Daten oder die Schlüssel dazu betroffen sind,
• welche Systeme betroffen sind und wie viele Kunden,
• ob die Sync-Variante (mSecure Cloud, Dropbox, iCloud, WLAN) eine Rolle spielt,
• ob sich der 2FA- und Passkey-Rat auf das mSecure-Konto bezieht, auf die im Tresor gespeicherten Einträge oder auf beides.

Fragen von The Register hatte mSeven bis zur Veröffentlichung nicht beantwortet. Im Support-Forum fragen Kunden mit 500 oder 800 gespeicherten Passwörtern, ob sie wirklich alle ändern müssen. Eine Antwort gibt es dort bisher nicht.

Was sich seit meinem Post geändert hat

In der Sache nichts. Ich finde bis heute (4. November) keine weitere Stellungnahme des Herstellers, keine CVE und keinen Patch, der mit dem Vorfall zusammenhängt. Eine Präzisierung gegenüber meinem Post: Die Mail formuliert die drei Schritte als Möglichkeiten („may include“), nicht als feste Anweisung. Da niemand sagen kann, welche Einträge gefährdet sind, läuft das praktisch trotzdem auf „alles“ hinaus.

Warum das wichtig ist

mSecure wirbt mit AES-256, Ende-zu-Ende-Verschlüsselung und Zero-Knowledge. Das heißt: Daten werden auf dem Gerät verschlüsselt, der Anbieter soll sie nicht lesen können. Wenn das stimmt, müsste ein Einbruch beim Anbieter für die Tresor-Inhalte weitgehend folgenlos bleiben. heise weist zu Recht darauf hin: Wer nach einem Vorfall beim Anbieter trotzdem zum Komplett-Reset rät, wirft die Frage auf, ob es Schwachstellen in der Verschlüsselung oder Zweitschlüssel gibt.

Dazu kommt ein bekannter Befund. Das BSI hat im Dezember 2025 zehn Passwort-Manager untersucht. Für mSecure 6.1.5 unter Android stellte es fest, dass der Hersteller theoretisch auf gespeicherte Daten zugreifen könnte. Das Gesamtkonzept entspreche nicht den üblichen Erwartungen an Passwort-Manager (test.de). Getestet wurde nur diese Version. Ob das mit dem aktuellen Vorfall zu tun hat, ist offen. Das sollte man nicht vermischen.

Wer betroffen ist

Alle, die mSecure nutzen oder genutzt haben. heise schätzt die Reichweite grob: über 500.000 Installationen bei Google Play, dazu nach den App-Store-Bewertungen grob 250.000 iOS-Nutzer. Wie viele Kunden tatsächlich betroffen sind, weiß man nicht.

Was du jetzt tun solltest

Solange der Hersteller schweigt, würde ich davon ausgehen, dass der Tresor-Inhalt bekannt ist.

1. Zuerst E-Mail-Konten. Wer dein Postfach hat, kann fast überall Passwörter zurücksetzen. Neues Passwort, 2FA neu einrichten, aktive Sitzungen beenden.
2. Dann Bank, Zahlungsdienste, Apple-/Google-/Microsoft-Konto, danach alles, was Geld oder Identität betrifft.
3. 2FA neu einrichten. Wenn TOTP-Codes (die sechsstelligen Codes aus Authenticator-Apps) im Tresor lagen, sind die Geheimnisse dahinter ebenso verdächtig wie die Passwörter.
4. Passkeys entfernen und neu anlegen, vor allem solche, die in mSecure gespeichert waren.
5. Restliche Konten nach Wichtigkeit abarbeiten. Bei Hunderten Einträgen ist das mühsam, aber die Reihenfolge schützt das Wichtigste zuerst.
6. Vorsicht vor Phishing. Eine Vorfallsmeldung ist perfekter Köder für gefälschte „Bitte hier zurücksetzen“-Mails. Logge dich direkt auf den Seiten ein, nicht über Links aus Mails.
7. Über einen Wechsel nachdenken. Ein Passwort-Manager, der nach einem Vorfall keine Details nennt, verliert das, was er verkauft: Vertrauen. Wer wechselt, sollte die neuen Passwörter direkt im neuen Manager anlegen.

Ich ergänze den Artikel, sobald mSeven mehr sagt.

Quellen

• The Hacker News: mSecure Warns Users to Change Passwords, Reset 2FA and Passkeys
• The Register: Password manager mSecure tells users to change passwords, won't say why
• heise: Passwort-Manager mSecure: Nach IT-Vorfall Zugangsdaten sichern
• test.de: Behörde rügt unsichere Passwort-Manager (BSI-Studie)

Eine Korrektur zu meinem Post auf X und im WhatsApp-Kanal: Dort stand der Patch-Status noch als unklar. Tatsächlich gibt es den Fix schon seit dem 28. Oktober.

Was passiert ist

Die Lücke ist eine sogenannte TOCTOU-Race-Condition. TOCTOU heißt "time of check to time of use": Zwischen dem Moment, in dem ein System etwas prüft, und dem Moment, in dem es das Ergebnis nutzt, bleibt ein kurzes Zeitfenster. Wer in diesem Fenster schneller ist, kann eingreifen.

Bei WordPress betrifft das Core-Updates mit dem vollständigen Update-Paket. Laut WordPress-Advisory GHSA-4w3m-c66w-69mg haben betroffene Versionen die neuen Dateien in ein vorhersagbares Verzeichnis im per Web erreichbaren Upgrade-Ordner entpackt. Wer das Rennen gegen diesen Entpackvorgang gewinnt, kann ohne Anmeldung PHP-Code auf dem Server ausführen. Ein Benutzerkonto oder eine Aktion des Admins braucht es dafür nicht.

Wie ernst ist das?

Bei der Bewertung sind sich die Beteiligten nicht einig. WordPress selbst stuft die Lücke als "Low" ein. Der CVE-Eintrag kommt laut Ostorlab und runZero auf CVSS 8.1, also "High". CVSS ist die übliche Punkteskala für Schweregrade von 0 bis 10. Der Unterschied kommt vom Zeitfenster: Es dauert nur Sekunden, ein Angriff ist also schwierig. In der hohen Wertung steckt das als "hohe Angriffskomplexität" schon drin.

Zum Ablauf: Laut Ostorlab hat Wordfence in den 24 Stunden bis zum 30. Oktober fast 63.000 Anfragen geblockt, die auf die Lücke zielten. Das waren Versuche, keine bestätigten Einbrüche. CISA nennt in der KEV-Meldung keine Details zu erfolgreichen Angriffen, die Aufnahme beruht aber auf "evidence of active exploitation". Wie viele Seiten tatsächlich kompromittiert wurden, ist öffentlich nicht bekannt.

Meine Einschätzung: "Schwer auszunutzen" reicht nicht als Ausrede. Die Angriffe laufen automatisiert und massenhaft, und WordPress läuft auf unzähligen Servern. Wer oft genug probiert, gewinnt irgendwann ein Rennen.

Wer betroffen ist

Betroffen sind laut Advisory alle WordPress-Versionen von 4.7.0 bis 7.1.3. Behoben ist die Lücke in 7.1.4 sowie in Backports für jeden älteren Zweig bis 4.7, zum Beispiel 7.0.8, 6.9.11, 6.8.12 und 4.7.39. Die vollständige Liste steht im Advisory. Pantheon beschreibt 7.1.4 als Sicherheitsrelease mit insgesamt 13 behobenen Problemen, darunter mehrere Stored-XSS-Lücken.

Wichtig ist eine Bedingung: Ausnutzbar ist die Lücke laut Ostorlab nur, wenn das Staging-Verzeichnis unter wp-content/upgrade/ vom Web aus erreichbar ist und PHP-Dateien darin ausgeführt werden. Bei vielen Standard-Hostings ist das der Fall.

Was du jetzt tun solltest

• Updaten. Mach ein Backup und spiel dann 7.1.4 oder die gepatchte Version deines Zweigs ein. Das Advisory nennt das als Gegenmaßnahme.
• Das Paradox bei Auto-Updates beachten. Automatische Hintergrund-Updates liefern den Fix aus. Das Update selbst läuft aber noch mit dem alten, verwundbaren Code. Wie Ostorlab erklärt, ist genau dieses eine Update-Fenster also noch angreifbar.
• Upgrade-Ordner sperren, wenn du nicht sofort updaten kannst. Blockiere den Web-Zugriff auf /wp-content/upgrade/ am Webserver, etwa mit einer 403-Regel. Das deckt nur diese Lücke ab und ersetzt kein Update. Am besten setzt du die Sperre vor dem Update, dann ist auch das Update-Fenster geschützt.
• Logs und Verzeichnis prüfen. Such in den Webserver-Logs nach Aufrufen von PHP-Dateien unter diesem Pfad. Achte im Verzeichnis auf PHP-Dateien, die dort nicht hingehören. Ein einzelner Treffer ist ein Hinweis, dem du nachgehen solltest, aber noch kein Beweis für einen Einbruch.
• Reste aufräumen. Lösch nach dem Update übrig gebliebene Dateien im Upgrade-Ordner.

Wer viele Seiten betreut, also Agenturen und Hoster, sollte die Sperre zentral auf Serverebene setzen. Das geht schneller, als jede Installation einzeln anzufassen.

Quellen

• WordPress Security Advisory GHSA-4w3m-c66w-69mg
• NVD: CVE-2026-119977
• CISA-KEV-Meldung vom 3. November 2026 (Zusammenfassung)
• Ostorlab: WordPress Core Upgrade-Window RCE
• runZero: WordPress CVE-2026-119977
• Pantheon Release Notes: WordPress 7.1.4

Was passiert ist

XCPE (intern „x.cpe“) ist eine Hintertür, die schon in der Firmware der Boxen steckt, also in der fest installierten Gerätesoftware. Sie läuft als System-App mit vollen Rechten und meldet sich bei Command-and-Control-Servern. Das sind Steuerserver, über die die Betreiber den Geräten Befehle schicken. Laut Help Net Security installiert sich die Hintertür nach einem Neustart aus einer geschützten Partition neu. Wer die App löscht, ist sie damit nicht los. Um unbemerkt Software nachzuladen, schaltet XCPE die App-Prüfung von Google Play Protect ab.

Googles Threat Intelligence Group ordnet XCPE „mit hoher Sicherheit“ dem chinesischen Hersteller Videostrong Technology aus Shenzhen zu. Videostrong baut Android-TV-Boxen unter eigenem Namen und für andere Marken. Laut The Hacker News hat Google mehrere Belege gefunden:

• XCPE reicht Einstellungen an andere Videostrong-Apps weiter.
• Ein GitHub-Konto, auf dem Pakete des Botnetzes lagen, heißt „yf-videostrong“.
• Das Partnerunternehmen Synthient fand auf einem Server des Botnetzes ein Dokument, das der Entwicklungsleiter von Videostrong unterschrieben hat.
• Eine Videostrong-Domain und das Steuerpanel der Betreiber teilten sich eine IP-Adresse.

Das Geschäftsmodell sah laut den Berichten so aus: Videostrong verkaufte Kriminellen Zugang zu den Boxen. Diese spielten eigene Module auf. Die meisten Module machten die Boxen zu Residential Proxys. Dabei wird fremder Internetverkehr über private Heimanschlüsse geleitet, damit er wie normaler Haushaltsverkehr aussieht. Andere Module riefen im Hintergrund Werbung ab, die niemand sah, also Werbebetrug. Die Betreiber konnten außerdem Screenshots machen, Tastatureingaben einschleusen, Zugangsdaten und Systemprotokolle kopieren und eine Fernsteuerung per Shell öffnen.

Wie Google vorgegangen ist

Google ist juristisch gegen die Domains und Server vorgegangen, die das Botnetz steuerten. Das betraf auch die Steuerinfrastruktur von mehr als einem Dutzend weiterer Schadsoftware-Familien. Beteiligt waren die japanische Nationale Polizeibehörde sowie Lumen, HUMAN Security, Plume, Synthient und TrendAI, die Enterprise-Sparte von Trend Micro. Videostrong und mögliche künftige Tochterfirmen dürfen keine zertifizierten Android-Geräte mehr bauen und keine Software an zertifizierte Hersteller liefern. Google will außerdem die Firmware-Prüfung für zertifizierte Android-TV-Geräte verschärfen und hat eine Lücke im Prüfprozess für Hersteller geschlossen.

Was sich seit meinem Post geändert hat

Im Post hatte ich geschrieben, die Verbreitung in Deutschland sei unklar. Inzwischen gibt es Zahlen. Laut The Hacker News gab es die meisten Infektionen in Malaysia, Brasilien, dem Irak, Mexiko und Taiwan. Die USA, Deutschland, Großbritannien, Australien und Kanada kommen jeweils auf etwa 26.000 bis 42.000 Geräte. TrendAI hat zwischen Juni und Oktober sogar 1.472.554 infizierte Geräte in 206 Modellen gezählt, also mehr als die 1,3 Millionen von Google. Bei den Marken fallen vor allem MECOOL-Boxen auf. Synthient hat eine Liste mit 182 Modellnamen veröffentlicht. Ein Modellname allein beweist aber noch keine Infektion. Betroffen sind laut Plume sowohl von Google zertifizierte Geräte als auch Boxen mit reinem AOSP, dem offenen Android ohne Google-Dienste. Die Hintertür steckte auch in Telemedizin-Geräten, Karaoke-Maschinen und digitalen Werbetafeln.

Google rechnet damit, dass die Abschaltung den Kriminellen den Zugriff auf mindestens 10 Millionen weitere Geräte nimmt, die auf anderen Wegen infiziert wurden.

Was du tun solltest

Einen Patch gibt es nach allem, was bekannt ist, nicht. Die Server sind zwar abgeschaltet, aber die Hintertür steckt weiter in der Firmware. Wer das Gerät kontrolliert, kann es also wieder in Gebrauch nehmen.

• Box prüfen: Hast du eine günstige Android-TV-Box, vor allem von MECOOL oder einer No-Name-Marke? Dann vergleiche das Modell mit der Liste von Synthient.
• Im Zweifel ersetzen: Synthient rät, betroffene Boxen zu entsorgen. Plume empfiehlt mindestens einen vollständigen Werksreset, sagt aber nicht, ob der XCPE entfernt. Laut TrendAI wird man die Hintertür nur über den Hersteller, über Schutzfunktionen der Plattform oder durch Austausch des Geräts los. Meine Einordnung: Ein Werksreset reicht hier wahrscheinlich nicht. Die Box gehört raus.
• Netz trennen: Smart-TV-Geräte und andere IoT-Geräte gehören in ein eigenes Netz, etwa ein Gäste-WLAN oder VLAN, getrennt von Rechnern und NAS.
• Für Firmen: Mit den veröffentlichten Indikatoren nach solchen Geräten suchen, die gelisteten Steuerdomains blockieren und private, nicht verwaltete Geräte im Homeoffice als Teil der Angriffsfläche behandeln.

Mein Rat bleibt: Bei der 30-Euro-Box ohne bekannte Marke bezahlst du am Ende vielleicht mit deinem Internetanschluss.

Quellen

• Help Net Security: XCPE botnet, Android backdoor
• The Hacker News: Google disrupts 1.3 million device botnet

Was passiert ist

Der Diebstahl geschah am 29. Oktober 2026. Laut FBI wurden virtuelle Assets im Wert von mehr als 6 Milliarden US-Dollar gestohlen. Die genauen Zahlen gehen auseinander: The Hacker News nennt 6,43 Milliarden, heise beruft sich auf 6,36 Milliarden aus Analysen von TRM Labs, und Chainalysis kam laut Cointelegraph auf rund 5,9 Milliarden. Fest steht nur die Größenordnung: Das ist der größte bekannte Kryptodiebstahl. Den bisherigen Rekord hielt der Bybit-Hack vom Februar 2025 mit rund 1,46 Milliarden Dollar, ebenfalls TraderTraitor zugeschrieben.

Die Beute lag laut The Hacker News auf elf Blockchains, 82 Prozent davon auf Ethereum und Bitcoin. Laut heise haben die Angreifer den Großteil innerhalb von etwa 20 Minuten abgezogen.

Zum Einfallstor gibt es noch keine gesicherte Aussage. Binance nannte zunächst den kompromittierten Laptop eines DevOps-Engineers, also eines Mitarbeiters, der Infrastruktur und Deployments betreut. Inzwischen geht Binance laut heise von mehreren Einstiegspunkten und einem komplexen Angriff aus.

Was sich seit unserem Post geändert hat

• Zuordnung offiziell: Zuerst hatten Analysefirmen wie TRM Labs, Chainalysis und Elliptic auf Nordkorea getippt. Das FBI hatte sich anfangs nur zu den Ermittlungen geäußert. Mit dem Hinweis vom 31. Oktober ist die Zuordnung jetzt behördlich.
• Wallet-Liste: Das FBI hat laut SecurityWeek 628 Adressen veröffentlicht: 608 auf Ethereum, 19 auf Bitcoin und eine auf Solana. Börsen, DeFi-Dienste (dezentrale Finanzdienste ohne zentrale Betreiber), Bridges und Node-Betreiber sollen Transaktionen mit diesen Adressen blockieren. Das FBI rechnet damit, dass die Beute über DeFi und Instant-Swap-Dienste weiter gewaschen wird.
• Eingefroren: Tether, Circle, Ripple, Arbitrum und Optimism haben laut Elliptic rund 2,85 Milliarden Dollar eingefroren. TRM Labs schätzt 2,7 Milliarden. Den Rest haben die Angreifer vor allem in Ether umgetauscht, und der lässt sich kaum einfrieren.
• Binance trägt den Schaden: Laut heise sagt Binance, der Schaden treffe die Börse und nicht die Nutzer. Rund 90 Prozent seien bereits gedeckt. Auszahlungen laufen seit dem 1. November wieder, inzwischen auf allen 15 Netzwerken. Am ersten Tag flossen netto rund 3,64 Milliarden Dollar ab.

Warum das wichtig ist

Das ist kein Gelegenheitsdiebstahl. Hier hat ein Staat mit langem Atem eine der größten Börsen der Welt geplündert. Laut Elliptic verdoppelt dieser eine Vorfall fast die Summe, die Nordkorea bisher an Kryptowerten erbeutet hat. TraderTraitor ist seit mindestens 2020 aktiv. Der Gruppe werden auch die Angriffe auf DMM Bitcoin, Bybit, KelpDAO und Bitget zugeschrieben.

Ihre bekannten Methoden zielen auf Menschen und Entwickler-Werkzeuge. Dazu gehören gefälschte Recruiter, Scheinfirmen und Lockangebote zu Jobs. Laut Berichten von SentinelOne, Zscaler und Microsoft kommen auch manipulierte Terraform-Provider dazu. Terraform ist ein Werkzeug, mit dem Teams Infrastruktur als Code verwalten. Ein manipulierter Provider bringt Schadcode direkt in den Entwickler-Workflow. Ob genau diese Techniken bei Binance eingesetzt wurden, ist nicht belegt. Das Muster passt aber zum Hinweis auf den Laptop.

Was du tun solltest

Als Privatperson mit Krypto:

• Lass nicht dein ganzes Vermögen auf einer Börse liegen. Was du nicht handelst, gehört in eine eigene Wallet, idealerweise eine Hardware-Wallet.
• Schütze Börsenkonten mit Hardware-Sicherheitsschlüsseln (FIDO2/Passkeys) statt mit SMS-Codes.
• Sei misstrauisch bei Jobangeboten, "Testaufgaben" und Dateien von Fremden, gerade wenn sie über LinkedIn, Telegram oder Discord kommen.
• Achte auf Phishing: Nach großen Vorfällen kursieren gefälschte "Entschädigungs"-Seiten.

Als Unternehmen oder Entwicklerteam:

• Nimm die Adressliste des FBI in dein Transaktions-Screening auf, wenn du mit Kryptowerten arbeitest.
• Behandle Rechner von Admins und Entwicklern als besonders wertvolle Ziele. Trenne Arbeits- und Signierumgebungen und halte die Rechte so knapp wie möglich.
• Prüfe, woher Terraform-Provider, Pakete und Skripte kommen, bevor sie in Pipelines landen.
• Schule HR und Engineering zu gefälschten Recruitern. Der Einstieg passiert oft im Bewerbungsgespräch, nicht in der Firewall.

Meine Einordnung: Die beste Verteidigung gegen staatliche Angreifer ist nicht ein einzelnes Tool. Es kommt darauf an, dass ein einziger kompromittierter Laptop nicht reicht, um Milliarden zu bewegen.

Quellen

• The Hacker News: FBI Links North Korea's TraderTraitor to Binance theft
• heise: FBI – Nordkorea steckt hinter Milliarden-Kryptodiebstahl bei Binance
• SecurityWeek: FBI Flags Over 600 Addresses Tied to North Korea's Binance Heist
• Cointelegraph: North Korea linked to $6.3B Binance hack

Was passiert ist

Laut Chainalysis begann der Zugriff Anfang Oktober. Betroffene Kunden wurden per E-Mail informiert. Folgende Daten von Nutzern, die auf der Plattform eingerichtet sind, hat der Angreifer gesehen:

• User-IDs
• vollständige Namen
• E-Mail-Adressen
• Rollenbezeichnungen innerhalb der Organisation

Nach Angaben des Unternehmens gibt es keine Hinweise auf Zugriffe auf Ermittlungsinhalte, Zugangsdaten oder Session-Tokens. Ein Session-Token ist der digitale Ausweis, der nach dem Login die Sitzung offen hält. Wer ihn stiehlt, kann sich ohne Passwort als Nutzer ausgeben. Das ist die Darstellung von Chainalysis. Unabhängig bestätigt ist sie bisher nicht.

Wie viele Kunden betroffen sind, steht in keiner Quelle. Chainalysis prüft nach eigenen Angaben noch, welche Datensätze pro Organisation betroffen sind, und will diese Aufschlüsselung später an die Kunden schicken.

Mehrere Punkte sind weiter offen: Wie der Angreifer hineinkam, welche Schwachstellen er ausnutzte, welche internen Tools betroffen waren und wie lange er im System war. Laut Chainalysis werden Lücken geschlossen und Systeme gehärtet. Was genau gepatcht wurde, sagt das Unternehmen nicht. Den Diebstahl bei Binance aus der Vorwoche bringt Chainalysis ausdrücklich nicht mit diesem Vorfall in Verbindung.

Was „agentic“ hier heißt

Ein KI-Agent ist ein Sprachmodell, das nicht nur Text erzeugt, sondern selbstständig Werkzeuge bedient. Er kann Befehle ausführen, Ergebnisse auswerten und den nächsten Schritt planen. Offensiv eingesetzt kann so ein Agent Erkundung und Ausnutzung von Lücken in einer Schleife automatisieren, deutlich schneller als ein Mensch.

Wichtig ist dabei: Den Begriff hat Chainalysis selbst gewählt, mehr erklärt hat das Unternehmen nicht. Ob der Angreifer ein vorhandenes Framework nutzte oder eigene Agenten baute, ist laut BleepingComputer unklar. Ein solches Framework ist etwa ARTEX, das Microsoft zufolge Angreifer bereits im ConnectWise-Lieferkettenangriff eingesetzt haben. Dass KI beteiligt war, geht also nur aus der Formulierung der Firma hervor. Wie groß ihr Anteil war, ist nicht belegt.

Warum das wichtig ist

Auf den ersten Blick wirken Namen, E-Mails und Rollen harmlos. Bei Chainalysis sieht das anders aus. Zu den Kunden gehören Ermittlungsbehörden, Compliance-Teams und Kryptofirmen. Eine Liste mit der Information „Person X ist Ermittlerin bei Organisation Y“ ist ideales Material für gezieltes Phishing. Phishing heißt: Angreifer schicken gefälschte Nachrichten, um Zugangsdaten oder Geld zu erbeuten. Die Rollenangabe zeigt ihnen außerdem, wer in einer Organisation die interessanten Rechte hat.

Dazu kommt das größere Bild. Chainalysis spricht selbst von einer branchenweiten Zunahme KI-gestützter Angriffe. Ich halte es für bemerkenswert, dass ein Unternehmen das so offen in seine Vorfallsmeldung schreibt. Wenn Agenten das Absuchen nach Lücken billiger machen, trifft es zuerst Firmen mit wertvollen Daten und großer Angriffsfläche an internen Tools.

Was du tun solltest

Wenn du oder deine Organisation Chainalysis nutzt:

• Zwei-Faktor-Authentifizierung (2FA) aktivieren, falls noch nicht geschehen. Das empfiehlt auch Chainalysis selbst.
• Auf unerwartete Passwort-Reset-Mails und Login-Abfragen achten. Nicht bestätigen, was du nicht selbst angestoßen hast.
• Mails, die angeblich von Chainalysis kommen, besonders kritisch lesen. Laut BleepingComputer warnt das Unternehmen vor Betrügern, die sich als Chainalysis ausgeben, vor allem mit Angeboten zur „Rückholung“ von Geldern oder mit Jobangeboten.
• Die Mitteilung von Chainalysis an deine Organisation prüfen und auf die angekündigte Aufschlüsselung pro Organisation achten.
• Das eigene Team warnen. Besonders Kollegen, deren Rolle auf der Plattform hinterlegt ist, sind wahrscheinliche Phishing-Ziele.

Was sich seit dem Post geändert hat

Gegenüber meinem ersten Post gibt es zwei Ergänzungen. Chainalysis gibt inzwischen konkrete Empfehlungen (2FA, Vorsicht bei Reset-Mails und Betrügern) und hat eine Aufschlüsselung der betroffenen Datensätze pro Organisation angekündigt. Die Zahl der Betroffenen ist weiter unbekannt. Eine CVE gibt es nicht. CVE ist die öffentliche Kennung für eine Schwachstelle. Ein benannter Patch existiert ebenfalls nicht.

Quellen

• BleepingComputer: Chainalysis discloses data breach from "offensive agentic techniques"
• The Hacker News: Chainalysis confirms intrusion
• Infosecurity Magazine: Chainalysis Warns Customers After "Offensive Agentic" Security Incident

Was sich seit meinem Post geändert hat

Auf X und im WhatsApp-Kanal hatte ich geschrieben, dass die Meldungen weder betroffene Versionen noch eine CVE-Nummer nennen. Das stimmt so nicht mehr. Es gibt inzwischen zwei Erklärungen, und sie passen nicht ganz zusammen:

• Synology sagt nicht ausdrücklich, welche Lücke ausgenutzt wird. Der Hersteller schreibt nur, sie sei im Dezember 2024 geschlossen worden, und verweist auf die Sicherheitsmeldung Synology-SA-24:20. Diese Meldung betrifft Lücken, die bei Pwn2Own 2024 vorgeführt wurden, darunter CVE-2024-10441. Das ist eine Remote-Code-Ausführung mit dem CVSS-Wert 9,8 von 10. Remote-Code-Ausführung heißt, dass ein Angreifer über das Netz eigenen Code auf dem Gerät starten kann.
• Das chinesische Sicherheitsunternehmen 360 hat betroffene Geräte untersucht und führt die Angriffe laut Gridinsoft auf CVE-2026-13639 und CVE-2026-13684 zurück. Beide Lücken sind ebenfalls mit 9,8 bewertet und stehen in Synology-SA-26:13 vom 18. September 2026. Über sie können Angreifer ohne Anmeldung beliebige Dateien lesen und schreiben.

Welche Erklärung zutrifft, lässt sich von außen nicht entscheiden. Vielleicht stimmen auch beide, wenn verschiedene Angreifer verschiedene Lücken nutzen. Für die Praxis spielt das kaum eine Rolle, denn für beide gibt es Updates. Wer nur den Patch von 2024 eingespielt hat, ist nach der Analyse von 360 aber nicht automatisch sicher.

Wie der Angriff aussieht

Laut BleepingComputer tauchten die ersten Berichte von Opfern in Foren und auf Reddit mehr als zwei Wochen vor Synologys Warnung auf. Verschlüsselte Dateien bekommen die Endung .L0CK3D, und in den Ordnern liegt eine Lösegeldforderung namens read-me3.txt. Darin behaupten die Täter, dass Wiederherstellungssoftware die Dateien zerstört und nur ihr eigener „C3rb3r Decryptor“ hilft. Der kostet über ein Darknet-Portal mehrere Tausend Dollar. Als Beweis bieten sie an, eine Datei kostenlos zu entschlüsseln. Ein kostenloses Entschlüsselungsprogramm gibt es bisher nicht.

Der Name ist von Cerber übernommen, einer Ransomware, die ab 2016 als Dienst vermietet wurde. C3RB3R selbst gibt es seit Ende 2021. Bisher hat sie vor allem Confluence- und GitLab-Server angegriffen.

Wer betroffen ist

Betroffen sind alle Synology-NAS mit einem DSM-Stand, der eine der genannten Lücken noch enthält. Besonders gefährdet sind Geräte, deren Weboberfläche aus dem Internet erreichbar ist. Shadowserver zählt laut BleepingComputer mehr als 380.000 Synology-NAS, die offen im Netz stehen. Wie viele davon gepatcht sind, ist nicht bekannt.

Die Mindestversionen aus den beiden Sicherheitsmeldungen:

Ältere Zweige wie 7.1 und 6.2 sind nur in SA-24:20 aufgeführt. Wer noch darauf läuft, sollte auf einen unterstützten Zweig wechseln, wenn das Modell es erlaubt.

Was du jetzt tun solltest

1. DSM sofort aktualisieren, und zwar auf die neueste verfügbare Version, nicht nur auf den Patch von 2024. Danach automatische Updates einschalten, wie Synology rät.
2. Die Verwaltungsoberfläche nicht ins Internet stellen. Fernzugriff besser über VPN, also einen verschlüsselten Tunnel ins eigene Netz, statt über eine Portfreigabe im Router.
3. Backups getrennt vom NAS aufbewahren, offline oder auf einem System, auf das das NAS nicht schreiben kann. Snapshots auf demselben Gerät helfen nicht, wenn der Angreifer das ganze Gerät kontrolliert.
4. Bei einem Befall nicht vorschnell zahlen. Das Gerät vom Netz trennen und die Lösegeldforderung samt Beispieldateien sichern. Dann den Synology-Support und gegebenenfalls einen Incident-Response-Dienstleister einschalten.

Meine Einordnung: Das Update ist Pflicht, aber nicht der Kern des Problems. Die Lücken von 2024 sind seit fast zwei Jahren geschlossen und werden trotzdem ausgenutzt. Ein NAS, das offen im Internet steht und nie aktualisiert wird, ist bei jeder neuen Lücke wieder angreifbar. Am meisten schützt es, das Gerät gar nicht erst aus dem Internet erreichbar zu machen.

Quellen

• Synology: Pressemitteilung zu C3RB3R (29.10.2026)
• Synology-SA-24:20
• Synology-SA-26:13
• BleepingComputer: Synology warns customers of ongoing C3RB3R ransomware attacks
• heise Security: Schwachstellen in Drupal, Ivanti Connect Secure und Synology angegriffen
• Gridinsoft: Analyse mit den Ergebnissen von 360

Was passiert ist

Der Fehler steckt im Telefondienst com.android.phone, der bei Android Mobilfunk, Anrufe und SMS verwaltet. Bei einer bestimmten Sorte SMS, einer sogenannten WAP-Push-Nachricht (Steuernachrichten, die Netzbetreiber z. B. für Konfigurationsdaten nutzen), wird ein Längenwert im Header nicht geprüft. Ein manipulierter Wert wird zu einer negativen Arraygröße, der Dienst wirft eine unbehandelte Ausnahme und stürzt ab. So beschreiben es BleepingComputer und heise.

Das ist ein Zero-Click-Angriff: Das Opfer muss nichts anklicken. Android verarbeitet die Nachricht, bevor sie im Posteingang landen würde. Man sieht also gar nichts, nur die Folgen:

• Die Mobilfunkverbindung bricht weg, laufende Anrufe fallen aus. Das gilt auch für Notrufe.
• Netzbetreiber stellen unbestätigte Nachrichten erneut zu. Laut heise hat eine einzige SMS in Tests bis zu eine Woche lang Ausfälle verursacht.
• Mit rund 20 solcher Nachrichten geriet ein Gerät in eine Neustartschleife, etwa alle 90 Sekunden. Der Wiederherstellungsmodus bietet dann an, die Daten zu löschen.

Reproduziert wurde das laut heise auf einem Pixel 9 und auf mehreren Samsung-Galaxy-Geräten. Es geht um Verfügbarkeit, nicht um Datendiebstahl. Hinweise auf echte Angriffe nennt keine der Quellen. Weil der Code aber öffentlich ist, ist die Hürde für Nachahmer niedrig.

Was sich seit meinem Post geändert hat

Nicht alle Versionen sind gepatcht. Google hat die Korrektur („Fix remote DoS in decodeWapPdu“) mit den Oktober-Updates 2026 für Android 14 bis 17 ausgeliefert. Laut GrapheneOS war der Fix schon ab Juli in Sicherheitsvorschauen für Hersteller enthalten. Für Android 12 und 13 wird es voraussichtlich keinen Fix geben, weil Google diese Versionen nicht mehr unterstützt. Bei der Frage, welche Versionen genau betroffen sind, nennen die Quellen mal 12 bis 16, mal 12 bis 17.

Im Oktober-Bulletin taucht die Lücke nicht auf. Laut heise und eSecurityPlanet soll sie im November-Bulletin stehen, Google stuft sie als kritisch ein. Das November-Bulletin war heute noch nicht online. Einen CVSS-Wert (die Standardskala für den Schweregrad) gibt es bisher nicht.

Holprige Vorgeschichte. Blaszczyk hat Google am 5. Mai informiert. Laut heise wurde der Bericht zunächst als „Will Not Fix“ geschlossen. GrapheneOS hält das für eine interne Kommunikationspanne. Behoben wurde nur die Fehlerbehandlung: Der Dienst fängt die Ausnahme jetzt ab und löscht die schadhafte Nachricht. Die vom Forscher vorgeschlagene Prüfung des Längenwerts kam nicht.

Was du tun solltest

1. Update installieren und neu starten. Unter Einstellungen → Sicherheit bzw. „Über das Telefon“ steht der Sicherheitspatch-Stand. Bei Android 14 bis 17 sollte dort mindestens Oktober 2026 stehen. Wann das Update kommt, entscheiden Hersteller und Netzbetreiber, nicht Google.
2. Android 12 oder 13? Prüf, ob dein Gerät noch ein Upgrade auf eine neuere Version bekommt. Wenn nicht, hilft keine Einstellung: Laut Berichten lässt sich WAP Push nicht abschalten, und Vorsicht bei verdächtigen Nachrichten nützt nichts, wenn man die Nachricht nie sieht. Dann ist es Zeit für ein neues Gerät, vor allem wenn das Handy für Notfälle gedacht ist, etwa bei älteren Angehörigen.
3. Gerät hängt in der Neustartschleife? Im Wiederherstellungsmodus nicht „Daten löschen“ wählen, sonst ist alles weg. Laut Forscher lassen sich die Nachrichten per ADB (Android Debug Bridge, ein Werkzeug zur Steuerung des Handys vom PC aus) entfernen. Das braucht einen Rechner und etwas Erfahrung. Wer das nicht kann, holt sich Hilfe, statt das Gerät zurückzusetzen.

Meine Einordnung

Ein reiner Absturz klingt harmlos, bis man an Notrufe denkt. Die eigentliche Schwachstelle ist aber das Update-Modell von Android: Google behebt den Fehler, und Millionen Geräte mit Android 12 und 13 bleiben trotzdem dauerhaft angreifbar. Wer ein Android-Handy kauft, sollte vorher nachsehen, wie lange der Hersteller Updates zusagt.

Quellen

• BleepingComputer: New Android SMS of Death exploit can remotely crash unpatched phones
• heise: „SMS des Todes“: Sicherheitslücke lässt Android-Smartphones abstürzen
• eSecurityPlanet: Android SMS of Death Flaw Threatens Calls and Phones

Was passiert ist

Am Donnerstagnachmittag (US-Ostküstenzeit) meldeten Nutzer Abbuchungen, die sie nicht selbst ausgelöst hatten. Polymarket schaltete die internationale Börse erst in den Modus „cancel-only“: Man konnte nur noch offene Orders stornieren, aber nicht mehr handeln. Außerdem wurden die sogenannten Relayer-Aktionen pausiert, also der Dienst, der Transaktionen im Namen der Nutzer an die Blockchain weiterreicht. Nach etwa einer Stunde lief der Handel wieder. Laut BleepingComputer galt der Vorfall um 15:05 Uhr Ostküstenzeit als behoben. Die US-Plattform von Polymarket war nach SecurityWeek offenbar nicht betroffen.

Polymarket selbst nennt den Zulieferer bis heute nicht. Das Unternehmen schreibt nur, einer seiner Drittanbieter sei kompromittiert worden, und es habe die Sache an die Strafverfolgung übergeben. Sicherheitsforschende von Hudson Rock und GoPlus haben die Spur aber zu DebugBear zurückverfolgt, einem britischen Anbieter für Website-Performance-Monitoring. Der Schadcode kam über dessen RUM-Skript. RUM steht für Real User Monitoring: Ein kleines JavaScript misst im Browser echter Besucher, wie schnell eine Seite lädt. DebugBear hat einen „laufenden Sicherheitsvorfall“ bestätigt, externe Incident Responder hinzugezogen und Kunden aufgefordert, das RUM-Snippet von ihren Seiten zu entfernen. Hudson Rock fand einen Produktions-Build von Polymarket mit dem Zeitstempel 17:59 UTC, dessen Änderungsnotiz das Entfernen des DebugBear-Skripts vermerkt.

Wie der Schadcode vorging

Bemerkenswert ist, was das Skript nicht getan hat. Hudson Rock fand keinen Code, der Passwörter, Seed-Phrasen oder private Schlüssel abgreift. Das Skript prüfte stattdessen, ob jemand bei Polymarket eingeloggt war, und nutzte dann die bestehende Sitzung. Je nach Kontotyp verkaufte es die Positionen des Nutzers und leitete den Erlös weiter oder schickte die Positions-Token direkt an eine Adresse der Angreifer. Anweisungen holte es sich von DebugBear-Infrastruktur und meldete auch Kontodaten dorthin zurück. Wer eingeloggt war, für den sah das aus Sicht der Plattform wie eigenes Handeln aus.

Wie groß der Schaden ist

Die Zahlen gehen je nach Quelle auseinander, und Polymarket hat keine eigenen veröffentlicht:

• Hudson Rock sah auf der Angreifer-Wallet rund 2,19 Mio. USD, bezeichnet das aber ausdrücklich als nicht verifiziert.
• BleepingComputer hat verfolgt, dass von dieser Wallet etwa 28,6 Mio. POL (rund 2,57 Mio. USD) an drei weitere Wallets gingen.
• GoPlus schätzt rund 2,71 Mio. USD über 710 Einzahlungs-Wallets und 731 Adressen, betont aber, dass die Zahl der Adressen nicht der Zahl der Opfer entspricht.

Was sich seit meinem Post geändert hat: Dort stand noch allgemein „ein Website-Monitoring-Tool“. Inzwischen ist der Anbieter durch die Forschenden benannt, der Handel läuft wieder, und Polymarket hat zugesagt, alle Betroffenen vollständig zu entschädigen. Wie diese Entschädigung abläuft, ist noch offen. Unklar ist auch, wie die Angreifer das DebugBear-Skript manipulieren konnten und ob andere DebugBear-Kunden gezielt angegriffen wurden. Hudson Rock sieht dafür bisher keine Hinweise. Für Polymarket ist das außerdem nicht der erste Fall: Schon im Juni hatte die Plattform einen anderen Drittanbieter-Vorfall mit eingeschleustem Frontend-Skript gemeldet, damals mit rund 3 Mio. USD Schaden.

Warum das wichtig ist

Jedes fremde Skript, das du auf deiner Seite einbindest, läuft mit denselben Rechten wie dein eigener Code. Ein Performance-Tracker sieht dieselbe Sitzung, dieselben Buttons und dieselben API-Aufrufe wie die eigentliche Anwendung. Bei einer Seite, auf der Nutzer mit einem Klick Geld bewegen, ist das ein Generalschlüssel. Da das Skript keine Zugangsdaten stahl, sondern die laufende Sitzung missbrauchte, hätten auch starke Passwörter und Zwei-Faktor-Anmeldung hier nichts genützt.

Was du tun solltest

Als Polymarket-Nutzer:

• Prüfe deinen Kontoverlauf auf Verkäufe und Transfers vom 29. Oktober, die du nicht selbst ausgelöst hast, und melde sie Polymarket für die angekündigte Entschädigung.
• Schau dir Wallet-Freigaben an und widerrufe, was du nicht brauchst. Laut den Analysen lief der Angriff zwar über die Sitzung und nicht über Freigaben, aufräumen schadet aber nie.
• Logge dich nach dem Handeln aus, statt Sitzungen dauerhaft offen zu lassen.

Als Website-Betreiber:

• Wer DebugBear RUM einsetzt: Snippet entfernen, wie der Anbieter selbst empfiehlt.
• Zähle, welche fremden Skripte bei dir laufen, und streiche alles, was du nicht wirklich brauchst. Monitoring und Analyse gehören nicht auf Seiten, auf denen Geld bewegt wird, oder nur in stark eingeschränkter Form.
• Setze eine Content Security Policy (CSP), also eine Regel im HTTP-Header, die festlegt, von welchen Quellen Skripte laden und wohin sie Daten senden dürfen. Das begrenzt den Schaden, verhindert ihn aber nicht, wenn die erlaubte Quelle selbst kompromittiert ist.
• Wo möglich, fremde Skripte selbst hosten und mit Subresource Integrity (SRI) einbinden: Der Browser prüft dann eine Prüfsumme und führt veränderten Code nicht aus.

Deine Website ist nur so sicher wie die Skripte, die sie lädt.

Quellen

• BleepingComputer: Polymarket halts trading after crypto-draining script breach, $2.5M traced
• SecurityWeek: $2 Million+ Drained From Polymarket Traders in New Supply Chain Attack
• SC Media: Polymarket trading suspended following third-party supply chain attack

Was passiert ist

Laut Trezors eigener Mitteilung ging am 28. Oktober 2026 über das Responsible-Disclosure-Programm eine Meldung ein. Responsible Disclosure heißt: Wer eine Schwachstelle findet, meldet sie zuerst dem Hersteller statt sie zu veröffentlichen. Ein Kunde aus Indonesien hatte die Safe 5 im August 2026 bei CryptoBilis über die Plattform Tokopedia gekauft. Nach dem Öffnen fand er nach eigenen Angaben eine zusätzliche Platine zwischen Hauptplatine und Display, mit Mobilfunkmodul und Antenne.

Diese Platine soll den Bildschirminhalt mitlesen, also auch die Recovery-Phrase. Das ist die Liste aus meist 12 bis 24 Wörtern, mit der sich ein Krypto-Wallet komplett wiederherstellen lässt. Wer sie hat, hat das Geld. Sobald das Gerät angeschlossen ist, soll die Platine die Phrase über ein Mobilfunknetz verschicken. Das ist alles noch unbestätigt. Trezor hat Fotos und ein Videogespräch mit dem Kunden, das Gerät wird gerade ins Labor geschickt (BleepingComputer, The Hacker News).

Was seit meinem ersten Post dazugekommen ist

Ein paar Punkte muss ich ergänzen bzw. präzisieren:

• Nicht nur die Safe 5: Die Warnung gilt für jedes Trezor-Modell, das seit März 2026 bei CryptoBilis gekauft wurde. Das gilt auch für Läden, die Geräte von CryptoBilis weiterverkauft haben, etwa den Tokopedia-Shop.
• Kein bekannter Schaden: Der meldende Kunde hatte sein Guthaben schon vor dem Fund vom Wallet abgezogen. Trezor sind bisher keine Verluste von CryptoBilis-Käufern gemeldet worden.
• Weitere Geräte unauffällig: Laut Decrypt hat Trezor inzwischen vier andere bei CryptoBilis gekaufte Geräte geprüft (eine Safe 7, zwei Safe 5, eine Safe 3) und keine Manipulation gefunden. Bisher geht es also um ein einziges gemeldetes Gerät.
• Ersatz: Wer seinen Kauf belegen kann, bekommt von Trezor ein neues Gerät oder einen Gutschein.

Warum das wichtig ist

Ein Hardware-Wallet ist ein kleines Gerät, das die Schlüssel zu Kryptowährungen offline aufbewahrt. Das soll genau gegen Malware auf dem PC schützen. Ein Implantat im Gerät selbst hebelt dieses Versprechen komplett aus. Das ist ein klassischer Lieferkettenangriff (Supply-Chain-Angriff): Nicht der Hersteller wird angegriffen, sondern das Produkt irgendwo auf dem Weg zum Kunden.

Der Fall steht nicht allein. CryptoBilis war auch in einen Implantat-Fall bei Ledger verwickelt. Ledger hat dort eine Manipulation bestätigt, die die Recovery-Phrase bei der Einrichtung abgreift. Trezor hat CryptoBilis deshalb schon am 9. Oktober als Händler gestrichen, noch bevor es Hinweise auf eigene Geräte gab. Die Polizei in Singapur hat am 28. Oktober zusätzlich vor manipulierten Ledger-Geräten aus einigen Ladengeschäften gewarnt. Trezor sagt, die gemeldete Platine scheine ähnlich zu funktionieren wie die Ledger-Implantate. Einen direkten Vergleich will der Hersteller aber nicht ziehen, solange die Untersuchungen laufen. Wer dahintersteckt, ist offen.

Wer betroffen ist

Alle, die seit März 2026 ein Trezor-Gerät bei CryptoBilis oder bei einem Laden mit CryptoBilis-Ware gekauft haben. Andere Händler oder Regionen sind laut Trezor bisher nicht betroffen. Wer unsicher ist, schaut auf die Rechnung nach dem Verkäufer oder fragt beim Trezor-Support nach.

Was du konkret tun solltest

• Gerät schon eingerichtet: Guthaben so schnell wie möglich auf ein neues Wallet mit einer neuen Recovery-Phrase verschieben. Die alte Phrase auf einem anderen Gerät wiederherzustellen bringt nichts, denn die Phrase selbst gilt als kompromittiert.
• Kein anderes sicheres Hardware-Wallet zur Hand: Übergangsweise ein Software-Wallet oder eine vertraute Börse nutzen und die Empfangsadresse vollständig prüfen.
• Gerät noch nicht eingerichtet: Nicht einrichten und auf keinen Fall eine bestehende Recovery-Phrase eingeben.
• Nicht selbst basteln: Gerät nicht öffnen und nicht wiegen. Laut Trezor ist das Gewicht kein verlässlicher Test. Gerät aufbewahren und den Support kontaktieren.
• Phishing erwarten: Betrüger werden den Fall mit gefälschten Mails, Briefen und Anrufen ausnutzen. Niemand Seriöses fragt nach deiner Recovery-Phrase, auch der Trezor-Support nicht.

Ganz allgemein rate ich: Hardware-Wallets nur direkt beim Hersteller oder bei offiziell gelisteten Händlern kaufen. Marktplatzangebote und Graumarkt-Ware sind bei einem Gerät, dem du dein Geld anvertraust, keine gute Idee. Sobald Trezor Laborergebnisse veröffentlicht, ordne ich das hier nach.

Quellen

• Trezor: Implant reported in a Trezor sold by CryptoBilis
• BleepingComputer: Trezor warns of suspected crypto-theft implant in hardware wallet
• The Hacker News: Trezor Warns of Suspected Hardware Implant
• Decrypt: Trezor Warns CryptoBilis Buyers After Report of Hardware Implant in Safe 5

Seit meinem ersten Post ist einiges dazugekommen. Hier der aktuelle Stand, mit den offenen Punkten.

Was passiert ist

Am 29. Oktober tauchten Berichte über sehr große Abflüsse aus Binance-Hot-Wallets auf. Ein Hot Wallet ist eine Wallet, die ständig online ist, damit die Börse Auszahlungen schnell abwickeln kann. Die Gelder gingen an eine frisch angelegte Ethereum-Adresse. Binance sprach zunächst nur von „reports of a potential security issue“ (BleepingComputer). Später nannte die Börse die 6,3 Milliarden als geschätzte Gesamtauswirkung.

Zur Ursache sagt Binance bisher nur, die erste Untersuchung deute darauf hin, dass der Vorfall „may involve a compromised DevOps engineer's laptop“. Über diesen Laptop soll der Angreifer Zugriff auf einen Service-Container bekommen und unautorisierte Auszahlungen abgeschickt haben. Für ein Leck privater Wallet-Schlüssel gebe es keine Hinweise (The Register). Inzwischen räumt Binance allerdings ein, die Untersuchung habe „additional points of breach“ gefunden, also weitere Einfallstellen neben dem Laptop. Eine vollständige Ursachenanalyse gibt es noch nicht.

Das Blockchain-Analysehaus TRM Labs beschreibt, wie es aus seiner Sicht technisch ablief: Vorbereitungen mindestens 36 Stunden vorher, Testläufe wenige Stunden vor dem Angriff, dann eine einzige Transaktion, die das Hot Wallet in rund dreieinhalb Minuten leerte. Elliptic geht davon aus, dass der Angreifer Binances eigene Systeme dazu gebracht hat, die Transaktionen zu signieren, statt Schlüssel zu stehlen (The Hacker News). Das passt zur Aussage, dass keine Schlüssel abgeflossen sind, und macht die Sache nicht besser.

Die Zahlen und was sie bedeuten

• Betroffen: rund 6,3 Mrd. Dollar laut Binance. Chainalysis schätzt den Wert zum Zeitpunkt des Diebstahls auf etwa 5,9 Mrd., Elliptic auf 6,43 Mrd.
• Eingefroren: Tether hat mehr als 1,567 Mrd. USDT gesperrt, Circle rund 800 Mio. USDC. Elliptic beziffert alle Sperren zusammen auf 2,84 Mrd. Dollar.
• Noch beim Angreifer: laut Elliptic etwa 3,33 Mrd. Dollar, verteilt auf rund 43 Wallets, darunter ETH und BTC.

Ein Wort zur Einordnung, auch als Korrektur meines eigenen Posts. Ich hatte geschrieben: „Betroffen“ heißt nicht „gestohlen“. Für die Frage, ob abgeflossen ist, hat sich das erledigt. Die Analysefirmen sprechen klar von Diebstahl, und es wäre der größte Kryptodiebstahl bisher, deutlich vor Bybit mit 1,5 Mrd. Dollar im Februar 2025. Offen bleibt, wie hoch der endgültige Verlust wird, wenn man die eingefrorenen und eventuell zurückgeholten Beträge abzieht.

Stablecoins sind Token, die an eine Währung wie den Dollar gekoppelt sind. Dass Tether und Circle so schnell sperren konnten, zeigt, dass diese Token zentral kontrolliert werden. Hier hat das geholfen.

Wer steckt dahinter?

TRM Labs ordnet den Angriff mit hoher Sicherheit TraderTraitor zu, einer nordkoreanischen Gruppe, die seit Jahren Kryptofirmen angreift. Chainalysis sieht ebenfalls Nordkorea, auch weil Gelder mit denen aus dem Bitget-Exploit vermischt wurden. Elliptic mahnt zur Vorsicht, solange es keine Ursachenanalyse gibt. Binance selbst hat noch niemanden verantwortlich gemacht (The Hacker News).

Wer betroffen ist

Zunächst alle Binance-Kunden: Ein- und Auszahlungen sind ausgesetzt. Binance rechnet damit, Auszahlungen innerhalb von 48 Stunden wieder freizugeben, nachdem der Auszahlungsdienst überarbeitet wurde. Verluste will die Börse aus dem SAFU-Fonds und aus eigenen Mitteln decken. SAFU ist ein Notfallfonds, den Binance für genau solche Fälle angelegt hat. Bisher ist das eine Zusage, die Umsetzung muss sich noch zeigen.

Was du jetzt tun solltest

Als Binance-Kunde:

• Prüfe Kontostand und Transaktionsverlauf, sobald der Betrieb wieder läuft. Bei Unstimmigkeiten wende dich an den Support, und zwar nur über die App oder die offizielle Website.
• Aktiviere 2FA (Zwei-Faktor-Authentisierung, ein zweiter Code neben dem Passwort) und den Anti-Phishing-Code. Damit tragen echte Binance-Mails ein Kennwort, das nur du kennst.
• Rechne mit Phishing. Nach solchen Vorfällen kommen Mails und Nachrichten über „Entschädigung“, „Kontoverifizierung“ oder „Recovery-Services“. Binance warnt selbst ausdrücklich vor inoffiziellen Links. Niemand Seriöses fragt nach deinem Passwort oder deiner Seed-Phrase.
• Grundsätzlich gilt: Was du nicht aktiv handelst, gehört nicht auf eine Börse.

Als Unternehmen: Wenn ein einzelner Entwickler-Laptop den Weg zu Milliarden öffnen kann, ist das ein Architekturproblem und nicht nur ein Endpoint-Problem. TraderTraitor arbeitet bekannt mit gefälschten Jobangeboten, Coding-Tests und präparierter Software. Behandelt die Geräte von DevOps-Leuten mit Produktionszugriff wie Kronjuwelen. Und kein einzelner Systempfad sollte große Auszahlungen ohne unabhängige Freigabe signieren können.

Ich aktualisiere, sobald Binance eine Ursachenanalyse vorlegt.

Quellen

• The Hacker News: Binance Suffers Security Breach Affecting $6.3 Billion in Assets
• BleepingComputer: Binance probes potential $5.8 billion crypto theft hack
• The Register: Crypto exchanges still have bad security
• NPR: Binance flags 'potential security issue'

Korrektur zu meinem Post

Auf X und im WhatsApp-Kanal habe ich geschrieben, das Paket sei auf Open VSX gefunden worden, dem Erweiterungs-Marktplatz der Eclipse Foundation, den Editoren wie Cursor und Windsurf nutzen. Dafür sind die Quellen inzwischen nicht mehr einig:

• Help Net Security beruft sich auf den Mac-Sicherheitsanbieter Phorion, der das Paket auf Open VSX entdeckt haben will. Im selben Artikel widerspricht Ax Sharma von Manifold Security: Betroffen sei die offizielle Erweiterung im Cursor-Marktplatz.
• The Hacker News hat seinen Artikel korrigiert. Bestätigt ist dort nur der Cursor-Marktplatz. Belege für Open VSX oder den Microsoft-Marktplatz gebe es keine.
• StepSecurity sagt dagegen, die Version sei auf Open VSX veröffentlicht und dort inzwischen gelöscht worden. Cursor spiegle Open VSX.

Fest steht: Über den Cursor-Marktplatz wurde die Version als ganz normales Update verteilt. Für den Visual Studio Marketplace von Microsoft hat bisher niemand eine bösartige Version gemeldet. Ob Open VSX selbst betroffen war, ist offen. Wer seine Erweiterungen von dort bezieht, sollte deshalb trotzdem prüfen.

Was passiert ist

Laut Cursor war die manipulierte Version am 29. Oktober 2026 rund elf Stunden im Marktplatz, etwa von 2:27 bis 13:35 Uhr US-Westküstenzeit. Nach Angaben aus den Berichten waren höchstens 5.000 Nutzer betroffen. Wer automatische Updates eingeschaltet hatte, bekam die Version ohne eigenes Zutun.

Laut The Hacker News steckte in der Hauptdatei der Erweiterung ein eingeschleuster Lader mit 66 Zeilen. Er lief vor dem eigentlichen Code. Nach den Analysen tat er Folgendes:

• Er trug einen fremden SSH-Schlüssel mit dem Kommentar svc-telemetry in die Datei authorized_keys ein. Darin steht, wer sich per SSH ohne Passwort am Rechner anmelden darf.
• Er versuchte, den SSH-Dienst einzuschalten, und baute einen Reverse-Tunnel zum Server der Angreifer auf. Bei einem Reverse-Tunnel öffnet dein Rechner selbst die Verbindung nach außen. Darüber kommen die Angreifer an Firewall und Router vorbei zurück auf deinen Rechner.
• Er richtete sich dauerhaft ein: über einen Startdienst unter macOS, einen Cron-Eintrag unter Linux und eine geplante Aufgabe namens „SysMon“ unter Windows.
• Er schickte Daten über den Rechner an die Angreifer: Hostname, Benutzername, Betriebssystem, Verzeichnisse, Git-Mailadresse, öffentliche IP und die Namen von bis zu 40 Umgebungsvariablen, die nach Zugangsdaten aussehen. Die Werte selbst wurden laut den Analysen nicht übertragen.

Cursor schreibt, dass das Einschalten von SSH auf den meisten macOS- und Windows-Rechnern wohl an fehlenden Adminrechten gescheitert ist. Der Schlüssel und der Autostart wurden trotzdem angelegt, und die Rechnerdaten gingen trotzdem raus. War SSH schon vorher aktiv, ist die Tür offen. Weitere Schadsoftware, die nachgeladen wurde, ist bisher nicht beobachtet worden.

Wie die Version in den Marktplatz kam, ist bis heute nicht öffentlich geklärt. Eine CVE-Nummer gibt es nicht. Hier wurde keine Lücke ausgenutzt, sondern eine Lieferkette manipuliert.

Stand heute

Cursor hat den Marktplatz vorübergehend abgeschaltet und die Version entfernt. Nach eigenen Angaben hat Cursor auch die Zugänge überprüft, die eigenen Schlüssel ausgetauscht und den Server der Angreifer mit Hilfe des Hosters vom Netz genommen. Anthropic hat Version 2.1.314 veröffentlicht. Ein Detail ist widersprüchlich: Cursor nennt in seiner Meldung auch 2.1.312 als manipuliert. StepSecurity hat 2.1.312 und 2.1.314 von Open VSX geprüft und darin keine Spuren gefunden. Wer über Cursor 2.1.312 bekommen hat, sollte deshalb genauso prüfen.

Was du jetzt tun solltest

1. Version prüfen. Schau in der Erweiterungsliste deines Editors nach, ob 2.1.313 (bei Cursor auch 2.1.312) installiert ist oder war. Danach auf 2.1.314 aktualisieren.
2. Deinstallieren reicht nicht. Die Hintertür läuft als eigene Skripte weiter. Durchsuche authorized_keys nach dem Eintrag „svc-telemetry“ und lösche ihn. Prüfe außerdem Autostart-Einträge, Cron und geplante Aufgaben sowie ausgehende SSH-Verbindungen.
3. Bereinigungsskripte nutzen. Cursor stellt Skripte für macOS und Windows und eine Liste mit Erkennungsmerkmalen (Indicators of Compromise) bereit.
4. Isolieren und im Zweifel neu aufsetzen. Wenn du Spuren findest, nimm den Rechner vom Netz. Cursor empfiehlt, eine Neuinstallation zu erwägen.
5. Zugangsdaten tauschen. Wechsle Schlüssel, Tokens und Sitzungen, die von dem Rechner aus erreichbar waren. Mach das von einem sauberen Gerät aus.

Meine Einordnung

KI-Coding-Assistenten laufen mit deinen Rechten, in deinen Projekten und oft neben Cloud-Schlüsseln. Genau deshalb sind sie ein lohnendes Ziel. Der bekannte Name auf dem Paket hat hier nicht geschützt, denn die manipulierte Version lief unter dem echten Herstellernamen. Automatische Updates sind normalerweise gut. Bei Erweiterungen aus Spiegel-Marktplätzen solltest du aber zumindest wissen, woher sie kommen. Eine Coding-Erweiterung hat in deinen SSH-Schlüsseln nichts verloren. Genau so etwas sollte die Überwachung auf dem Rechner erkennen.

Quellen

• Help Net Security: Claude Code extension poisoned with persistent SSH backdoor
• The Hacker News: Official Claude Code VS Code extension
• Cursor: Security notice zu Anthropic.claude-code 2.1.313
• StepSecurity: Trojanized Claude Code Extension

Was passiert ist

Laut dem Advisory SA-CONTRIB-2026-254 schützt das Modul „bestimmte Routen und Entity-Felder nicht ausreichend“. Routen sind die Adressen, unter denen Drupal Funktionen anbietet. Entity-Felder sind die Datenfelder von Objekten wie Bestellungen oder Produkten. Es geht um eine fehlende Autorisierung: Das System prüft nicht richtig, ob jemand eine bestimmte Aktion überhaupt ausführen darf. Die Folge ist ein sogenannter Access Bypass, also das Umgehen von Zugriffsbeschränkungen.

Laut BleepingComputer können Angreifer die Lücke ohne Anmeldung ausnutzen. Drupal schreibt nur, dass der Bypass dem Shopbetreiber „finanziell schaden kann“. Wie die Angriffe genau ablaufen und wie viele es gibt, sagt Drupal nicht. Das bestätigt auch The Hacker News.

Einen CVSS-Wert gibt es bisher nicht. CVSS ist die übliche Skala von 0 bis 10 für den Schweregrad einer Lücke. Drupal nutzt stattdessen ein eigenes Bewertungssystem und vergibt dort 21 von 25 Punkten. In diese Wertung fließt ein, dass die Lücke leicht auszunutzen ist, dass ein Exploit existiert (also ein Werkzeug, mit dem man sie ausnutzen kann) und dass sie alle Installationen betrifft.

Korrektur zu den Versionsangaben

In meinen Posts auf X und WhatsApp stand „betroffen: 0.0.0 bis 2.41 und 3.0.0 bis 3.3.13“. So haben es auch die Nachrichtenseiten formuliert. Das ist missverständlich. Im Advisory selbst steht „<2.41“ und „>=3.0.0 <3.3.13“. Betroffen sind also alle Versionen vor 2.41 und alle 3.x-Versionen vor 3.3.13. Genau diese beiden Versionen enthalten den Fix:

• 3.x-Zweig: Update auf Commerce Core 3.3.13
• Ältere Installationen: Update auf Commerce Core 8.x-2.41

Wer schon 3.3.13 oder 8.x-2.41 einsetzt, ist gegen diese Lücke geschützt.

Wer betroffen ist

Laut BleepingComputer läuft Commerce Core auf mehr als 42.000 Websites, darunter Seiten von Fortune-500-Konzernen und Forschungsuniversitäten. Betroffen sind alle Drupal-Seiten, auf denen das Modul installiert ist, egal ob ein großer Onlineshop oder eine kleine Vereinsseite mit Ticketverkauf. Drupal-Seiten ohne Commerce sind von dieser Lücke nicht betroffen.

Diese Warnung kommt nicht allein. Im Mai 2026 wurde eine SQL-Injection in Drupal Core (CVE-2026-9082) ausgenutzt, und die US-Behörde CISA hat sie in ihren Katalog bekannter ausgenutzter Lücken (KEV) aufgenommen. Etwa zwei Wochen vor dieser Warnung hat Drupal zwei Lücken zur Remote Code Execution geschlossen. Damit können Angreifer aus der Ferne eigenen Code auf dem Server ausführen.

Was du jetzt tun solltest

1. Prüfen, ob Commerce im Einsatz ist. Das geht in der Modulübersicht von Drupal oder über die Abhängigkeiten deines Projekts in Composer.
2. Version abgleichen. Liegt sie unter 3.3.13 (im 3.x-Zweig) oder unter 2.41 (im älteren Zweig), bist du betroffen.
3. Sofort aktualisieren auf 3.3.13 bzw. 8.x-2.41. Weil die Lücke schon ausgenutzt wird, solltest du damit nicht bis zum nächsten Wartungsfenster warten.
4. Bestellungen prüfen. Drupal rät ausdrücklich, die Bestellungen auf Unstimmigkeiten zu kontrollieren, zum Beispiel auf ungewöhnliche Preise, Rabatte, Status oder Zahlungsangaben. Ein Update schließt die Lücke, macht aber keine Manipulationen rückgängig, die schon passiert sind.
5. Bei Agenturen und Hostern nachfragen. Wenn jemand anderes deinen Shop betreut, frag konkret nach, ob das Update installiert ist.

Ich halte vor allem Punkt 4 für wichtig. Bei einer Lücke, die laut Drupal finanziell schaden kann, reicht das Update allein nicht. Man muss auch prüfen, ob in der Zwischenzeit schon jemand etwas verändert hat.

Quellen

• Drupal Security Advisory SA-CONTRIB-2026-254
• BleepingComputer: Drupal warns of critical Commerce Core flaw exploited in attacks
• The Hacker News: Hackers actively exploit highly critical Drupal Commerce flaw

Was passiert ist

Laut GitLabs Sicherheitshinweis steckt der Fehler im Compiler für reguläre Ausdrücke (Regex, also Suchmuster für Text), den GitLab für CI/CD-Konfigurationen nutzt. CI/CD steht für die automatisierten Build- und Deploy-Pipelines. Ein präparierter Regex löst einen Ganzzahlüberlauf aus, also eine Rechnung, deren Ergebnis zu groß für den vorgesehenen Speicher ist und deshalb „umkippt“. Am Ende kann ein Angreifer ohne Anmeldung Code auf dem GitLab-Server ausführen. Laut Rapid7 liegt die Ursache in Onigmo, der Regex-Engine von Ruby.

Betroffen sind die GitLab Community Edition und die Enterprise Edition auf selbst betriebenen Servern. GitLab.com und GitLab Dedicated sind laut GitLab bereits gepatcht. Den Fix gab es am 12. Oktober in den Versionen 19.2.8, 19.3.5 und 19.4.2. Schon am Tag danach veröffentlichte Rapid7 einen Proof of Concept, also Code, der die Ausnutzbarkeit demonstriert.

Der Fall Alpine Linux

Wie The Hacker News und heise berichten, hat ein unbekannter Angreifer am 20. und 21. Oktober versucht, die Lücke auf dem GitLab-Server von Alpine Linux auszunutzen. Dafür nutzte er ein frisch registriertes Konto und schickte präparierte CI-Konfigurationen. Die GitLab-Worker stürzten dabei achtmal ab, viermal kam der Angreifer ein Stück weit in die Ausnutzung hinein. Spätere Versuche am 25. und 26. Oktober wurden blockiert.

Hier muss man Versuch und Erfolg sauber trennen. Alpine fand keinen Beleg, dass Code ausgeführt wurde, kann es aber auch nicht ausschließen. Ein erfolgreicher Angriff hinterließe keinen Absturz und keine Spur im Web-Log, und ein Teil der Logs vom Angriffstag fehlt. Alpine behandelte den Server deshalb als kompromittiert, baute ihn neu auf, setzte alle Passwörter zurück und tauschte GitLabs geheime Schlüssel aus. Die Paket-Builds vom 20. bis 24. Oktober stimmten mit Aufzeichnungen außerhalb von GitLab überein, und die Signaturschlüssel lagen nie auf dem Server.

Der lehrreichste Teil: Alpine hatte am 13. Oktober versehentlich auf 19.3.4 statt 19.3.5 aktualisiert. Auch das spätere Update auf 19.3.6 schloss die Lücke nicht. GitLabs Fix steckt nämlich in dem Ruby, das GitLab in seinen eigenen Linux-Paketen und offiziellen Images mitliefert. Alpines Image verwendete dagegen ein normales Ruby. Die gefixten Ruby-Versionen sind 3.3.13, 3.4.12 und 4.0.9.

Was sich seit dem Post geändert hat

Am 21. Oktober hat GitLab mit CVE-2026-110264 eine weitere Lücke geschlossen, ebenfalls CVSS 10.0. Auch sie ist ein Ganzzahlüberlauf im Regex-Compiler und erlaubt Code-Ausführung ohne Anmeldung. Betroffen sind laut GitLab alle Versionen ab 7.0. Behoben ist sie in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13. Mehrere Fachmedien, darunter eSecurity Planet, weisen darauf hin, dass die Patches vom 12. Oktober diese zweite Lücke nicht abdecken. Für CVE-2026-110264 habe ich keine Meldung über aktive Ausnutzung gefunden, auf der KEV-Liste steht nur CVE-2026-97229.

Zur Einordnung der Dringlichkeit: Für US-Bundesbehörden empfiehlt CISA, die Fixes bis zum 1. November 2026 einzuspielen. Das gilt formal nur für diese Behörden, ist aber ein guter Maßstab für alle anderen.

Was du jetzt tun solltest

• Auf den aktuellen Stand gehen, nicht nur auf den ersten Fix. Also mindestens 19.5.1, 19.4.3, 19.3.6 oder 19.2.9, je nach Versionszweig. Damit sind beide Regex-Lücken abgedeckt.
• Ruby prüfen, wenn du GitLab nicht über die offiziellen Pakete oder Images betreibst, etwa als Quellinstallation oder mit einem Distributions-Image. Ruby muss auf 3.3.13, 3.4.12, 4.0.9 oder neuer stehen. Wer das alpinelinux/gitlab-Image nutzt, sollte 19.3.6 neu ziehen. Erst der Build vom 27. Oktober enthält das gefixte Ruby.
• Nach Spuren suchen. Gehäufte Worker-Abstürze, 502-Fehler und fehlgeschlagene CI-Jobs seit dem 12. Oktober sind Warnzeichen, ebenso neu registrierte Konten mit auffälligen CI-Konfigurationen. GitLab stellt für Selbsthoster eigene Erkennungsregeln bereit, darunter „Onigmo native worker crash“.
• Bei Verdacht wie Alpine handeln. Lässt sich ein Erfolg nicht ausschließen, solltest du Passwörter, Personal Access Tokens, Runner-Tokens, CI/CD-Variablen und Webhook-Zugangsdaten rotieren.
• Offene Registrierung überdenken. Bei Alpine reichte ein frisch angelegtes Konto. Wer keine öffentliche Registrierung braucht, sollte sie abschalten.

Meine Einordnung: Gefährlich ist hier nicht nur die Lücke selbst, sondern das falsche Gefühl von Sicherheit nach dem Patch. Ob du wirklich geschützt bist, zeigt nicht die GitLab-Versionsnummer allein. Es hängt auch davon ab, welches Ruby tatsächlich darunter läuft.

Quellen

• GitLab: Critical Patch Release 19.4.2 (CVE-2026-97229)
• GitLab: Critical Patch Release 19.5.1 (CVE-2026-110264)
• NVD: CVE-2026-97229
• The Hacker News: CISA nimmt GitLab-RCE in KEV auf
• The Hacker News: Angriffsversuch auf Alpine Linux
• heise Security: Cisco-Firewalls und GitLab-Lücke werden angegriffen
• Rapid7: CVE-2026-97229
• eSecurity Planet: Zweite 10.0-Lücke bei GitLab im Oktober

Was passiert ist

Betroffen ist der Code, der neue IPv4-Verbindungen aufbaut. Es handelt sich um eine Race Condition: Zwei CPUs greifen gleichzeitig auf dieselben Daten zu, und das Ergebnis hängt davon ab, welche zuerst dran ist. Die Folge ist ein Use-after-free, der Kernel liest also Speicher, den er schon freigegeben hat. Konkret geht es um IP-Optionen aus einer Verbindungsanfrage, die der Kernel an den neuen Socket weiterreicht, ohne sie zu kopieren. The Hacker News und heise berichten übereinstimmend, dass IPv6 nicht betroffen ist, weil der Kernel die Optionen dort kopiert.

Der fehlerhafte Commit stammt laut heise vom Oktober 2015. Im Kernel-Fix wird Anthropic-Forscher Xinyang Ge als Melder genannt. Anthropic schreibt, Claude habe den Exploit nach „initial prompting“ selbst erstellt. Der Exploit arbeitet in zwei Stufen: Zuerst verrät der Kernel Speicheradressen, womit sich KASLR aushebeln lässt (die Zufallsverteilung des Kernels im Speicher). Danach wird ein Funktionszeiger überschrieben, sodass ein Befehl als root läuft. Ein verlorenes Rennen lässt nur den einzelnen Verbindungsversuch scheitern, das System stürzt dabei nicht ab. Ein Angreifer kann es also einfach wieder versuchen. In Anthropics Test dauerte das Adressleck 48 Minuten, die Codeausführung danach noch fünf. Code, Kernelversion und Testaufbau hat Anthropic nicht veröffentlicht.

Wichtig ist eine Einschränkung: Anthropics Exploit zielte auf Server, auf denen ein Dienst über Multipath-TCP (MPTCP) lauscht. Das ist eine TCP-Erweiterung, die eine Verbindung über mehrere Netzwege verteilt. Ob Server ohne MPTCP genauso angreifbar sind, ist offen. Red Hat geht davon aus, dass jeder erreichbare TCP-Dienst reicht, um die Race Condition auszulösen. Go-Programme nutzen MPTCP laut heise standardmäßig.

Warum die Bewertungen so weit auseinandergehen

Die 9.8 stammt vom Kernel-CVE-Team. Andere sehen es anders. Red Hat nennt auf seiner CVE-Seite 5.9, im maschinenlesbaren Advisory 8.1. Oracle und SUSE vergeben 8.1, Amazon 7.0. Der Grund ist vor allem, wie schwer man das Rennen gewinnen kann. Für mich zählt am Ende: Der Angriff läuft aus der Ferne, braucht keine Zugangsdaten, und es gibt einen funktionierenden Root-Exploit, auch wenn der nicht öffentlich ist. Das reicht, um das Update ganz nach oben auf die Liste zu setzen.

Angriffe in freier Wildbahn sind bisher nicht bekannt. Weder Hersteller noch CVE-Eintrag oder Anthropic berichten davon, und im KEV-Katalog der US-Behörde CISA steht die Lücke bislang nicht.

Wer betroffen ist und wo es Patches gibt

Betroffen sind alle Kernel ab 4.4 mit IPv4, also praktisch jeder Linux-Server. Upstream ist der Fehler behoben in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3. Bei den Distributionen sieht es laut The Hacker News (Stand 29. Oktober) so aus:

• Debian: Trixie und Bookworm haben Patches.
• Oracle Linux 7 bis 10 (UEK): Gepatcht seit 16. Oktober.
• SUSE: openSUSE Leap 16.0 und SUSE Linux Micro 6.2 sind gepatcht, SLES-Versionen sind teils im Test.
• Amazon Linux 2023: Die Pakete kernel6.18 und kernel6.12 sind gepatcht, der Rest ist noch offen.
• Ubuntu (16.04 bis 26.10): Noch kein Fix veröffentlicht.
• RHEL 8, 9, 10 und OpenShift 4: Noch kein Fix. Red Hat hatte die Updates zunächst „auf ein künftiges Update verschoben“. RHEL 7 ist nicht betroffen.

Was du tun solltest

1. Patchen, sobald es geht. Wo es Updates gibt, einspielen und neu starten. Ein neuer Kernel wirkt erst nach dem Reboot.
2. Advisories beobachten. Wer Ubuntu oder RHEL nutzt, sollte täglich nachsehen.
3. Erst die exponierten Systeme. Server, deren TCP-Dienste aus dem Internet erreichbar sind, kommen zuerst dran.
4. MPTCP prüfen. Für Go-Dienste nennt das Go-Security-Team GODEBUG=multipathtcp=0 als Notlösung. Die Entwickler nennen das selbst fragil, und Systeme ohne MPTCP sind womöglich trotzdem verwundbar. Einen Patch ersetzt das nicht. Red Hat sagt, es gebe keine Mitigation, die seinen Anforderungen genügt.

Einordnung

Ein Fehler, den mehrere Fachleute vor elf Jahren geprüft und durchgewunken haben, wird jetzt von einem KI-Modell gefunden, samt Exploit. heise-Autor Jürgen Schmidt erwartet „eine riesige Welle von Schwachstellen“. Das halte ich für realistisch. Was Verteidiger finden können, finden Angreifer früher oder später auch. Patch-Zyklen von Wochen werden damit zum Risiko.

Quellen

• The Hacker News: Linux Kernel TCP Flaw with 9.8 CVSS
• heise Security: Erneut kritischer Bug in Linux-TCP/IP aufgedeckt
• CVE-Eintrag CVE-2026-98432 (CVEProject)

Was passiert ist

Die Lücke ist eine sogenannte Race Condition. Damit ist ein Fehler gemeint, bei dem das Ergebnis vom zeitlichen Ablauf abhängt: Wer im richtigen Moment zugreift, „gewinnt das Rennen“. Laut den Release Notes zu WordPress 7.1.4 handelt es sich um „eine Race Condition bei Core-Updates, die zu Remote Code Execution führen kann“. Gemeldet hat sie der Sicherheitsforscher Umut Bayram. Remote Code Execution (RCE) bedeutet, dass ein Angreifer aus der Ferne eigenen Programmcode auf dem Server ausführen kann.

Das Problem in groben Zügen: Bei einem Update mit dem vollständigen Core-Paket entpackt WordPress die neuen Dateien zuerst in ein Zwischenverzeichnis unter wp-content/upgrade. Dessen Pfad ist vorhersehbar, und auf vielen Servern ist er aus dem Internet erreichbar. In dieser Kopie liegt auch der WordPress-Installer. Wer ihn in dem kurzen Zeitfenster aufruft, in dem die Dateien dort liegen, kann laut The Hacker News bis zur Ausführung von PHP-Code kommen, und zwar ohne Anmeldung.

Ganz einfach ist das nicht. Mehrere Bedingungen müssen zusammenkommen: ein Update mit vollem Paket, öffentlicher Web- und PHP-Zugriff auf das Zwischenverzeichnis, ein bekannter oder erratener Pfad und genug Zeit, bevor WordPress die temporären Dateien wieder löscht. In Laborumgebungen existierte das Verzeichnis laut heise Security nur wenige Sekunden. SecurityWeek spricht deshalb von hoher Angriffskomplexität. Die Bewertung liegt bei CVSS 8.1 („hoch“). Eine CVE-Nummer gibt es bisher nicht.

Die Angriffsversuche

Die Sicherheitsfirma Wordfence (Defiant) hat nach eigenen Angaben innerhalb von 24 Stunden 62.969 Angriffe auf diese Lücke blockiert. Die erste Übereinstimmung mit der neuen Firewall-Regel kam neun Minuten nach deren Einführung. Allein in den ersten 21 Stunden zielten mehr als 18.500 Anfragen auf den Installer im Zwischenverzeichnis. Zwei der aktivsten Quellen haben kleine Gruppen von Seiten rund 14,5 Stunden lang immer wieder abgefragt, offenbar in der Hoffnung, ein laufendes Update zu erwischen.

Wichtig ist die Unterscheidung: Das sind Versuche. Keine der Quellen berichtet bisher von einem bestätigten erfolgreichen Einbruch.

Was sich seit meinem Post geändert hat

Inzwischen ist klarer, wie genau gepatcht wird. Die aktuelle Version ist 7.1.4. Für ältere Zweige gibt es Backports bis hinunter zu 4.7.39, zum Beispiel 7.0.8, 6.9.11 und 6.8.12. Laut SecurityWeek legt WordPress das Zwischenverzeichnis jetzt unter einem zufälligen Namen an, ergänzt einen Index-Schutz und übernimmt dort abgelegte Konfigurationsdaten nicht mehr. Version 7.1.4 schließt außerdem 22 weitere Sicherheitsprobleme, darunter mehrere XSS-Lücken. Versionen vor 4.7 bekommen gar keine Sicherheitsupdates mehr.

Warum das wichtig ist

Das Perfide an dieser Lücke ist, dass sie genau in dem Moment greift, in dem man das Richtige tut, nämlich beim Update. Wer WordPress noch auf einer betroffenen Version betreibt, ist bei jedem künftigen Core-Update mit vollem Paket diesem Risiko ausgesetzt, solange das Zwischenverzeichnis erreichbar bleibt. Hinzu kommt, dass schon die Lücke von Ende September innerhalb weniger Stunden angegriffen wurde. Die Zeit zwischen Patch und Angriff ist bei WordPress praktisch null.

Was du jetzt tun solltest

• Updaten: auf 7.1.4 oder auf den Backport deines Zweigs. Im Dashboard unter „Aktualisierungen“ nachsehen, welche Version wirklich läuft.
• Automatische Updates prüfen: Sie sind für Sicherheitsreleases eigentlich aktiv, werden aber manchmal durch Hoster, Konfiguration oder Dateirechte blockiert. Nicht davon ausgehen, dass sie gelaufen sind, sondern es kontrollieren.
• Zwischenverzeichnis absichern: Patchstack empfiehlt, den Webzugriff auf wp-content/upgrade/ zu sperren und sicherzustellen, dass das Verzeichnis nicht auflistbar ist.
• Logs prüfen: nach auffälligen Aufrufen von PHP-Dateien unter wp-content/upgrade suchen, besonders wenn das Update erst nach dem 28. Oktober eingespielt wurde.
• Auf Spuren achten: unbekannte Admin-Konten, Plugins, die niemand installiert hat, und PHP-Dateien, die nicht dorthin gehören.

Mein Rat: Wer mehrere WordPress-Seiten betreut, sollte heute jede einzelne prüfen und sich nicht auf „läuft automatisch“ verlassen. Die Angreifer prüfen ebenfalls jede einzelne Seite.

Quellen

• The Hacker News: WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts
• SecurityWeek: Fresh WordPress Vulnerability in Attackers' Crosshairs
• heise Security: WordPress-Update stopft Schadcode-Lücke, Exploit-Versuche beobachtet
• WordPress.org: Version 7.1.4
• Patchstack: WordPress 7.1.4 Security Release

Was passiert ist

KI-Coding-Agenten wie OpenAI Codex oder Claude Code lesen beim Start automatisch Anweisungsdateien im Arbeitsverzeichnis, also dem Ordner, in dem man sie startet. Bei Codex heißt diese Datei AGENTS.md, bei Claude Code CLAUDE.md. Darin stehen normalerweise Projektregeln wie „nutze pnpm“ oder „Tests liegen in /test“. Der Agent behandelt den Inhalt als Arbeitsanweisung.

Laut BleepingComputer war das Arbeitsverzeichnis des Kunden sein Downloads-Ordner. Dort lag eine AGENTS.md, getarnt als gewöhnliche Entwicklernotizen. Sie wies den Agenten an, das npm-Paket „function-color“ zu installieren. npm ist der Paketmanager für JavaScript. Nach The Hacker News zieht dieses Paket ein weiteres nach („function-flag“), das als Downloader eine Windows-Schadsoftware nachlädt und ausführt. Zusätzlich sollte Codex einen Server in seine globale Konfiguration eintragen. Die Änderung hätte also auch Sitzungen in ganz anderen Ordnern betroffen.

Wie die Datei in den Ordner kam, ist weiterhin unklar. Forever Security hat gezeigt, dass eine Webseite eine Datei namens AGENTS.md in den Downloads-Ordner legen kann. Chrome, Edge und Firefox speichern dort standardmäßig und zeigen nur eine Benachrichtigung. BleepingComputer hat diesen Proof of Concept, also einen Machbarkeitsnachweis, mit einer harmlosen Datei nachvollzogen. Ob ein echter Angreifer genau diesen Weg genutzt hat, ist aber nicht belegt.

Neu seit dem Post: Labor-Ergebnisse und kein Patch

Beim Kunden blieb es beim Versuch. Im Labor sah es anders aus:

• Codex: Laut BleepingComputer funktionierte ein harmloser Test-Payload (Öffnen des Taschenrechners) in rund 90 Prozent der Versuche.
• Claude Code: Eine präparierte CLAUDE.md, getarnt als interne Gateway-Konfiguration, sollte den API-Verkehr auf einen Server der Forschenden umleiten. Damit wäre das Login-Token offengelegt worden, und der Server hätte sich als Modell ausgeben und Befehle zurückschicken können. Das gelang in etwa der Hälfte der Fälle. Claude fragt bei solchen Änderungen meist nach Freigabe und lehnt Verdächtiges oft ab.

Einen Patch wird es nicht geben. Forever Security sagt selbst, dass OpenAI und Anthropic nichts zu reparieren haben. Der Agent tut genau das, wofür er gebaut ist: Er folgt den Anweisungen im Arbeitsverzeichnis. Eine Stellungnahme der Hersteller nennen beide Berichte nicht. Laut BleepingComputer empfehlen beide ohnehin, Agenten im Projektordner zu starten.

Warum das wichtig ist

Das ist im Kern eine Prompt-Injection: Fremder Text wird vom Modell als Befehl behandelt. Neu ist der Ort. Kein präpariertes Repository, keine manipulierte Webseite im Chat, sondern ein Ordner, in dem jeder Browser ungefragt Dateien ablegt. Und das ist kein Randfall. Laut BleepingComputer starten Hunderte Kunden von Forever Security Agenten wie Claude Code, Codex oder Cursor CLI aus dem Downloads-Ordner, allein bei Claude Code waren es über 1.300 Sitzungen.

Ich halte das für einen Weckruf. Anweisungsdateien sehen aus wie Doku, wirken aber wie ein Skript mit den Rechten des Agenten. Und die sind oft dieselben wie deine eigenen.

Wer betroffen ist

Alle, die KI-Coding-Agenten lokal nutzen, besonders wenn sie die Agenten im Downloads- oder Home-Ordner starten. Bestätigt ist bisher ein gestoppter Versuch bei einem Kunden, ein Schaden ist nicht bekannt.

Was du konkret tun solltest

• Agenten nie im Downloads- oder Home-Ordner starten. Immer im Wurzelverzeichnis des jeweiligen Projekts.
• Fremde AGENTS.md, CLAUDE.md und ähnliche Dateien lesen, bevor der Agent sie liest. Das gilt auch für frisch geklonte Repositories.
• Konfiguration prüfen: Bei Codex die config.toml auf unbekannte Server-Einträge, bei Claude Code die settings.json auf eine unerwartete ANTHROPIC_BASE_URL oder fremde API-Endpunkte.
• Freigabe-Abfragen und Sandbox eingeschaltet lassen. Misstrauisch werden, wenn eine Datei den Agenten auffordert, sie abzuschalten.
• Paketinstallationen nur nach Freigabe. Kein „auto-approve“ für npm, pip und Co.
• Bei Fund Token rotieren. Wer eine untergeschobene Datei findet, sollte davon ausgehen, dass das Login-Token abgeflossen ist.
• Unbekannten Code isoliert testen, etwa in einer VM oder einem Container.

Kurz gesagt: Behandle Anweisungsdateien wie fremden Code. Denn für deinen Agenten sind sie genau das.

Quellen

• The Hacker News: Malicious File in Downloads Folder
• BleepingComputer: AI coding agents hijacked using AGENTS.md file in Downloads folder

Was passiert

Das Werkzeug nimmt ein gestohlenes Token und schiebt in jedes Repository, auf das dieses Token Schreibzugriff hat, einen neuen Workflow. Ein Workflow ist eine Automatisierung in GitHub Actions, also GitHubs eingebautem CI/CD-System. Der eingeschleuste Workflow schreibt die Secrets, die der Job lesen kann, in sein eigenes Run-Log. Damit GitHubs Maskierung nicht greift, sind sie dabei kodiert. Das Werkzeug lädt das Log über die API herunter und löscht den Run wenige Sekunden später.

Der heikle Punkt: Die Daten verlassen GitHub über GitHub selbst. Es gibt keinen Angreifer-Server und keine ausgehende Verbindung, die eine Firewall blocken könnte. Eine Variante greift laut Wiz zusätzlich auf Secrets einzelner Deployment-Umgebungen zu, oft also auf Produktionszugänge. Seit etwa 19. Oktober gibt es außerdem eine Version, die auf selbst gehosteten Runnern nach Zugangsdaten sucht. Wiz nennt diese Variante fehlerhaft und hat keinen erfolgreichen Lauf gesehen.

Wie groß ist das?

Im Post hatte ich, gestützt auf Dark Reading, von Tausenden betroffenen Entwickler-Repos gesprochen. Die Zahlen von Wiz sind genauer: mehr als 13.500 eingeschleuste Branches aus über 850 kompromittierten Accounts, beobachtet seit dem 15. September. Wie viele Organisationen tatsächlich Secrets verloren haben, sagt Wiz nicht. Am 24. Oktober lief die Kampagne noch. Etwa zwei Drittel der Accounts waren da auf GitHub aber nicht mehr erreichbar.

Die Tokens stammen laut Wiz unter anderem aus Infostealer-Logs und aus früheren Lieferkettenangriffen, etwa der Kompromittierung des Scanners Trivy im März. Infostealer sind Schadprogramme, die Passwörter und Tokens von Entwicklerrechnern abgreifen. Eine Sicherheitslücke im eigentlichen Sinn steckt nicht dahinter, deshalb gibt es weder CVE noch Patch. Missbraucht wird ganz normaler Schreibzugriff.

Was sich seit dem Post geändert hat

Ein Detail gehört nachgereicht: Seit dem 28. Juli hält GitHub potenziell bösartige Workflow-Runs an, bis jemand mit Schreibrechten sie freigibt. Das gilt aber nur für öffentliche Repositories auf github.com. Jeder öffentliche Gheist-Run, den Wiz geprüft hat, hing in dieser Warteschleife fest. Der Wiz-Bericht trägt deshalb auch den Titel, dass der Angriff „stolpert“.

Bei privaten Repositories und bei GitHub Enterprise Server greift dieser Schutz nicht. Dort hat Wiz in Audit-Logs gesehen, wie die Runs durchliefen und gelöscht wurden. In einem Fall wurden Stunden später Cloud-Zugangsdaten derselben Organisation genutzt, um AWS Secrets Manager abzufragen. Woher genau diese Zugangsdaten stammten, lässt Wiz offen.

Wer betroffen ist

Betroffen ist jede Organisation, deren Mitglieder oder Automations-Accounts Tokens mit Schreibrechten besitzen, die irgendwo abgeflossen sein könnten. Besonders exponiert sind private Repos und selbst betriebene Enterprise-Server.

Was du tun solltest

Prüfen:

• Nach Branches suchen, die mit ci-sync- beginnen und nur eine neue Workflow-Datei namens sync-check.yml mit der Commit-Nachricht „ci: sync config“ enthalten.
• In den GitHub-Audit-Logs nach Runs auf solchen Branches suchen, die kurz nach dem Ende gelöscht wurden, und nach dem User-Agent gheist.
• Wer OIDC nutzt, also kurzlebige Cloud-Anmeldungen direkt aus dem Workflow, sollte die Cloud-Audit-Logs nach Rollenübernahmen mit ci-sync- im Subject durchsuchen. Das funktioniert auch ohne GitHub-Logs.

Wenn ein Repo betroffen ist:

• Alle Repository-, Organisations- und Umgebungs-Secrets rotieren, die das Repo nutzen konnte. Gelöschte Runs machen den Abfluss nicht rückgängig.
• Die Tokens widerrufen, die die Commits gepusht haben, und die Rechner ihrer Besitzer auf Infostealer prüfen.
• Lief so ein Branch auf einem selbst gehosteten Runner, die Maschine und ihre Cloud-Rolle als kompromittiert behandeln.
• Angehaltene sync-check-Runs nicht freigeben.

Härten:

• Für Umgebungen mit Produktions-Secrets Pflicht-Reviewer einrichten.
• OIDC-Vertrauensrichtlinien auf geschützte Branches oder Umgebungen beschränken.
• GitHub Apps oder kurzlebige, fein granulierte Tokens statt klassischer Personal Access Tokens verwenden.

Meine Einordnung: Gheist zeigt, dass ein Token mit Schreibrechten praktisch ein Schlüssel zu allen Secrets eines Repos ist. Die Sperre für öffentliche Repos ist gut, aber gerade die wertvollen Daten liegen meist in privaten Repos. Dort muss man sich selbst schützen.

Quellen

• The Hacker News: Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logs
• Help Net Security: Private repos still leak secrets to Gheist
• Dark Reading: 'Gheist' Weaponizes GitHub Tokens to Steal Cloud Secrets
• Wiz Research: Gheist

Seit meinem Post auf X und im WhatsApp-Kanal gab es neue Berichte zur nächsten Xbox. Die stehen weiter unten.

Nintendo: Switch 2 verkauft sich, aber langsamer

Laut Nintendos Quartalszahlen hat die Switch 2 bis zum 30. Juni 2026 weltweit 23,68 Millionen Geräte ausgeliefert (Gematsu). Wichtig ist das Wort „ausgeliefert“. Gemeint ist Sell-in, also was Nintendo an den Handel geliefert hat. Wie viel davon schon bei Kundinnen und Kunden angekommen ist (Sell-through), weiß nur der Handel. VGChartz schätzt diese Zahl auf rund 21,84 Millionen.

Es gibt auch eine Kehrseite. Im ersten Quartal lagen die Hardware-Verkäufe 34,4 Prozent unter dem Vorjahr, und Nintendo rechnet im Geschäftsjahr bis März 2027 mit 16,5 Millionen Geräten (Game Developer). Das ist ein normales zweites Jahr nach einem sehr starken Start. Mit einem sterbenden Markt hat es nichts zu tun. Die nächsten Quartalszahlen kommen Anfang November.

Microsoft: Project Helix ist offiziell, der Termin nicht

Auf der GDC im März 2026 hat Microsoft die nächste Xbox mit dem Codenamen Project Helix vorgestellt (Xbox Wire, VGC). Sie läuft auf einem eigens entwickelten AMD-Chip (SoC, „System on a Chip“, also CPU und Grafik auf einem Baustein) und soll Xbox- und PC-Spiele abspielen. Alpha-Dev-Kits, also frühe Entwicklergeräte, sollen 2027 an Studios gehen (Gematsu).

Neu seit meinem Post: Im Oktober berichtete Pure Xbox unter Berufung auf Fortune, dass zuerst ein Xbox-Handheld Ende 2027 kommen soll und Helix selbst erst 2028. Intern soll mit Preisen deutlich über 1.000 US-Dollar gerechnet werden, sofern Microsoft nicht subventioniert. Microsoft hat weder Termin noch Preis bestätigt. Das ist ein Bericht, keine Ankündigung. Er passt aber zum Bild, dass die nächste Generation später kommt und teuer wird. Laut Pure Xbox plant die Xbox-Führung außerdem eine „Familie“ von Geräten, einige davon von Partnern gebaut. Für ein Ende der Konsolen spricht das nicht.

Sony: PS6 in Arbeit, Termin offen

Sony hat im Mai und erneut im August 2026 gesagt, dass Termin und Preis der PS6 noch nicht feststehen (Push Square, Mai, Push Square, August). Als Grund nennt die Konzernspitze die Knappheit bei Bauteilen (TechRadar), vor allem die hohen Speicherpreise (Insider Gaming). Hier kommt KI ins Spiel. Rechenzentren für generative KI kaufen riesige Mengen Arbeitsspeicher, und das treibt die Preise für alle anderen hoch. Auch Konsolenhersteller zahlen also für den KI-Boom mit.

Ein Start von PS6 und nächster Xbox im Jahr 2027 ist deshalb nicht belegt. Das Datum stammt aus Leaks. Laut Bloomberg ist eine Verschiebung auf 2028 oder 2029 möglich (Vice).

Der Markt: Wachstum, aber unscharfe Zahlen

Alle Marktprognosen, die ich gefunden habe, rechnen bis 2032 mit Wachstum: IMARC mit 59,4 Mrd. USD (IMARC), Meticulous Research mit 67,2 Mrd. (Meticulous), Stratistics mit 46,4 Mrd., SNS mit 55,4 Mrd. Die Ausgangswerte der Institute widersprechen sich allerdings. Diese Zahlen taugen deshalb nur als grobe Spanne. Einen Rückgang auf null sagt keine davon voraus.

Was sich tatsächlich verschiebt: Laut Newzoo liegt PC beim Umsatz vor den Konsolen und wächst schneller, 6,6 Prozent gegenüber 4,4 Prozent pro Jahr (GameDev.net, ChannelNews). Die Überschriften sprechen von „bis 2028“, die Zusammenfassungen davon, dass PC schon vorn liegt. Den Originalreport habe ich nicht eingesehen.

Was das für dich heißt

• Wer jetzt eine Konsole will, muss nicht auf das „Ende“ warten. PS5, Xbox Series und Switch 2 werden noch Jahre unterstützt.
• Wer auf die nächste Generation wartet, sollte eher mit 2028 als mit 2027 rechnen und mit höheren Preisen. Offizielle Preise gibt es nicht. Zahlen wie „1.000 Dollar“ sind Spekulation.
• Wer zwischen PC und Konsole schwankt: Die Grenze verschwimmt. Helix soll PC-Spiele können, Xbox-Funktionen kommen auf Windows. Die eigene Spielebibliothek wird wichtiger als die Hardware.
• Bei Schlagzeilen zu Verkaufszahlen lohnt der Blick, ob „ausgeliefert“ oder „verkauft“ gemeint ist.

Mein Fazit: Konsolen verschwinden nicht. Sie werden PC-ähnlicher, teurer und kommen später. Ein Teil davon geht auf den KI-Boom zurück.

Quellen

• Gematsu: Switch 2 worldwide sales top 23.68 million
• Game Developer: Switch 2 unit sales down 34.4% YoY
• Xbox Wire: Building the Next Generation of Xbox
• Gematsu: Project Helix alpha dev kits to ship in 2027
• Pure Xbox: Report – handheld 2027, Helix 2028
• Push Square: Sony still hasn't decided when to launch PS6
• Insider Gaming: PS6 launch window uncertain amid memory prices
• GameDev.net: Newzoo on PC vs. console revenue
• IMARC: Gaming console market

Was passiert ist

Die Lücke trägt inzwischen die Kennung CVE-2026-111497. Bekannt ist sie als „Node2Shell“, je nach Quelle auch als HTTP2Shell, Broccoli2Shell oder Brotli2Shell. Es handelt sich um einen Out-of-bounds-Write: Das Programm schreibt Daten über das Ende eines reservierten Speicherbereichs hinaus und überschreibt dabei, was dahinter liegt. Laut Brandefense und weiteren Analysen wertet der Decoder einen bestimmten ungültigen Datenstrom fälschlich als „brauche mehr Input“ statt als Formatfehler. Danach hängt er weitere Daten an einen internen Puffer von acht Byte an und schreibt über dessen Ende hinaus.

Die Folgen reichen vom Absturz über das Auslesen von Prozessspeicher bis zur Ausführung von Schadcode. Google bewertet die Lücke mit CVSS 4.0 als 9.2 (kritisch). Microsoft vergibt CVSS 3.1 mit 8.1 und schätzt eine Ausnutzung als „wahrscheinlicher“ ein (SecurityWeek).

Betroffen sind die Brotli-Versionen 1.0.3 bis 1.2.0 auf allen Plattformen. Gefunden hat den Fehler OpenAI Codex Security. Die eigentliche Korrektur steckte laut OpenAI schon seit Februar im Brotli-Quellcode, galt damals aber nicht als Sicherheitsfix. Eine neue Version erschien erst jetzt.

Was sich seit meinem Post geändert hat

Als ich gepostet habe, war noch unklar, ob die Lücke ausgenutzt wird. Jetzt gibt es dazu Neues: Die US-Behörde CISA hat CVE-2026-111497 am 27. Oktober in ihren Katalog bekannter ausgenutzter Lücken (KEV) aufgenommen. US-Bundesbehörden müssen bis zum 10. November patchen. Wer angreift und wie, sagt CISA nicht.

Belegt sind bisher Angriffsversuche auf Honeypots, also Lockrechner, die Angriffe aufzeichnen sollen. ELLIO hat am 26. Oktober eine bösartige Anfrage gegen Node.js 24.22.0 registriert. Laut ELLIO war der Exploit aber kaputt und lieferte in 50 Tests keine Shell. Previdian hat am 27. Oktober einen Versuch protokolliert und ausdrücklich betont, dass das keinen Erfolg bedeutet. Erfolgreiche Einbrüche in produktive Systeme sind öffentlich bisher nicht bekannt.

Im Labor sieht das anders aus. Imperva hat Codeausführung auf dem offiziellen Node.js-Image erreicht, allerdings nicht bei jedem Versuch. Es gibt öffentliche Proof-of-Concepts, also Demonstrations-Exploits. Ob die Lücke praktisch zu Codeausführung führt oder vor allem Abstürze verursacht, wird noch diskutiert. Der Unterschied ist für die Praxis egal: patchen muss man so oder so.

Wer betroffen ist

Angreifbar ist nur, wer Brotli-Daten aus nicht vertrauenswürdiger Quelle dekodiert. Das können komprimierte HTTP-Request-Bodys sein, Antworten fremder Server oder komprimierte Dateien. Ein nackter Node.js-HTTP-Server tut das nicht von selbst, Middleware wie Express 5 oder body-parser 2 schon. In .NET ist der Pfad nicht standardmäßig aktiv, sondern läuft über Request-Dekompression in ASP.NET Core, automatische Dekompression im HttpClient oder direkte Nutzung von BrotliStream/BrotliDecoder. Apache und Nginx gelten in der Standardkonfiguration als nicht betroffen.

Gepatchte Versionen laut SecurityWeek und heise:

• Brotli: 1.0.10, 1.1.1, 1.2.1
• Node.js: 22.23.4, 24.22.1, 26.12.1 (seit 21. Oktober). Ältere Linien ohne Support bekommen keinen offiziellen Fix.
• Python: Brotli 1.2.1 und brotlicffi 1.2.1.0
• .NET: 8.0.33, 9.0.22, 10.0.14 und .NET 11 RC 3 (seit 25. Oktober), dazu Visual Studio 2019, 2022, 2026
• PowerShell: 7.4, 7.5 und 7.6 mit aktuellen Updates
• Bun, Envoy und Istio haben ebenfalls nachgezogen.

Laut Tracker broccoli2shell.com fehlen Patches noch bei DuckDB, Apache Arrow, 7-Zip-zstd, p7zip und EDK II. Broadcom meldet zudem VMware SDDC Manager als betroffen, Patches stehen dort noch aus. Auch Bindings für Java, PHP, Ruby und Go, die die C-Bibliothek einbinden, kommen in Frage.

Was du tun solltest

1. Laufzeiten aktualisieren: Node.js, Bun, .NET und PowerShell auf die oben genannten Stände bringen.
2. Abhängigkeiten prüfen: In Python-Projekten nach Brotli und brotlicffi suchen, auch als indirekte Abhängigkeit. Für andere Sprachen gilt dasselbe für Brotli-Bindings.
3. Dienste neu starten: Laufende Prozesse nutzen den alten Code weiter, bis sie neu gestartet sind.
4. Container-Images neu bauen, und zwar auf gepatchtem Basis-Image. Ein Update auf dem Host hilft dem Container nicht.
5. Übergangsweise Brotli-Dekodierung abschalten, wenn ein Update noch nicht möglich ist. Aikido gibt dafür Hinweise.

Meine Einordnung: Bisher gibt es nur Versuche auf Honeypots und keine bestätigten Einbrüche. Ein KEV-Eintrag, öffentliche PoCs und Codeausführung im Labor reichen trotzdem, um das nicht auf den nächsten Wartungstermin zu schieben. Wer selbst Node.js-Dienste mit Express oder .NET-APIs mit Request-Dekompression betreibt, sollte das diese Woche erledigen.

Quellen

• SecurityWeek: Node2Shell Brotli Flaw Triggers Patching Across Microsoft, Node.js, Python Packages
• SecurityWeek: CISA Warns of Node2Shell Exploitation as Honeypots Log Attack Attempts
• heise Security: Brotli-Decoder-Lücke nicht nur in Node.js, sondern auch in Bun, Python und mehr
• Sophos: Node2Shell in active exploitation
• Aikido: Node2Shell – Analyse und Fix
• Broccoli2Shell-Tracker

Was passiert ist

PHP2Shell ist der Sammelname für zwei kritische Lücken in PHP: CVE-2026-109618 und CVE-2026-109619. Beide erlauben Remote Code Execution (RCE), also das Ausführen von beliebigem Code auf dem Server aus der Ferne, und das ohne Anmeldung. Laut BleepingComputer waren Details und Proof-of-Concept-Code schon vor den Patches im Umlauf. Das PHP-Team hielt keinen davon für funktionsfähig. Amazon Threat Intelligence meldete Angriffsversuche bereits vier Tage vor der Veröffentlichung der Patches. Cloudflare, watchTowr, Patchstack und andere stuften die frühen Versuche als erfolglos ein.

Dann kam der Nachweis aus Honeypots. Ein Honeypot ist ein absichtlich verwundbares Ködersystem, das Angriffe protokolliert. Der Forscher Adel Karimi (Perplexity) beobachtete einen Angriff auf eine Apache-mod_php-Installation mit PHP 8.4.26. Die Kette bestand aus vier Stufen von HTTP-Anfragen: Speicher erschöpfen, Speicherinhalte auslesen, am Ende einen Shell-Befehl ausführen. Laut SecurityWeek wurden am 24. Oktober 35 Shells auf drei Honeypots gestartet. Sie kamen von zwei IP-Adressen: Eine erzeugte 3 Shells, die andere 32. Einen nachgeladenen Schadcode (Second Stage) hat man dabei nicht beobachtet. Marcus Hutchins (Expel) bestätigte die Auswertung.

Bei der Einordnung hilft eine Unterscheidung. Das sind Honeypot-Zahlen und keine Zahl bestätigter Opfer. Karimi weist selbst darauf hin, dass sein Aufbau mit nur einem Worker-Prozess für Angreifer günstig war. Wie zuverlässig der Exploit auf anderen Konfigurationen funktioniert, zeigen die Daten nicht. Klar ist aber: Aus Versuchen ist erfolgreiche Codeausführung geworden.

Was sich seit unserem Post geändert hat

Drei Punkte muss ich nachtragen oder korrigieren:

• Es gibt Patches. Im Post stand der Patch-Status als offen da. Tatsächlich hat das PHP-Team die Lücken schon am 21. Oktober geschlossen. Laut mehreren Distributions- und Fachquellen, etwa AlmaLinux und computingforgeeks, sind die korrigierten Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
• CISA bestätigt die Ausnutzung. Am 23. Oktober meldete die US-Behörde noch keine erfolgreichen Angriffe und veröffentlichte eine Sigma-Erkennungsregel. Am 26. Oktober hat sie beide CVEs in ihren Katalog aktiv ausgenutzter Lücken (KEV) aufgenommen. Das berichten BleepingComputer und SecurityWeek.
• Unit 42 rudert zurück. Palo Alto Unit 42 hatte einen Angriff auf eine europäische Behörde mit PHP2Shell in Verbindung gebracht. Inzwischen heißt es laut The Hacker News, man könne nicht bestätigen, dass der Erstzugriff über diese CVEs lief. Der Angriff selbst ist damit nicht vom Tisch, nur seine Zuordnung zu PHP2Shell.

Wer betroffen ist

Betroffen ist PHP, und PHP läuft auf einem großen Teil des Webs. VirusTotal schätzt laut BleepingComputer mehr als 5,1 Millionen öffentlich erreichbare PHP-Hosts. Wie viele davon tatsächlich verwundbar sind, nennen die Quellen nicht. Besonders heikel sind ältere Zweige ab 8.1 abwärts, die offiziell keine Updates mehr bekommen (End of Life). Für sie gibt es nur Backports von Distributionen oder kommerziellen Anbietern wie TuxCare.

Dazu kommt eine dritte, eigenständige Lücke: CVE-2026-115560. Für sie gibt es noch keinen Patch, nur eine Empfehlung zur Abhilfe. Laut PHP ist sie nur bei einer ungewöhnlichen Kombination aus Konfiguration und Anwendungscode ausnutzbar.

Was du tun solltest

1. PHP aktualisieren, und zwar auf die oben genannten Versionen oder die gepatchten Pakete deiner Distribution. Achtung: Debian, Ubuntu und andere übernehmen den Fix oft in ihre Pakete, ohne die Versionsnummer anzuheben. Maßgeblich ist das Sicherheitsupdate der Distribution, nicht die angezeigte PHP-Version.
2. PHP-Prozesse neu starten. Gemeint sind PHP-FPM, Apache mit mod_php oder was sonst bei dir läuft. Laufende Worker behalten den alten Code im Speicher.
3. Übergangslösung nutzen, wo du nicht sofort patchen kannst. PHP empfiehlt session.upload_progress.enabled=0. Das ist auch die empfohlene Abhilfe für CVE-2026-115560. Laut Fachquellen deckt die Einstellung aber nicht alle PHP2Shell-Angriffswege ab und ersetzt kein Update.
4. Auf Spuren prüfen. Durchsuche Logs nach auffälligen Häufungen von Out-of-Memory-Fehlern und abgestürzten Workern. Prüfe Webverzeichnisse auf unbekannte PHP-Dateien, also mögliche Webshells. Wer ein SIEM betreibt, kann die Sigma-Regel der CISA einbinden.
5. EOL-Versionen ernst nehmen. Wer noch PHP 7.x oder 8.0/8.1 betreibt, sollte das jetzt als Anlass für ein Upgrade nehmen.

Meine Einschätzung: Die Lücken sind für Angreifer anspruchsvoll, und die Honeypot-Erfolge stammen aus einem günstigen Aufbau. Darauf würde ich mich trotzdem nicht verlassen. Mit KEV-Eintrag, öffentlichem Exploit und funktionierenden Shells gilt: Patch einspielen, Prozesse neu starten, Logs prüfen. Bei Selfhosting-Systemen mit PHP-Webanwendungen am besten heute.

Quellen

• BleepingComputer: PHP2Shell security flaws now successfully exploited in the wild
• BleepingComputer: CISA confirms PHP2Shell vulnerabilities now exploited in attacks
• SecurityWeek: PHP2Shell exploitation moves from probes to working shells
• The Hacker News: PHP2Shell exploitation and Unit 42 retraction
• AlmaLinux: Patched PHP packages released
• computingforgeeks: Check and patch PHP2Shell
• TuxCare: Patches for PHP 5.2 through 8.1

Was passiert ist

Ein Bootkit ist Schadsoftware, die sich in den Startvorgang des Rechners einnistet und vor dem Betriebssystem lädt. Dort sieht sie kaum ein Virenscanner, und eine Neuinstallation von Windows entfernt sie nicht unbedingt. Secure Boot soll genau das verhindern: Die UEFI-Firmware (der moderne BIOS-Nachfolger) startet nur Bootloader, deren Signatur sie für vertrauenswürdig hält.

BlackX nutzt Baton Drop (CVE-2022-21894). Diese Lücke in alten, aber von Microsoft signierten Windows-Bootmanagern erlaubt es, Secure Boot auszuhebeln. Die Angreifer trugen damit eigene Schlüssel (Machine Owner Keys) ein und konnten so beliebige EFI-Dateien laden. Kaspersky beschreibt die Umsetzung als „bemerkenswert ähnlich“ zum bekannten Bootkit BlackLotus. The Hacker News nennt BlackX eine weiterentwickelte Version davon. Da der Quellcode von BlackLotus nie vollständig öffentlich war, haben die Täter ihn wohl entweder nachgebaut oder auf anderem Weg beschafft.

Wichtig für die Einordnung: BlackX war nicht der Einstieg. Die Angreifer waren bereits im Netz und hatten Administratorrechte, bevor sie das Bootkit installierten. Wie sie hineinkamen, ist nicht bekannt. Das Bootkit diente der dauerhaften und unauffälligen Verankerung.

Nach dem Start lädt BlackX einen Kernel-Treiber, der Sicherheitsprozesse und Überwachungsfunktionen von Windows (etwa ETW, die Ereignisprotokollierung) ausschaltet. Signiert ist er mit einem inzwischen widerrufenen Zertifikat. Einige Routinen laufen nur, wenn Produkte von Kaspersky oder Avast installiert sind. Hier muss ich meinen WhatsApp-Post präzisieren: Laut Kaspersky waren genau diese Routinen gegen ihre Produkte wirkungslos. Dazu kommen Spionagewerkzeuge, darunter ein Fernzugriffstrojaner, der Google Drive, OneDrive und Yandex.Disk als Kommandokanal nutzt, sowie ein Loader namens OxiDLLRunner.

Wer steckt dahinter?

Kaspersky ordnet die Kampagne der China-nahen Gruppe APT41 zu, und zwar mit „mittlerer Sicherheit“. Das ist eine begründete Vermutung, kein Beweis. ESET sieht Ähnlichkeiten zu seinen Recherchen über die Gruppe FishMonger aus dem Juni 2026, die zum APT41-Umfeld gezählt wird. Ohne Vergleich der Samples will ESET eine Verbindung aber nicht bestätigen.

Warum Patchen allein nicht reicht

Das ist der eigentliche Punkt. Der Patch für Baton Drop korrigiert den Bootmanager, doch der alte, verwundbare Bootmanager bleibt gültig signiert. Ein Angreifer mit Adminrechten kann ihn einfach selbst mitbringen. Dagegen hilft nur eine Revocation, also ein Eintrag in der Sperrliste der Firmware (DBX), die das alte Zertifikat „Windows Production PCA 2011“ für ungültig erklärt. Diesen Schritt führt Windows nicht automatisch aus, Admins müssen ihn selbst anstoßen. Laut Kaspersky setzen die Angreifer genau darauf, dass das in vielen Organisationen nie passiert ist.

Neu seit meinem Post: Das PCA-2011-Zertifikat ist am 19. Oktober 2026 abgelaufen. Das schützt aber nicht, denn die Firmware lädt die alten Binärdateien weiterhin, solange das Zertifikat nicht gesperrt ist. Microsoft hat laut seinem Leitfaden zu CVE-2023-24932 (Stand 30. September 2026) noch keinen Termin für die automatische Durchsetzung genannt. Wir befinden uns weiterhin in der „Deployment Phase“.

Wer betroffen ist

Konkrete Ziele waren Diplomaten in Zentralasien. Deutsche Opfer sind nicht bekannt. Verwundbar ist aber grundsätzlich jeder Windows-Rechner mit Secure Boot, auf dem die Revocations fehlen. Das dürften sehr viele sein, auch in Firmen und Behörden hierzulande. Die Voraussetzung Adminrechte begrenzt das Risiko, beseitigt es aber nicht. Wer gezielt angegriffen wird, verliert mit Secure Boot eine Schutzschicht, auf die er sich verlassen hat.

Was du tun solltest

• Windows-Updates einspielen, das ist die Grundlage.
• Secure-Boot-Revocations aktiv umsetzen nach Microsofts Leitfaden: das Zertifikat „Windows UEFI CA 2023“ eintragen, den Bootmanager aktualisieren und anschließend PCA 2011 in die DBX aufnehmen. Prüfe danach, ob der Status wirklich übernommen wurde.
• Vorher testen und Recovery-Medien anlegen. Eine Sperrung lässt sich bei aktivem Secure Boot nicht zurücknehmen, auch nicht durch Neuformatieren. Alte Boot-USB-Sticks und Rettungsmedien starten danach unter Umständen nicht mehr. Fang mit einem Gerät pro Modellreihe an.
• Firmware (UEFI) aktuell halten, damit die Geräte die neuen Zertifikate überhaupt sauber übernehmen.
• Adminrechte knapp halten. BlackX brauchte sie, bevor es überhaupt aktiv wurde.

Mein Fazit: Secure Boot ist nur so stark wie seine Sperrliste. Ein grünes „Alle Updates installiert“ sagt darüber nichts.

Quellen

• BleepingComputer: BlackX UEFI bootkit exploits Baton Drop flaw to bypass Secure Boot
• The Hacker News: BlackX UEFI Bootkit Bypasses Secure Boot
• Microsoft: Windows Boot Manager revocations for CVE-2023-24932
• Borncity: BlackX-Bootkit – Windows-Schutz bleibt trotz Updates lückenhaft

Was passiert ist

Laut BleepingComputer hat Quest den Zugriff am 21. Oktober 2026 bemerkt und ihn am Tag danach in einem 8-K gemeldet. Das ist eine Pflichtmitteilung an die US-Börsenaufsicht SEC, mit der börsennotierte Firmen wesentliche Ereignisse bekannt geben müssen. SecurityWeek hat den Bericht der Nachrichtenagentur AP übernommen. Darin steht, dass Quest davon ausgeht, dass „bestimmte Patientendatensätze“ eingesehen wurden.

Quanum LSM ist eine Weboberfläche für Arztpraxen, Kliniken und deren Personal. Darüber bestellen sie Labortests, rufen Ergebnisse ab, verfolgen den Bearbeitungsstand und bestellen Material. Es ist also kein Patientenportal. Trotzdem laufen dort Auftrags- und Befunddaten von Patienten zusammen.

Was sich seit dem Post geändert hat

Im WhatsApp-Post schrieb ich, dass es keine belegten Angaben zu den Datenarten gibt. Das stimmt nur noch teilweise. TechCrunch berichtet, Quest habe bestätigt, dass geschützte Gesundheitsdaten abgeflossen sind, nämlich „persönliche Informationen und Patientenakten“. Welche Felder genau betroffen sind, also etwa Namen, Geburtsdaten, Versicherungsdaten oder konkrete Befunde, untersucht Quest noch.

Außerdem ist inzwischen bekannt:

• Quest hat Quanum LSM abgeschaltet. Kunden sollen auf Papieraufträge oder das separate Portal Quanum eLabs ausweichen. Die Dienste Essential Insights und LabHQ sind vorsorglich pausiert (BleepingComputer).
• Praxen, die direkt per Laborsystem-Schnittstelle (LIS) oder über ihre elektronische Patientenakte (EMR) angebunden sind, sind laut Quest nicht betroffen.
• Quest hat die Bundesbehörden eingeschaltet und arbeitet mit externen Sicherheitsfachleuten.
• Laut Quest hat der Vorfall nichts mit der PHP-Schwachstelle zu tun, über die in derselben Woche berichtet wurde (SecurityWeek/AP).
• Bisher hat sich keine Angreifergruppe zu dem Angriff bekannt.

Weiter offen sind die Zahl der Betroffenen, der Einstiegsweg und die Täter. Eine CVE oder einen Patch gibt es nicht, weil bisher keine konkrete Schwachstelle genannt wurde. Vorsicht bei Artikeln, die von 11,9 Millionen Opfern sprechen: Diese Zahl stammt aus dem AMCA-Vorfall von 2019 bei einem Inkassodienstleister. Mit dem aktuellen Fall hat sie nichts zu tun.

Warum das wichtig ist

Labordaten sind sehr sensibel. Aus einem Testauftrag kann man Schwangerschaften, Infektionen, Drogentests oder chronische Erkrankungen ablesen. Anders als ein Passwort kann man so etwas nicht ändern. Für Betrüger sind solche Daten wertvoll, weil sie damit glaubwürdige Phishing-Mails schreiben können: Wer den Arzt, das Labor und den Testtermin kennt, wirkt am Telefon schnell echt.

Dazu kommt ein strukturelles Problem. Getroffen wurde ein Portal, das Dritte nutzen, also Praxen und Kliniken. Patienten haben mit diesem System nie direkt zu tun und wissen oft nicht, dass ihre Daten dort liegen. Für Quest ist es außerdem nicht der erste Vorfall: 2016 wurden laut AP Daten von rund 34.000 Menschen offengelegt, 2019 folgte der AMCA-Fall.

Wer betroffen ist

In erster Linie Patienten in den USA, deren Tests über Praxen oder Kliniken mit Quanum LSM bestellt wurden. Leserinnen und Leser in Deutschland dürften kaum direkt betroffen sein. Die Lehre gilt aber überall, wo Labore, Praxissoftware und externe Portale Daten austauschen.

Was du tun solltest

Als Patient (vor allem in den USA):

• Achte auf offizielle Benachrichtigungen von Quest oder deiner Praxis. Nach der HIPAA-Meldepflicht, dem US-Gesetz zum Schutz von Gesundheitsdaten, müssen Betroffene spätestens 60 Tage nach Entdeckung informiert werden.
• Sei misstrauisch bei unerwarteten Anrufen oder Mails zu Laborergebnissen, Nachzahlungen oder „Identitätsprüfungen“.
• Bestätige keine Daten über Links in Nachrichten. Ruf lieber selbst über die bekannte Nummer der Praxis an.
• Prüfe Abrechnungen deiner Krankenversicherung auf Leistungen, die du nicht bekommen hast.

Als Praxis, Klinik oder IT-Verantwortlicher:

• Prüfe, welche externen Portale Patientendaten verarbeiten und wer dort Zugänge hat.
• Ein Notfallplan sollte auch den Ausfall eines Dienstleister-Portals abdecken. Quest musste Kunden kurzfristig auf Papier und Ersatzportale umstellen.
• Erzwinge Mehr-Faktor-Anmeldung für Webportale mit Gesundheitsdaten und entferne verwaiste Konten.

Sobald Quest Opferzahlen oder den Einstiegsweg nennt, ergänze ich das hier.

Quellen

• BleepingComputer: Quest Diagnostics confirms data breach exposed patient records
• SecurityWeek (AP): Quest Diagnostics reports cyber breach affecting certain patient records
• TechCrunch: Quest Diagnostics confirms patients' personal and health data was compromised
• MedicalDaily: Quanum portal breach, number of affected people unknown

Was passiert ist

Am 19. Oktober bemerkte Capcom verdächtige Aktivitäten, sperrte den Zugriff und bestätigte noch am selben Tag, dass Unbefugte eingedrungen waren. Am 20. Oktober richtete das Unternehmen einen internen Krisenstab ein, am 21. Oktober folgte die Meldung an die Polizei der Präfektur Osaka und an die japanische Datenschutzbehörde (Personal Information Protection Commission). Wie die Angreifer hineingekommen sind, sagt Capcom nicht. Es heißt nur, man habe den Angriffsweg identifiziert und Gegenmaßnahmen umgesetzt. Bis zum Stand der Berichte hat sich keine Gruppe zu dem Angriff bekannt (Help Net Security).

Welche Daten betroffen sind

Laut Capcom, BleepingComputer und SecurityWeek:

• 11.774.247 Datensätze mit E-Mail-Adresse und Kontometadaten: Erstellungsdatum des Kontos, letzter Login, Anzahl der Logins und die IP-Adresse beim letzten Login.
• 43 Datensätze zusätzlich mit Geburtsdatum, Geschlecht, Land/Region und Nickname.
• 196 Konten, bei denen die Angreifer das Login-Passwort geändert und die Besitzer damit ausgesperrt haben. Capcom hat diese Passwörter inzwischen zurückgesetzt.
• Nicht betroffen sind laut Capcom Kreditkartendaten. Dass die von Kunden selbst gesetzten Passwörter abgeflossen sind, hat Capcom nach eigenen Angaben nicht festgestellt.

Hier muss ich meinen eigenen Post etwas präzisieren: Dort stand „Passwort ändern“, als wären Passwörter Teil des Lecks. Nach aktuellem Stand sind sie das nicht. Die Angreifer konnten aber bei 196 Konten Passwörter ändern, hatten also zumindest Schreibzugriff auf Kontodaten. Wie weit dieser Zugriff ging, untersucht Capcom noch. Ein neues Passwort bleibt deshalb eine sinnvolle Vorsichtsmaßnahme, ist aber nicht der wichtigste Punkt.

Warum das wichtig ist

Eine E-Mail-Adresse allein klingt harmlos. Zusammen mit dem Wissen, dass jemand ein Capcom-Konto hat, wann er sich zuletzt eingeloggt hat und von welcher IP-Adresse, wird daraus Material für glaubwürdiges Phishing. Phishing heißt: gefälschte Nachrichten, die dich auf eine nachgebaute Login-Seite locken oder Schadsoftware unterjubeln sollen. Eine Mail wie „Wir haben Ihr Passwort nach dem Vorfall zurückgesetzt, bitte hier bestätigen“ wirkt nach so einer Meldung erschreckend plausibel. Capcom warnt selbst ausdrücklich vor Mails und Nachrichten, die sich als Capcom ausgeben.

Die IP-Adresse kann außerdem grob verraten, wo und über welchen Provider jemand online war. Für die Masse der Betroffenen ist das kein Drama, für gezielte Angriffe aber ein weiteres Puzzleteil.

Kleine Randnotiz: Capcom ist nicht zum ersten Mal Ziel. 2020 traf das Unternehmen ein Ransomware-Angriff der Gruppe Ragnar Locker. Der Einstieg lief damals laut Capcom über ein altes VPN-Gerät.

Wer betroffen ist

Jeder, der ein CAPCOM-ID-Konto hat, etwa für Capcoms Webdienste oder Online-Spiele. Da es um 11,7 Millionen Datensätze weltweit geht, sollte man im Zweifel davon ausgehen, dabei zu sein. Capcom will Betroffene schrittweise benachrichtigen und hat regionale Support-Kanäle eingerichtet, für Europa über das Kontaktformular von Capcom Europe. Die registrierte E-Mail-Adresse kann laut Capcom weiter genutzt werden.

Was du jetzt tun solltest

1. Mails, SMS und Anrufe „von Capcom“ misstrauen. Keine Links anklicken, keine Anhänge öffnen. Wenn du etwas prüfen willst, ruf die Capcom-Seite selbst im Browser auf.
2. Passwort für CAPCOM ID ändern, als Vorsichtsmaßnahme, solange die Untersuchung läuft.
3. Dasselbe Passwort woanders ersetzen, falls du es mehrfach nutzt. Ein Passwortmanager macht das dauerhaft einfacher.
4. Prüfen, ob du dich noch einloggen kannst. Wenn nicht, gehörst du womöglich zu den 196 Konten. Dann über den offiziellen Support melden, nicht über Links aus einer Mail.
5. Zwei-Faktor-Anmeldung aktivieren, wo sie angeboten wird, vor allem bei Konten, die mit derselben Mailadresse verknüpft sind.

Ich halte vor allem Punkt 1 für entscheidend. Das eigentliche Risiko dieses Lecks liegt in den Mails, die in den nächsten Wochen kommen werden.

Quellen

• Capcom: Notice and Apology Regarding Customer Information Affected Through Unauthorized Access
• BleepingComputer: Capcom confirms data breach affecting 11.7 million accounts
• SecurityWeek: 11 Million Impacted by Capcom Data Breach
• Help Net Security: Capcom data breach exposes 11.7 million account records

Was sich seit meinem Post geändert hat

Als ich das Thema auf X und im WhatsApp-Kanal gepostet habe, war die Lage beim Patch noch unklar. Inzwischen ist sie es nicht mehr. Laut dem GitHub-Advisory von Collabora ist die Lücke ab Version 26.4.303 der App geschlossen. Außerdem gibt es einen wichtigen Hinweis, der vorher fehlte: Die App nur zu deaktivieren, schützt nicht.

Was genau kaputt ist

Betroffen ist die Nextcloud-App „Collabora Online – Built-in CODE Server“, technischer Name richdocumentscode. CODE ist die Entwicklerausgabe von Collabora Online, einem Office im Browser. Die eingebaute Variante läuft direkt im Nextcloud-Server mit. Das ist bequem, weil man keinen eigenen Office-Server braucht.

Die Lücke ist eine OS Command Injection. Damit ist gemeint, dass Eingaben aus einer Webanfrage ungeprüft in einen Befehl an das Betriebssystem gelangen. Wer die Anfrage passend baut, lässt eigene Befehle laufen, und zwar mit den Rechten des Webserver-Benutzers. Laut Advisory steckt der Fehler in der Datei proxy.php der App. Ausnutzbar ist er nur, solange der eingebaute CODE Server gerade nicht läuft, etwa nach einem Neustart des Containers, einem Update oder einem Absturz. Das klingt nach einer Hürde, kommt im Alltag aber regelmäßig vor.

Nicht betroffen sind laut Collabora eigenständige Collabora-Online-Server und die separate Connector-App „Nextcloud Office“ (richdocuments). Es geht also nur um die eingebaute Variante.

Was Angreifer damit machen

Die Ausnutzung ist kein theoretisches Szenario. Nach Berichten von The Hacker News und der Analyse von Corgea laufen Angriffe seit mindestens Anfang September 2026. Die Angreifer legten Web Shells ab, also kleine Skripte, über die sie den Server danach bequem fernsteuern können. Damit lasen sie die Nextcloud-Konfiguration aus, in der unter anderem Zugangsdaten zur Datenbank und zum Mailserver stehen. Außerdem suchten sie gezielt nach Dateien von Passwortmanagern und Krypto-Wallets. Laut Corgea hat auch das italienische CSIRT einen Hinweis zum Diebstahl solcher Konfigurationsgeheimnisse veröffentlicht.

CISA hat die Lücke am 23. Oktober 2026 in den Katalog aufgenommen. US-Bundesbehörden mussten sie bis zum 26. Oktober schließen. Für alle anderen gilt diese Frist nicht. Sie zeigt aber, wie ernst die Behörde den Fall nimmt. Wie viele Systeme weltweit betroffen sind, nennt keine der Quellen.

Wer betroffen ist

Betroffen ist jeder, der Nextcloud mit der App „Built-in CODE Server“ in einer Version unter 26.4.303 betreibt. Das sind typischerweise selbst gehostete Instanzen in kleinen Firmen, Vereinen, Schulen und Haushalten, denn genau dort spart man sich gern den separaten Office-Server. Ein Sonderfall sind Nextcloud 29 und ältere Versionen. Sie haben ihr Lebensende erreicht und können die reparierte App laut Advisory nicht installieren.

Was du jetzt tun solltest

1. Prüfen, ob die App installiert ist, auch wenn sie deaktiviert ist. Deaktiviert heißt nicht entfernt.
2. Aktualisieren auf mindestens 26.4.303 oder die App entfernen. Corgea beschreibt mit 26.4.402 und 26.4.502 zwei spätere Versionen mit weiterer Härtung. Sie empfiehlt die neueste Version, weil erst dort auch das Deaktivieren den angreifbaren Einstiegspunkt wirklich schließt. Mein Rat: auf die aktuellste Version gehen.
3. Nextcloud 29 oder älter? Dann die App entfernen oder Nextcloud auf eine unterstützte Version bringen.
4. Nach Spuren suchen. Unerwartete PHP-Dateien im Verzeichnis der App sind ein Warnsignal. Ein Update entfernt keine bereits abgelegte Web Shell und macht gestohlene Daten nicht wieder geheim.
5. Bei Verdacht gründlich aufräumen. Logs und verdächtige Dateien sichern, den Server oder Container aus einem sauberen Image neu aufsetzen und alle Geheimnisse wechseln, die der Webserver lesen konnte, zum Beispiel Datenbank- und Mailpasswörter sowie die Secrets aus der Nextcloud-Konfiguration.

Meine Einordnung: Die eingebaute Office-Variante ist eine Komfortlösung. Wer Nextcloud Office ernsthaft nutzt, fährt mit einem eigenständigen Collabora-Server meist besser. Wer es gar nicht nutzt, sollte die App löschen statt sie nur abzuschalten.

Quellen

• NVD: CVE-2026-110447
• GitHub Security Advisory GHSA-g3vx-3m76-fghh (Collabora Online)
• The Hacker News: CISA Flags Two Actively Exploited Flaws
• Corgea: Analyse zu CVE-2026-110447
• CISA Known Exploited Vulnerabilities Catalog

Das wollte ich ausprobieren. Teil 1 handelt davon, wie man so etwas sicher zum Laufen bringt. Die KI kommt in Teil 2.

Warum ein Käfig

Wer Programme zerlegt, hat Dateien auf dem Rechner, denen er nicht traut. Dazu kommt ein Werkzeug, das acht Tage alt ist, zwei Sterne auf GitHub hat und sich selbst „Pre-Alpha“ nennt. Und eine KI, die Code schreibt und ausführt.

Bevor ich irgendetwas installiert habe, habe ich das Repository gelesen: keine Aufgaben, die beim Öffnen im Editor automatisch starten, keine Build-Skripte, die heimlich etwas herunterladen, keine versteckten Anweisungen an KI-Agenten in den Projektnotizen. Das Sicherheitskonzept ist durchdacht. Trotzdem gilt: Lesen ersetzt keine Abschottung.

Eine Kleinigkeit fiel dabei auf. Die Anleitung verspricht, dass Downloads per Signatur geprüft werden. Im Installationsskript steht aber, dass der Signaturschlüssel noch gar nicht erzeugt wurde. Geprüft wird nur eine Prüfsumme, die vom selben Server kommt wie der Download. Das schützt vor kaputten Dateien, nicht vor manipulierten.

Eine Maschine, die nichts darf

KRAKEN läuft bei mir in einer eigenen Linux-Maschine, einer virtuellen Maschine auf dem Mac mini. Die Software dafür heißt OrbStack. Sie bietet einen „isolierten“ Modus: kein Zugriff auf die Dateien des Macs, keine Mac-Befehle, kein Zugriff auf andere Maschinen.

Ich habe nachgemessen. Mac-Dateien: nicht sichtbar. Dienste auf dem Mac: nicht erreichbar. Mein privates VPN: erreichbar. Die isolierte Maschine kam über den Mac an Geräte in meinem VPN heran. Ein Dienst hat sie abgewiesen, weil er prüft, wer anfragt. Andere Dienste im VPN vertrauen jedem, der drin ist.

Deshalb kam eine eigene Firewall in die Maschine: nur Internet, keine privaten Netze, kein VPN. Danach habe ich dem Benutzer in der Maschine die Admin-Rechte genommen. Was dort läuft, kann die Firewall nicht abschalten. Ändern kann ich sie nur vom Mac aus.

Die Lehre: „Isoliert“ heißt bei jedem Werkzeug etwas anderes. Nachmessen, nicht glauben.

Der Apple-Chip und die Sandbox

Fertige Pakete von KRAKEN gibt es nur für Linux auf Intel- und AMD-Prozessoren. Der Mac mini hat einen Apple-Chip. Kein Problem, dachte ich: OrbStack kann Intel-Linux über Rosetta übersetzen.

Installiert, gestartet, abgebrochen. KRAKEN verlangt Landlock, eine Sandbox-Funktion des Linux-Kernels, die einem Programm verbietet, Dateien außerhalb eines Ordners anzufassen oder ins Netz zu gehen. Der Kernel hatte Landlock. Aber unter Rosetta kommt der Aufruf nicht an, der Kernel antwortet „gibt es nicht“.

Für die reine Analyse hätte ich die Sandbox abschalten können. Für das eigentlich Spannende nicht: Den Rust-Code, den eine KI schreibt, baut und startet KRAKEN nur in dieser Sandbox. Einen Schalter dafür gibt es bewusst nicht. Das finde ich richtig.

Also eine zweite Maschine, diesmal für den Apple-Chip, und KRAKEN aus dem Quellcode bauen. Dort meldet der Kernel Landlock in Version 10.

Drei Stolpersteine beim Bauen

Der stille Platzhalter. Der erste Build war nach 98 Sekunden fertig, ohne Fehler. Verdächtig schnell. Ohne die Quellen des Ghidra-Decompilers baut KRAKEN still einen Platzhalter, der nichts dekompiliert. Der Einrichtungsbefehl lädt nur einen Teil der Dateien, die Decompiler-Quellen braucht einen zweiten Befehl.

Die fehlende Bibliothek. Mit den echten Quellen brach der Build ab: Funktionen zum Entpacken fehlten beim Zusammenfügen des Programms. KRAKEN bringt die Bibliothek dafür mit, auf dem Apple-Chip landet sie aber in der falschen Reihenfolge. Getestet wird das Projekt bisher nur auf Intel und AMD. Ein zusätzlicher Verweis auf die System-Bibliothek löste es.

Der Emulator. Für Programme, die gemeinsame Bibliotheken des Systems nutzen, braucht KRAKEN eine Kopie dieser Bibliotheken für den Emulator. Programme, die alles selbst mitbringen, liefen sofort.

Der erste Blick

Mein Testfall: ein kleiner Taschenrechner aus den Übungsprogrammen des Projekts, optimiert kompiliert und ohne Funktionsnamen. So sieht ein Programm aus, von dem man nichts weiß.

KRAKEN fand 14 Funktionen. Die meisten heißen nur FUN_00101280 und ähnlich. Der Decompiler macht daraus lesbaren C-Code. Bei einer Funktion sieht man nach ein paar Zeilen, was sie tut: Leerzeichen überspringen, auf Klammern und Minus prüfen, Ziffern zu einer Zahl zusammensetzen. Das ist der Teil des Rechners, der Zahlen einliest. Ein zweites Übungsprogramm lief im Emulator und lieferte dieselbe Ausgabe wie im echten Betrieb.

Bis hierhin hat keine KI etwas getan. Das ist Teil 2: Kann ein Modell diese Funktionen richtig benennen und in Rust neu schreiben, so dass am Ende dasselbe herauskommt? Ich nehme dafür ein Open-Source-Programm, dessen Quellcode ich kenne. Dann lässt sich prüfen, wie nah die KI rankommt.

Zerlegt werden bei mir nur Programme, die ich analysieren darf. KRAKEN schreibt das selbst in die Anleitung, und das gilt nicht nur dort.

Erst die Gratis-Modelle

Bei OpenRouter gibt es Modelle zum Nulltarif. Ich habe fünf ausprobiert. Keines kam zu einem Ergebnis.

Nemotron 3 Ultra hat Zahlen als Text übergeben, also "50" statt 50. KRAKEN hat das jedes Mal abgelehnt, nach elf Aufrufen war das Budget leer. Laguna S hat das Programm sofort richtig erkannt und sich dann beim Blättern durch die Funktionsliste verheddert. Flint hat in neun Aufrufen 243.000 Tokens verbraucht. Inkling gibt OpenRouter nur für bestimmte Apps frei, Gemma war überlastet.

KRAKEN hat sich dabei gut benommen: Es fragt vor jeder KI-Arbeit nach den Kosten, bricht sauber ab, wenn ein Limit erreicht ist, und kann jeden Lauf mit einem Befehl rückgängig machen.

Claude draußen, KRAKEN drinnen

Dann Claude, über mein normales Abo. Claude läuft auf dem Mac, nicht in der Testmaschine. Es bekommt keine Shell und keinen Zugriff auf Dateien, nur die Werkzeuge von KRAKEN: Funktionen auflisten, dekompilieren, Texte suchen, umbenennen, kommentieren. KRAKEN selbst bleibt im Käfig.

Die Aufgabe war für beide Programme gleich: Finde die eigenen Funktionen des Programms, gib ihnen Namen, sag, was sie tun. Welches Programm es ist, habe ich nicht verraten.

Test 1: 2048

Das Spiel 2048 als Open-Source-Version in C, 577 Zeilen. Ich habe es selbst übersetzt, alle Namen entfernt und die C-Bibliothek fest eingebaut, wie bei vielen echten Programmen. KRAKEN fand 1.111 Funktionen, 196 davon ohne Namen. Irgendwo darin stecken 19 Funktionen des Spiels.

Claude brauchte 78 Sekunden. Es fand alle 19. 17 Namen waren exakt die aus dem Quellcode: slideArray, rotateBoard, findPairDown. Einer war nur anders geschrieben, einer anders benannt, aber inhaltlich richtig. Nebenbei bemerkte Claude, dass der Compiler eine Funktion in eine andere hineinkopiert hat.

Test 2: das echte xxd

Dann eine Datei, die ich nicht selbst gebaut habe: xxd, das Hexdump-Werkzeug aus Vim, so wie Ubuntu es ausliefert. 22 Kilobyte, ohne Funktionsnamen. Ich habe die Datei über Ubuntus signierte Paketlisten geprüft, von der Signatur bis zur Prüfsumme. Als Lösung dient das offizielle Debug-Paket mit den echten Namen. Die KI hat es nie gesehen.

Claude brauchte 53 Sekunden. 10 von 10 Funktionen, alle mit exakt dem Originalnamen: xxdline, skip_to_eol, exit_with_usage, fclose_or_die. Dazu alle Optionen und die Exit-Codes. Und es nannte Funktionen, die der Compiler in main eingebaut hat, mit Adressbereich, obwohl diese Namen in der Datei nirgends stehen.

Warum mich das nicht beruhigt

Beide Programme enthalten einen Versionstext. Bei xxd steht der Autor drin. Claude hat ihn gefunden und dann selbst geschrieben: „Die Hilfsfunktionen entsprechen xxd.c.“ Es kennt den Quellcode von Vim. Er steckt in seinen Trainingsdaten, genau wie 2048, ein Projekt mit über 600 Sternen auf GitHub.

Die Namen kommen also zum Teil aus dem Gedächtnis. Die Datei bestätigt nur, was die KI schon weiß.

Ganz so einfach ist es aber auch nicht. Wo genau im Maschinencode welche Funktion liegt, welche Teile der Compiler zusammengeschoben hat, welche Option welchen Exit-Code auslöst: Das steht in keinem Quellcode. Das hat Claude aus der Datei gelesen.

Für Angreifer und Verteidiger heißt das dasselbe. Bekannte Software, und das ist fast alle Software, durchschaut eine KI in Sekunden. Was früher Tage dauerte, ist jetzt eine Minute.

Was das noch nicht beweist

Ob die KI ein Programm versteht, das sie nicht kennen kann, weiß ich noch nicht. Darum geht es in Teil 3: ein Programm, das erst nach dem Wissensstand des Modells entstanden ist. Dann zeigt sich, wie viel von den 100 Prozent Lesen war und wie viel Erinnern.

Zerlegt habe ich nur Open-Source-Programme. Ihre Lizenz erlaubt das, und wir haben den Quellcode zum Vergleich.

Das lässt sich prüfen. Man braucht ein Programm, das niemand kennen kann. Also habe ich eines geschrieben.

Ein Programm, das es nur bei mir gibt

Es heißt tierstat, 234 Zeilen C, nirgends veröffentlicht. Es liest Zeilen mit einem Namen und vier Zahlen, bildet daraus einen Punktwert, teilt ihn in Stufen ein und druckt eine sortierte Rangliste.

Das Wichtige: Ich habe die Logik absichtlich eigenwillig gemacht, damit kein Standardwissen hilft. Die Spalten haben erfundene Gewichte. Der Punktwert ist eine Mischung aus 85 Prozent gewichteter Summe und 15 Prozent eines gestutzten Mittels, bei dem der höchste und der niedrigste Wert wegfallen. Die Stufen beginnen bei krummen Schwellen. Und die Prüfsumme habe ich selbst erfunden: Startwert 777, in jedem Schritt mal 131 plus das Zeichen gewichtet mit seiner Position, auf 20 Bit begrenzt, am Ende mit einer verschobenen Kopie seiner selbst verodert. Kein bekanntes Verfahren. Wer das richtig beschreibt, hat es gelesen.

Dann habe ich das Programm übersetzt, alle Namen entfernt und in dieselbe Testmaschine gelegt. Mein eigener eingebauter Selbsttest lief im Emulator durch: alle 16 Prüfungen bestanden. Das Programm funktioniert.

Derselbe Blindlauf

Claude bekam wieder nur die nackte Datei über KRAKEN, keine Shell, keinen Quellcode. Die Aufgabe: Finde die eigenen Funktionen, benenne sie, sag genau, was sie tun, mit allen Konstanten.

Nach 130 Sekunden lag die Antwort vor. Von meinen 13 Funktionen fand Claude alle 13. Jede Beschreibung stimmte. Es nannte die Gewichte {0.15, 0.25, 0.30, 0.30}, die 85/15-Mischung, das gestutzte Mittel. Und die Prüfsumme beschrieb es Zeichen für Zeichen richtig: Startwert 0x309, das sind 777, mal 131 plus Zeichen mal Position, Maske 0xFFFFF, zum Schluss h ^ (h >> 7). Es fand sogar zwei Hilfsfunktionen, die der Compiler in andere eingebaut hatte.

Das sah aus wie der klare Beweis: Die KI liest Code, den sie nicht kennen kann.

Mein Test hat geschummelt

Bevor ich das feiere, habe ich nachgesehen, was eigentlich in der Datei steht. Und da war ein Fehler, meiner.

Mein Selbsttest prüft Dinge wie classify_tier(82.0) == 'S'. Diese Prüfzeilen schreibt der Compiler als Klartext in die Datei, damit im Fehlerfall etwas Lesbares erscheint. Damit standen die echten Namen meiner Funktionen und mehrere Schwellen schwarz auf weiß im Programm:

clamp_value(-5.0) == 0.0
classify_tier(82.0) == 'S'
weighted_score(full)
fold_checksum("A") != fold_checksum("B")

Die Namen waren also kein Blindtest. Claude musste classify_tier nicht aus dem Code erschließen, der Name lag offen herum. Genau so etwas verrät sich in echten Programmen ständig, über Fehlermeldungen, Protokolltexte, Debug-Reste. Reverse Engineering beginnt fast immer mit den Texten in einer Datei. Insofern war mein Fehler ein realistischer. Trotzdem war es ein Fehler, und ich sage ihn hier, statt ihn zu verschweigen.

Was trotzdem stehen bleibt

Die Prüfsumme rettet den Test. Ihre Formel steht nirgends als Text, ich habe danach gesucht: kein 777, kein 131, keine Maske. Sie existiert nur als Rechenschritte im Maschinencode. Claude hat sie exakt herausgelesen. Dasselbe gilt für die Gewichte, die als nackte Zahlen im Datenbereich liegen, und für die 85/15-Mischung.

Damit ist die Frage aus Teil 2 beantwortet. Die KI liest kompilierten Code wirklich. Wo kein Name und kein Text hilft, rekonstruiert sie die Logik aus den Maschinenbefehlen. Die 100 Prozent bei bekannter Software waren nicht nur Erinnerung.

Für Sicherheit heißt das etwas Unbequemes. Es zählt nicht mehr, ob eine Software bekannt ist. Auch eigener, nie veröffentlichter Code, die Firmware im Wohnzimmergerät, das interne Werkzeug einer Firma, liegt offen, sobald jemand die Datei hat. Was früher einen Spezialisten und Tage brauchte, ist jetzt eine Minute und ein Chatfenster. Das gilt für Angreifer, und es gilt für Verteidiger.

Zerlegt habe ich nur Programme, die ich zerlegen darf. Dieses hier habe ich selbst geschrieben.

Was passiert ist

Die Lücke hat die Kennung CVE-2026-114625. Es handelt sich um eine SQL-Injection: Ein Angreifer schmuggelt eigene Datenbankbefehle in Eingaben, die die Anwendung ungeprüft an ihre Datenbank weiterreicht. Laut The Hacker News und SecurityWeek bewertet Arista sie mit CVSS 9.9 von 10. Einzelne andere Berichte nennen 9.4, an der Einstufung als kritisch ändert das nichts.

Der VCO ist die zentrale Verwaltungsoberfläche für VeloCloud-SD-WANs. SD-WAN bedeutet softwaregesteuerte Vernetzung von Standorten: Filialen, Rechenzentren und Cloud-Anbindungen werden darüber konfiguriert. Wer den Orchestrator kontrolliert, kontrolliert also einen großen Teil des Firmennetzes.

Für einen Angriff braucht man Netzzugriff auf die Weboberfläche und ein gültiges Login. Das klingt nach einer Hürde, ist aber eine niedrige. Nach Angaben von Arista reicht schon die schwächste eingebaute Rolle, „Enterprise Read Only“, also ein reines Lesekonto. Darüber kann ein Angreifer Operator-Rechte erlangen und sich als lokaler „Superuser Operator“ ausgeben. Das ist die höchste Kontrollebene im VCO. Laut BleepingComputer ist der Angriff wenig komplex und braucht keine Mitwirkung eines Nutzers.

Was sich seit meinem Post geändert hat

Inzwischen gibt es mehr Details. Die korrigierten Versionen sind bekannt, der CVSS-Wert ist veröffentlicht, und die Abgrenzung ist klarer. Die beiden Vorgänger-Lücken aus Juli (CVE-2026-16812) und September (CVE-2026-93952) ließen sich ohne Login ausnutzen. Die neue Lücke ist die erste der drei, die ein Konto voraussetzt.

Offen bleibt laut The Hacker News einiges: Arista sagt nicht, seit wann angegriffen wird, welche Orchestratoren betroffen waren und was die Angreifer danach getan haben. Unklar ist auch, ob ein Update bereits erlangten Zugriff wieder entfernt.

Wer betroffen ist

Betroffen sind On-Prem-Installationen des VCO in diesen Versionen:

• 5.2 vor 5.2.3.18
• 6.1 vor 6.1.3.10
• 6.4 vor 6.4.2.12

Die von Arista gehosteten und dedizierten Orchestratoren sind bereits gepatcht. VeloCloud Gateway und Edge sind nicht betroffen, ebenso wenig der 7.0-Zweig. Releases ohne Support hat Arista nicht geprüft. Wer so etwas betreibt, sollte sich an den Arista-Support (TAC) wenden. Arista weist laut The Hacker News außerdem darauf hin, dass der VCO standardmäßig erreichbar ist und sich das nicht per Konfiguration verhindern lässt. Wie viele Installationen in Deutschland betroffen sind, sagen die Quellen nicht.

Was du jetzt tun solltest

1. Update einspielen. Auf 5.2.3.18, 6.1.3.10, 6.4.2.12 oder neuer aktualisieren. Wer noch auf 6.1 ist, sollte zusätzlich prüfen, ob die September-Lücke dort abgedeckt ist. Laut The Hacker News nennt Arista dafür keine korrigierte 6.1-Version.
2. Zugriff einschränken. Die Weboberfläche nur aus vertrauenswürdigen Admin-Netzen erreichbar machen und unnötige ausgehende Verbindungen vom VCO-Host blockieren.
3. Konten aufräumen. Weil schon ein Lesekonto reicht, ist jedes vergessene oder geteilte Login ein Risiko. Konten prüfen und nicht benötigte entfernen.
4. Auf Spuren prüfen. In der Advisory nennt Arista zwei IP-Adressen aus beobachteten Angriffen. Diese blockieren und in den Logs danach suchen. Zusätzlich auf auffällige Pfade, kodierte Zeichen, Verweise auf interne Dienste und hohe Anfrageraten achten. Prüfen, ob Admins zuletzt unerwartete Änderungen vorgenommen haben. Auch nach Webshells und Hintertür-Diensten suchen.
5. Bei Verdacht Beweise sichern. Web-, Anwendungs-, System- und Datenbanklogs sowie Dateizeitstempel sichern, bevor man aufräumt, und Arista TAC einschalten.

Einordnung

Drei ausgenutzte Zero-Days im selben Verwaltungsprodukt innerhalb weniger Monate sind kein Zufall. Angreifer haben den VCO offensichtlich gezielt im Visier, weil er ein lohnendes Ziel ist: Wer ihn übernimmt, hat den Schlüssel zum ganzen Standortnetz. Wer VCO On-Prem betreibt, sollte ihn deshalb wie einen Domänencontroller behandeln. Das heißt: nicht ins offene Netz stellen, Patches sofort einspielen und Logs aktiv überwachen. Ich würde nach dieser Serie außerdem ernsthaft prüfen, ob die gehostete Variante nicht die ruhigere Wahl ist. Die war diesmal schon gepatcht, als die Meldung kam.

Quellen

• CISA: Aufnahme in den KEV-Katalog
• The Hacker News: Arista warns of critical VeloCloud SQL injection
• BleepingComputer: Arista patches new VeloCloud Orchestrator zero-day
• SecurityWeek: Third VeloCloud Orchestrator zero-day in four months
• NVD: CVE-2026-114625

LiteLLM ist ein weit verbreiteter Open-Source-Proxy, der Anfragen an viele LLM-Anbieter über eine einheitliche Schnittstelle verteilt. Laut BleepingComputer kommt das Paket auf rund 92 Millionen PyPI-Downloads im Monat. Genau deshalb ist es so ein lohnendes Ziel: Auf einem LiteLLM-Host liegen die API-Keys sämtlicher angebundenen KI-Anbieter.

Was passiert ist

Bei einem Lieferkettenangriff (Supply-Chain-Angriff) wird nicht die Software beim Nutzer angegriffen, sondern ihr Verteilungsweg. Hier traf es die Release-Pipeline. Laut dem Vorfallsbericht von LiteLLM waren die Artefakte zu diesen Zeiten verfügbar (UTC, 21. Oktober):

• PyPI: litellm==1.107.0, sieben Wheels für Linux, macOS und Windows, von 11:39 bis 13:23 Uhr
• Docker Hub: Tags v1.107.0, latest, main-latest und main-stable, von 11:46 bis 14:20 Uhr
• GHCR: dieselben Tags für die Images litellm, litellm-database und litellm-non_root, bis 13:51 Uhr

Kunden der privaten Enterprise-Edition waren nicht betroffen. Der offizielle Quellcode-Tag auf GitHub ist sauber, denn gebaut wurde aus einem Lookalike-Repository namens Berri-AI/litellm (das Original heißt BerriAI/litellm). SecurityWeek schätzt anhand von PyPI-Daten über 49.000 Downloads, wobei das nicht dasselbe ist wie 49.000 infizierte Systeme.

Was die Schadsoftware tut

Der Code steckt nicht in LiteLLM selbst, sondern in drei Dateien im site-packages-Verzeichnis (cook.pth, cook.py, sitecustomize.py). Python lädt solche Dateien bei jedem Start des Interpreters. Die Malware läuft also auch dann, wenn LiteLLM gar nicht importiert wird, und sogar dann, wenn man pip aufruft, um nachzusehen.

Abgegriffen werden laut Help Net Security und BleepingComputer unter anderem Zugangsdaten für AWS, Azure, Google Cloud, Kubernetes und Docker, Git-, SSH- und GPG-Schlüssel, .env-Dateien, Shell-Historien, Browser-Logins und Cookies sowie Auth-Dateien von KI-Werkzeugen wie Claude, Codex, Gemini und Cursor. Dazu kommt ein Versuch, die in der LiteLLM-Datenbank gespeicherten Provider-Keys auszulesen. Ein zusätzlicher Loader fragt stündlich eine Quelle auf GitHub nach nachzuladendem Python-Code ab.

Das ist nicht nur ein Versuch geblieben. Wiz beobachtete etwa viereinhalb Stunden nach dem Datenabfluss, wie die Angreifer gestohlene AWS-Zugangsdaten prüften und den Zugriff auf Amazon-Bedrock-Modelle testeten. Das deutet auf LLMjacking hin, also darauf, dass fremde KI-Kontingente auf Kosten der Opfer genutzt werden sollen.

Was sich seit meinem Post geändert hat

Gepostet hatte ich, dass die Angreifer gekaperte GitHub-CLI-OAuth-Tokens benutzt haben. Das stimmt nach wie vor. Woher die Tokens stammen, war in der ersten Version des Vorfallsberichts aber falsch dargestellt. Damals vermutete LiteLLM, die Tokens seien über Logs einer öffentlich erreichbaren internen Instanz abgeflossen. In der korrigierten Ursachenanalyse vom 23. Oktober steht etwas anderes: Im Mai wurde ein administrativer Schlüssel für eine interne Agent-Plattform versehentlich in ein öffentliches Repository committet und danach nie widerrufen. Über diesen Schlüssel kamen die Angreifer am 10. Oktober an das Token eines GitHub-Organisationsinhabers, danach an die Tokens weiterer Maintainer, und am 21. Oktober schließlich an die Release-Pipeline. LiteLLM selbst schreibt, frühere Annahmen hätten sich als „ungenau oder unvollständig“ herausgestellt.

Für uns heißt das: Am Anfang stand kein raffinierter Zero-Day, sondern ein geleakter Key, den monatelang niemand widerrufen hat.

Was du jetzt tun solltest

• Prüfen, ob LiteLLM 1.107.0 oder eines der genannten Docker-Tags in Projekten, CI-Runnern oder Images steckt. Achtung: Wer latest oder main-stable im Zeitfenster gezogen hat, ist möglicherweise betroffen, ohne es zu ahnen.
• Nicht zuerst Python oder pip starten in einer verdächtigen Umgebung. Lieber per Dateisuche nach litellm-1.107.0.dist-info, cook.pth und sitecustomize.py schauen. Wenn nichts auftaucht, heißt das laut LiteLLM übrigens noch nicht, dass das System sauber ist.
• Neu aufsetzen statt reparieren: Betroffene Systeme isolieren, virtuelle Umgebungen und Images von Grund auf neu bauen, auf litellm==1.106.2 oder eine andere Version von vor dem Vorfall pinnen. Ein Update allein reicht nicht.
• Alles rotieren, was auf dem Host erreichbar war: Cloud-Rollen und Keys, alle Provider-Keys in der LiteLLM-Datenbank, Master- und virtuelle Keys, Datenbank-Passwörter, SSH-Schlüssel, Tokens in Umgebungsvariablen.
• Logs prüfen: In AWS CloudTrail nach GetCallerIdentity-Aufrufen um den Installationszeitpunkt und nach Nutzung eurer Credentials von außerhalb suchen.

Mein Rat geht aber über diesen Vorfall hinaus. Ein KI-Gateway ist ein Tresor für API-Keys, und so sollte man es auch behandeln: Versionen fest pinnen statt latest, Images per Digest referenzieren, neue Releases ein paar Tage abhängen lassen. Und wer selbst Software veröffentlicht, sollte geleakte Keys sofort widerrufen, auch wenn das Leck harmlos aussieht. Ein CVE gibt es zu diesem Vorfall übrigens bisher nicht, man kann also nicht darauf warten, dass der Schwachstellenscanner anschlägt.

Quellen

• LiteLLM: Security Incident Oct 21, 2026
• LiteLLM: Ursachenanalyse / Attack Chain
• BleepingComputer: LiteLLM release pipeline hacked to distribute info-stealer malware
• Help Net Security: LiteLLM compromised in supply chain attack
• SecurityWeek: LiteLLM Compromised in Fresh Supply Chain Attack

Was ich getestet habe

Am 23. Oktober 2026 habe ich die kostenlosen Modelle darauf geprüft, ob sie Werkzeuge korrekt aufrufen. Fachlich heißt das Tool Calling: Das Modell gibt einen strukturierten Aufruf zurück, etwa „Funktion X mit Parameter Y“, und das Agenten-Programm führt ihn aus.

Ergebnis meines Tests:

• Funktioniert hat es bei Nemotron 3 Ultra 550B (NVIDIA), Flint 1.0 (Recursive), Laguna S 2.1 (Poolside), Dots 3 (Dots Studio) und North Mini Code (Cohere).
• Gemma 4 31B (Google) und Xing 4.0 lieferten nur den Fehler 429.
• Inkling (Thinking Machines) lief bei mir nur in Agenten-Programmen.

Das sind Beobachtungen aus einem einzelnen Testlauf und keine unabhängige Messung. Belegen lässt sich dagegen: Alle genannten Modelle sind als kostenlos gelistet und nehmen laut Modellseiten bzw. der Übersicht von CostGoat den Parameter für Werkzeuge an.

Zum Fehler 429: Laut OpenRouter-Doku bedeutet er „Rate limit exceeded“, also zu viele Anfragen. Ob dahinter eine Überlastung beim Anbieter steckte oder ein Limit auf meiner Seite, lässt sich von außen nicht sicher sagen.

Zu Inkling: Auf der Modellseite von Inkling (free) steht kein Hinweis, dass der kostenlose Zugang auf Agenten-Programme beschränkt ist. Erwähnt wird dort nur, dass das Modell derzeit nicht über EU-Routing erreichbar ist. Die Einschränkung auf Agenten bleibt also meine Beobachtung.

Was sich seit dem Post getan hat

Viel ist es nicht. Die CostGoat-Liste wurde am 29. Oktober aktualisiert und führt weiterhin alle acht genannten Modelle als :free, jeweils mit Tool-Unterstützung. Insgesamt stehen dort derzeit 17 kostenlose Modelle. Das zeigt aber auch, wie schnell sich diese Liste ändert. Was heute gratis ist, kann nächste Woche verschwunden sein.

Die Limits

Laut der offiziellen Doku, die TrueFoundry bestätigt, gilt für alle :free-Modelle:

• höchstens 20 Anfragen pro Minute,
• höchstens 50 Anfragen pro Tag, solange man insgesamt weniger als 10 Credits gekauft hat,
• 1.000 Anfragen pro Tag, sobald man mindestens 10 Credits gekauft hat.

Für Agenten ist das knapp. Ein Agent schickt pro Aufgabe oft viele Anfragen, weil jeder Werkzeugaufruf eine eigene Runde ist. 50 Anfragen sind deshalb schnell weg. Laut TrueFoundry können außerdem auch fehlgeschlagene Anfragen auf das Tageslimit angerechnet werden.

Datenschutz: Der eigentliche Preis

„Kostenlos“ heißt nicht „ohne Gegenleistung“. Laut TrueFoundry laufen 9 von 19 untersuchten Gratis-Modellen bei Anbietern, deren Bedingungen ein Training mit den Prompts erlauben, darunter NVIDIA und Thinking Machines. Andere speichern die Prompts eine Zeit lang, ohne damit zu trainieren, bei Google AI Studio sind es zum Beispiel 55 Tage. Kann OpenRouter die Richtlinie eines Anbieters nicht feststellen, wird der Endpunkt vorsorglich so markiert, als würde er trainieren und speichern.

Das heißt nicht, dass jeder Prompt im Training landet. Erlaubt ist es aber. Für einen Agenten, der Dateien liest, Code sieht oder Logs auswertet, ist das ein echtes Risiko. Was er sieht, geht an den Anbieter.

Was ich rate

• Zum Ausprobieren gut: Wer Agenten-Workflows testen oder ein Modell kennenlernen will, bekommt hier brauchbare Modelle ohne Kosten.
• Keine vertraulichen Daten: Keine Kundendaten, keine Zugangsdaten, kein interner Code. Davon geht man am besten bei jedem :free-Modell aus.
• Datenschutz-Einstellungen prüfen: OpenRouter bietet Schalter für den Datenschutz und die Anfrage-Option data_collection: "deny". Dann fallen aber Anbieter weg, die trainieren, und damit oft auch Gratis-Modelle.
• Nicht darauf bauen: Bei 50 Anfragen am Tag, 429-Fehlern und einer Liste, die sich ständig ändert, gehört nichts Produktives auf diese Endpunkte.
• Fallback einplanen: Wer es trotzdem nutzt, sollte ein zweites Modell hinterlegen, falls eines wegfällt oder gedrosselt wird.

Mein Fazit: Zum Spielen und Lernen gut, für Arbeit, auf die man sich verlassen muss, eher nicht.

Quellen

• OpenRouter: Modelle, Suche „free“
• OpenRouter Docs: API-Limits
• OpenRouter: Nemotron 3 Ultra (free)
• OpenRouter: Flint (free)
• OpenRouter: Dots3-Note Preview (free)
• OpenRouter: Gemma 4 31B (free)
• OpenRouter: Inkling (free)
• CostGoat: OpenRouter Free Models
• TrueFoundry: OpenRouter free models – what's actually free

Ich habe mir die Kernaussagen angesehen. Kurz gesagt: Die Lage ist ernst. Der Text ist lauter als die Fakten.

Was belegt ist

PHP2Shell. Zwei Lücken in PHP, der Software hinter einem großen Teil aller Webseiten, Schweregrad 9.2 von 10. Wer sie ausnutzt, kann ohne Anmeldung eigenen Code auf dem Server ausführen. Die Updates kamen am 21. Oktober. Gefunden haben die Lücken Forscher von Wiz zusammen mit Calif und OpenAI, mit KI-gestützten Werkzeugen, gemeldet schon im August. (Recorded Future)

Amazon hat in seinen Honeypots, also Server, die nur als Köder für Angreifer dastehen, schon am 17. Oktober einen ersten Versuch gesehen. Vier Tage vor der Veröffentlichung. Inzwischen spricht Amazon von breiter Ausnutzung, Cloudflare von einem starken Anstieg der Angriffe. Laut Help Net Security zeigt ein funktionierender Exploit, dass eine einzige Anfrage ohne Anmeldung reicht. Einen bestätigten erfolgreichen Einbruch nennt aber bisher keiner der Berichte, die ich gelesen habe. Auch Amazons Fund vom 17. Oktober traf einen Köder-Server. (The Register, Techzine, Help Net Security)

Behörden gehen vom Netz. Deutschland, die Niederlande und weitere Länder haben vorsorglich Webseiten abgeschaltet, Wikimedia einen Teil seiner Systeme. In Deutschland waren laut Digitalministerium keine Vorfälle bekannt. Das Abschalten war Vorsicht, kein Einbruch. (CNBC)

Ein Angreifer, über 100 Firmen. Laut Reuters und dem Forscher Snorre Fagerland hat ein einzelner Angreifer mit KI-Agenten auf der Plattform Cairn die Webseiten von über 100 Firmen geknackt, darunter Deere und SharkNinja. Kosten: rund 5.000 Dollar, also etwa 50 Dollar pro erfolgreichem Einbruch. Wie viele Daten abgeflossen sind, ist unklar. Deere sieht keine Hinweise auf sensible Daten. (TNW)

Banken sperren KI-Agenten aus. JPMorgan lässt fremde KI-Agenten nicht mehr in Kundenkonten. Wer seine Zugangsdaten einem Agenten gibt, trägt laut Jamie Dimon das Risiko selbst. (Cybernews)

Was ich nicht bestätigen konnte

• Dass die Zahl „die Hälfte der Server ist zu alt für das Update“ von Cisco stammt. Eine ähnliche Zahl gibt es aber, dazu gleich mehr.
• Das Zitat, Bankmanager fänden die Lage „horrifying“.
• Weitere Zahlen aus dem Text (Lateinamerika, Südkorea, Japan) habe ich nicht nachgeprüft. Deshalb lasse ich sie weg.

Die Hälfte zu alt? Zahlen mit Vorsicht

Eine Shodan-Auswertung, auf die sich der Sicherheitsdienst CybelAngel beruft: Von rund 1,5 Millionen Servern, die ihre PHP-Version offen anzeigen, laufen 59 Prozent (883.717) auf einem Zweig, für den es kein offizielles Update gibt. Die „Hälfte“ aus dem Text ist also nicht aus der Luft gegriffen. (CybelAngel)

Nur zählen solche Scanner Versionsnummern, keine Lücken. Linux-Distributionen wie Ubuntu bauen den Fix in ihre eigenen Pakete ein und lassen die alte Versionsnummer stehen. Ein Server, den ich betreue, meldet „PHP 8.3.6“. Das klingt Jahre alt. Im Paket steckt aber der Patch für genau diese beiden Lücken, eingespielt am Morgen nach der Veröffentlichung. Ein Scanner zählt ihn trotzdem als verwundbar. Die echte Zahl ist also niedriger. Wie viel, weiß niemand genau.

Für PHP 7.4, 8.0 und 8.1 gibt es nur minimale Korrekturen im Quellcode, gedacht für Leute, die PHP selbst bauen. Wer bei einem Hoster auf so einer Version sitzt, kann damit nichts anfangen.

Was am Text nicht passt

„Black October“, „schick das allen“, Bargeld und Vorräte zu Hause: Das ist Alarm. Dabei schreibt Shumer selbst, dass bisher kein erfolgreicher Einbruch über die PHP-Lücke bestätigt ist.

Der Rat, kleine Webseiten zu meiden, ist gut gemeint, aber im Alltag nicht umsetzbar. Und die US-Einlagensicherung hilft hier niemandem. In Deutschland und der EU sind Einlagen gesetzlich bis 100.000 Euro pro Kunde und Bank geschützt.

Was du heute tun kannst

1. Updates installieren. Handy, Rechner, Browser und Router. Nie ein „Update“ aus einem Pop-up, einer SMS oder einer Mail.
2. Passwortmanager nutzen. Jedes Konto bekommt ein eigenes Passwort. iPhone und Android haben einen eingebaut.
3. Zwei-Faktor-Anmeldung einschalten, zuerst für E-Mail und Bank. Die E-Mail ist der Generalschlüssel zu allem anderen.
4. Bei Anrufen „von der Bank“ auflegen und selbst die Nummer auf der Karte wählen. Keine Bank fragt nach TAN oder Passwort.
5. Keine Bankdaten an KI-Assistenten oder fremde Apps geben, auch wenn es bequem wäre.
6. Kein Geld abheben. Panik ist genau das, worauf Betrüger setzen.

Wer selbst eine Webseite mit PHP betreibt: Version prüfen und auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren. Amazon empfiehlt, die Logs ab dem 17. Oktober durchzusehen, nicht erst ab der Veröffentlichung. Für 8.1 und älter gibt es kein fertiges Update: umsteigen oder beim Hoster bzw. der Distribution nachfragen. Unter Ubuntu und Debian bleibt die alte Versionsnummer stehen, ob der Fix drin ist, zeigt apt changelog php8.3-common (mit deiner Version). Wer hinter Cloudflare liegt, bekommt Firewall-Regeln gegen die bekannten Angriffswege, auch im kostenlosen Tarif. Das ersetzt das Update nicht.

Schneller, nicht unaufhaltsam

Angreifer sind schneller geworden, weil KI ihnen Arbeit abnimmt. Das ist real. Die Antwort darauf ist aber nicht Panik, sondern das Langweilige: Updates, eigene Passwörter, zweiter Faktor.

Die ersten 48 Stunden dieser Woche gibt es als Video: The 48 Hours, Folge 1.

Der Aufbau

Alles läuft in Containern, zusammengehalten von einer einzigen Compose-Datei:

• Caddy als Webserver vorne dran. Er verteilt jede Anfrage anhand des Hostnamens an die richtige Stelle.
• WordPress für den Hauptblog, mit MariaDB als Datenbank.
• Nextcloud für Dateien, Kalender und Videoanrufe.
• Forgejo als eigener Git-Server.
• Ein paar statische Seiten, so wie diese hier.

Die Daten liegen auf einer externen Platte. Die Idee dahinter: Platte an einen anderen Rechner hängen, Stack starten, alles läuft weiter.

Keine offenen Türen

Der Router hat für die Webseiten keinen einzigen offenen Port. Stattdessen baut ein kleiner Dienst von innen eine Verbindung zu Cloudflare auf, einen Tunnel. Besucher landen bei Cloudflare, Cloudflare reicht die Anfrage durch den Tunnel an Caddy weiter. Von außen sieht man meinen Anschluss gar nicht.

Für mich selbst gibt es noch einen zweiten Weg über ein privates VPN. Darüber erreiche ich auch Dinge, die bewusst nicht öffentlich sind.

Was dabei passiert ist

Eine Lektion, die ich nicht erwartet hatte: Mein Git-Server war eine Zeit lang öffentlich erreichbar. Innerhalb von gut anderthalb Tagen haben KI-Crawler rund 300.000 Anfragen geschickt und tausende Archive heruntergeladen. Kein Angriff im klassischen Sinn, einfach Bots, die alles abgrasen, was sie finden.

Seitdem hängt der Git-Server nicht mehr am Tunnel. Ich erreiche ihn nur noch über das VPN. Und ich führe Zugriffsprotokolle, die ich regelmäßig auswerte.

Lohnt sich das?

Für mich ja. Ich lerne dabei mehr als bei jedem Kurs, ich weiß, wo meine Daten liegen, und es kostet kaum mehr als Strom. Der Preis: Wenn etwas kaputtgeht, bin ich der Admin. Um drei Uhr nachts auch.

PHP: zwei Lücken, Schweregrad 9.2 von 10. Patchen oder vom Netz nehmen.

GitLab: 10.0, die Höchstnote. Betroffen ist jede Version seit 2014.

eMudhra: Ein privater Schlüssel hatte den Wert 4.

LiteLLM: knapp zwei Stunden lang ein verseuchtes Paket auf PyPI.

Onamae: 26.739 Server, alle Tarife abgeschaltet.

Cairn: ein Angreifer, über 100 Firmen, rund 50 Dollar pro Einbruch.

SBI: 3.897 Datensätze betroffen.

USA, EU, Japan. Patchen oder offline gehen.

Wie das Video entstand

Skript, Gestaltung und Code mit Claude Code, gerendert mit HyperFrames aus HTML. Die Stimme ist Kokoro-82M und läuft lokal auf meinem Rechner. Kein Stock-Material, kein Rendern in der Cloud.

Die „9.2“ auf der Tafel ist übrigens keine PHP-Version, sondern der CVSS-Wert, also der Schweregrad. Darüber bin ich selbst gestolpert, deshalb steht es jetzt dabei.

Das soll sich hier ändern.

Was hier steht

Zwei Sorten Artikel:

• Gebaut: Berichte über meine Projekte. Was es ist, wie es funktioniert, wo es gehakt hat. Ohne Hochglanz.
• Alles andere: Gedanken zu Technik, Gesellschaft, Alltag, was mich gerade umtreibt. Kein festes Thema.

Was „ungefiltert“ heißt

Nicht: laut, provokant, ohne Nachdenken. Sondern: Ich schreibe, wie es war. Wenn ein Projekt halb fertig ist, steht da „halb fertig“. Wenn ich falsch lag, steht das auch da.

Und die KI?

Ich schreibe diese Texte zusammen mit einer KI. Das läuft so:

1. Ich gebe ein Thema vor, oft mit Stichpunkten, Notizen oder einfach dem Projekt selbst.
2. Die KI macht daraus einen Entwurf.
3. Ich lese, streiche, korrigiere und gebe frei. Erst dann erscheint der Text hier.

Die KI hilft mir, schneller vom Gedanken zum Text zu kommen. Was hier steht, vertrete ich trotzdem selbst. Wenn etwas nicht stimmt, ist das mein Fehler, nicht der der Maschine.

Technik, kurz

Dieser Blog ist eine Handvoll statischer HTML-Dateien. Kein Content-Management-System, keine Datenbank, keine Cookies, kein Tracking, keine externen Schriften. Er läuft auf einem Mac mini bei mir zu Hause und ist über einen Cloudflare-Tunnel erreichbar. Jeder Artikel erscheint auf Deutsch und Englisch. Wer mitlesen will, nimmt den RSS-Feed.

Warum so klein?

Weil ich nicht wissen will, wie es sich vor tausend Leuten schlägt, sondern wie es sich mit zehn anfühlt. Mit wenigen Mitspielern kann ich jedes Feedback lesen, jeden Fehler nachvollziehen und schnell nachbessern, ohne Support-Abteilung.

Wer mitspielen will, fragt einen persönlichen Zugangscode an. Solange Plätze frei sind, gibt es einen. Die Spielstände bleiben auf dem eigenen Rechner.

Was drinsteckt

• Der Spielkern ist in Rust geschrieben und enthält alle Regeln. Er läuft ohne Grafik und hat eigene Tests, das Spiel selbst und der Server benutzen ihn unverändert.
• Die Windows-Version baut eine automatische Pipeline, die Mac-Versionen baue ich selbst.
• Die Webseite dazu läuft als kleiner Worker bei Cloudflare, mit Intro-Video und Download-Bereich.

Die Saatstube

Ab Level 50 gibt es die Saatstube. Dort kreuzt man Pflanzen, gibt neuen Sorten einen Namen, sammelt sie in einem Sortenbuch und zeigt sie in einer Sortenschau. Die Sorten verändern nur das Aussehen, nicht die Spielwerte. Das war eine bewusste Entscheidung: Wer nicht kreuzen will, hat keinen Nachteil.

Die Balance habe ich nicht nach Gefühl eingestellt, sondern simuliert. Von Level 50 bis 100 braucht man in der Simulation 26 Tage, gut ein Viertel der Erfahrungspunkte kommt dabei aus der Saatstube. Auf dem Weg dorthin musste ich Bäume abwerten: Sie brachten so viele Punkte, dass sich alles andere kaum lohnte.

Der Dorfplatz

Seit Version 0.3 spielt man nicht mehr nur für sich. Es gibt einen eigenen Spielserver und einen gemeinsamen Dorfplatz: einen Chat für alle Mitspieler, dazu Nachrichten, wenn jemand ein Level erreicht oder eine seltene Sorte gezüchtet hat. Die Nachrichten kann jeder für sich abschalten.

Den Chat habe ich ernster genommen, als man es bei zehn Leuten müsste. Er ist Ende-zu-Ende verschlüsselt mit MLS (Messaging Layer Security), einem offenen Standard für Gruppenchats. Der Server stellt die Nachrichten nur zu und kann sie nicht lesen. Dazu kommt Post-Quanten-Kryptografie, also Verfahren, die auch ein künftiger Quantencomputer nicht knacken soll: Schlüsselaustausch mit ML-KEM und X25519 kombiniert, Signaturen mit ML-DSA. Die Verbindung zum Server ist auf dieselbe Art geschützt und läuft über einen Cloudflare-Tunnel statt über offene Ports.

Ehrlich gesagt: Die verwendete Kombination ist noch ein Entwurf der IETF, kein fertiger Standard. Das steht auch so im Spiel. Getestet habe ich unter anderem, was passiert, wenn der Server lügt, also einen falschen Absender vortäuscht oder Nachrichten vertauscht. Dann zeigt das Spiel nichts davon an, sondern eine Warnung. Einen unabhängigen Blick auf den Einbau halte ich trotzdem für sinnvoll, bevor ich mich darauf verlasse.

Figuren, die reden

Auf dem Hof laufen Figuren herum, die arbeiten und mit denen man sprechen kann. Mit einem lokalen Sprachmodell antworten sie frei, ohne Modell kommen die Antworten aus Vorlagen. Seit 0.3.1 startet das Spiel ohne KI, man schaltet sie im Gespräch mit „Mit KI reden“ zu. Der Grund ist einfach: Die meisten Mitspieler haben kein Sprachmodell auf dem Rechner, und ein Spiel sollte nicht hängen, nur weil eine KI fehlt.

Das Radio

Nebenbei ist Farmaradio entstanden: ein Webradio als Web-Komponente, die man mit einer Zeile in jede Seite einbauen kann. Zuerst nur für das Spiel gedacht, ist es inzwischen ein eigenes kleines Projekt und läuft auch im Spiel in der Fußzeile.

Der nervigste Teil daran war nicht das Abspielen, sondern Browser-Sicherheitsregeln: Welche Seite darf Audio von welcher anderen Seite laden? Das hat mich einen Abend gekostet und ist jetzt mit zwei Zeilen erledigt.

Wie es weitergeht

Erst einmal gar nicht. Die Entwicklung ruht, bis sich ein paar Leute gefunden haben, die mitspielen. Ein Dorfplatz ohne Dorf ergibt wenig Sinn, und ich will nicht weiter an Dingen bauen, die noch niemand ausprobiert hat.

Die Pläne liegen trotzdem fertig in der Schublade. Als Nächstes käme die Dorfschau: eine wöchentliche Runde, in der alle ihre schönsten Sorten zeigen und die besten einen Preis bekommen. Danach soll derselbe Hof auf einem zweiten Rechner laufen, also morgens am Mac und abends unter Windows.

Offen ist die Frage, wo die KI der Figuren laufen soll, wenn mehr Leute sie nutzen. Beim Spieler selbst kostet sie nichts, braucht aber einen kräftigen Rechner. Auf meinem Server oder bei einem Anbieter würde der getippte Text das Gerät verlassen. Das will ich erst sauber geregelt haben, bevor ich es anbiete.

Was davon kommt und in welcher Reihenfolge, entscheiden die, die mitspielen. Wer dabei sein will, fragt auf farmeramania.de einen Zugangscode an.