Die Malware war von Red Hat signiert
Diese Woche erreichte Code, der Zugangsdaten stiehlt, Entwickler unter dem Namen von Red Hat. Die Bedrohung kam nicht von außerhalb deines Vertrauenskreises — sie kam von innen. Da hilft kein Prüfen. Aber du kannst deine Zugangsdaten außer Reichweite halten.
Diese Woche versuchte von Red Hat signierter Code, deine Zugangsdaten zu stehlen.
Angreifer verschafften sich Zugang zum Konto eines Red-Hat-Entwicklers und veröffentlichten manipulierte Versionen offizieller Red-Hat-Pakete. In dem Moment, in dem ein Rechner eines davon installierte, lief automatisch versteckter Code und griff nach allem Wertvollen, das er finden konnte — Cloud-Schlüssel, Zugangstokens, Logins, alles, was eine Tür öffnet. Dann nutzte er das Gestohlene, um sich weiterzuverbreiten.
Achte auf das Muster dahinter. Red Hat war nicht das Ziel — du warst es. Ihr Name, ihr vertrauenswürdiges Konto, die Installations-Pipeline, die du tausendmal ohne Nachdenken genutzt hast: Das war nicht das Opfer. Das war die Waffe. Der Angriff schlich sich nicht an deinem Vertrauenskreis vorbei. Er kam durch die Vordertür, mit einem Ausweis, den du selbst ausgestellt hast. Genau das unterscheidet Supply-Chain-Angriffe von allem anderen — die Gefahr ist kein Fremder, den du blockieren kannst, sondern der Anbieter, dem du dich längst anvertraut hast und der die Schadlast für dich ausliefert. Und das war Red Hat: eines der sicherheitsreifsten Unternehmen überhaupt, mit echten Reviews und echtem Budget. Der Schadcode ging trotzdem unter ihrem Namen raus.
Daraus ergibt sich ein Schluss, dem du nicht ausweichen kannst: Wenn Red Hat nicht garantieren kann, dass das, was du von ihnen installierst, sauber ist, dann kann es niemand. Nicht dein Framework, nicht dein CI-Anbieter, nicht die Abhängigkeit drei Ebenen tiefer, die du nie gelesen hast. Irgendwann führst du Code aus, den du nicht geschrieben und nicht vollständig geprüft hast. Das ist kein Prozessfehler — das ist das Wesen davon, auf der Software anderer aufzubauen.
Scanne weiter. Pinne weiter deine Versionen. Prüfe weiter. All das ist sinnvoll — verlass dich nur nicht darauf, denn diese Woche hätte nichts davon geholfen: Die Malware kam bereits mit Vertrauensvorschuss. Die eigentliche Frage ist nicht, wie du den Schadcode draußen hältst. Sondern: Wenn Schadcode auf deinem Rechner läuft — hast du deine Geheimnisse geschützt?
Für die meisten lautet die ehrliche Antwort: nein. Sieh dir an, was dieser Angriff abgegriffen hat — Umgebungsvariablen, Tokens in Dateien, und dann ging er direkt zu den Cloud-Secret-Managern und bat sie, ihre Inhalte herauszugeben. Denn so liegen Zugangsdaten 2026 herum: an einem Ort gestapelt, in Reichweite von allem, was gerade läuft. Eine einzige verseuchte Installation nimmt nicht ein Geheimnis. Sie nimmt alle — und verbreitet sich dann weiter.
Die Lösung ist, deine Zugangsdaten nicht mehr dort aufzubewahren, wo dein Code sie greifen kann. Halte sie auf Armlänge Abstand.
Genau darauf beruht die Funktionsweise von Clavitor. Deine Geheimnisse liegen nicht in deiner Umgebung; nichts wartet in einer .env-Datei darauf, gelesen zu werden. Ein Programm — oder ein KI-Agent — hält niemals die Zugangsdaten selbst. Es erhält die Fähigkeit, sie zu nutzen, frisch abgerufen genau in dem Moment, in dem sie gebraucht werden — nie gespeichert, nie zwischengespeichert — von einem unserer 21 Standorte auf sechs Kontinenten, sodass die nächste Kopie immer nur Millisekunden entfernt ist, beschränkt auf genau das eine Geheimnis, für das die Freigabe erteilt wurde, und jeder Zugriff wird protokolliert. Wenn ein bösartiges Installationsskript nach Schlüsseln tastet, findet es einen leeren Raum.
Und wir gehen davon aus, dass irgendwann doch einmal Zugangsdaten abgefangen werden — deshalb ist das, was ein Agent mit sich trägt, im Fall eines Diebstahls nahezu wertlos. Es funktioniert nur von dem Rechner aus, für den es ausgestellt wurde — entwende es und nutze es von den Servern des Angreifers, und es wird abgewiesen. Es ist ratenbegrenzt und überwacht: nur wenige Geheimnisse pro Minute, sodass es deinen Tresor nicht leersaugen kann, und sobald es über seine übliche Handvoll hinausgreift, löst es einen Alarm aus und wird gesperrt. Die ganze Strategie eines Wurms — alles schnell greifen, überall verwenden — läuft gegen eine Wand.
Keine Versprechen von Unverwundbarkeit: Wenn ein Zugangsdatum genau in dem Moment in aktiver Nutzung ist, in dem die Malware läuft, kann genau dieses eine erwischt werden — keine Architektur schreibt die Physik um. Aber genau das ist der Punkt. Der Red-Hat-Angriff war so verheerend, weil eine einzige Installation einen ganzen Secret-Speicher leeren und zur Waffe machen konnte. Armlänge Abstand, plus Zugangsdaten, die an einen Rechner gebunden und auf ein Rinnsal gedrosselt sind, verwandeln „sie haben alles genommen und sich verbreitet" in „sie haben vielleicht einen Schlüssel im Flug erwischt, und der funktionierte nirgendwo sonst". Das ist der Unterschied zwischen einer Katastrophe und einer Fußnote.
Die Malware war von Red Hat signiert. Da kommst du mit Prüfen nicht durch. Geh davon aus, dass der Code hereinkommt — und sorge dafür, dass deine Geheimnisse dann nicht einfach dort liegen und auf ihn warten.
(Wird öffentlich als „Miasma" verfolgt, eine Variante der Shai-Hulud-Familie sich selbst verbreitender npm-Würmer. Die technischen Analysen lohnen sich; in diesem Beitrag geht es um den Teil, der von einem Fall zum nächsten gleich bleibt.)
Sources: