Falhas no software da NASA permitem enviar comandos a espaçonaves sem autenticação
Pesquisadores de segurança da Cycode identificaram uma cadeia de vulnerabilidades no AIT-GUI, console web integrado ao AMMOS Instrument Toolkit (AIT), projeto de código aberto desenvolvido pela NASA e pelo Jet Propulsion Laboratory (JPL). Os problemas poderiam permitir que um invasor com acesso ao serviço enviasse comandos arbitrários a instrumentos e sistemas de espaçonaves sem apresentar credenciais.
A falha foi registrada sob o identificador GHSA-p9r8-2q67-fp86 e recebeu nota 9,4 no CVSS v3.1, classificação considerada crítica. O alerta divulgado em 13 de agosto de 2026 aponta que o problema afeta a versão 2.5.1 e edições anteriores do AIT-GUI. A versão 2.5.2 foi lançada como correção, mas avaliações posteriores indicaram que a atualização não elimina completamente a ausência de autenticação.
O AMMOS Instrument Toolkit reúne componentes usados na criação de sistemas terrestres capazes de operar instrumentos, enviar instruções a espaçonaves e processar dados de telemetria. Dentro dessa arquitetura, o AIT-GUI funciona como uma interface de operação baseada na web. Algumas de suas rotas possuem acesso direto ao barramento de comandos, o que transforma qualquer falha de controle de acesso em um risco potencialmente grave.
Serviço exposto e rotas sem proteção
Segundo a análise da Cycode, o servidor web do AIT-GUI não respeitava corretamente o endereço de host configurado pelo administrador. Como resultado, o serviço permanecia ouvindo, por padrão, em `0.0.0.0`, na porta 8080. Essa configuração faz com que a aplicação aceite conexões por todas as interfaces de rede disponíveis, ampliando sua exposição.
Além disso, endpoints capazes de modificar o estado do sistema estavam disponíveis sem autenticação, autorização adequada ou mecanismos efetivos de defesa contra Cross-Site Request Forgery, conhecido pela sigla CSRF. Entre as rotas afetadas estavam funções relacionadas ao envio de comandos, à execução de scripts e ao disparo de sequências operacionais.
Duas dessas rotas também montavam caminhos de arquivos com base em dados fornecidos pelo usuário sem validação suficiente. Esse comportamento poderia permitir que um invasor escapasse dos diretórios autorizados e acessasse arquivos localizados em outras partes do sistema.
As falhas foram associadas a três categorias conhecidas: CWE-306, que trata da ausência de autenticação em funções críticas; CWE-352, referente a ataques CSRF; e CWE-22, relacionada a path traversal, técnica usada para manipular caminhos e alcançar arquivos fora da área prevista.
Possibilidade de enviar comandos e executar scripts
Um atacante sem autenticação, desde que conseguisse alcançar a porta do serviço, poderia utilizar a rota `POST /cmd` para encaminhar comandos aos instrumentos conectados. A rota `POST /script/run` poderia ser explorada para executar scripts no servidor, enquanto `POST /seq` permitiria iniciar sequências de comandos.
Dependendo da versão instalada e da configuração do ambiente, a falha de path traversal também possibilitaria referenciar arquivos fora dos diretórios definidos pelos administradores. Em uma infraestrutura operacional, esse tipo de acesso poderia afetar tanto a execução de tarefas quanto a integridade de dados usados pelo sistema terrestre.
O risco não dependia necessariamente de uma instalação publicada diretamente na internet. A aplicação também poderia ser atacada em uma rede interna ou atrás de um firewall caso um operador autorizado acessasse uma página maliciosa enquanto estivesse conectado ao console.
Isso ocorre porque as rotas aceitavam requisições no formato `application/x-www-form-urlencoded`, classificadas pelos navegadores como solicitações simples. Nesses casos, o navegador pode enviar a requisição cross-origin sem realizar antes a verificação preliminar CORS, chamada preflight e normalmente feita por meio de uma requisição `OPTIONS`.
A Cycode afirmou ter confirmado esse comportamento em tráfego real de navegador. Os pedidos `POST` eram entregues e processados sem uma etapa anterior de validação, permitindo que uma página controlada por terceiros tentasse induzir o navegador de um operador a enviar comandos ao AIT-GUI.
O que mudou na versão 2.5.2
O AIT-GUI 2.5.2 foi disponibilizado em 12 de agosto com alterações destinadas a reduzir a superfície de ataque. A versão passou a respeitar o host definido na configuração e adotou `localhost` como valor padrão, diminuindo a possibilidade de exposição acidental em interfaces externas.
A atualização também acrescentou verificações de mesma origem para requisições dos métodos `POST`, `PUT`, `DELETE` e `PATCH`. Além disso, os caminhos utilizados pelas funções `/script/run` e `/seq` passaram a ser limitados aos diretórios previamente configurados.
Essas mudanças dificultam ataques originados de páginas maliciosas e reduzem o impacto de determinadas formas de path traversal. No entanto, elas não equivalem à implementação de uma autenticação completa.
Uma análise do código da versão 2.5.2 apontou que os endpoints responsáveis por comandos, scripts e sequências ainda não exigem credenciais válidas. A rota principal continua chamando `Sessions.create()` e entregando um cookie de sessão sem comprovar a identidade do usuário. Em seguida, as rotas protegidas aceitam solicitações que apresentem esse cookie.
Na prática, a atualização melhora o isolamento da aplicação, limita sua disponibilidade à interface configurada e dificulta requisições cross-origin feitas por navegadores. Porém, permanece uma deficiência estrutural: funções críticas ainda podem ser acessadas sem uma verdadeira camada de autenticação e autorização.
Divergências sobre as versões vulneráveis
Também existem inconsistências entre os registros de vulnerabilidades e as análises técnicas disponíveis. Um problema relacionado à falta de autenticação foi registrado como CVE-2026-60112 e recebeu pontuação 9,3 no CVSS v4.
Esse registro informa que as versões anteriores à 2.5.1 seriam vulneráveis e indica uma correção específica. Já a Cycode considera a própria 2.5.1 afetada e trata a 2.5.2 como versão corrigida, embora ressalve as limitações da atualização.
A inspeção do repositório sugere que a criação de sessões sem verificação de credenciais continua presente nas versões 2.5.1 e 2.5.2. Por isso, administradores não devem interpretar automaticamente a atualização como uma solução definitiva para o problema de controle de acesso.
Há divergências semelhantes em relação ao path traversal. Embora a versão 2.5.1 tenha sido usada para validar as descobertas, o código dessa edição já apresentava uma verificação para limitar os caminhos empregados pela rota `/script/run`. A ausência de uma restrição equivalente permanecia, entretanto, na função `/seq`.
Risco adicional na distribuição pelo PyPI
Outro fator que complica a correção é a diferença entre o código disponível no repositório e os pacotes publicados no PyPI. Em 20 de agosto, a versão mais recente do pacote `ait-gui` disponível na plataforma ainda era a 2.4.1, lançada 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 PyPI. Dessa forma, usuários que instalaram o software por meio do gerenciador de pacotes poderiam continuar executando uma edição antiga, mesmo acreditando estar protegidos pela versão corrigida.
O código da 2.4.1 mantinha o serviço vinculado a `0.0.0.0` e apresentava a construção de caminhos sem as restrições necessárias. Isso significa que a exposição pode variar conforme o método de instalação, a origem do pacote e os procedimentos adotados por cada equipe.
Medidas recomendadas para administradores
Enquanto a correção definitiva não estiver claramente distribuída e validada, o AIT-GUI deve ser tratado como um componente de alto risco. A primeira medida é impedir que a porta 8080 fique acessível pela internet ou por segmentos de rede que não sejam estritamente necessários.
Também é recomendável limitar o serviço a `localhost` ou a uma interface de gerenciamento isolada, aplicar regras de firewall e utilizar uma camada adicional de autenticação, como um proxy reverso com controle de identidade. Essas barreiras não substituem uma correção no código, mas reduzem significativamente a possibilidade de exploração remota.
As equipes devem revisar os registros de acesso, procurar requisições inesperadas às rotas `/cmd`, `/script/run` e `/seq` e verificar alterações em arquivos ou sequências operacionais. Em ambientes críticos, é importante manter uma separação rigorosa entre estações de operação, sistemas administrativos e redes com acesso à internet.
Outra providência essencial é confirmar a versão efetivamente instalada, e não apenas a versão indicada no repositório de desenvolvimento. O pacote utilizado pela aplicação deve ser conferido diretamente no ambiente de produção, incluindo sua origem, data de instalação e arquivos presentes.
Por fim, qualquer atualização deve ser testada em um ambiente controlado antes de ser aplicada a sistemas operacionais. Mesmo mudanças voltadas à segurança podem alterar o comportamento de rotas, scripts, sequências e mecanismos de telemetria. A prioridade deve ser combinar atualização, restrição de rede, autenticação externa e monitoramento contínuo até que todos os endpoints críticos exijam credenciais e permissões verificadas.