Falha na AWS expôs repositórios GitHub a riscos de ataques
16 de Janeiro de 2026

Uma falha crítica na configuração do AWS CodeBuild poderia ter permitido o controle total dos repositórios do próprio provedor de nuvem no GitHub, incluindo o AWS JavaScript SDK, colocando em risco todos os ambientes AWS.

A vulnerabilidade, batizada de CodeBreach pela empresa de segurança em nuvem Wiz, foi corrigida pela AWS em setembro de 2025, após divulgação responsável realizada em 25 de agosto do mesmo ano.

"Explorando o CodeBreach, atacantes poderiam injetar código malicioso e comprometer toda a plataforma, impactando não apenas as diversas aplicações que dependem do SDK, mas também o Console da AWS, ameaçando todas as contas na nuvem", explicaram os pesquisadores Yuval Avrahami e Nir Ohfeld em relatório compartilhado com o The Hacker News.

De acordo com a Wiz, a falha decorreu de uma vulnerabilidade nas pipelines de integração contínua (CI) que poderia permitir que invasores não autenticados acessassem o ambiente de build, vazassem credenciais privilegiadas, como tokens de administrador do GitHub, e as utilizassem para introduzir alterações maliciosas nos repositórios afetados — abrindo caminho para ataques à cadeia de suprimentos.

Mais especificamente, o problema comprometeu os filtros de webhook implementados pela AWS para garantir que apenas determinados eventos disparassem a construção no CI.

Por exemplo, o AWS CodeBuild pode ser configurado para iniciar um build somente quando alterações de código são feitas em uma branch específica, ou se o ID de uma conta no GitHub ou no GitHub Enterprise Server (conhecido como ACTOR_ID) corresponder a um padrão de regex predefinido.

Esses filtros são essenciais para impedir que pull requests não confiáveis acionem builds.

A configuração incorreta afetou os seguintes repositórios open source da AWS no GitHub, que executam builds ao receber pull requests:

- aws-sdk-js-v3
- aws-lc
- amazon-corretto-crypto-provider
- awslabs/open-data-registry

Embora esses quatro projetos aplicassem um filtro ACTOR_ID, apresentavam uma "falha grave": não utilizavam os delimitadores obrigatórios — os caracteres ^ (início) e $ (fim) — que garantem a correspondência exata no regex.

Em vez disso, o padrão aceitaria qualquer ID de usuário do GitHub que contivesse um ID aprovado como substring (por exemplo, 755743), permitindo que usuários não autorizados passassem pelo filtro e acionassem o build.

Como o GitHub atribui IDs numéricos aos usuários de forma sequencial, a Wiz conseguiu prever que novos IDs — atualmente com nove dígitos — ultrapassariam os IDs de mantenedores confiáveis, que têm seis dígitos, aproximadamente a cada cinco dias.

Combinando isso ao uso de criação automática de bots via GitHub Apps, era possível gerar IDs-alvo (como 226755743) ao registrar centenas de novos bots.

Com o ACTOR_ID em mãos, o invasor poderia acionar um build e obter as credenciais do projeto aws-sdk-js-v3 no CodeBuild, especificamente um Personal Access Token (PAT) do usuário aws-sdk-js-automation, que possui privilégios administrativos completos no repositório.

Esse acesso elevado permite ao atacante enviar código diretamente para a branch principal, aprovar pull requests e extrair segredos do repositório, facilitando ataques à cadeia de suprimentos.

Em comunicado divulgado hoje, a AWS confirmou que "as expressões regulares configuradas nos filtros de webhook do CodeBuild, que deveriam limitar os IDs de atores confiáveis, foram insuficientes, permitindo que IDs previsivelmente adquiridos obtivessem permissões administrativas nos repositórios afetados."

A empresa ressaltou que essa foi uma má configuração específica nos filtros desses projetos, e não uma falha no serviço CodeBuild em si.

Além de corrigir as vulnerabilidades apontadas, a AWS implementou medidas adicionais, como rotação de credenciais e protocolos para proteger processos de build que armazenam tokens do GitHub ou outras credenciais em memória.

A empresa enfatizou não ter encontrado evidências de exploração do CodeBreach em ambientes reais.

Para mitigar riscos semelhantes, é fundamental evitar que contribuições não confiáveis acionem pipelines CI/CD privilegiadas.

Recomenda-se habilitar o novo build gate Pull Request Comment Approval, usar runners hospedados no CodeBuild para controlar os gatilhos via workflows do GitHub, garantir que padrões de regex nos filtros de webhook estejam corretamente ancorados, gerar PATs exclusivos para cada projeto com permissões mínimas e considerar o uso de contas GitHub dedicadas e sem privilégios para integração com CodeBuild.

"Essa vulnerabilidade é um exemplo clássico do motivo pelo qual adversários miram ambientes CI/CD: uma falha sutil e facilmente ignorada, que pode ser explorada para causar impacto massivo", observam os pesquisadores da Wiz.

"A combinação de complexidade, dados não confiáveis e credenciais privilegiadas cria uma tempestade perfeita para ataques de alto impacto, dispensando qualquer acesso prévio."

Essa não é a primeira vez que a segurança das pipelines CI/CD recebe atenção.

Em 2024, pesquisas da Sysdig mostraram como workflows inseguros do GitHub Actions, associados ao gatilho pull_request_target, poderiam vazar o token privilegiado GITHUB_TOKEN e dar acesso não autorizado a dezenas de projetos open source por meio de um único pull request de forks.

Análises similares da Orca Security revelaram que projetos de empresas como Google, Microsoft e NVIDIA também apresentavam vulnerabilidades no pull_request_target, permitindo execução remota de código, extração de segredos sensíveis e envio de código malicioso para branches confiáveis — um problema apelidado de pull_request_nightmare.

"O abuso de workflows mal configurados acionados via pull_request_target pode permitir que atacantes escalem de pull requests de forks não confiáveis para execução remota de código em runners hospedados no GitHub ou mesmo em servidores próprios", explicou o pesquisador Roi Nisimi.

"Workflows que usam pull_request_target jamais devem fazer checkout de código não confiável sem validação adequada, sob risco de comprometimento total."

Publicidade

Proteja sua empresa contra hackers através de um Pentest

Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...