CVE-2026-33634 und die Kompromittierung der Trivy-Lieferkette - wie veränderbare Tags einen Sicherheitsscanner in einen Dieb von Zugangsdaten verwandelten

CVE-2026-33634 beschreibt eine Kompromittierung der Lieferkette in Trivy und den damit verbundenen GitHub-Aktionen, nicht einen normalen Fehler in der Scanner-Logik. Die öffentlichen Aufzeichnungen bringen den Vorfall mit einer bösartigen Trivy-Version v0.69.4 in Verbindung, die unter Druck gesetzt wurde aquasecurity/trivy-action Tags, kompromittiert setup-trivy Tags und eine breitere Fortsetzung eines früheren Einbruchs Ende Februar 2026 in die Release-Pipeline von Trivy. In dem NVD-Eintrag werden die betroffenen Benutzer aufgefordert, davon auszugehen, dass die Geheimnisse dieser Workflows kompromittiert wurden, Workflows zu überprüfen, die die betroffenen Aktionen verwendet haben, Protokolle aus dem Zeitfenster vom 19. bis 20. März zu untersuchen und nach öffentlichen Repositories mit dem Namen tpcp-docs. GitHub, das als CNA fungiert, kennzeichnete das Problem als kritisch mit einem CVSS-B-Wert von 9,4. (NVD)

Dieser Rahmen ist wichtig, weil viele frühe Zusammenfassungen des Ereignisses den Eindruck erweckten, dass "Trivy eine bösartige Veröffentlichung hatte". Das stimmt zwar, ist aber nicht die ganze Geschichte. Ein weithin vertrauenswürdiger Scanner befand sich in CI-Pipelines, Release-Jobs, Container-Build-Systemen und Entwickler-Workflows. Als der Auslieferungspfad für diesen Scanner und seine Aktionen manipuliert wurde, beschränkte sich der Explosionsradius nicht auf den Rechner, auf dem der Scanner lief. Das eigentliche Ziel war die geheimnisumwitterte Umgebung: GitHub-Tokens, Cloud-Zugangsdaten, Registrierungsdaten, SSH-Material, Kubernetes-Daten und alle anderen hochwertigen Daten, die vom Runner aus erreichbar sind. GitHubs eigene Anleitung zur sicheren Nutzung warnt, dass eine kompromittierte Drittanbieter-Aktion auf Repository-Geheimnisse und die GITHUB_TOKENDas ist genau der Grund, warum veränderbare Verweise auf Aktionen eher ein Risiko in der Lieferkette darstellen als ein Vorteil bei der Versionierung. (GitHub-Dokumente)

Der Fall Trivy ist auch eine Erinnerung daran, dass nicht jedes kritische CVE einen direkt ausnutzbaren Code-Fehler beschreibt. Manchmal ist die Schwachstelle das Vertrauensmodell selbst. In diesem Fall waren die entscheidenden Schwachstellen ein wiederherstellbarer Veröffentlichungszugriff, veränderbare Tags, ein Weg in offizielle Veröffentlichungskanäle und die betriebliche Realität, dass viele Pipelines getaggte Aktionen so behandeln, als wären sie unveränderlich. Die Analyse von CrowdStrike zur Trivia-Aktion Teil der Kompromisslösung zeigte, dass 76 von 77 Tags in der Lagerstätte neu verfugt wurden. Das Gutachten von Aqua und die von Trivy geführte Diskussion über den Vorfall bestätigen, dass Trivia-Aktion, setup-trivyund Trivy-Release-Artefakte waren alle während bestimmter Zeitfenster betroffen, während Trivy v0.69.3 sicher blieb, da es bereits durch unveränderbare Releases geschützt war. (GitHub)

CVE-2026-33634, was der Datensatz tatsächlich umfasst

Ein nützlicher Ausgangspunkt ist die Trennung des offiziellen Umfangs von CVE-2026-33634 von der breiteren Kampagne, die sich um ihn herum entwickelt hat. Die Beschreibung von NVD verweist auf das bösartige Trivy v0.69.4, 76 von 77 aquasecurity/trivy-action Tags, und alle sieben setup-trivy Es wird ausdrücklich darauf hingewiesen, dass es sich bei dem Vorfall um die Fortsetzung eines Angriffs auf die Lieferkette Ende Februar 2026 handelt. Außerdem heißt es, dass die Rotation der Zugangsdaten nach der Offenlegung am 1. März nicht atomar war, was ein zurückhaltendes, aber wichtiges Eingeständnis ist: Der Schritt der Eindämmung hat den Zugang der Angreifer nicht vollständig unterbrochen. (NVD)

Das Advisory von GitHub enthält weitere Details zu den sicheren und unsicheren Zuständen. Laut dem Advisory waren die "known-safe"-Referenzen Trivy-Binärdateien und -Images in Version 0.69.3 oder früher, Trivia-Aktion bei v0.35.0 oder Commit 57a97c7und setup-trivy bei v0.2.6 oder Commit 3fb12ec. In demselben Gutachten wird erklärt, dass viele alte Trivia-Aktion Tags konnten nach der Force-Push-Aktivität des Angreifers nicht einfach unter ihrem alten Namen wiederhergestellt werden, so dass das Projekt sichere Veröffentlichungen mit einem führenden v Präfix. In der Praxis bedeutet das, dass die Teams Referenzen wie @0.34.0 diese Referenzen als unsicher zu behandeln und zu neuen sicheren Referenzen wie @v0.35.0 oder, besser noch, eine vollständige SHA-Übertragung. (GitHub)

Eine zweite Grenze ist ebenso wichtig. Docker gab später bekannt, dass die Kompromittierung nicht mit Version 0.69.4 endete. Zwischen dem 19. und 23. März zogen Docker Hub-Kunden, die 0.69.4, 0.69.5, 0.69.6, oder neueste aus dem Trivy-Repository von Aqua wurden möglicherweise ebenfalls offengelegt. Die Erklärung von Docker ist wichtig, weil sie klarstellt, dass diese späteren Image-Pushes als Aqua-Aktivitäten mit den Anmeldeinformationen von Aqua authentifiziert wurden. Docker sagte, dass seine eigene Infrastruktur und die Docker Hardened Images nicht kompromittiert wurden. Diese Unterscheidung verhindert, dass die Verteidiger falsche Schlüsse darüber ziehen, wo die Sicherheitslücke aufgetreten ist. Der Vertrauensbruch lag im Veröffentlichungspfad des Herausgebers, nicht in der Sicherheitsgrenze von Docker Hub. (Docker)

Die dritte Grenze ist der breitere Kontext der Kampagne. Microsoft brachte den Trivy-Vorfall mit Aktivitäten in Verbindung, die es TeamPCP zuschreibt, und sagte, dass sich dieselbe Kampagne auf Checkmarx KICS und LiteLLM ausweitete. Checkmarx veröffentlichte später ein eigenes Vorfalls-Update für betroffene GitHub-Aktionen, und LiteLLM veröffentlichte eine separate Meldung über die bösartigen PyPI-Pakete 1.82.7 und 1.82.8. Diese nachgelagerten Ereignisse sind relevant, weil sie zeigen, dass die Betreiber nicht nur an Trivy interessiert waren. Sie hatten es auf vertrauenswürdige Software-Vertriebskanäle und KI-nahe Ökosysteme im Allgemeinen abgesehen. Dennoch wäre es ungenau, alle diese Ereignisse in CVE-2026-33634 selbst zusammenzufassen. Das CVE von Trivy sollte als ein kritischer Knotenpunkt in einer größeren Supply-Chain-Kampagne beschrieben werden, nicht als Etikett für jedes bösartige Paket, das in diesem Monat veröffentlicht wurde. (Microsoft)

Das ist auch der Grund, warum die nützlichsten Fragen nicht lauten: "War mein Scanner verwundbar?" oder "Habe ich Trivy 0.69.4 benutzt?" Die besseren Fragen sind: Haben meine Workflows veränderbare Tags in den betroffenen Repositories referenziert, haben meine Runner diese Referenzen während des Expositionsfensters ausgeführt, welche Secrets waren betroffen und welche anderen Systeme vertrauten diesen Secrets? Teams, die nur ihre Paketmanifeste durchsuchen, verpassen die GitHub-Aktionsschicht. Teams, die nur GitHub-Workflows durchsuchen, entgehen möglicherweise Docker-Pulls von neueste. CVE-2026-33634 erstreckt sich über mehrere Vertrauensgrenzen, so dass das Scoping-Verfahren dies ebenfalls tun muss. (NVD)

CVE-2026-33634 Zeitleiste, von Ende Februar Fuß fassen, um 23. März Reinigung

Die öffentliche Geschichte beginnt vor dem 19. März. Der Bericht von Aqua über den Vorfall und die Diskussion des Trivy-Teams besagen beide, dass die Kompromittierung am 19. März die Fortsetzung eines umfassenderen Angriffs war, der Ende Februar 2026 begann. In der separaten Berichterstattung von Orca über die frühere Phase wurde das Standbein mit einem unsicheren GitHub-Aktionsmuster in Verbindung gebracht, an dem pull_request_target und Checkout von nicht vertrauenswürdigem Pull-Request-Code. Dieses Muster ist gefährlich, weil pull_request_target mit erhöhtem Kontext ausgeführt wird, und wenn der Workflow dann eine vom Angreifer kontrollierte Hauptübergabe auscheckt, kann der Angreifer die für die vertrauenswürdige Repository-Logik vorgesehenen Berechtigungen erben. Die spätere Zeitleiste von Aqua und die Diskussion über den Vorfall vom 19. März von Trivy stimmen mit dem Kernpunkt überein, auch wenn sie nicht jedes Detail des Workflows wiedergeben: Der Angreifer hatte bereits vor der Ausführungsphase am 19. März Fuß gefasst. (Orca Sicherheit)

Am 1. März machte Trivy den früheren Vorfall öffentlich und wechselte die Zeugnisse. Dies wäre normalerweise der Zeitpunkt, an dem Verteidiger erwarten, dass sich das Fenster schließt. Stattdessen wurde in der Empfehlung vom 19. März erklärt, dass die Rotation nicht atomar war, so dass weiterhin gültige Anmeldedaten oder aktualisierte Zugriffspfade vorhanden waren. Dieser eine Satz ist für die Verteidigung von überragender Bedeutung. Er bedeutet, dass das Team zwar reagiert hat, aber die Reaktionssequenz es einem geschickten Angreifer ermöglichte, innerhalb der Freigabe- und Automatisierungsebene am Leben zu bleiben. Incident Response-Teams neigen dazu, die Rotation von Geheimnissen als binär zu betrachten: entweder rotiert oder nicht rotiert. CVE-2026-33634 ist ein praktisches Beispiel dafür, warum Reihenfolge, Umfang und Vollständigkeit genauso wichtig sind wie die Rotation selbst. (GitHub)

Am 19. März um etwa 17:43 UTC begann die sichtbare Ausführungsphase. Laut Aqua erzwang der Angreifer 76 von 77 Tags in aquasecurity/trivy-action und alle sieben Tags in aquasecurity/setup-trivy. Etwa zur gleichen Zeit löste ein kompromittiertes Dienstkonto die Release-Automatisierung aus, um ein bösartiges Trivy v0.69.4 zu erzeugen. Der GitHub-Beratungsbericht fügte später technische Details hinzu: ein bösartiger Commit 1885610c den Freigabe-Workflow durch Ersetzen von Aktionen/Checkout mit einer Fälscherbindung 70379aadDann luden sie bösartige Go-Dateien von einer typosquatted Domain herunter und umgingen so die normale Validierung der Version. Diese Kombination war von Bedeutung, weil sie sowohl den Inhalt der Veröffentlichung als auch das Vertrauen der Benutzer in den Arbeitsablauf, der sie erstellt hat, untergrub. (Aqua)

Die Trivy-Maintainer identifizierten und dämmten die erste Welle später am 19. März ein, und am 20. März veröffentlichten sie sichere Versionen und Hinweise auf die Kompromittierung. Die betroffenen Zeiträume in der offiziellen Diskussion über den Vorfall waren knapp bemessen, aber folgenreich: Trivy v0.69.4 war von etwa 18:22 UTC bis 21:42 UTC am 19. März betroffen, Trivia-Aktion von etwa 17:43 UTC am 19. März bis 05:40 UTC am 20. März, und setup-trivy von etwa 17:43 UTC bis 21:44 UTC am 19. März. Diese Zeitfenster sind so klein, dass einige Teams davon ausgingen, dass sie wahrscheinlich nicht getroffen wurden. Das ist ein Irrtum. CI-Pipelines laufen oft über Cron, werden bei jeder Zusammenführung gezogen oder bei Wiederholungsversuchen automatisch neu gestartet. Wenn ein Workflow ein gefährdetes veränderbares Tag verwendet, ist die Dauer des Fensters weniger wichtig als die Häufigkeit und die Berechtigung der Jobs, die es berührt haben. (GitHub)

Die Geschichte war damit noch nicht zu Ende. Laut Docker verbreiteten die Angreifer später weitere kompromittierte Image-Tags 0.69.5, 0.69.6und neueste über Aqua's eigenes Docker Hub Repository. Die Zeitleiste von Docker zeigt die Auswirkungen auf die Benutzer vom 19. März um 18:24 UTC bis zum 23. März um 01:36 UTC für diese Tags. Docker stellte außerdem fest, dass neueste wurde nach einer anfänglichen Bereinigung neu verlinkt, und der kompromittierte Inhalt wurde später zur Untersuchung unter Quarantäne gestellt. Das Trivy GitHub Advisory ergänzt diese Offenlegung, indem es erklärt, dass 0.69.5 und 0.69.6 überhaupt keine normalen GitHub-Releases waren. Sie wurden direkt auf Docker Hub gepusht, wobei separat kompromittierte Docker Hub-Anmeldedaten verwendet wurden. Mit anderen Worten: Verteidiger können "keine GitHub-Veröffentlichung sehen" nicht mit "es wurde nichts Bösartiges veröffentlicht" gleichsetzen. (Docker)

Eine weitere Nuance ist leicht zu übersehen. In der Empfehlung heißt es, dass der Angreifer auch versucht hat, eine v0.70.0 Freigabe, aber diese Freigabe wurde unterbrochen, bevor das Tag verschoben wurde. Das ist für die Protokollprüfung von Bedeutung. Eine fehlgeschlagene oder teilweise 0.70.0 Referenz in Ihren Telemetriedaten kann immer noch auf die Gefährdung durch den Angriffspfad hinweisen, selbst wenn die Version nie zu einem normalen öffentlichen Release wurde. Teams, die nur abgeschlossene Artefakt-Downloads überprüfen, können fehlgeschlagene Release-Job-Nebeneffekte übersehen. (GitHub)

Die Zeitleiste hat also zwei unterschiedliche Bedeutungen. Aus operativer Sicht zeigt sie Ihnen, wo Sie jagen müssen. Aus strategischer Sicht zeigt sie das Modell des Angreifers: Fuß fassen auf der Release-Ebene, unvollständige Abhilfemaßnahmen überleben, vertrauenswürdige Tags manipulieren, bösartige Inhalte in offizielle Kanäle einschleusen und diese Kanäle dann nutzen, um Geheimnisse aus nachgelagerten CI-Umgebungen zu sammeln. Dieses Modell ist übertragbar. Wenn die Verteidiger nur die Versionsnummern und nicht das Muster entfernen, sind sie beim nächsten Mal, wenn dieselbe Technik in einem anderen Projekt auftaucht, unvorbereitet. (GitHub)

Warum CVE-2026-33634 kein normaler Trivy-Bug ist

Es ist verlockend, jede CVE als einen Softwarefehler im herkömmlichen Sinne zu betrachten: ein Parser-Fehler, ein Fehler bei der Rechteabgrenzung, ein RCE-Pfad, ein Speicherbeschädigungsproblem. CVE-2026-33634 ist aufschlussreicher als das. Das Sicherheitsversagen lag nicht in der Logik der Schwachstellenerkennung des Scanners. Er lag in der Software-Lieferkette und in der Art und Weise, wie nachgeschaltete Verbraucher den Lieferreferenzen vertrauten. Der NVD stuft das Problem unter CWE-506, eingebetteter bösartiger Code, ein. Anhand dieser Klassifizierung erkennt man sofort, dass der Vorfall zur gleichen Familie wie vergiftete Versionen und bösartige Artefakte gehört, und nicht zur gewöhnlichen Ausnutzung von Fehlern. (NVD)

Diese Unterscheidung ist nicht akademisch. Wenn eine normale Anwendungsschwachstelle einen Scanner betrifft, ist die Verteidigungshaltung in der Regel einfach: Flicken, erneut testen, vielleicht die Exposition einschränken. Bei einer Kompromittierung auf dem Freigabepfad wird jede Annahme über das Vertrauen in die Komponente verdächtig. Über welche Kanäle sie bereitgestellt wurde. Welche Tags auf die Komponente verweisen. Welche Signaturen sie verifiziert haben. Welche Runner haben sie ausgeführt. Welche Geheimnisse zum Zeitpunkt der Ausführung in Kraft waren. Ob die Bereinigung frühere Anmeldeinformationen vollständig ungültig machte. Ob Mirrors bösartige Inhalte zwischengespeichert haben, nachdem die ursprüngliche Quelle behoben wurde. Docker hat einen Teil dieser Lektion unterstrichen, als es warnte, dass veränderliche Tags keine Sicherheitsgrenze darstellen und dass Digest-Pinning identische Bytes garantiert, nicht aber die Herkunft von Artefakten. (Docker)

In der Dokumentation von GitHub wird der CI-Teil noch deutlicher. Eine Aktion eines Drittanbieters wird mit genau den Berechtigungen und der Umgebung ausgeführt, die Sie dem Job zugestehen. Wenn Sie eine Action mit einem veränderbaren Tag referenzieren, vertrauen Sie dem Konto des Action-Maintainers, dem Schutz des Repositorys, dem Veröffentlichungsprozess, der Fähigkeit zum Schutz der Release-Anmeldedaten und der Fähigkeit der Plattform, die Tag-Integrität durchzusetzen. Viele Teams sagen, dass sie eine Aktion "verkaufen", weil sie ein Freigabe-Tag verwenden wie @v1 oder @1.2.3. GitHub warnt ausdrücklich davor, dass Tags verschoben oder gelöscht werden können, selbst wenn man dem Autor vertraut, und empfiehlt, einen vollständigen SHA-Commit zu pinnen. CVE-2026-33634 existiert, weil zu viele Pipelines diesen Hinweis als optional behandelt haben. (GitHub-Dokumente)

Die Kompromittierung von Trivy ist besonders schwerwiegend, weil die angegriffene Komponente selbst ein Sicherheitstool war. Sicherheitstools werden häufig in privilegierten Arbeitsabläufen ausgeführt, oft mit weitreichendem Repository-Zugang, Artefakt-Zugang, Registry-Zugang und manchmal auch mit Cloud-Zugangsdaten, die zum Scannen oder Validieren bereitgestellter Images benötigt werden. Das bedeutet, dass das Sicherheitstool ein attraktiveres Ziel in der Lieferkette werden kann als die zu testende Anwendung. Microsofts Bericht über den Trivy-Vorfall verdeutlicht dies indirekt, indem er zeigt, wie die Nutzlast Prozessspeicher, Cloud-Metadaten, Kubernetes-Daten und Dateipfade in Verbindung mit Anmeldeinformationen abfragte. Der Angreifer hat nicht von Trivy gestohlen. Der Angreifer stahl aus der Vertrauenszone um Trivy. (Microsoft)

Es gibt hier auch eine umfassendere kulturelle Lektion. Viele Entwicklungsorganisationen haben sich mit Sicherheitsscannern als passive Hygienetools angefreundet. Sie fühlen sich wie Routine an, fast wie eine Infrastruktur. Das Ergebnis ist, dass Scanner-Updates, GitHub-Aktionsverweise und Container-Tags weniger genau geprüft werden als Änderungen am Produktionscode. CVE-2026-33634 ist eine starke Widerlegung dieser Gewohnheit. Ein Scanner in CI ist nicht nur eine Hilfsbinärdatei. Es handelt sich um ausführbaren Code in einer der reichhaltigsten Berechtigungsumgebungen in Ihrem Unternehmen. Ihn als eine Abhängigkeit mit geringem Risiko zu behandeln, ist genau das, was ein Angreifer von Ihnen erwartet. (GitHub-Dokumente)

Wie die Kompromittierung von CVE-2026-33634 Trivy durchgeführt wurde

Der offizielle Hinweis enthält genügend Details, um den Hauptübertragungsweg zu rekonstruieren, ohne etwas zu erfinden. Der Angreifer behielt oder erlangte zunächst nach dem früheren Vorfall Ende Februar Zugang, weil die Rotation der Anmeldeinformationen am 1. März unvollständig war. Dieser verbleibende Zugang wurde dann genutzt, um die Freigabe- und Aktionsreferenzen am 19. März zu manipulieren. Bei der Kompromittierung handelte es sich also nicht um einen Einbruch in ein einzelnes Paket-Repository. Es handelte sich vielmehr um ein schrittweises Eindringen in die Freigabeebene. (GitHub)

Innerhalb des Trivy-Veröffentlichungspfads wird ein bösartiger Commit gemeldet 1885610c ersetzte einen vertrauten Aktionen/Checkout Verweis auf eine Fälscherbindung 70379aad. Der Betrüger lud bösartige Go-Dateien von scan.aquasecurtiy.orgDie Freigabelogik wurde geändert, um die Validierung zu überspringen. Dies ist ein kompaktes Beispiel dafür, warum Freigabe-Workflows die gleiche Codeüberprüfung und Integritätskontrolle verdienen wie Anwendungscode. Der Angreifer brauchte keinen subtilen Logikfehler in die Scanner-Engine von Trivy einzuschleusen. Es genügte, die Freigabemaschinerie auf bösartige Eingaben umzulenken und die Leitplanken zu unterdrücken, die sie zurückgewiesen hätten. (GitHub)

Die Verbreitung vergrößerte dann den Schaden. Laut dem Advisory wurde die bösartige Trivy-Veröffentlichung über GitHub Container Registry, Amazon ECR Public, Docker Hub, Debian und RPM-Pakete verbreitet und get.trivy.dev. In der offiziellen Diskussion über den Vorfall heißt es separat, dass Benutzer von Builds aus dem Quellcode nicht betroffen waren und dass v0.69.3 dank unveränderlicher Versionen sicher blieb. Dieser Unterschied zwischen Quellcode-Builds und offiziell veröffentlichten Binärdateien ist nicht nur eine Kuriosität. Er zeigt, dass sich das Vertrauensproblem auf den Veröffentlichungskanal konzentrierte und nicht unbedingt auf den vorgelagerten Quellcode zu jedem Zeitpunkt. Einige Teams waren sicherer, weil ihre Lieferkette weniger undurchsichtige Sprünge aufwies. (GitHub)

Die GitHub Actions-Komponente des Angriffs war sogar noch wichtiger für den Betrieb. Der Angreifer erzwang 76 von 77 Tags in Trivia-Aktion und alle sieben Tags in setup-trivyDas bedeutet, dass eine große Anzahl von Workflows, die auf ein scheinbar feststehendes Tag verwiesen, unbemerkt auf bösartigen Code umgeleitet wurden. Der Bericht von CrowdStrike erklärt, warum dies in der Praxis so gefährlich ist. Wenn Unternehmen Aktionen an Tags statt an vollständigen SHAs festmachen, glauben sie oft, dass sie eine stabile Version wählen. In Wirklichkeit wählen sie aber einen Namen, der verschoben werden kann. Auf der Versionsseite ist diese Änderung für nachgelagerte Benutzer nicht immer ersichtlich, und viele Pipelines überprüfen den zugrunde liegenden Commit nie. Das ist genau der Grund, warum die Tag-Integrität eine Sicherheitskontrolle ist, und nicht eine Komfortfunktion. (CrowdStrike)

Die Nutzlast war auch so konzipiert, dass sie unauffällig genug war, um nicht aufzufallen. Microsoft beobachtete, dass betroffene Arbeitsabläufe scheinbar normal abgeschlossen werden konnten, während der bösartige Code im Hintergrund Anmeldedaten sammelte und exfiltrierte. Das ist ein ernstes Problem für den Betrieb. Viele Unternehmen überprüfen den Zustand von Sicherheitstools, indem sie fragen, ob der Auftrag erfolgreich war, ob der Scanner Ergebnisse zurückgegeben hat oder ob der Workflow die erwarteten Ergebnisse geliefert hat. In diesem Fall war der Erfolg kein Beweis für die Sicherheit. Der Erfolg war Teil der Verschleierung. Die Nutzlast führte ihre Sammel- und Exfiltrationsaufgaben aus und ermöglichte dann die Fortsetzung der legitimen Workflow-Logik. (Microsoft)

Die spätere Phase, die nur für Docker Hub gilt, bringt eine weitere Lektion in Sachen Bereitstellung. Docker sagte 0.69.5 und 0.69.6, zusammen mit neuestewurden mit kompromittierten Publisher-Anmeldeinformationen in das Docker Hub Repository von Aqua gepusht. Das Trivy-Advisory besagt, dass es sich bei diesen Images um direkte Docker Hub-Pushes handelte und nicht um standardmäßige GitHub-Veröffentlichungen oder Tags. Dies ist eine praktische Warnung vor vereinfachten Vertrauensmodellen für Abhängigkeiten. Einige Teams denken, dass die Validierung von GitHub-Veröffentlichungen ausreicht. Andere denken, dass Digest Pinning allein ausreicht. Das richtige Modell ist vielschichtiger: Provenance, Unveränderlichkeit, Signaturprüfung, Kanalintegrität, Mirror Awareness und Runner Isolation sind wichtig. Ein Publisher Credential kann eine offizielle Registry vergiften, auch wenn ein GitHub-Repository sauber aussieht (Docker)

Ein letzter Aspekt der Bereitstellung ist es wert, näher beleuchtet zu werden, da er in fast jeder Nachbetrachtung eines Vorfalls auftaucht: Warum haben so viele Teams immer noch veränderbare Tags für Aktionen verwendet? In vielen Unternehmen lautet die ehrliche Antwort, dass SHAs schwieriger zu lesen, schwieriger manuell zu aktualisieren und weniger angenehm zu verwalten sind. Das ist wahr, aber der Vorfall bei Trivy zeigt deutlich, dass es einen Kompromiss gibt. Menschenfreundliche Referenzen sind praktisch, aber sie verlagern das Vertrauen vom Inhalt auf den Zustand des Herausgebers. Wenn der Herausgeber oder der Tag-Schutz des Herausgebers ausfällt, folgt Ihr Workflow dem Angreifer. Die Aktionsreferenz wird zu einer delegierten Vertrauensentscheidung, die Sie nicht mehr kontrollieren können. Die Secure-Use-Dokumentation von GitHub warnt schon seit einiger Zeit vor diesem Problem; CVE-2026-33634 zeigt, wie diese Warnung aussieht, wenn sie zu einem echten Vorfall wird. (GitHub-Dokumente)

Was die Nutzlast CVE-2026-33634 nach der Ausführung tat

Der Trivy-Beratung zufolge hat die bösartige Aktion den Speicher des Läufer.Arbeiter Prozess mit /proc//memscannte mehr als fünfzig Dateisystempfade, verschlüsselte die Ergebnisse mit AES-256-CBC und RSA-4096 und exfiltrierte dann das Paket. Diese Beschreibung allein reicht aus, um die Absicht des Angreifers zu verstehen. Der Runner-Prozess war interessant, weil er wertvolle Laufzeitdaten enthielt: Token, Umgebungsdaten, Schrittkontext und Geheimnisse, die für den Auftrag benötigt wurden. Die Durchsuchung des Dateipfads war interessant, weil nicht alle Anmeldeinformationen im Prozessspeicher gespeichert sind. CI-Umgebungen speichern oft temporäre Dateien, Konfigurationsfragmente, Cloud-CLI-Anmeldeinformationen, Docker-Anmeldeinformationen, kubeconfigs oder SSH-Material an vorhersehbaren Orten. (GitHub)

Microsofts Untersuchung fügt Details zur Umgebung hinzu. Bei selbst gehosteten Läufern wurde ein breiteres Sammelverhalten beobachtet, bei dem auch Metadatenpfade von Cloud-Anbietern, Kubernetes-Geheimnisse und andere Konfigurationsartefakte erfasst wurden, die über das Muster des Memory Scraping bei Linux-GitHub-gehosteten Läufern hinausgehen. Dies entspricht dem, was erfahrene Beobachter erwarten würden. Ein auf GitHub gehosteter Runner ist standardisiert und kurzlebig, sodass die Angreiferlogik auf den Runner-Prozess und eine kleine Gruppe gemeinsamer Pfade abzielen kann. Ein selbst gehosteter Runner ist oft sehr viel umfangreicher. Er kann über persistente Festplatten, zwischengespeicherte Anmeldeinformationen, Docker-Zugriff, Build-Artefakte aus früheren Aufträgen, organisationsspezifische Konfigurationen oder sogar seitliche Pfade in die interne Infrastruktur verfügen. Dieselbe böswillige Aktion wird daher umso gefährlicher, je weniger der Runner zur Verfügung steht. (Microsoft)

Der Exfiltrationspfad ist auch deshalb ungewöhnlich nützlich für die Jagd, weil er von mehreren Quellen öffentlich dokumentiert wurde. Offizielle Trivy-Materialien veröffentlichten die typosquatted Domain scan.aquasecurtiy.org und die IP 45.148.10.212 als Indikatoren zum Blockieren und Suchen. Microsofts Blog fügt Jagdhinweise hinzu wie tpcp.tar.gz, /tmp/runner_collected_und verwandte Befehlszeilenmuster. Diese Indikatoren sind nicht die ganze Geschichte, aber sie sind hochwertige Ausgangspunkte, da sie direkt auf das Verhalten nach der Ausführung und nicht auf ein abstraktes Risiko schließen lassen. Wenn Sie diese Zeichenfolgen in Ausführungsprotokollen, Prozessprotokollen, DNS-Protokollen oder Netzwerktelemetrie während der betroffenen Zeiträume sehen, haben Sie mehr als eine theoretische Gefährdung. Es handelt sich um Aktivitäten, die mit der veröffentlichten Angriffskette übereinstimmen. (GitHub)

Ein Fallback-Verhalten aus dem offiziellen Hinweis verdient besondere Aufmerksamkeit. Wenn die Exfiltration fehlschlägt und INPUT_GITHUB_PAT gesetzt war, konnte die Malware ein öffentliches Repository namens tpcp-docs und laden Sie das gesammelte Archiv als Release-Asset hoch. Dies ist eine bemerkenswerte Design-Entscheidung, da sie GitHub selbst als Backup-Exfiltrationskanal nutzt. Sie gibt den Verteidigern auch einen überraschend konkreten Suchbegriff an die Hand. In der Empfehlung werden Organisationen aufgefordert, nach folgenden Dingen zu suchen tpcp-docs Repositories in ihrer Umgebung zu überprüfen und alle Spuren in Audit-Protokollen zu untersuchen. Dies ist einer der seltenen Fälle, in denen eine öffentliche Reaktion auf einen Vorfall direkt auf vom Angreifer erstellte Repository-Artefakte hinweisen kann und nicht nur auf einfache Endpunktindikatoren. (GitHub)

Forscher von Drittanbietern berichteten über zusätzliches Persistenz- oder Folgeverhalten auf Entwicklersystemen, die kompromittierte Trivy-Binärdateien ausgeführt haben. Laut CrowdStrike könnte die Binärdatei ~/.config/sysmon.pydann schlafen und etwa alle fünfzig Minuten einen Internet-Computer-Kanister nach zusätzlichen Nutzlastanweisungen abfragen, wobei /tmp/pglog und andere temporäre Pfade in der Kette. Palo Alto Unit 42 beschrieb ähnliche Indikatoren für das Beaconing von Arbeitsstationen. Diese Details werden in der Aqua-Notiz zum Vorfall nicht als Bestätigung des Erstanbieters präsentiert und sollten daher eher als technische Erkenntnisse denn als unumstößliche Fakten betrachtet werden. Dennoch sind sie wertvoll, da sie die Suche über KI hinaus auf Entwickler-Workstations ausdehnen, die den kompromittierten Scanner direkt oder über containerisierte Workflows installiert haben könnten. (CrowdStrike)

Ein zweites Verhaltensmuster ist die Täuschung durch Kontinuität. Microsoft betonte, dass der Arbeitsablauf oft weiterlief und erfolgreich zu sein schien. CrowdStrike stellte ebenfalls fest, dass nach der Sammelphase die legitime Trivy-Eingangslogik weiterhin ausgeführt wurde. Das ist von Bedeutung, weil viele Unternehmen eine erfolgsorientierte Überwachung von KI-Aufträgen haben: Fehlschläge werden angezeigt, erfolgreiche Läufe jedoch nicht. Ein Angreifer, der das erwartete Ergebnis beibehalten kann, während er Geheimnisse stiehlt, senkt die Wahrscheinlichkeit einer sofortigen Entdeckung drastisch. Für Verteidiger ist die Lektion klar: Bei Vorfällen in der Lieferkette hat die Aussage "der Auftrag wurde erfolgreich ausgeführt" fast keinen Wert als Sicherheitssignal. Man braucht Artefaktnachweise und Laufzeittelemetrie, keinen Ergebnisoptimismus. (Microsoft)

Der praktische Unterschied zwischen von GitHub gehosteten und selbst gehosteten Läufern ist ebenfalls hervorzuheben, da er den Reaktionsplan verändert. Bei auf GitHub gehosteten Linux-Runnern lautet die Arbeitsannahme in der Regel: "Die Geheimnisse dieses Auftrags wurden kompromittiert". Bei selbst gehosteten Läufern lautet die Annahme: "Der Host und seine erreichbare Vertrauenszone könnten kompromittiert sein", insbesondere wenn der Läufer über einen langlebigen Status, Docker-Socket-Zugriff, umfassende Dateisystemberechtigungen, zwischengespeicherte Cloud-Anmeldeinformationen oder Netzwerkzugriff auf interne Umgebungen verfügt. In den GitHub-Dokumenten wird bereits darauf hingewiesen, dass selbst gehostete Runner nicht die gleichen ephemeren Garantien bieten und für öffentliche Repositories besonders riskant sind. CVE-2026-33634 verwandelt diese allgemeine Anleitung in eine konkrete Fallstudie. (GitHub-Dokumente)

Betroffene Komponenten und sichere Referenzen für CVE-2026-33634

Komponente	Was war betroffen?	Belichtungsfenster	Bekannte sichere Referenz	Was jetzt zu tun ist
Trivy-Binär- und Standard-Release-Artefakte	v0.69.4	Ungefähr 19. März 2026, 18:22 bis 21:42 UTC	v0.69.3 oder früher, oder aus dem Quellcode von einem bekannten, guten Zustand erstellen	Entfernen der betroffenen Artefakte, Rotieren der während der Ausführung offengelegten Geheimnisse, Überprüfen der Signaturen für Ersatzartefakte
Trivy Docker Hub Bilder	0.69.4, 0.69.5, 0.69.6und neueste während des betroffenen Zeitraums	19. März 2026, 18:24 UTC bis 23. März 2026, 01:36 UTC laut Docker	Verwenden Sie bekannt gute Digests oder sichere Versionen wie 0.69.3und Überprüfung der Herkunft	Behandeln Sie alle Anmeldeinformationen, die für diese Container verfügbar sind, als kompromittiert; wenn der Docker-Socket gemountet wurde, behandeln Sie den Host als potenziell kompromittiert
aquasecurity/trivy-action	76 von 77 historischen Tags wurden zwangsversteigert	Ungefähr 19. März 2026, 17:43 UTC bis 20. März 2026, 05:40 UTC	v0.35.0 oder begehen 57a97c7	Ersetzen alter Tag-Referenzen, Überprüfen von Arbeitsabläufen und Audit-Protokollen, Rotieren offener Geheimnisse
aquasecurity/setup-trivy	Alle sieben Tags wurden vor der sicheren Wiederherstellung gefährdet	Ungefähr 19. März 2026, 17:43 UTC bis 21:44 UTC	v0.2.6 oder begehen 3fb12ec	Ersetzen alter Referenzen, Audit-Läufe, Rotation offener Geheimnisse
Quelle: Builds	Nicht in der gleichen Weise betroffen wie veröffentlichte bösartige Artefakte	Nicht anwendbar	Erstellen Sie aus verifizierten Quellen und verifizieren Sie Ihre Toolchain	Überprüfen Sie dennoch, ob Ihr CI kompromittierte Aktionen oder Bilder an anderer Stelle im Arbeitsablauf abgerufen hat

Die obige Tabelle kombiniert das offizielle Advisory von Trivy, die Diskussion über den Vorfall und die Notiz von Docker zum Vorfall. Eine wichtige Nuance ist, dass Digest Pinning und Version Pinning unterschiedliche Probleme lösen. Ein Digest pinnt genaue Bytes. Er allein beweist nicht, dass diese Bytes durch einen vertrauenswürdigen Freigabeprozess erzeugt wurden. Bei diesem Vorfall haben die veränderlichen Tags das Risiko eindeutig erhöht, aber die Überprüfung der Herkunft ist auch dann noch wichtig, wenn man die schlechten Tags entfernt hat. (GitHub)

CVE-2026-33634 Erkennung, Sichtung und Eindämmung

Der erste Erkennungsdurchlauf sollte sich auf Referenzen konzentrieren, nicht nur auf installierte Binärdateien. Beginnen Sie mit der Suche in Ihrem Workflow-Repository nach Trivia-Aktion und setup-trivyund klassifizieren dann jeden Verweis als vollständiges SHA, als neues sicheres Tag oder als unsicheres historisches Tag. Auf diese Weise lassen sich am schnellsten Arbeitsabläufe ermitteln, die auf eine böswillig erzwungene Markierung gefolgt sein könnten, selbst wenn sich das Repository selbst nie geändert hat. Der Zweck dieses Durchgangs ist nicht nur das Zählen der Verwendungen. Es geht darum, eine Expositionskarte zu erstellen, die an konkrete Jobs, Repositories und Geheimnisse gebunden ist. Trivy's eigenes Advisory und GitHub's Secure-Use-Referenz unterstützen beide diesen Ansatz, da das Risiko in der Aktionsreferenz und den damit verbundenen Berechtigungen liegt. (GitHub)

# Finden Sie alle Trivy-bezogenen Aktionsverwendungen in GitHub-Workflows
rg -n "aquasecurity/(trivy-action|setup-trivy)@" .github/workflows

# Kennzeichnen Sie Aktionsreferenzen, die nicht an ein vollständiges 40-Zeichen-SHA angeheftet sind
rg -n "aquasecurity/(trivy-action|setup-trivy)@([A-Za-z0-9._-]+)$" .github/workflows \
  | rg -v "@[0-9a-f]{40}$"

# Jobs anzeigen, die auf historische Tags ohne V-Präfix verweisen, z. B. @0.34.0
rg -n "aquasecurity/trivy-action@0\." .github/workflows
rg -n "aquasecurity/setup-trivy@0\." .github/workflows

Diese Befehle sind absichtlich einfach gehalten. Ein stressiger Vorfall ist der falsche Zeitpunkt für cleveres Parsing, das nur ein Ingenieur versteht. Worauf es ankommt, ist die Auflistung aller Arbeitsabläufe, die während des betroffenen Zeitraums Vertrauen in eine veränderbare Referenz delegiert haben. Sobald Sie diese Liste haben, besteht der nächste Schritt darin, diese Workflows mit dem Laufverlauf und dem geheimen Bereich zu korrelieren. In welchen Repositories wurden sie zwischen dem 19. und 20. März ausgeführt. Auf welche Umgebungen sie abzielten. Welche Organisations- oder Umgebungsgeheimnisse zugänglich waren. Ob der Job ein persönliches Zugriffstoken, Anmeldeinformationen des Cloud-Anbieters, Registrierungsberechtigungen oder Bereitstellungsschlüssel verwendet hat. Die Formulierung des NVD ist hier unverblümt: Wenn die Möglichkeit besteht, dass die betroffenen Versionen in Ihrer Umgebung ausgeführt wurden, sollten die Geheimnisse, auf die diese Pipelines zugreifen können, als ausgesetzt behandelt werden. (NVD)

Bei der Verwendung von Containern sollten Sie die Image-Pull-Historie und die lokalen Caches nach den betroffenen Digests und Tags durchsuchen. Docker hat die bekannten kompromittierten Digests für die drei betroffenen Image-Versionen veröffentlicht, und das Trivy-Advisory enthielt die gleichen Digests. Die Suche nur nach Tags ist weniger zuverlässig, da neueste während des Vorfalls verschoben, und Tags sind von vornherein veränderbar. Digests geben Aufschluss darüber, ob der genaue bösartige Bildinhalt Ihre Umgebung erreicht hat. (GitHub)

# Auflisten der lokalen Trivy-Images mit Digests
docker images --digests | rg "aquasec/trivy|aquasecurity/trivy"

# Exakte Digests auf verdächtige lokale Tags untersuchen
docker inspect --format '{{json .RepoDigests}}' aquasec/trivy:0.69.4 2>/dev/null | jq
docker inspect --format '{{json .RepoDigests}}' aquasec/trivy:0.69.5 2>/dev/null | jq
docker inspect --format '{{json .RepoDigests}}' aquasec/trivy:0.69.6 2>/dev/null | jq
docker inspect --format '{{json .RepoDigests}}' aquasec/trivy:latest 2>/dev/null | jq

Die offiziell veröffentlichten kompromittierten Zusammenfassungen waren:

Mit bösartigem Bild verbundener Tag	Veröffentlichte kompromittierte Zusammenfassung
0.69.4	sha256:27f446230c60bbf0b70e008db798bd4f33b7826f9f76f756606f5417100beef3
0.69.5	sha256:5aaa1d7cfa9ca4649d6ffad165435c519dc836fa6e21b729a2174ad10b057d2b
0.69.6	sha256:425cd3e1a2846ac73944e891250377d2b03653e6f028833e30fc00c1abbc6d33

Diese Digests stammen von Docker und wurden im Trivy-Advisory aufgegriffen. Wenn einer von ihnen in lokalen Caches, CI-Logs, Registry-Mirrors oder Node-Level-Image-Stores auftaucht, sollten Sie die Umgebung als exponiert behandeln. (GitHub)

Die nächste Ebene ist die IOC- und Verhaltenssuche. In offiziellen Berichten und Berichten Dritter wurden mehrere Artefakte gefunden, nach denen es sich lohnt, sofort zu suchen: scan.aquasecurtiy.org, 45.148.10.212, tpcp.tar.gz, tpcp-docs, /tmp/runner_collected_und bei der Analyse von Drittanbieter-Workstations, sysmon.py, pgmonund der von CrowdStrike und Palo Alto gemeldete Internet Computer Beacon Path. Die Suche nach diesen Pfaden ersetzt nicht die Rotation der Zugangsdaten, aber sie hilft Ihnen, hypothetische Angriffe von bewiesenen Kompromittierungen zu unterscheiden. (GitHub)

IOC-Tabelle für CVE-2026-33634 Jagd

Indikator	Warum das wichtig ist	Quelle: Typ
scan.aquasecurtiy.org	Offiziell veröffentlichte typosquatted Exfil-Domain, die mit dem bösartigen Arbeitsablauf und dem Freigabepfad verbunden ist	Offizielle Trivy-Beratung und Diskussion über den Vorfall
45.148.10.212	Offiziell veröffentlichte IP im Zusammenhang mit dem Vorfall	Offizielle Trivy-Materialien
tpcp-docs	Offizieller Fallback-GitHub-Repository-Name, der verwendet wird, wenn PAT-basiertes Exfil erfolgreich war	Offizielle Trivy-Beratung
tpcp.tar.gz	Name des Archivs, der in der Jagdanleitung angegeben ist	Microsoft
/tmp/runner_collected_	Vorübergehender Sammelpfad, der während der Untersuchung beobachtet wurde	Microsoft
~/.config/sysmon.py	Gemeldetes arbeitsplatzseitiges Persistenz- oder Staging-Artefakt	CrowdStrike und Palo Alto
tdtqy-...raw.icp0.io	Gemeldeter Befehls- und Kontrollpfad in der Analyse Dritter	CrowdStrike und Palo Alto
checkmarx.zone	Nützlich für ein breiteres Kampagnen-Scoping, insbesondere wenn dieselbe Organisation auch das betroffene Checkmarx-Tooling verwendet	Microsoft, Checkmarx, Palo Alto

Bei den ersten drei Einträgen handelt es sich um Umgebungsindikatoren mit der höchsten Zuverlässigkeit, da sie direkt aus dem Trivy-Material zur Reaktion auf Vorfälle stammen. Die Arbeitsplatzindikatoren sind nützlich, aber sie sollten als Forschungsergebnisse und nicht als alleiniger Beweis für Trivy-spezifische Auswirkungen betrachtet werden. (GitHub)

Wenn Sie eine KQL-fähige Plattform verwenden, können Sie mit einer kompakten Triage-Abfrage die Telemetrie von Läufern und Workstations abfragen. Microsoft hat seine eigenen Suchanleitungen und Indikatoren veröffentlicht; das folgende Beispiel folgt derselben Logik, wobei die Abfrage so lesbar ist, dass sie lokal angepasst werden kann. (Microsoft)

let iocs = dynamic([
  "scan.aquasecurtiy.org",
  "45.148.10.212",
  "tpcp.tar.gz",
  "tpcp-docs",
  "/tmp/runner_collected_",
  "sysmon.py",
  "raw.icp0.io"
]);
DeviceProcessEvents
| where Zeitstempel zwischen (datetime(2026-03-19) .. datetime(2026-03-24))
| where ProcessCommandLine has_any (iocs)
   oder InitiatingProcessCommandLine has_any (iocs)
   oder Dateiname in~ ("curl", "wget", "python", "bash", "cat", "tar")
| Projekt Zeitstempel, Gerätename, Dateiname, ProcessCommandLine,
          InitiierenderProzessDateiname, InitiierenderProzessBefehlszeile, Kontoname
| Reihenfolge nach Zeitstempel absteigend

Durchsuchen Sie für die GitHub-native Triage Workflow-Protokolle und Audit-Daten nach dem Fallback-Exfil-Repository und nach Verweisen auf die unsicheren Tags. Wenn Ihr Unternehmen die GitHub-CLI verwendet und über einen entsprechenden Zugang verfügt, kann sogar eine schnelle Repository-Suche offensichtliche rote Flaggen aufdecken. Es geht nicht darum, die Unschuld durch einen Mangel an Treffern zu beweisen. Es geht vielmehr darum, die einfachsten Artefakte mit hohem Signalwert zu finden, bevor Sie zu einer umfassenden Rotation der Anmeldeinformationen und einem Neuaufbau der Runner übergehen. (GitHub)

# Durchsuchen Sie die Workflow-Definitionen in Ihrem Org-Klon oder Mono-Repo-Satz
rg -n "tpcp-docs|scan\.aquasecurtiy\.org|45\.148\.10\.212" .

# Wenn Sie Läuferprotokolle zentral verwalten, suchen Sie das betroffene Fenster
rg -n "tpcp-docs|tpcp\.tar\.gz|runner_collected_|scan\.aquasecurtiy\.org" /var/log /opt/actions-runner 2>/dev/null

Die Eindämmung muss beginnen, bevor die Jagd abgeschlossen ist. Deaktivieren Sie die betroffenen Workflow-Referenzen, stellen Sie die Verwendung kompromittierter Bild-Tags ein und blockieren Sie die veröffentlichte Domäne und IP-Adresse, während Sie noch das vollständige Expositionsdiagramm erstellen. Bei einem Vorfall auf dem Freigabepfad ist es der falsche Weg, auf absolute Sicherheit zu warten. Die verfügbaren offiziellen Hinweise sind bereits aussagekräftig genug, um eine aggressive Eindämmung zu rechtfertigen, da der Zweck der Nutzlast der Diebstahl von Anmeldeinformationen war und nicht ein Denial-of-Service-Fall. Mit jeder zusätzlichen Minute der Wiederverwendung eines betroffenen Tags oder Bildes steigt die Wahrscheinlichkeit, dass eine neu ausgelöste Pipeline etwas preisgibt, das Sie noch nicht gedreht haben. (GitHub)

Wiederherstellung des Vertrauens nach CVE-2026-33634

Der erste Schritt zur Wiederherstellung ist mechanisch: keine unsicheren Referenzen mehr verwenden und sie durch explizit sichere ersetzen. Für Trivy-Binärdateien und Standard-Release-Artefakte lautete die offizielle Anweisung, auf Version 0.69.3 oder früher zurückzugreifen. Für Trivia-Aktionverwenden v0.35.0 oder begehen 57a97c7. Für setup-trivyverwenden v0.2.6 oder begehen 3fb12ec. Teams, die zuvor alte Tags ohne Präfix verwendet haben, sollten nicht davon ausgehen, dass diese Namen nun auf denselben Inhalt verweisen, für den sie einst standen. In der Empfehlung heißt es ausdrücklich, dass alte Trivia-Aktion Veröffentlichungen wurden mit einem v Präfix, weil die alten Tag-Namen nach dem Force-Push-Verhalten des Angreifers nicht mehr sicher in der ursprünglichen Weise wiederverwendet werden konnten. (GitHub)

# Sicherer als eine veränderbare historische Markierung
- Verwendet: aquasecurity/trivy-action@v0.35.0

# Besser, an eine vollständige SHA-Übertragung anheften
- uses: aquasecurity/trivy-action@57a97c7f3f5d0b6f0b4b0c5f6f5f4b2a1d3e9abc

Der zweite Wiederherstellungsschritt ist die Reaktion auf Anmeldeinformationen. Behandeln Sie jedes Geheimnis, auf das ein betroffener Workflow oder Container-Lauf zugreifen kann, bis zum Beweis des Gegenteils als offen. Das gilt auch für persönliche GitHub-Zugangstoken, GITHUB_TOKEN-abgeleitete Schreibpfade, Cloud-Zugangsdaten, Registrierungsanmeldungen, SSH-Schlüssel, Deployment-Schlüssel, kubeconfigs, Datenbank-Zugangsdaten und alle Service-to-Service-Tokens, die von der Auftragsumgebung aus erreichbar sind. Die Anweisungen von Docker sind besonders streng für die Containerseite: Wenn ein kompromittierter Trivy-Container den Docker-Socket gemountet hat, sollte der Host als potenziell kompromittiert betrachtet werden. Das ist kein konservatives Theater. Der Zugriff auf Docker-Sockets ist in vielen realen Umgebungen tatsächlich eine Kontrolle auf Host-Ebene. (NVD)

Der dritte Schritt ist die Überprüfung der Herkunft. Das Trivy-Advisory enthält Beispiele für die Verifizierung von sicheren Images mit Cosign und die Überprüfung von Transparenzprotokolldaten in Rekor, einschließlich der Überprüfung, ob die Signatur vor dem Kompromittierungsfenster vom 19. März erstellt wurde. Dies ist einer der nützlichsten Teile der offiziellen Antwort, weil er die Teams über Versionsstrings hinaus zurück zum Artefaktvertrauen führt. Eine Versionsnummer kann kopiert werden. Ein veränderbares Tag kann verschoben werden. Eine verifizierte Signatur, die mit einem Transparenzprotokoll verknüpft ist, gibt Ihnen eine genauere Auskunft über das Artefakt, das Sie gerade ausführen wollen. (GitHub)

# Beispielmuster für die Verifizierung einer sicheren Bildsignatur
cosign verify \
  --certificate-identity-regexp ".*" \
  --zertifikat-oidc-aussteller-regexp ".*" \
  ghcr.io/aquasecurity/trivy:0.69.3

# Suchen Sie in Rekor nach den erwarteten Image Digest- oder Signatur-Metadaten
rekor-cli search --artifact ghcr.io/aquasecurity/trivy:0.69.3

Die genauen Optionen, die Sie verwenden, hängen von Ihrer Umgebung und Ihrer Vertrauensrichtlinie ab, aber die allgemeine Lektion ist stabil: Die Wiederherstellung des Vertrauens nach einer Kompromittierung einer Version bedeutet eine erneute Überprüfung von Artefakten, nicht nur eine Neuinstallation der neuesten sichtbaren Version. Dies ist auch der Punkt, an dem viele Unternehmen feststellen, dass sie nie einen Verifizierungsschritt für Sicherheitstools von Drittanbietern formalisiert haben, weil sie sich stattdessen auf den Ruf des Ökosystems verlassen haben. CVE-2026-33634 ist ein guter Grund, dies dauerhaft zu korrigieren. (GitHub)

Die Wiederherstellung von selbst gehosteten Läufern verdient eine strengere Behandlung als die von ephemeren gehosteten Läufern. Wenn ein selbst gehosteter Runner einen betroffenen Workflow ausgeführt hat, ist davon auszugehen, dass der Runner nicht nur speicherinterne Auftragsgeheimnisse, sondern auch persistente Hostzustände, zwischengespeicherte Anmeldeinformationen und nahe gelegene Infrastrukturpfade weitergegeben hat. Ein Reimaging ist oft schneller und vertretbarer, als zu versuchen, zu beweisen, dass ein persistenter Runner sauber ist. In der Anleitung von GitHub zu selbst gehosteten Läufern wird bereits betont, dass sie nicht dieselben Sauberkeitsgarantien bieten wie gehostete Läufer und mit großer Vorsicht verwendet werden sollten, insbesondere in öffentlichen oder stark exponierten Kontexten. CVE-2026-33634 ist eines der deutlichsten aktuellen Beispiele dafür, warum diese Anleitung existiert. (GitHub-Dokumente)

Sobald die Anmeldeinformationen ausgetauscht und die Läufer neu aufgebaut sind, haben viele Teams immer noch ein praktisches Problem: Sie müssen die Systeme, die diesen Anmeldeinformationen vertraut haben, erneut testen, bestätigen, dass keine Anfälligkeit in ihrer Angriffsoberfläche verbleibt, und die Beweise für Auditoren oder die interne Überprüfung des Vorfalls sichern. In diesem speziellen Arbeitsablauf nach einem Vorfall können Tools, die auf menschengesteuerten, automatisierten Tests basieren, nützlich sein, da diese Arbeit sich wiederholt, beweislastig ist und man leicht den Überblick verliert, wenn sie ad hoc erfolgt. Auf den Produktseiten von Penligent werden agentengestützte Prüfabläufe mit Benutzerkontrolle, reproduzierbaren Ergebnissen und Berichten beschrieben, so dass diese Art von Tool ganz natürlich an die Validierungsphase nach einem Vorfall in der Lieferkette anschließt, nicht als Ersatz für die Reaktion auf einen Vorfall, sondern als Möglichkeit zur Systematisierung der erneuten Überprüfung und Dokumentation. (Sträflich)

Der letzte Schritt der Wiederherstellung ist das organisatorische Gedächtnis. Beenden Sie den Vorfall nicht mit "wir haben aufgerüstet und rotiert". Schreiben Sie auf, welche Workflows von veränderbaren Tags abhingen, welche Geheimnisse absichtlich offengelegt wurden, welche Runner zu langlebig waren, welche Registry-Pulls nicht herkunftsgeprüft waren und welche Repositories keinen Tag-Schutz hatten. Vorfälle in der Lieferkette werden zu wiederholten Vorfällen, wenn die Lektion nur eine betriebliche Folklore bleibt, anstatt zu einer durchsetzbaren Richtlinie zu werden. (GitHub-Dokumente)

Lehren aus CVE-2026-33634 zum Härten

Die erste Lektion ist die einfachste und die am wenigsten verhandelbare: Binden Sie GitHub-Aktionen von Drittanbietern an vollständige SHAs von Commits. Die GitHub-Referenz für sichere Nutzung empfiehlt dies schon seit einiger Zeit, da Tags verschoben oder gelöscht werden können. CVE-2026-33634 ist genau der Fall, den diese Empfehlung zu verhindern versucht hat. Wenn eine Aktion an ein vollständiges SHA angeheftet ist, ändert eine erzwungene Tag-Verschiebung nichts daran, was Ihr Workflow ausführt. Sie müssen dem referenzierten Commit immer noch vertrauen, aber Sie beseitigen eine große Klasse von stillen Umleitungsrisiken. GitHub weist auch darauf hin, dass Unternehmen das Full-SHA-Pinning mit Richtlinien erzwingen können, was wichtig ist, da man sich selten auf die Disziplin einzelner Entwickler verlassen kann. (GitHub-Dokumente)

Die zweite Lektion ist, dass unveränderliche Versionen nicht nur eine Nettigkeit der Versionsverwaltung sind. Die Trivy-Maintainer wiesen ausdrücklich darauf hin, dass v0.69.3 sicher blieb, weil unveränderliche Veröffentlichungen nach dem früheren Verstoß aktiviert worden waren. In der Dokumentation von GitHub heißt es, dass unveränderliche Versionen Tags und Assets nach der Veröffentlichung sperren und helfen können, Angriffe auf die Lieferkette zu verhindern. Damit sind unveränderliche Freigaben das Gegenstück zu SHA-Pinning auf der Verbraucherseite. Das eine kontrolliert die Fähigkeit des Herausgebers, die Geschichte umzuschreiben. Die andere kontrolliert, ob der Verbraucher der umgeschriebenen Geschichte ausgesetzt ist. Sie wollen beides. (GitHub)

Die dritte Lektion ist, dass der Schutz von Tags und Zweigen auch die Kontrolle von Force-Pushs umfassen sollte. GitHub-Regelsätze können verwendet werden, um Tag-Aktualisierungen einzuschränken und Force-Pushs zu blockieren. Beim Trivy-Vorfall war das Forcieren von Aktions-Tags ein zentraler Bestandteil der Umleitungsstrategie. Viele Organisationen schützen Haupt oder Freigabe/* Zweige, aber weit weniger streng bei Tags. Für Projekte, die GitHub-Aktionen oder die Automatisierung von Veröffentlichungen über getaggte Referenzen verbreiten, ist das ein Rückschritt. Wenn nachgelagerte Nutzer den Tags vertrauen, dann sind Tags ein Teil Ihrer Sicherheitsgrenze. Schützen Sie sie entsprechend. (GitHub-Dokumente)

Die vierte Lektion besteht darin, den Wert von Geheimnissen innerhalb der KI zu reduzieren. In der GitHub-Dokumentation wird empfohlen, nach Möglichkeit OpenID Connect anstelle von langlebigen Cloud-Anmeldeinformationen zu verwenden, und es wird vorgeschlagen, dass für Umgebungen oder Geheimnisse, die hoch privilegierte Workflows auslösen, Prüfer erforderlich sind. Diese Kontrollen hätten die Trivy-Kompromittierung nicht zum Verschwinden gebracht, aber sie reduzieren, was der Angreifer bei einer erfolgreichen Workflow-Ausführung stehlen kann. Ein kurzlebiger föderierter Berechtigungsnachweis, der für einen bestimmten Auftrag erstellt wurde, ist zwar immer noch gefährlich, wenn er gestohlen wird, aber er ist wesentlich weniger gefährlich als ein langlebiger Cloud-Zugangsschlüssel mit breitem Anwendungsbereich und ohne zweite Genehmigungsstelle. (GitHub-Dokumente)

Die fünfte Lektion besteht darin, selbst gehostete Runner als Infrastruktur mit einem Bedrohungsmodell zu betrachten, nicht als billigeren Ersatz für gehostete Runner. In den Dokumenten von GitHub heißt es, dass selbst gehostete Runner so gut wie nie für öffentliche Repositories verwendet werden sollten, und selbst Just-in-Time-Runner benötigen eine Garantie für eine saubere Umgebung. Das Verhalten der Nutzlast von Trivy bestätigt diese Warnung. Bei einem standardisierten gehosteten Runner neigt der Angreifer dazu, das zu sammeln, was der Job sehen kann. Bei einem persistenten, selbst gehosteten Runner kann der Angreifer die Überreste früherer Jobs, Anmeldeinformationen auf Host-Ebene, interne Netzwerkverbindungen oder die angeschlossene Container-Infrastruktur übernehmen. Dieselbe böswillige Aktion kann daher in einer selbst gehosteten Infrastruktur einen viel größeren Aktionsradius haben. (GitHub-Dokumente)

Die sechste Lektion besteht darin, Aktionen als eigenständige Abhängigkeiten zu verfolgen. Der Abhängigkeitsgraph von GitHub kann Workflow-Aktionen erkennen, und das Sicherheitsmodell von GitHub behandelt Workflow-Komponenten zunehmend als erstklassige Supply-Chain-Objekte. Viele Anwendungssicherheitsprogramme konzentrieren sich immer noch hauptsächlich auf Anwendungsbibliotheken, Container-Basisimages und Betriebssystempakete. CVE-2026-33634 zeigt, dass Ihre Workflow-Schicht die gleiche Aufmerksamkeit verdient. Wenn das, was Ihren Code erstellt, signiert, scannt und ausliefert, veränderlich und unzureichend überwacht ist, dann ist Ihr sicherer SDLC an einem schwachen Punkt verankert. (GitHub-Dokumente)

Die siebte Lektion besteht darin, Digest Pinning nicht mit Provenance zu verwechseln. In der Docker-Notiz zum Vorfall wird ein subtiler, aber wichtiger Punkt angesprochen: Veränderbare Tags sind keine Sicherheitsgrenze, aber Digest-Pinning allein beweist nur, dass Sie jedes Mal die gleichen Bytes abrufen. Es beweist nicht, dass diese Bytes von einem vertrauenswürdigen Build-Prozess stammen. In der Praxis ist das richtige Muster mehrschichtig: Pinning per Digest, wenn Unveränderlichkeit erforderlich ist, Verifizierung von Signaturen oder Bescheinigungen, wenn die Herkunft nachgewiesen werden muss, und Sicherstellung, dass der Freigabepfad des Herstellers selbst durch Kontrollen für unveränderliche Freigaben und Hygiene der Anmeldedaten geschützt ist. (Docker)

Die achte Lektion ist die Abfolge von Ereignissen und Reaktionen. Das Eingeständnis von Aqua, dass seine Rotation vom 1. März nicht atomar war, sollte für jedes Team, das Freigabeberechtigungen verwaltet, Pflichtlektüre sein. Die geheime Rotation ist nicht nur ein Befehl. Es handelt sich um eine Transaktion über Identitäten, Caches, Automatisierung und Rückfallpfade hinweg. Wenn ein privilegierter Token rotiert wird, aber eine benachbarte Automatisierung einen neuen prägen oder abrufen kann, bevor der alte Pfad vollständig abgeschaltet ist, kann der Verteidiger den Anschein einer Eindämmung erwecken, ohne eine tatsächliche Eindämmung zu erreichen. Das ist eine harte Lektion, aber eine der am besten umsetzbaren in dem gesamten Vorfall. (GitHub)

Verwandte CVEs, die CVE-2026-33634 in den Kontext stellen

CVE-2025-30066, die tj-actions/geänderte-dateien ist die nächstliegende Parallele, weil sie dieselbe Vertrauenslektion durch ein anderes Projekt vermittelt. Der NVD sagt, dass vor der Version 46, tj-actions/geänderte-dateien wurde kompromittiert, als Tags von v1 über v45.0.7 wurden so verändert, dass sie auf einen bösartigen Commit im März 2025 hinwiesen. Die CISA fügte sie später dem Katalog der bekannten ausgenutzten Schwachstellen (Known Exploited Vulnerabilities) hinzu. Der Grund, warum dies für das Verständnis von CVE-2026-33634 von Bedeutung ist, ist einfach: Beide Vorfälle zeigen den falschen Komfort des Tag-basierten Vertrauens für GitHub-Aktionen auf. In beiden Fällen glaubten die nachgelagerten Arbeitsabläufe, dass sie eine stabile Version aufrufen würden. In beiden Fällen hat der Angreifer den Verweis verschoben, anstatt einen Fehler in der Anwendung des Nutzers zu finden. (NVD)

Die praktische Schlussfolgerung aus dem Vergleich dieser beiden CVEs ist, dass das Problem strukturell und nicht projektspezifisch ist. Ein Verweis auf ein Release-Tag ist nicht dasselbe wie die Unveränderbarkeit von Inhalten. Wenn Ihre Workflow-Richtlinie veränderbare Verweise auf Drittanbieter zulässt, dann treffen Sie jedes Mal, wenn der Auftrag ausgeführt wird, eine Vertrauensentscheidung über die Betriebssicherheit des Herausgebers. Diese Vertrauensentscheidung mag für einige interne Repositories oder streng kontrollierte Lieferanten angemessen sein, aber sie sollte bewusst getroffen und durch Kontrollen gestützt werden, und nicht zufällig von Beispielen aus dem Internet übernommen werden. CVE-2025-30066 und CVE-2026-33634 bestrafen beide die faule Annahme, dass sich Tags wie Paketprüfsummen verhalten. (NVD)

CVE-2024-3094, die XZ Utils-Backdoor, hilft dabei, eine andere Seite der gleichen allgemeinen Supply-Chain-Geschichte zu beleuchten. NVD beschreibt diesen Vorfall als bösartigen Code, der in Upstream-XZ-Release-Tarballs für die Versionen 5.6.0 und 5.6.1 eingebettet ist, wobei eine Obfuskation zur Build-Zeit verwendet wird, um bösartiges Verhalten in liblzma. Der Trivy-Vorfall ist mechanisch gesehen nicht derselbe. Der XZ-Fall konzentrierte sich auf Upstream-Release-Artefakte und Kompromisse im Build-Stadium. Der Fall Trivy konzentrierte sich auf die Automatisierung der Veröffentlichung, GitHub Action Tags und offizielle Vertriebskanäle. Beide Vorfälle zeigen jedoch dieselbe strategische Realität: Angreifer bevorzugen zunehmend vertrauenswürdige Verbreitungswege gegenüber der Ausnutzung lauter Perimeter. Wenn Sie über den Veröffentlichungspfad verfügen, müssen Sie nicht erraten, wo sich die privilegierten Umgebungen befinden. Die Benutzer bringen Ihren Code für Sie in diese Umgebungen. (NVD)

Der Vergleich hilft auch, die Prioritäten der Verteidigung zu schärfen. Bei XZ lernten die Verteidiger, dass sie den Artefakten einer Veröffentlichung misstrauen sollten, selbst wenn die Quellcode-Repositories normal aussahen. Trivy lehrt die Verteidiger, veränderbaren Aktionsreferenzen und offiziellen Bild-Tags zu misstrauen, wenn die Identität der Veröffentlichung oder der Veröffentlichungspfad kompromittiert ist. Zusammengenommen plädieren sie für ein Verteidigungskonzept für die Lieferkette, das die Herkunft von Artefakten, unveränderliche Freigabekontrollen, die Überprüfung von Signaturen, die Härtung von Läufern, die Minimierung von Geheimnissen und strengere Richtlinien für Workflow-Abhängigkeiten umfasst. Patch-Management allein ist keine Antwort auf diese Art von Risiko. (NVD)

Was Sicherheitsteams nach CVE-2026-33634 beachten sollten

Das schädlichste Missverständnis über CVE-2026-33634 wäre, es geistig unter "schlechte Trivy-Version, jetzt behoben" abzulegen. Die eigentliche Lektion ist umfassender. Ein Scanner, der innerhalb von CI läuft, ist eine Ausführungseinheit mit hoher Vertrauenswürdigkeit. Wenn sein Veröffentlichungspfad, seine Action-Tags oder sein Container-Verteilungspfad unterwandert werden können, dann wird der Scanner zu einem idealen Vehikel für den Diebstahl von Anmeldeinformationen. Die Tatsache, dass das Tool auf Sicherheit ausgerichtet ist, verringert die Gefahr nicht. In diesem Fall wurde sie sogar noch vergrößert, da Sicherheitstools oft dort eingesetzt werden, wo die besten Geheimnisse schlummern. (NVD)

Zweitens sollte man nicht vergessen, dass das Vertrauen in die Lieferkette vielschichtig ist. Versionsnummern spielen eine Rolle, aber auch Tags, SHAs, Registry Digests, Signaturen, Bescheinigungen, Unveränderlichkeit von Versionen, Isolierung von Ausführenden und der geheime Bereich. Die Beobachtung von Docker, dass Tags keine Sicherheitsgrenze darstellen, die langjährige Warnung von GitHub vor dem Pinning an vollständige SHAs und Trivys eigenes Vertrauen in unveränderliche Releases für v0.69.3 weisen alle in die gleiche Richtung. Die Verteidiger müssen aufhören, nach einer Silberkugel-Kontrolle zu suchen und anfangen, Vertrauen über den gesamten Pfad vom Herausgeber zur Pipeline zu entwickeln. (Docker)

Die letzte Lektion ist die operative Disziplin. Teams erholen sich von Vorfällen wie diesem, indem sie schnell, langweilig und gründlich vorgehen: Identifizieren Sie jeden veränderbaren Verweis, ersetzen Sie ihn durch einen sicheren, unveränderbaren, rotieren Sie jedes Geheimnis, das in den Geltungsbereich fiel, bilden Sie die Läufer, denen nicht vertraut werden kann, neu ab, verifizieren Sie die Ersatzartefakte und dokumentieren Sie die Kontrolländerungen, die verhindern, dass sich das gleiche Muster wiederholt. Diese Arbeit ist nicht glamourös, aber sie ist der Unterschied zwischen "wir haben reagiert" und "wir haben es tatsächlich eingedämmt". CVE-2026-33634 ist ein schwerwiegendes Ereignis, aber es zeigt auch ungewöhnlich deutlich, wo moderne CI-Vertrauensmodelle noch am schwächsten sind. (GitHub)

Weitere Informationen zu CVE-2026-33634 und zum Schutz der Software-Lieferkette

• Eintrag in der National Vulnerability Database für CVE-2026-33634, einschließlich NVD-Beschreibung und Zusammenfassung der betroffenen Komponenten. (NVD)
• GitHub-Sicherheitshinweis für Trivy, einschließlich sicherer Versionen, kompromittierter Digests, Fallback-Exfil-Verhalten und Verifizierungsanleitung. (GitHub)
• Trivy Maintainers' Incident Discussion mit Expositionsfenstern und sofortigen Abhilfeanleitungen. (GitHub)
• Aqua's offizieller Zeitplan für den Vorfall und der aktuelle Stand der Abhilfemaßnahmen. (Aqua)
• Docker's incident note für Trivy-Benutzer auf Docker Hub, einschließlich betroffener Tags, Digests und Anleitungen zur Host-Kompromittierung für gemountete Docker-Sockets. (Docker)
• Microsofts Anleitung zur Untersuchung von Bedrohungen und zur Jagd auf die Kompromittierung, einschließlich Telemetriedaten von Läufern und breiterem Kampagnenkontext. (Microsoft)
• GitHub-Referenz für die sichere Nutzung von Actions, einschließlich einer Anleitung für Full-SHA-Pinning, Secret-Handling, OIDC und Vorsichtsmaßnahmen für selbst gehostete Runner. (GitHub-Dokumente)
• GitHub Dokumentation zu unveränderlichen Veröffentlichungen und Anleitung zu Tag-Schutz-Regelsätzen. (GitHub-Dokumente)
• CrowdStrike's technische Analyse der Kompromittierung auf der Aktionsseite und der gemeldeten Artefakte der Workstation-Persistenz. (CrowdStrike)
• Orca's Berichterstattung über den früheren Fußabdruck Ende Februar und die unsichere pull_request_target Workflow-Muster. (Orca Sicherheit)
• Checkmarx' Vorfallsnotiz für verwandte Kampagnenaktivitäten, die seine GitHub-Aktionen betreffen. (Checkmarx)
• LiteLLMs offizielle Offenlegung für bösartige PyPI-Veröffentlichungen im Rahmen derselben breiteren Kampagne. (GitHub)
• Penligents englischer Bericht über den LiteLLM-PyPI-Kompromiss, nützlich als begleitende Fallstudie für geheimnisvolle KI-Werkzeuge in Software-Lieferketten. (Sträflich)
• Penligents englische Analyse der XZ Utils-Backdoor, nützlich für den Vergleich der Kompromittierung von Release-Artefakten mit der Kompromittierung von CI und Action-Tags. (Sträflich)
• Penligents Artikel über Cloud-native Sicherheitspraktiken, der für Teams relevant ist, die nach diesem Vorfall ihre Annahmen zu KI, Containern und Geheimhaltungsmanagement überdenken. (Sträflich)
• Penligent-Produktübersicht und -Homepage für Leser, die menschengesteuerte automatisierte Retesting- und Reporting-Workflows nach der Behebung von Vorfällen evaluieren möchten. (Sträflich)