Eine Schwachstelle in der Build-Automatisierung von AWS hätte Angreifern ermöglichen können, vertrauenswürdige GitHub-Repositories zu übernehmen und Schadcode in viel genutzte AWS-Softwarekomponenten einzuschleusen.
Die Wiz-Forscher erklärten, dass das Problem, das sie CodeBreach nannten, einen Weg von einem einzigen Pull Request in privilegierte CI/CD-Workflows eröffnete – mit potenziellen Auswirkungen auf nachgelagerte Anwendungen in massivem Maßstab.
Die Forscher „… identifizierten ein Konfigurationsproblem, das die folgenden von AWS verwalteten Open-Source-GitHub-Repositories betraf und zur Einbringung unangemessenen Codes hätte führen können“, sagte AWS in seiner Stellungnahme.
Sie fügten hinzu: „Während dieser Sicherheitsforschungsaktivität wurde kein unangemessener Code in eines der betroffenen Repositories eingebracht. Die Aktivitäten hatten keine Auswirkungen auf AWS-Kundenumgebungen und betrafen weder AWS-Services noch die AWS-Infrastruktur.“
Das Lieferkettenrisiko von CodeBreach
Wiz berichtete, dass CodeBreach ein Lieferkettenrisiko in vier AWS-Repositories offengelegt habe: aws/aws-sdk-js-v3, aws/aws-lc, corretto/amazon-corretto-crypto-provider und awslabs/open-data-registry.
Die Sorge beschränkte sich nicht auf ein einzelnes Projekt – es ging um die Möglichkeit, dass Angreifer vertrauenswürdige CI/CD-Automatisierung missbrauchen könnten, um Schadcode vorgelagert einzuschleusen und diese Kompromittierung anschließend durch reguläre Builds und Releases nachgelagert weiterzutragen.
Das schwerwiegendste Auswirkungsszenario betraf das AWS-JavaScript-SDK, das in Cloud-Umgebungen weit verbreitet ist und häufig über Paketmanager wie npm eingebunden wird.
Wenn Angreifer dieses SDK manipulieren könnten, könnten sie Updates vergiften, die Entwickler und Produktivsysteme automatisch beziehen, und so normale Abhängigkeitsaktualisierungen in einen unauffälligen Verbreitungskanal für Schadcode verwandeln.
Auf technischer Ebene führte Wiz die Ursache auf eine Schwachstelle bei der Zugriffskontrolle in AWS-CodeBuild-Webhook-Filtern zurück, die an den Parameter ACTOR_ID gebunden waren.
Diese Filter sollen sicherstellen, dass nur vertrauenswürdige GitHub-Identitäten privilegierte Builds auslösen können – insbesondere in Workflows, die mit erweiterten Berechtigungen ausgeführt werden oder Zugriff auf vertrauliche Secrets haben.
Wiz stellte jedoch fest, dass die in diesen Filtern verwendeten regulären Ausdrücke nicht verankert waren, also die ^ sogenannten $^- und $-Anker für eine strikte, exakte Übereinstimmung fehlten.
Dieses Detail war entscheidend, weil ein nicht verankertes Muster mehr Treffer liefern kann als beabsichtigt.
Statt Builds nur dann zuzulassen, wenn die ACTOR_ID mit einer bestimmten freigegebenen Benutzer-ID übereinstimmte, konnte der Filter auch jede GitHub-Benutzer-ID erfassen, die eine genehmigte Teilzeichenfolge enthielt.
Die Forscher zeigten, wie Angreifer dies über sogenannte Eclipse-Ereignisse ausnutzen könnten – Fälle, in denen eine neu erstellte, längere numerische GitHub-ID schließlich die aus sechs bis sieben Ziffern bestehende Kurz-ID eines älteren Maintainers als Teilzeichenfolge enthält.
Da GitHub IDs sequenziell vergibt und täglich etwa 200.000 neue IDs ausstellt, kommen solche Überschneidungen laut Wiz häufig genug vor, um praktisch relevant zu sein; bei den anvisierten IDs treten Eclipse-Bedingungen ungefähr alle fünf Tage auf.
Proof of Concept (PoC)
In einem Proof of Concept, der auf aws/aws-sdk-js-v3 abzielte, demonstrierte Wiz, wie ein bösartiger Pull Request einen privilegierten Build auslösen und versteckte Payload-Logik innerhalb der Build-Umgebung ausführen konnte.
Die Payload dumpte anschließend den Prozessspeicher, um ein persönliches GitHub-Zugriffstoken (PAT) zu extrahieren, das dem Konto aws-sdk-js-automation zugeordnet war – trotz der zuvor nach dem Amazon-Q-Vorfall eingeführten Härtungsmaßnahmen.
Nachdem Wiz die Auswirkungen bestätigt hatte, verzichtete das Unternehmen auf eine vollständige Eskalation und meldete das Problem am 25. August 2025 verantwortungsvoll an AWS.
Die Forscher berichteten, dass das wiederhergestellte PAT weitreichende Berechtigungsbereiche besaß, darunter repo und admin:repo_hook, wodurch ein Angreifer Mitarbeiter einladen, Berechtigungen erweitern und direkt in geschützte Branches pushen konnte.
Dasselbe Token ermöglichte außerdem den Zugriff auf verwandte private Repositories, vergrößerte damit den potenziellen Schadensradius über ein einzelnes Open-Source-Projekt hinaus und schuf die Voraussetzungen für eine umfassendere, Ökosystem-weite Lieferketten-kompromittierung.
AWS behob das Problem, rotierte die offengelegten Zugangsdaten und implementierte zusätzliche Schutzmaßnahmen, um eine Wiederholung zu verhindern.
CI/CD-Pipelines härten
Vorfälle wie CodeBreach zeigen, wie kleine Vertrauenslücken in CI/CD schnell zu folgenschweren Kompromittierungspfaden werden können.
Wenn Build-Systeme mit erweiterten Berechtigungen ausgeführt werden, kann bereits eine einzige Umgehung Automatisierungszugangsdaten offenlegen und unbefugte Codeänderungen im Upstream ermöglichen.
Ziel ist es, implizites Vertrauen in Build-Trigger zu reduzieren, den Zugriff nicht vertrauenswürdiger Workflows zu begrenzen und die Transparenz über abnormales Pipeline-Verhalten zu verbessern.
- Verankern Sie Regex-Muster für Webhook-Filter (mit ^ und $), um exakte Identitätsübereinstimmungen zu erzwingen und Umgehungen der Actor-ID zu verhindern.
- Verwenden Sie kurzlebige, fein abgestufte Zugangsdaten (nach Möglichkeit OIDC) und vermeiden Sie weitreichende, langlebige PAT-Berechtigungsbereiche in CI/CD-Workflows.
- Verlangen Sie ausdrückliche Freigabestufen für Pull Requests und stellen Sie sicher, dass Builds nicht vertrauenswürdiger PRs ohne Zugriff auf Secrets oder privilegierte Variablen ausgeführt werden.
- Trennen Sie vertrauenswürdige Release-Pipelines von nicht vertrauenswürdigen Beitrags-Workflows und führen Sie Builds auf isolierten, kurzlebigen Runnern aus, um den Schadensradius zu begrenzen.
- Überwachen Sie Build-Logs und Runner-Telemetrie auf ungewöhnliche Ausführung, Speicherauslesen, Token-Missbrauch und unbefugte Änderungen an Repositories (z. B. Hooks, Einladungen und Pushes).
- Stärken Sie die Lieferketten-integrität durch geschützte Branches, erforderliche Reviews, signierte Commits sowie die Herkunftsprüfung und Signierung von Artefakten, um nachgelagerte Risiken zu reduzieren.
- Testen und proben Sie CI/CD-Vorfallreaktions-Playbooks (z. B. Token-Widerruf, Runner-Isolierung, Schlüsselrotation und Wiederaufbauverfahren), um bei einer Kompromittierung von Automatisierungszugangsdaten eine schnelle Eindämmung sicherzustellen.
Diese Kontrollen helfen, den Missbrauch von CI/CD zu verhindern, Automatisierungszugangsdaten zu schützen und den Schadensradius von Lieferkettenangriffen zu begrenzen.
Wenn Build-Automatisierung zum Angriffspfad wird
CodeBreach erinnert daran, dass die Sicherheit der Lieferkette häufig von kleinen Vertrauensannahmen innerhalb von CI/CD-Pipelines abhängt, in denen Automatisierung, Identitätskontrollen und Secrets zusammenlaufen.
Selbst wenn keine Auswirkungen auf Kunden bestätigt wurden, zeigt das Szenario, wie schnell eine falsch konfigurierte Build-Sperre routinemäßige Pull-Request-Aktivitäten in die Offenlegung von Zugangsdaten und das Risiko einer vorgelagerten Kompromittierung verwandeln kann.
Organisationen sollten dies zum Anlass nehmen, die Logik der Webhook-Filter zu überprüfen, Token-Berechtigungen zu reduzieren, nicht vertrauenswürdige Builds zu isolieren und die Kontrollen für die Integrität von Releases durchgängig zu stärken.
Dasselbe Prinzip – implizites Vertrauen zu minimieren und strenge Verifizierung durchzusetzen – ist der Grund, warum Organisationen Zero-Trust-Lösungen einsetzen.