Błąd w regexie w AWS – jak dwa znaki mogły zagrozić chmurze?

Ile warte są dwa znaki w regexie? W tym przypadku: potencjalnie – spokój wszystkich użytkowników AWS.

Wystarczyły brakujące „^” i „$” w filtrze CodeBuild, by otworzyć furtkę do zaufanych repozytoriów AWS na GitHubie. Badacze z Wiz pokazali, że tym mikrobłędem dało się przeskoczyć zabezpieczenia, wykraść tokeny admina i przejąć m.in. AWS SDK for JavaScript – bibliotekę, która napędza samą Konsolę AWS. AWS naprawił konfigurację w 48 godzin, nie ma dowodów nadużyć. Ale lekcja jest większa niż szybka łatka.

To historia o tym, jak łańcuch dostaw oprogramowania (CI/CD) bywa najsłabszym ogniwem. Takie pipeline’y automatycznie budują, testują i wydają kod. Jedno przeoczenie w regule „kto może uruchomić build” potrafi zniweczyć mechanikę bezpieczeństwa. A gdy mówimy o SDK używanym w 66% środowisk chmurowych i zintegrowanym z Konsolą AWS, skala ryzyka przestaje być teoretyczna.

O co poszło

W kilku zarządzanych przez AWS repozytoriach open source (m.in. aws-sdk-js-v3, aws-lc, amazon-corretto-crypto-provider i awslabs/open-data-registry) filtrowano wyzwalacze CodeBuild po ACTOR_ID – czyli ID użytkownika GitHuba, który może uruchomić build dla pull requestu. Reguła była sprytna, ale nie dość precyzyjna: w regexie zabrakło kotwic początku i końca wzorca (^ i $). Efekt? Zamiast „dokładnie ten ID” dostawaliśmy „dowolny ID zawierający ten fragment”. [3]

GitHub przydziela numery ID sekwencyjnie. Jeśli zaufany maintainer ma np. 755743, to prędzej czy później pojawi się ktoś z ID 226755743 – zawierającym tamten ciąg jako podciąg. Badacze z Wiz nie czekali na „prędzej czy później”. Zautomatyzowali tworzenie GitHub Apps (każda tworzy bota), tworzyli setki nowych kont i „złapali” dokładny numer, który przechodził filtr. [3]

Jak to wykorzystano w praktyce

Mając „pasującego” bota, otworzyli PR do aws/aws-sdk-js-v3. Zmiana była legitna, ale w zależnościach NPM ukryli ładunek, który uruchamiał się w środowisku builda i z pamięci wyciągał GitHubowe poświadczenia.

W kilka chwil zdobyli Personal Access Token użytkownika aws-sdk-js-automation z pełnymi uprawnieniami admina do repo. Dalej to już administracja: zaprosić własne konto jako admina, móc pushować do maina, akceptować PR-y, podejrzeć sekrety.

Dlaczego to tak groźne

AWS SDK for JavaScript publikuje się regularnie na GitHubie i NPM. Z takim dostępem można doszyć złośliwy kod tuż przed wydaniem. Wiz szacuje, że dwie trzecie środowisk chmurowych trzyma gdzieś tę bibliotekę. Do tego sama Konsola AWS bundle’uje świeże wersje SDK. Jeden trefny release mógłby więc trafić zarówno do aplikacji klientów, jak i do interfejsu, którym zarządza się infrastrukturą. Jak ujął to jeden z badaczy: to „centralny układ nerwowy chmury”. SolarWinds dawał dostęp do sieci korporacyjnych; tu stawką była egzekucja kodu w miejscu, skąd zarządza się całym kontem.

AWS odpowiada i sprząta

Linia czasu jest krótka: zgłoszenie 25 sierpnia 2025 r., w 48 godzin AWS kotwiczy filtry regexem, cofa tokeny, a we wrześniu dorzuca twarde zabezpieczenia przed wyciekiem poświadczeń z pamięci buildów. Potem audyt publicznych pipeline’ów i logów – bez śladów nadużyć. Ważny niuans: Amazon podkreśla, że to nie bug w CodeBuild jako usłudze, lecz projektowa miskonfiguracja kilku repo. Na deser pojawia się nowa bramka „Pull Request Comment Approval”, która wymusza ludzką zgodę, zanim PR-y od nieufanych kont dotkną uprzywilejowanych buildów.

Szerszy trend, ten sam ból

Ta historia nie bierze się znikąd. W lipcu podobny błąd w konfiguracji CodeBuild posłużył do próby ataku supply-chain na rozszerzenie Amazon Q dla VS Code. W tle przewija się też incydent Nx S1ngularity i ogólna prawidłowość: subtelne błędy w CI/CD potrafią dać niewspółmiernie duży efekt. Jak ironicznie zauważył Corey Quinn: jeśli nawet AWS potrafi potknąć się na własnym regexie, to może czas double-check u reszty z nas. [4]

Czego się nauczyć (i szybko wdrożyć)

• Kotwicz regexy w webhookach. ACTOR_ID bez ^ i $ to zaproszenie na imprezę dla każdego, kto przewidzi numerację ID.
• Nie uruchamiaj uprzywilejowanych buildów z nieufanych PR-ów. Domyślna odmowa plus ręczna aprobata to mniej seksi CI, ale dużo zdrowsza.
• Tokeny na diecie: minimalne uprawnienia, fine-grained, rotacja; a w buildach – krótkotrwałe poświadczenia i obrona przed „zrzutami z pamięci”.
• Audyty konfiguracji CI/CD co jakiś czas, nie „raz przy wdrożeniu”.

Ironia losu? Dwa znaki interpunkcyjne to różnica między „dopasuj dokładnie” a „dopasuj cokolwiek, co trochę przypomina”. W łańcuchu dostaw oprogramowania taki niuans może mieć nieproporcjonalnie duże skutki. Pytanie na koniec: kiedy ostatnio zaglądaliście do własnych filtrów i uprawnień w pipeline’ach – i czy wasze „^” i „$” na pewno są na swoim miejscu?

FAQ

Czy podatność CodeBreach była wykorzystywana w praktyce przeciwko AWS?

Nie, AWS nie znalazł dowodów nadużyć w logach repozytoriów i CloudTrail. Luka została załatana w ciągu 48 godzin od zgłoszenia, a później wdrożono dodatkowe zabezpieczenia.

Kiedy AWS naprawił błąd w CodeBuild/konfiguracjach repozytoriów?

Główna poprawka trafiła w końcówce sierpnia 2025 r., w 48 godzin po zgłoszeniu 25 sierpnia. Dodatkowe utwardzenia wdrożono we wrześniu 2025 r., a publiczne ujawnienie nastąpiło 15 stycznia 2026 r.

Czy to był błąd usługi AWS CodeBuild, czy tylko zła konfiguracja?

To była zła konfiguracja konkretnych repozytoriów, nie wada samej usługi. AWS zakotwiczył filtry, zrotował poświadczenia i przeaudytował pozostałe projekty.

Jak sprawdzić, czy mój filtr ACTOR_ID w CodeBuild jest bezpieczny?

Najpierw tak: wzorzec musi używać ^ i $ dla pełnego dopasowania ID. Dodatkowo ogranicz PR-y z zewnątrz, a uprzywilejowane buildy przepuszczaj tylko po ręcznej akceptacji zaufanego maintenera.

Które repozytoria AWS były dotknięte podatnością CodeBreach?

Potwierdzono cztery: aws-sdk-js-v3, aws-lc, amazon-corretto-crypto-provider i awslabs/open-data-registry. AWS informuje, że podobnej miskonfiguracji nie znaleziono w pozostałych projektach.

Źródła

• [1] https://infoq.com/news/2026/01/aws-github-vulnerability/
• [2] https://thehackernews.com/2026/01/aws-codebuild-misconfiguration-exposed.html
• [3] https://techzine.eu/news/infrastructure/137983/codebreach-enables-takeover-of-aws-github-repositories/
• [4] https://infoworld.com/article/4117662/possible-software-supply-chain-attack-through-aws-codebuild-service-blunted.html
• [5] https://techradar.com/pro/security/critical-aws-supply-chain-vulnerability-could-have-let-hackers-take-over-key-github-repositories
• [6] https://theregister.com/2026/01/15/codebuild_flaw_aws/
• [7] https://hackread.com/how-2-missing-chars-compromised-aws/
• [8] https://sqmagazine.co.uk/aws-codebuild-codebreach-supply-chain-risk/
• [9] https://infosecurity-magazine.com/news/codebuild-flaw-aws-console-risk/