O que aconteceu
A Cloud Security Alliance publicou uma nota de pesquisa em 6 de agosto de 2026 descrevendo CoreBreak, um conjunto de quatro CVEs nas estruturas de agente AWS, Google e Vercel em que a camada de despacho de ferramentas executou uma chamada de ferramenta sem verificar se um modelo de linguagem realmente a produziu. Todos os quatro têm correções de fornecedores.
A AI Safety Initiative da Cloud Security Alliance publicou uma nota de pesquisa em 6 de agosto de 2026 descrevendo um padrão de vulnerabilidade entre plataformas que os pesquisadores chamaram de CoreBreak. De acordo com a nota, os pesquisadores de segurança Hedi Ingber e Aviyam Ivgi, cofundadores da empresa de segurança Stealth, apresentaram descobertas no Black Hat USA 2026 mostrando que as camadas de execução de ferramentas do Amazon Bedrock AgentCore, Google's Agent Development Kit (ADK) para Python, e os pacotes de chicote distribuídos com o AI SDK da Vercel podem ser induzidos a executar uma ferramenta sem que ocorra uma mudança de modelo legítima. Como o modelo de linguagem nunca foi invocado, argumenta a nota, as grades de proteção construídas em torno do modelo não tiveram decisão de intervir.
Estruturas de agentes desse tipo compartilham uma estrutura comum. Uma camada de orquestração agrupa a solicitação do usuário, o prompt do sistema, o histórico de conversas e um catálogo de ferramentas disponíveis, envia-os para um modelo de linguagem e espera que o modelo retorne uma instrução estruturada nomeando uma ferramenta e seus argumentos. O SDK então despacha a função, script ou chamada de API correspondente e alimenta o resultado de volta na conversa. CoreBreak visa a última etapa: de acordo com a nota, a lógica de despacho em cada um dos três produtos tratava dados que apenas se assemelhavam a uma chamada de ferramenta gerada por modelo como autoritativos, sem verificar de onde vieram.
A nota lista quatro identificadores CVE com caminhos de exploração distintos, citando boletins de fornecedores e entradas do Banco Nacional de Vulnerabilidades. A AWS atribuiu CVE-2026-18830 (CVSS v4.0 8.6, High) à falha de chicote Bedrock AgentCore, onde um chamador remoto autenticado poderia colocar um bloco de conteúdo de uso de ferramenta diretamente na mensagem final de uma solicitação de API InvokeHarness. Google atribuiu CVE-2026-18236 (9.3, Crítico) a uma falha ADK na qual um invasor capaz de injetar eventos no histórico da sessão poderia forjar uma confirmação de aprovação humana, porque o processador de confirmação não verificou se a ferramenta de destino pertencia ao agente executor, que ela realmente exigia confirmação ou que seu nome e argumentos correspondiam à chamada gravada original. @ai-sdk/harness-codex e @ai-sdk/harness-opencode da Vercel receberam CVE-2026-64650 e CVE-2026-64651 (6.3, Médio cada), onde código malicioso já em execução dentro de uma sandbox Linux poderia satisfazer uma verificação de caminho de processo que confiasse em qualquer processo cuja linha de comando contivesse o caminho de um script auxiliar aprovado.
Correções estão disponíveis, mas a carga difere de acordo com o modelo de implantação. A nota diz que a correção da AWS para a API Bedrock AgentCore InvokeHarness totalmente gerenciada, implantada automaticamente antes de 31 de julho de 2026 e não exigiu nenhuma ação do cliente, embora ainda aconselhe a confirmação da cobertura para uma determinada região e configuração. A correção de Google enviada no ADK para Python versão 2.5.0 em 16 de julho de 2026, e as correções de Vercel enviadas em chicote-codex 1.0.29 e chicote-opencode 1.0.28 em 10 de julho de 2026 - atualizações de pacote que os próprios operadores auto-hospedados devem aplicar. A nota enquadra o CoreBreak como distinto da injeção imediata: a injeção imediata tenta manipular o julgamento do modelo, enquanto o CoreBreak ignora a questão de saber se o modelo exerceu julgamento.
Leia a fonte primária: labs.cloudsecurityalliance.org ↗
Por que isso importa
Filtros de conteúdo, prompts do sistema, treinamento de recusa e portas de aprovação humana presumem que o modelo é quem decide se uma ferramenta será executada. Se a camada de despacho aceitar qualquer coisa com formato semelhante a uma chamada de ferramenta de modelo, esses controles serão ignorados em vez de anulados – e os registros que as equipes de monitoramento normalmente inspecionam nunca serão criados.
A maioria dos controles corporativos para IA de agente ficam no modelo ou ao redor dele. Os prompts do sistema restringem ações confidenciais, os filtros de conteúdo pontuam entradas e saídas, o treinamento de recusa é incorporado aos pesos do modelo e as etapas de confirmação humana controlam ferramentas de alto risco. Cada um desses controles presume que o modelo é quem decide se uma ferramenta será executada. Se uma camada de despacho executar qualquer carga corretamente moldada, esses investimentos fornecerão pouca proteção preventiva – não porque tenham sido mal projetados, mas porque o ataque se direciona ao redor do local onde operam. Essa é uma classe de problema diferente de uma barreira de proteção que pode ser superada.
Os recursos específicos por trás dessas camadas de despacho são o que dão peso à descoberta. A nota diz que as falhas do Vercel podem atingir ferramentas expostas ao host, incluindo pesquisas secretas, operações de implantação e chamadas de API na nuvem. A falha Google é ainda mais acentuada: permitiu que confirmações forjadas chegassem a ferramentas deliberadamente colocadas sob aprovação humana, que é a reserva das organizações de controlo para ações consideradas demasiado importantes para serem automatizadas. Um desvio que neutralize especificamente a etapa humana no circuito prejudica a mitigação que muitas equipes citam ao justificar uma autonomia mais ampla dos agentes.
A história do patch também ilustra uma assimetria que se repetirá à medida que as ferramentas dos agentes se espalharem. Os clientes do serviço AWS totalmente gerenciado foram corrigidos sem fazer nada. As equipes que executam o ADK de Google ou pacotes de chicote de Vercel em seus próprios ambientes precisam observar o aviso, atualizar a dependência e reimplantar - e as atualizações de dependência nas pilhas de produção geralmente atrasam semanas ou meses. A mesma lacuna de design subjacente tem, portanto, uma janela de exposição prática muito diferente, dependendo se uma organização consome infraestrutura de agente como um serviço ou a vende em sua própria base de código.
Há também uma lacuna de detecção. A nota observa que o monitoramento de segurança para sistemas de agente geralmente se concentra nas entradas e saídas do modelo – registrando prompts, sinalizando conclusões suspeitas, revisando quais ferramentas o modelo escolheu. Quando uma ferramenta é executada sem o modelo em execução, nenhum desses artefatos existe para ser registrado. Várias coisas importantes permanecem desconhecidas: a nota não relata nenhuma evidência de exploração em estado selvagem, não dá nenhuma estimativa de quantas implantações foram afetadas e não descreve o código de prova de conceito. A CSA é sincera ao afirmar que duas divulgações de quatro fornecedores não provam um padrão em todo o setor e que o gradiente de gravidade observado é um ponto de dados e não uma regra de pontuação.
O que assistir a seguir
Se os operadores auto-hospedados realmente aplicam as atualizações do pacote Google e Vercel, se lacunas de proveniência semelhantes surgem em outras estruturas de agentes, se qualquer exploração in-the-wild é relatada e se os fornecedores mudam para tokens de autorização assinados e vinculados à sessão para execução da ferramenta.
A questão mais concreta no curto prazo é a adoção do patch. A correção gerenciada da AWS é descrita como já implantada, mas o ADK 2.5.0 e as duas versões do Vercel aproveitam apenas os operadores que os instalam. Fique atento aos sinais downstream – taxas de adoção de registro de pacotes, forks vendidos que nunca extraem a atualização e imagens internas da plataforma que fixam versões mais antigas. A nota também recomenda uma verificação retrospectiva: revisão de logs para invocações de ferramentas que não podem ser vinculadas a uma conclusão de modelo correspondente e bem formada no registro da sessão. Se as organizações têm a telemetria da camada de despacho para executar essa verificação, isso não está resolvido.
A segunda questão é o escopo. CoreBreak abrange três produtos, mas o padrão descrito – confiar no formato de uma carga útil ou na linha de comando de um processo como prova de autorização do modelo – não é específico para eles. Qualquer estrutura com a mesma estrutura de SDK para modelo e ferramenta poderia apresentar uma lacuna comparável. Fique atento a mais recomendações de outros mantenedores da estrutura de agente e para saber se os pesquisadores publicam detalhes técnicos mais completos após a apresentação do Black Hat. Casos adicionais confirmados fortaleceriam o argumento da CSA de que este é um padrão estrutural e não três erros coincidentes.
Terceiro, observe a resposta arquitetônica. A recomendação da CSA é exigir prova criptográfica de que uma chamada de ferramenta se originou da conclusão de um modelo real – um token único assinado, vinculado à sessão – em vez de inferir a autorização da estrutura da mensagem ou da identidade do processo. Se os principais fornecedores adotarem esse modelo, e se ele se tornar algo que os compradores possam solicitar e verificar durante a aquisição, determinará se esta divulgação altera os designs ou apenas produz patches. A lógica de processamento de confirmação que valida a propriedade da ferramenta, o requisito de confirmação e a integridade do argumento em relação à chamada gravada original é a versão mais restrita da mesma correção.
Por fim, observe as trilhas de governança e inteligência de ameaças. A CSA aponta sua estrutura de modelagem de ameaças MAESTRO e AI Controls Matrix v1.1 como locais onde as avaliações de controle de execução e gerenciamento de privilégios devem agora cobrir explicitamente o envio de ferramentas e conecta o CoreBreak à sua pesquisa anterior do GuardFall sobre desvios de proteção em nível de shell. Também vale a pena monitorar: se as entradas do NVD ou as pontuações do CVSS são revisadas, se os fornecedores publicam detalhes pós-incidente além dos boletins iniciais e se surge alguma exploração confirmada. Atualmente, nenhum dos quatro CVEs traz um relatório público de abuso em estado selvagem no material citado pela CSA, e a ausência de tais relatórios não é o mesmo que ausência de atividade.
