Chave exposta no SageMaker permite executar código — atualizar não basta
A AWS publicou em 1º de setembro de 2026 um aviso sobre a CVE-2026-83551, falha no Amazon SageMaker Python SDK que deixa uma chave HMAC em texto claro nas definições de pipeline. O boletim de segurança da AWS confirma que alguém autenticado na mesma conta, com acesso a DescribePipeline e permissão para sobrescrever o objeto correspondente no S3, pode forjar uma carga válida e executar código com as credenciais do pipeline de outro usuário.
Também em 1º de setembro, o projeto classificou a vulnerabilidade como de severidade alta e publicou as correções: a linha v3 precisa estar na versão 3.11.0 ou posterior, e a v2, na 2.256.0 ou posterior. Para pipelines existentes criados com @step, porém, instalar o pacote corrigido não basta: o advisory do repositório oficial determina que suas definições sejam registradas novamente com o SDK atualizado; no caso de @remote, a atualização é suficiente.
Como a chave exposta leva à execução de código
Os componentes de pipeline usados pelos decoradores @step e @remote serializam funções Python e armazenam as cargas resultantes no S3. A assinatura HMAC serve para verificar a integridade desses objetos antes da desserialização, mas o segredo usado na assinatura também era persistido na definição do pipeline e podia ser recuperado pela API DescribePipeline.
A exposição da chave, sozinha, não conclui o ataque. O agente precisa reunir sagemaker:DescribePipeline, acesso de gravação como s3:PutObject no objeto serializado e conhecimento do alvo. Nessas condições, pode substituir a carga por outro objeto, gerar uma assinatura aceita e fazer com que uma execução legítima processe o código adulterado com a função de execução da vítima.
O alcance está limitado a usuários da mesma conta AWS e depende dessas permissões prévias; não se trata de execução anônima pela internet. Ainda assim, o registro publicado da vulnerabilidade confirma o risco de execução entre usuários e identifica as versões anteriores a 3.11.0 e 2.256.0 como afetadas.
O inventário precisa cobrir instalações e pipelines persistidos
A verificação deve começar nos ambientes que constroem ou publicam cargas do SageMaker: notebooks, imagens de contêiner, runners de CI e estações administrativas. Em cada runtime, use python -m pip show sagemaker ou python -c "import sagemaker; print(sagemaker.__version__)". Conferir apenas requirements.txt ou pyproject.toml não prova qual versão está instalada em uma imagem já implantada.
Na linha v3, versões abaixo de 3.11.0 são vulneráveis; na v2, o corte é 2.256.0. O inventário também deve relacionar cada instalação antiga aos pipelines que ela publicou, registrando conta, região, nome do pipeline e repositório ou automação responsável pelo deployment.
Essa segunda parte é indispensável porque a atualização local não altera definições já armazenadas pelo serviço. Um ambiente pode exibir a versão corrigida enquanto um pipeline @step continua contendo o material gerado pela versão vulnerável.
@step exige novo upsert; @remote, apenas o SDK corrigido
Quem permanecer na série v3 pode instalar a versão mínima corrigida com python -m pip install "sagemaker>=3.11.0,<4". Na v2, o equivalente é python -m pip install "sagemaker>=2.256.0,<3". Depois da instalação, imagens e ambientes de execução precisam ser reconstruídos ou atualizados, e a versão deve ser conferida no runtime que efetivamente publica o recurso.
A correção da v3 substitui a assinatura HMAC simétrica por ECDSA assimétrica: a chave privada permanece no cliente, enquanto a definição recebe o material público usado na verificação. Na v2, a correção remove a chave armazenada. Essas mudanças impedem que novas definições sejam produzidas com o segredo exposto.
Para cada pipeline existente criado com @step, é necessário executar novamente o código de construção com o SDK corrigido e chamar pipeline.upsert() usando os parâmetros operacionais do deployment original. O upsert substitui a definição persistida; apenas editar a dependência no repositório ou reiniciar uma sessão não remove o material já registrado.
O fluxo de @remote é diferente porque cada invocação cria um trabalho novo, sem material de chave persistente que precise ser republicado. Nesse caso, basta garantir que todos os ambientes que iniciam as chamadas — não apenas a estação do operador — estejam usando uma versão corrigida.
DescribePipeline e a escrita no S3 formam o caminho de risco
Até que a atualização e os upserts terminem, a mitigação indicada é restringir sagemaker:DescribePipeline a identidades confiáveis e configurar um s3_root_uri dedicado por usuário nas cargas @step e @remote. A prioridade é romper a combinação entre a leitura da definição e a possibilidade de sobrescrever a carga serializada correspondente.
A revisão deve considerar políticas anexadas e inline, permission boundaries, políticas de bucket e funções que a identidade possa assumir. Um teste com aws iam simulate-principal-policy pode ajudar a avaliar DescribePipeline e s3:PutObject, mas a simulação precisa usar os recursos e contextos relevantes e não substitui a inspeção das políticas de recurso.
Equipes que já registravam eventos pertinentes podem procurar chamadas a DescribePipeline e gravações nos prefixos afetados. A falta de registros não demonstra ausência de exploração quando eventos de dados do S3 ou o período necessário não estavam cobertos; a conclusão deve explicitar quais logs realmente existiam.
A validação termina na definição republicada
Depois da implantação, confirme a versão em cada runtime, refaça o fluxo de publicação dos pipelines @step e verifique, com uma identidade administrativa controlada, se a definição antiga foi substituída. A resposta de DescribePipeline não deve ser copiada integralmente para logs de CI, tickets ou históricos compartilhados durante essa inspeção.
Em seguida, valide se identidades sem função administrativa deixaram de obter DescribePipeline quando não precisam dessa ação, se usuários diferentes gravam em raízes S3 separadas e se cada pipeline republicado ainda executa com a região, a função IAM e os parâmetros esperados. O estado corrigido exige as duas evidências: SDK nas versões mínimas ou posteriores e novas definições para os pipelines @step que já existiam.
As correções e o procedimento oficial já estão disponíveis. O que permanece específico de cada conta é localizar todas as definições antigas e eliminar a combinação de permissões que possibilita a adulteração; sem essas verificações, a simples atualização do pacote não comprova que a exposição foi removida.
Leia também:
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.