Blueprint do CodeCatalyst executa comandos — só o pacote exige ação
Em 3 de setembro de 2026, o repositório oficial do CodeCatalyst publicou um advisory de segurança de gravidade alta sobre o pacote npm @amazon-codecatalyst/blueprints.blueprint. Nas versões anteriores à 0.3.156, uma pessoa com permissão para gravar no repositório pode manipular o campo owner do arquivo .ownership-file e executar comandos do sistema durante a ressíntese.
Na mesma data, o boletim de segurança da AWS delimitou quem precisa agir: o serviço gerenciado Amazon CodeCatalyst já aplica proteções e não requer mudanças, enquanto consumidores diretos do pacote devem instalar a versão 0.3.156 ou posterior. Para esse consumo direto, a atualização é a única mitigação; forks e código derivado precisam incorporar a correção.
Onde a execução de comandos acontece
A falha está no framework aberto de ressíntese distribuído pelo pacote, não em todo uso de blueprints no serviço hospedado. Durante a ressíntese, o framework lê o .ownership-file do projeto existente para determinar quais arquivos o blueprint pode modificar.
Nas edições vulneráveis, o campo owner de uma entrada com estratégia de mesclagem [local] era repassado a um comando do sistema por meio de um shell, sem validação adequada. Metacaracteres inseridos nesse valor podiam alterar o comando e executar código arbitrário com as permissões e credenciais disponíveis no ambiente de ressíntese.
O ataque pressupõe acesso para fazer commit no repositório do projeto. Portanto, não é uma execução acionável por qualquer visitante externo: a exposição surge quando alguém que já pode alterar o repositório introduz um .ownership-file preparado e o projeto passa por nova ressíntese.
No Amazon CodeCatalyst gerenciado, a ressíntese ocorre em um ambiente isolado por projeto, com credenciais de escopo limitado. A validação no servidor rejeita comandos [local] fora de uma forma autorizada, inclusive para blueprints publicados em versões anteriores à 0.3.156. Essa é a razão técnica para o serviço não exigir atualização do usuário.
Como separar serviço, pacote e dependência vulnerável
A triagem deve classificar o projeto em três situações: uso exclusivo do serviço gerenciado, instalação do pacote npm ou manutenção de uma cópia derivada do SDK. Somente encontrar referências a CodeCatalyst ou a “blueprints” no repositório não comprova que o pacote vulnerável esteja instalado.
O identificador a procurar é @amazon-codecatalyst/blueprints.blueprint. O registro da CVE no OpenCVE confirma que o produto afetado são as versões anteriores à 0.3.156 e que a vulnerabilidade corresponde à neutralização inadequada de elementos especiais em comandos do sistema.
No diretório de cada aplicação ou workspace, consulte a árvore instalada com o comando do gerenciador usado pelo projeto:
- npm ls @amazon-codecatalyst/blueprints.blueprint --all
- yarn why @amazon-codecatalyst/blueprints.blueprint
- pnpm why @amazon-codecatalyst/blueprints.blueprint
Esses comandos também ajudam a revelar uma dependência transitiva. Se o ambiente ainda não tiver as dependências instaladas, procure o identificador em package.json e nos arquivos de lock com rg -n "@amazon-codecatalyst/blueprints\.blueprint" --glob "package.json" --glob "*lock*" ..
Uma resolução em 0.3.155 ou anterior está vulnerável; a ausência do pacote na árvore e nos manifests indica que não há consumo por essa via. A conferência deve alcançar o diretório, contêiner ou imagem realmente usado na ressíntese, pois um package.json atualizado não altera sozinho um node_modules antigo ou uma imagem de CI já construída.
Como fazer a versão corrigida chegar ao build
Para uma dependência direta, fixe a atualização em 0.3.156 ou posterior e regenere o lockfile. Conforme o gerenciador, isso pode ser feito com npm install @amazon-codecatalyst/blueprints.blueprint@^0.3.156, yarn add @amazon-codecatalyst/blueprints.blueprint@^0.3.156 ou pnpm add @amazon-codecatalyst/blueprints.blueprint@^0.3.156.
Depois, reinstale as dependências no ambiente de ressíntese e repita o inventário. A correção só chegou ao fluxo quando a árvore efetivamente instalada deixou de resolver qualquer versão anterior à 0.3.156; mudar apenas a faixa no manifest não garante o mesmo resultado em builds reproduzidos a partir de um lockfile antigo.
Quando o pacote entra de forma transitiva, a opção preferencial é atualizar o componente que o adiciona. Um override ou resolution também pode forçar uma versão corrigida, mas precisa ser registrado no lockfile e validado pelos testes do próprio projeto, porque a compatibilidade depende da árvore que consome o pacote.
A versão 0.3.156 remove a interpretação do campo owner pelo shell, executa o comando diretamente e rejeita valores fora da forma permitida. Filtrar manualmente alguns metacaracteres ou combinar por convenção que o .ownership-file não será alterado não substitui esse patch.
Forks podem escapar do inventário de pacotes
Um fork continua no escopo mesmo que npm, Yarn ou pnpm não encontrem o identificador original. Isso ocorre quando o código vulnerável foi copiado para o repositório, incorporado a outro pacote ou publicado sob um nome diferente.
Nesse caso, é necessário localizar o processamento de .ownership-file, o campo owner das entradas [local] e qualquer chamada que entregue esse valor a um shell. A correção equivalente deve reunir as duas propriedades da versão 0.3.156: executar sem interpretação pelo shell e aceitar somente a forma de comando autorizada.
O estado confirmado em 3 de setembro de 2026 é, portanto, restrito e acionável: projetos que usam apenas o Amazon CodeCatalyst gerenciado não precisam mudar; instalações diretas abaixo da 0.3.156 devem ser atualizadas; e derivações do SDK precisam receber o patch no próprio código. A versão instalada no ambiente de ressíntese — e não apenas a declaração no manifest — é o critério final da verificação.
Leia também:
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.