Falhas no software da NASA permitem enviar comandos a espaçonaves sem autenticação
Pesquisadores de segurança identificaram uma cadeia de vulnerabilidades no AIT-GUI, console web utilizado pelo AMMOS Instrument Toolkit (AIT), projeto de código aberto desenvolvido pela NASA e pelo Laboratório de Propulsão a Jato (JPL). As falhas podem permitir que invasores com acesso à interface enviem comandos arbitrários a instrumentos e sistemas de espaçonaves sem apresentar credenciais válidas.
O conjunto de problemas foi registrado como GHSA-p9r8-2q67-fp86 e recebeu nota 9,4 no CVSS v3.1, classificação considerada crítica. O alerta, publicado em 13 de agosto de 2026, aponta que o AIT-GUI 2.5.1 e versões anteriores estão entre as edições afetadas. A versão 2.5.2 foi liberada como tentativa de correção, mas avaliações posteriores indicaram que a atualização não resolve completamente a falta de autenticação.
O AMMOS Instrument Toolkit reúne componentes usados na construção de sistemas terrestres responsáveis por controlar instrumentos, transmitir instruções a espaçonaves e processar dados de telemetria. Dentro dessa arquitetura, o AIT-GUI funciona como um painel operacional baseado na web. Entre suas funções estão rotas capazes de encaminhar comandos diretamente ao barramento de controle.
Interface exposta em todas as interfaces de rede
Uma das falhas estava relacionada ao modo como o servidor web era iniciado. O AIT-GUI ignorava o endereço de host definido na configuração e, por padrão, escutava em `0.0.0.0`, na porta 8080. Isso fazia com que o serviço aceitasse conexões por todas as interfaces de rede disponíveis, aumentando consideravelmente a possibilidade de exposição acidental.
Além disso, funções capazes de modificar o estado do sistema estavam disponíveis sem autenticação, autorização adequada ou proteção contra falsificação de requisições entre sites, conhecida como CSRF. Dessa forma, o acesso à porta do serviço poderia ser suficiente para tentar executar operações sensíveis.
Duas rotas também montavam caminhos de arquivos a partir de dados fornecidos pelo usuário sem validação consistente. Essa condição poderia permitir o acesso a arquivos fora dos diretórios esperados, característica associada a ataques de path traversal.
Os problemas foram associados a três categorias de falhas: CWE-306, que trata da ausência de autenticação em funções críticas; CWE-352, referente a CSRF; e CWE-22, relacionada à travessia de diretórios.
Rotas permitiam comandos, scripts e sequências
Segundo a análise de segurança, um invasor capaz de alcançar o serviço poderia enviar requisições para diferentes endpoints do AIT-GUI. A rota `POST /cmd` poderia ser usada para encaminhar comandos a instrumentos e espaçonaves. Já `POST /script/run` permitiria executar scripts no servidor, enquanto `POST /seq` poderia iniciar sequências de instruções.
Em determinadas versões, a manipulação inadequada de caminhos também poderia permitir a referência a arquivos localizados fora das pastas previamente definidas pelo administrador. O impacto exato dependeria da configuração do ambiente e das permissões atribuídas ao processo que executava o console.
A gravidade do cenário não depende exclusivamente de uma instalação diretamente acessível pela internet. O AIT-GUI aceitava requisições no formato `application/x-www-form-urlencoded`, consideradas simples pelos navegadores. Por esse motivo, uma página maliciosa poderia enviar uma requisição de outro domínio sem necessariamente provocar a etapa preliminar de verificação CORS, conhecida como preflight.
Risco também existe em redes internas
Na prática, uma instalação protegida por firewall ou limitada à rede local ainda poderia estar vulnerável. Bastaria que um operador autorizado acessasse o console e, posteriormente, visitasse uma página preparada para disparar requisições contra o serviço interno.
A análise indicou que requisições POST eram efetivamente entregues e processadas pelo navegador sem uma solicitação `OPTIONS` anterior. Isso amplia o risco de ataques indiretos, especialmente em ambientes onde operadores utilizam a mesma estação para acessar sistemas de controle e navegar na internet.
Esse tipo de ameaça é particularmente preocupante em sistemas operacionais críticos. Mesmo quando o atacante não obtém controle total do servidor, a capacidade de emitir comandos indevidos pode interromper operações, alterar configurações de instrumentos, provocar perda de dados ou afetar uma missão em andamento.
O que mudou na versão 2.5.2
O AIT-GUI 2.5.2 foi lançado em 12 de agosto com alterações destinadas a reduzir a superfície de ataque. A atualização passou a respeitar o host configurado pelo administrador e adotou `localhost` como valor padrão, diminuindo a exposição automática do serviço.
A nova versão também acrescentou verificações de mesma origem para requisições dos métodos POST, PUT, DELETE e PATCH. Outra mudança restringiu os caminhos utilizados pelas rotas `/script/run` e `/seq` aos diretórios definidos na configuração.
Essas medidas dificultam ataques originados de páginas maliciosas e reduzem o risco de acesso a arquivos fora das pastas autorizadas. Entretanto, elas não equivalem à implantação de autenticação real.
Correção não elimina a ausência de credenciais
Uma inspeção do código da versão 2.5.2 identificou que os endpoints mais sensíveis continuam sem exigir credenciais de forma efetiva. A rota principal ainda chama `Sessions.create()` e entrega um cookie de sessão sem comprovar a identidade do usuário.
Depois disso, a rota de comandos aceita requisições que apresentem o cookie gerado. Em outras palavras, a aplicação mantém um mecanismo de sessão, mas não garante que a sessão tenha sido criada após uma autenticação válida.
A atualização, portanto, limita a exposição da interface, bloqueia parte dos ataques cross-origin feitos por navegadores e restringe a manipulação de caminhos. Contudo, comandos, scripts e sequências continuam sem uma barreira de autenticação adequada, segundo a análise do código.
Divergências entre os registros de vulnerabilidade
Também existem inconsistências sobre quais versões devem ser consideradas corrigidas. Uma falha relacionada à ausência de autenticação foi registrada como CVE-2026-60112 e recebeu pontuação 9,3 no CVSS v4.
Esse registro informa que versões anteriores à 2.5.1 seriam vulneráveis e aponta uma correção específica. Já a análise da Cycode inclui a própria 2.5.1 entre as versões afetadas e trata a 2.5.2 como corrigida em relação à cadeia de problemas identificada.
A inspeção do repositório, porém, sugere que a criação de sessões sem autenticação continua presente tanto na 2.5.1 quanto na 2.5.2. Isso cria uma diferença importante entre a descrição formal da correção e o comportamento observado no código.
Há ainda divergências sobre o path traversal. Embora a versão 2.5.1 tenha sido utilizada para validar as descobertas, ela já continha uma verificação de caminhos na função `/script/run`. A ausência dessa restrição permanecia, entretanto, na rota `/seq`.
Pacote distribuído pelo PyPI estava desatualizado
Outro ponto de atenção envolve a distribuição do AIT-GUI pelo PyPI. Em 20 de agosto, a versão mais recente do pacote disponível na plataforma ainda era a 2.4.1, publicada em julho de 2023.
As versões 2.5.0, 2.5.1 e 2.5.2 não apareciam no histórico de releases do pacote. O código da edição 2.4.1 continha tanto a configuração que fazia o serviço escutar em `0.0.0.0` quanto a construção de caminhos sem as restrições necessárias.
Essa diferença entre o código do repositório e o pacote efetivamente distribuído pode levar administradores a acreditar que instalaram uma versão corrigida quando, na realidade, continuam utilizando uma edição antiga e vulnerável.
Medidas recomendadas para administradores
Enquanto não houver confirmação de uma correção completa, o AIT-GUI não deve ser exposto diretamente à internet. O serviço precisa ficar restrito a uma rede de gerenciamento isolada, com regras de firewall limitando o acesso apenas a operadores e sistemas que realmente necessitem da interface.
Também é recomendável utilizar uma camada adicional de autenticação, como um proxy reverso com controle de identidade, VPN corporativa ou mecanismo de acesso baseado em certificados. Essa proteção deve ser aplicada antes que as requisições alcancem os endpoints de comandos e scripts.
Administradores devem revisar os logs em busca de chamadas incomuns para `/cmd`, `/script/run` e `/seq`, além de verificar tentativas de acesso a caminhos fora dos diretórios autorizados. Alterações inesperadas em sequências de comandos, execução de scripts ou sessões criadas sem identificação clara também merecem investigação.
Por fim, é importante confirmar a versão instalada diretamente no ambiente de produção e não apenas consultar o repositório do projeto. A defasagem observada no pacote do PyPI demonstra que diferentes canais de distribuição podem apresentar versões distintas, dificultando a aplicação correta das correções.