Een kritieke misconfiguratie in Amazon Web Services (AWS) CodeBuild had een volledige overname van de eigen GitHub-repository’s van de cloudserviceprovider mogelijk kunnen maken, inclusief de AWS JavaScript SDK, waardoor elke AWS-omgeving in gevaar kwam.
De kwetsbaarheid heeft een codenaam gekregen Codebreuk door cloudbeveiligingsbedrijf Wiz. Het probleem werd in september 2025 door AWS opgelost na een verantwoorde openbaarmaking op 25 augustus 2025.
“Door CodeBreach te misbruiken, hadden aanvallers kwaadaardige code kunnen injecteren om een platformbreed compromis te lanceren, wat mogelijk niet alleen gevolgen heeft voor de talloze applicaties die afhankelijk zijn van de SDK, maar ook voor de console zelf, waardoor elk AWS-account wordt bedreigd”, aldus onderzoekers Yuval Avrahami en Nir Ohfeld in een rapport gedeeld met The Hacker News.
De fout, zo merkte Wiz op, is het resultaat van een zwakte in de continue integratie (CI) pijplijnen die niet-geverifieerde aanvallers in staat hadden kunnen stellen de bouwomgeving te doorbreken, geprivilegieerde inloggegevens zoals GitHub-beheertokens te lekken en deze vervolgens te gebruiken om kwaadaardige wijzigingen naar de gecompromitteerde repository te pushen, waardoor een pad werd gecreëerd voor supply chain-aanvallen.
Anders gezegd: het probleem ondermijnt de webhookfilters die door AWS zijn geïntroduceerd om ervoor te zorgen dat alleen bepaalde gebeurtenissen een CI-build activeren. AWS CodeBuild kan bijvoorbeeld zo worden geconfigureerd dat een build alleen wordt geactiveerd wanneer codewijzigingen worden doorgevoerd in een specifieke branch of wanneer een GitHub- of GitHub Enterprise Server-account-ID (ook bekend als ACTOR_ID of actor-ID) overeenkomt met het reguliere expressiepatroon. Deze filters dienen ter beveiliging tegen niet-vertrouwde pull-aanvragen.
De verkeerde configuratie had gevolgen voor de volgende door AWS beheerde open source GitHub-opslagplaatsen, die zijn geconfigureerd om builds op pull-aanvragen uit te voeren:
- aws-sdk-js-v3
- aws-lc
- amazon-corretto-crypto-provider
- awslabs/open-data-register
De vier projecten, die een ACTOR_ID-filter implementeerden, leden aan een “fatale fout” in die zin dat ze er niet in slaagden twee tekens op te nemen om ervoor te zorgen (namelijk de begin ^ en eind $ ankers) die nodig zijn om een exacte reguliere expressie (regex) overeenkomst te verkrijgen. In plaats daarvan stond het regex-patroon elke GitHub-gebruikers-ID toe die een superstring was van een goedgekeurde ID (bijvoorbeeld 755743) om het filter te omzeilen en de build te activeren.
Omdat GitHub numerieke gebruikers-ID’s opeenvolgend toewijst, zei Wiz dat het kon voorspellen dat de nieuwe gebruikers-ID’s (momenteel 9 cijfers lang) ongeveer elke vijf dagen de zescijferige ID van een vertrouwde beheerder zouden “overschaduwen”. Dit inzicht, gekoppeld aan het gebruik van GitHub Apps om het maken van apps te automatiseren (wat op zijn beurt een corresponderende botgebruiker creëert), maakte het mogelijk om een doel-ID te genereren (bijvoorbeeld 226755743) door honderden nieuwe botgebruikersregistraties te activeren.
Gewapend met de actor-ID kan een aanvaller nu een build activeren en de GitHub-referenties verkrijgen van het aws-sdk-js-v3 CodeBuild-project, een Personal Access Token (PAT) van de aws-sdk-js-automation-gebruiker, die volledige beheerdersrechten heeft voor de repository.
De aanvaller kan deze verhoogde toegang gebruiken om code rechtstreeks naar de hoofdtak te pushen, pull-aanvragen goed te keuren en repository-geheimen te exfiltreren, waardoor uiteindelijk de weg wordt geëffend voor supply chain-aanvallen.
“De geconfigureerde reguliere expressies van de bovenstaande repository’s voor AWS CodeBuild-webhookfilters, bedoeld om vertrouwde actor-ID’s te beperken, waren onvoldoende, waardoor een voorspelbaar verkregen actor-ID beheerdersrechten kon krijgen voor de getroffen repository’s”, aldus AWS in een vandaag vrijgegeven advies.
“We kunnen bevestigen dat dit projectspecifieke verkeerde configuraties waren in webhook actor ID-filters voor deze repository’s en geen probleem in de CodeBuild-service zelf.”
Amazon zei ook dat het de geïdentificeerde problemen heeft verholpen, samen met het implementeren van aanvullende maatregelen, zoals het roteren van inloggegevens en stappen om de bouwprocessen te beveiligen die GitHub-tokens of andere inloggegevens in het geheugen bevatten. Het benadrukte verder dat het geen bewijs heeft gevonden dat CodeBreach in het wild is uitgebuit.
Om dergelijke risico’s te beperken, is het essentieel dat niet-vertrouwde bijdragen geen bevoorrechte CI/CD-pijplijnen activeren door de nieuwe Pull Request Comment Approval-buildgate in te schakelen, door CodeBuild gehoste runners te gebruiken om build-triggers te beheren via GitHub-workflows, ervoor te zorgen dat regex-patronen in webhookfilters zijn verankerd, een unieke PAT te genereren voor elk CodeBuild-project, de PAT-machtigingen te beperken tot het vereiste minimum en te overwegen een speciaal niet-bevoorrecht GitHub-account voor CodeBuild te gebruiken integratie.
“Deze kwetsbaarheid is een schoolvoorbeeld van waarom tegenstanders zich op CI/CD-omgevingen richten: een subtiele, gemakkelijk over het hoofd geziene fout die kan worden uitgebuit voor een enorme impact”, aldus Wiz-onderzoekers. “Deze combinatie van complexiteit, niet-vertrouwde gegevens en geprivilegieerde inloggegevens creëert een perfecte storm voor inbreuken met grote impact waarvoor geen voorafgaande toegang vereist is.”
Dit is niet de eerste keer dat de beveiliging van CI/CD-pijpleidingen onder de loep wordt genomen. Vorig jaar heeft onderzoek van Sysdig gedetailleerd beschreven hoe onveilige GitHub Actions-workflows die verband houden met de pull_request_target-trigger kunnen worden uitgebuit om de geprivilegieerde GITHUB_TOKEN te lekken en ongeautoriseerde toegang te krijgen tot tientallen open-sourceprojecten door gebruik te maken van een enkele pull-request van een fork.
Een soortgelijke tweedelige analyse van Orca Security vond onveilige pull_request_target in projecten van Google, Microsoft, NVIDIA en andere Fortune-500-bedrijven die aanvallers in staat hadden kunnen stellen willekeurige code uit te voeren, gevoelige geheimen te exfiltreren en kwaadaardige code of afhankelijkheden naar vertrouwde branches te pushen. Het fenomeen wordt pull_request_nightmare genoemd.
“Door misbruik te maken van verkeerd geconfigureerde workflows die worden geactiveerd via pull_request_target, kunnen kwaadwillenden escaleren van een niet-vertrouwd gevorkt pull-verzoek naar externe code-uitvoering (RCE) op door GitHub gehoste of zelfs zelfgehoste runners”, merkte beveiligingsonderzoeker Roi Nisimi op.
“GitHub Actions-workflows die de pull_request_target gebruiken, mogen nooit niet-vertrouwde code uitchecken zonder de juiste validatie. Als ze dat eenmaal doen, lopen ze het risico van een volledig compromis.”
