CVE-2026-18953: O Transform MCP Server da AWS não tinha limite de escrita

A Amazon publicou o boletim de segurança 2026-075-AWS em 5 de agosto de 2026 referente à CVE-2026-18953, uma travessia de caminho na get_resource, ferramenta do awslabs.aws-transform-mcp-server, o servidor de código aberto do Model Context Protocol que é executado na própria máquina de um desenvolvedor para que um assistente de IA possa conduzir jobs do AWS Transform e recuperar seus artefatos. As versões 0.1.0 a 0.1.4 não restringiam adequadamente os nomes de caminho, e o savePath parâmetro poderia gravar arquivos fora do diretório de trabalho pretendido — o que o aviso do GitHub no repositório da Amazon diz que "poderia levar à execução local de código". A Amazon atribuiu-lhe 8,6, Alta. A correção é a versão 0.1.5, e não há solução alternativa apenas do lado do servidor ou somente de configuração, porque o caminho de código vulnerável está presente na configuração padrão. Nenhuma fonte pública registrou que alguém o tenha explorado. O registro completo, com suas notas de gravidade e confiança, está no Orca AI Incident Archive juntamente com os incidentes de MCP e de runtime de agentes registrados no mesmo mês.

Um servidor MCP que escreve onde o desenvolvedor trabalha

Os servidores do Model Context Protocol são a camada que fornece ao assistente ferramentas invocáveis, e este é deliberadamente local. O boletim da Amazon o descreve como “um servidor MCP de código aberto que é executado localmente na máquina de um desenvolvedor e permite que assistentes com IA interajam com o AWS Transform para executar trabalhos de transformação de código e recuperar seus artefatos”. A descrição do pacote no Python Package Index diz que ele expõe o ciclo de vida do Transform por meio de 19 ferramentas, gerenciando espaços de trabalho de transformação, trabalhos, conectores, tarefas com intervenção humana, artefatos e chat, e abrange modernização de mainframe, migração de VMware, modernização de .NET e transformações de código personalizadas.

É esse posicionamento que dá importância à falha. Um servidor na infraestrutura do próprio fornecedor que lida incorretamente com um nome de arquivo corrompe o armazenamento do fornecedor. Este rodava como o desenvolvedor, no diretório home do desenvolvedor, ao lado da configuração de shell e das chaves SSH dele, e o impacto que a Amazon descreve não é um download corrompido, mas sim "execução local de código". Toda pontuação atribuída ao CVE concorda em um ponto: o vetor de ataque é local, não de rede.

A ferramenta citada no alerta é a que traz um artefato de job para o disco. get_resource recebe um savePath que indica onde o arquivo deve ser gravado. O bug é que nada impedia que esse caminho apontasse para outro lugar.

Quão ruim, e pela aritmética de quem?

Três pontuações estão associadas a este CVE e não coincidem. A Amazon, que atribuiu o CVE como autoridade de numeração, pontua-o com 8,6 Alta no CVSS v3.1 com o vetor CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — local, baixa complexidade, sem privilégios exigidos, interação do usuário exigida, escopo alterado, alto impacto na confidencialidade, integridade e disponibilidade. A entrada do NIST no National Vulnerability Database traz sua própria pontuação primária v3.1 de 8,8 em um vetor diferente, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: privilégios baixos exigidos, sem interação do usuário. Ambas ficam na faixa Alta. A divergência diz respeito às precondições — se o ator já precisa de um ponto de apoio e se um humano precisa ser persuadido —, e não ao quão ruim é o resultado.

A pontuação CVSS v4.0 da Amazon para o mesmo CVE é 6,3, Médio, em CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H. Leia as métricas de impacto: nada no próprio sistema vulnerável, tudo alto no sistema subsequente. Essa é a forma de uma travessia que rompe os limites da própria ferramenta — o dano é causado a tudo o que a ferramenta consegue alcançar, então fica na coluna do subsistema e o sistema vulnerável pontua zero.

O enriquecimento do CVE pela CISA, datado de 6 de agosto de 2026, registra uma decisão SSVC de Exploração: nenhuma, Automatizável: não, Impacto Técnico: total. O registro do NVD foi modificado pela última vez em 23 de outubro de 2026 e ainda traz tanto o 8,6 quanto o 8,8 lado a lado. Nenhum dos dois documentos trata o outro como incorreto.

O que o código vulnerável fazia e o que a versão 0.1.5 alterou

A descrição da Amazon sobre o mecanismo é uma única frase e é cuidadosa: a ferramenta "não restringiu adequadamente os nomes de caminho", o que poderia permitir que "um agente dependente de contexto" "gravasse arquivos arbitrários fora do diretório de trabalho pretendido por meio do parâmetro savePath". O aviso não define o agente, não diz o que dispara a gravação e não descreve como seria uma exploração bem-sucedida. Diz apenas que o resultado "poderia levar à execução local de código".

O relato público mais detalhado do mecanismo não é o da Amazon. Trata-se de um pequeno repositório de prova de conceito, ronamosa/CVE-2026-18953, publicado no GitHub em 8 de agosto de 2026 sob a licença Apache-2.0 — dois commits, sem estrelas nem forks no momento da redação —, que incorpora cópias literais do file_validation.py vulnerável e corrigido e executa ambos com as mesmas entradas.

Sua leitura da 0.1.4 é esta: validate_write_path() resolveu savePath com realpath e expanduser, rejeitou uma curta lista de locais negados (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd) e removeu os componentes de diretório do nome de arquivo fornecido. Nunca confinou o caminho resolvido a qualquer diretório base ou de trabalho. Uma lista de bloqueio de nomes de arquivo sensíveis — .bashrc, .zshrc, authorized_keys, id_rsa — era aplicada nas leituras, mas não nas gravações.

O repositório demonstra três gravações que isto permite: um caminho absoluto que não precisa de travessia alguma, uma fuga relativa ../../ e um nome de arquivo oculto que o caminho de leitura teria recusado. Todas as três ficam dentro de um diretório temporário criado pelo script, e sua saída de exemplo mostra dropped_by_absolute_path.sh, dropped_by_traversal.sh e um .bashrc sob um diretório home de fachada; o diretório home real nunca é tocado. A versão 0.1.5 adiciona o limite ausente: um diretório base obtido de $AWS_TRANSFORM_MCP_WRITE_DIR ou do diretório de trabalho inicial do servidor, abaixo do qual toda gravação resolvida deve ficar, além da lista de bloqueio de nomes de arquivo aplicada ao caminho de gravação resolvido final. O validador corrigido gera "Write path must be within the working directory" para todas as três.

Nenhum desses detalhes aparece no comunicado de segurança, e o repositório não afirma que isso veio de lá. Considere a lista de bloqueio, a verificação de nome de arquivo somente leitura e a correção do diretório base como uma reconstrução a partir do código-fonte, e não como uma segunda constatação oficial. O que o repositório acrescenta além do comunicado é um relato de quem pode fornecer o caminho: como a função do servidor é trazer conteúdo de jobs e tarefas para o contexto de um assistente, a parte que escolhe savePath não precisa ser a pessoa que está no teclado. Um assistente conduzido por conteúdo não confiável que ele buscou por meio da mesma ferramenta pode tomar essa decisão. Esse é o argumento do repositório a partir do código e do design da ferramenta, não uma afirmação feita pela Amazon; o "ator dependente de contexto" indefinido da Amazon é consistente com isso e não vai além disso.

Sete semanas entre a correção e o boletim

A correção não chegou com o anúncio. O histórico de versões do Python Package Index — metadados de origem própria do registro pelo qual o pacote é distribuído — registra a 0.1.4 em 20 de maio de 2026 e a 0.1.5 em 17 de junho de 2026, sete semanas antes de o boletim 2026-075 ser publicado em 5 de agosto. Não existe nenhum arquivo 0.1.0 no índice; o artefato publicado mais antigo dentro do intervalo afetado é a 0.1.1, enviada em 9 de maio de 2026. Um desenvolvedor que instalasse a partir do índice só poderia, portanto, ter recebido uma build vulnerável entre 9 de maio e 17 de junho, e qualquer pessoa que acompanhasse as versões já estava com código corrigido em meados de junho.

A Amazon não informa quando soube do problema, quando o relatório chegou, nem por que a versão que o encerrou foi publicada. A única pessoa nomeada no registro é Drew Raines, agradecido tanto no boletim quanto no aviso do GitHub "por colaborar neste problema por meio do processo coordenado de divulgação do problema". O GHSA-66mr-jr63-2jgw foi publicado no repositório awslabs/mcp da Amazon em 5 de agosto de 2026, no mesmo dia que o boletim; o registro CVE foi reservado às 13:44 UTC e publicado às 19:33 UTC daquele dia.

Portanto, a data da correção está estabelecida, e o motivo dela não está. Uma versão corrigida disponível no registro sete semanas antes do aviso é compatível com uma correção silenciosa seguida de uma divulgação coordenada — mas isso é uma inferência a partir de dois carimbos de data e hora, e nenhum dos dois documentos afirma isso.

O que o registro estabelece, e o que não estabelece

O arquivo classifica esta entrada como A — bem documentada, as fontes primárias concordam — e não a marca como disputada. Ele a registra como um registro de pesquisa, uma constatação de vulnerabilidade e não um incidente de implantação, sem dano real registrado. A nota diz respeito à qualidade da documentação e, com base nas evidências revisadas, ela se sustenta: o boletim, o aviso do GitHub e o registro CVE são três documentos publicados pela Amazon que concordam quanto ao produto, às versões, à correção e ao crédito.

• Confirmado. A Amazon publicou o boletim 2026-075-AWS em 5 de agosto de 2026, abrangendo CVE-2026-18953, uma travessia de caminho CWE-22 no tratamento do get_resource de savePath no awslabs.aws-transform-mcp-server 0.1.0 até 0.1.4, corrigida na 0.1.5, sem solução alternativa apenas no lado do servidor ou apenas de configuração porque o caminho vulnerável está na configuração padrão.

• Estabelecido. As pontuações e sua divergência: 8,6 Alto pela Amazon como autoridade de numeração CVE, 8,8 Alto pelo NIST como pontuação primária do NVD, 6,3 Médio no CVSS v4.0, e a decisão SSVC de 6 de agosto da CISA de que nenhuma exploração e nenhum caminho automatizável haviam sido observados.

• Estabelecido. As datas de lançamento no Python Package Index, e o crédito a Drew Raines pela divulgação coordenada.

• Inferido a partir do código-fonte, por um terceiro. A lista de negação, a lista de bloqueio de nomes de arquivo somente leitura, o diretório base ausente e a _ALLOWED_WRITE_BASE correção — todos eles vêm do repositório de prova de conceito ronamosa, cujas cópias incorporadas das duas versões do validador qualquer pessoa pode comparar.

• Inferido com base nos carimbos de data/hora e no design. Que a 0.1.5 foi um lançamento de segurança deliberado, e que um assistente conduzido por conteúdo não confiável poderia fornecer o caminho hostil. A Amazon não afirma nenhuma das duas coisas.

• Não estabelecido.Qualquer exploração em ambiente real. A indicação "Exploitation: none" da CISA está datada de 6 de agosto, dois dias antes de surgir a prova de conceito pública, portanto, refere-se a esse momento e não a nada posterior. Não foi publicado nenhum número de usuários afetados, notificação aos clientes ou telemetria.

• Não estabelecido.Reportagem independente. Nenhum veículo de comunicação de grande porte parece ter coberto esta CVE. O registro público é composto pelos três documentos da Amazon, pelos enriquecimentos do NIST e da CISA sobre eles, por páginas de rastreadores que reafirmam o registro e pelo único pequeno repositório de prova de conceito descrito acima.

O que mudou e o que verificar

A solução da Amazon é um aumento de versão e nada mais: atualize para a 0.1.5 ou posterior e “garanta que qualquer código bifurcado ou derivado seja corrigido para incorporar as novas correções”. A segunda cláusula é a que se aplica além do original. O servidor é open source, e um fork que vendorizou o validador 0.1.4 herda a falha sem herdar o aviso; o boletim pede aos operadores de código derivado que incorporem a mudança nele, ou seja, a versão upstream não chega a uma cópia mantida por outra pessoa.

O repositório de prova de conceito sugere algo que o comunicado de segurança se recusa a sugerir. Segundo ele, operadores que não puderem atualizar imediatamente devem executar o servidor com seu diretório de trabalho definido para um diretório vazio dedicado e tratar qualquer arquivo no qual ele consiga gravar como comprometido. A posição da Amazon é mais rígida: não há qualquer solução alternativa apenas no lado do servidor ou apenas na configuração. Segundo o próprio repositório, essa sugestão também é frágil, já que o código vulnerável nunca restringiu as gravações ao diretório de trabalho, para começar. Onde os dois divergem, prevalece a instrução do fornecedor de apenas atualizar.

O que há de útil neste registro não é a sua pontuação. É a sua forma: um servidor MCP local, um download de artefato com destino fornecido pelo chamador, e nenhuma fronteira entre os dois. A verificação que importa não é a data do boletim, mas a versão fixada — 0.1.5 ou posterior, e a mesma alteração levada para qualquer fork que tenha copiado o validador.