---
title: "Falhas no console da NASA podem permitir invasores darem ordens em espaçonaves"
author: "Gabriela P. Torres"
date: "2026-08-22 07:00:00-03"
category: "Segurança & Privacidade"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/08/22/falhas-no-console-da-nasa-podem-permitir-invasores-darem-ordens-em-espaconaves/md"
---

## Resumo
- Falhas no AIT-GUI permitiam que invasores não autenticados obtivessem sessões válidas.
- A vulnerabilidade podia levar ao envio de comandos arbitrários ao barramento de controle de espaçonaves.
- O problema afetava versões até a 2.5.1 do software usado pela NASA.
- A função Sessions.create() não verificava credenciais, segundo o registro CVE-2026-60112.
- Endpoints de mudança de estado não tinham autenticação, autorização nem proteção contra CSRF.
- A falha recebeu pontuação 9,4 no CVSS v3.1 e foi identificada como GHSA-p9r8-2q67-fp86.
- A NASA confirmou a correção na versão 2.5.2 e recomendou a atualização imediata.

---

Uma cadeia de falhas no **AIT-GUI**, console de solo usado para monitorar telemetria e controlar instrumentos e espaçonaves, permitia que um invasor não autenticado emitisse comandos arbitrários ao barramento de controle. Traduzindo o problema sem o verniz de um comunicado técnico: se o sistema aceitava criar uma sessão sem conferir credenciais, então o atacante podia avançar até a função responsável por enviar instruções; se também não havia autorização e proteção contra requisições forjadas, a barreira entre uma interface de monitoramento e o comando de uma espaçonave praticamente deixava de cumprir seu papel. A falha atingia versões até a **2.5.1** e foi corrigida pela NASA na versão **2.5.2**.

## O que o AIT-GUI fazia no controle terrestre

A primeira peça para entender o caso é separar o nome da ferramenta de sua função real. O **AIT-GUI** é a interface gráfica do AMMOS Instrument Toolkit, um software de código aberto usado pela NASA para monitoramento de telemetria, isto é, os dados enviados pelos instrumentos, além do controle de instrumentos e espaçonaves. O problema não estava em uma página meramente informativa: o sistema também tinha acesso ao barramento de comando, o canal pelo qual instruções podem ser encaminhadas ao equipamento controlado. O [relato técnico sobre o caso](https://thehackernews.com/2026/08/nasa-ait-gui-flaws-could-let.html) descreve justamente essa combinação entre acompanhamento operacional e capacidade de enviar comandos, ligação que transforma uma falha de acesso em um risco de controle.

Essa combinação explica por que a descrição da vulnerabilidade não deve ser reduzida a “um painel sem login”. O AIT-GUI concentrava funções de sessão, execução de scripts e envio de sequências de comando, de acordo com os pesquisadores. Uma sessão é o estado que identifica uma conexão ativa com o sistema; em condições normais, ela deveria nascer depois de uma verificação de identidade e permanecer limitada às permissões concedidas ao usuário. Quando essa sequência falha, o atacante não precisa necessariamente quebrar uma senha: ele tenta obter do próprio aplicativo uma sessão considerada válida e, a partir dela, alcançar operações que alteram o estado do sistema. É essa transição, da tela para a ação, que conduz ao próximo ponto da análise.

## A cadeia que levava da sessão ao comando

A primeira falha detalhada no registro **CVE-2026-60112** está na função **Sessions.create()**. Segundo o registro, essa função não realizava a verificação de credenciais, permitindo que um invasor obtivesse uma sessão válida. A lógica é quase forense: se criar uma sessão não exige provar quem está do outro lado, então a sessão deixa de ser evidência de identidade; se uma sessão válida pode chamar a função seguinte, a autenticação não está protegendo o fluxo completo, apenas aparentando existir na superfície. O caso é particularmente sensível porque a etapa posterior podia invocar **handle_cmd()**, função associada ao envio de comandos diretamente ao barramento de controle.

A segunda parte da cadeia aparece quando se observa o que o invasor conseguia fazer depois de entrar. As fontes descrevem a possibilidade de enviar **comandos arbitrários** ao barramento da espaçonave, além de executar scripts e sequências de comando no servidor. “Arbitrário”, aqui, não significa que toda instrução necessariamente seria aceita pelo equipamento, mas que o fluxo vulnerável não restringia adequadamente o conteúdo encaminhado antes de chegar à etapa de comando. O resultado prático descrito no alerta é direto: uma pessoa sem autenticação podia passar da obtenção de uma sessão à tentativa de manipular instrumentos ou espaçonaves por meio da interface comprometida. O [detalhamento da descoberta](https://www.infosecurity-magazine.com/news/nasa-ground-control-software-flaw/) ajuda a conectar essas etapas, em vez de tratá-las como falhas independentes.

## Por que a nota 9,4 não é um detalhe burocrático

Somada à ausência de autenticação, a falha envolvia endpoints de mudança de estado sem autenticação, autorização ou proteção contra **CSRF**. Endpoint é um endereço funcional que recebe uma solicitação do aplicativo; mudança de estado é qualquer operação que altera uma condição do sistema, como iniciar uma ação ou encaminhar um comando. Já CSRF, sigla para falsificação de requisição entre sites, descreve uma técnica na qual uma aplicação pode ser induzida a aceitar uma solicitação que o usuário não pretendia enviar. No AIT-GUI, a ausência dessas camadas significava que o sistema não conferia de modo adequado quem podia chamar determinadas operações nem se a solicitação era legítima. A falha foi catalogada como **GHSA-p9r8-2q67-fp86** e recebeu pontuação **9,4 no CVSS v3.1**.

Essa pontuação não substitui a leitura técnica, mas dá uma medida padronizada da gravidade atribuída ao problema. O ponto decisivo está na combinação documentada pelas fontes: falta de autenticação, ausência de autorização em operações de mudança de estado e possibilidade de executar scripts e sequências de comando. O alerta também registra que o servidor se vinculava incorretamente a **todas as interfaces de rede**, uma configuração que fazia parte do conjunto de problemas identificado pelos pesquisadores. Não é preciso acrescentar uma história de ataque que as fontes não descrevem; basta seguir a cadeia apresentada. Se uma interface capaz de controlar instrumentos aceita sessões sem credenciais e expõe operações de alteração, então o risco não é apenas de visualizar telemetria, mas de alcançar funções operacionais.

## A correção e o que precisa ser verificado

A correção anunciada pela NASA ocorreu na versão **2.5.2** do AIT-GUI, depois da identificação das falhas nas versões até 2.5.1. A confirmação veio por meio do **Jet Propulsion Laboratory**, o Laboratório de Propulsão a Jato da NASA, que confirmou a resolução do problema nessa atualização. A diferença entre 2.5.1 e 2.5.2 é pequena na numeração, mas não no procedimento: para quem administra o software, a versão instalada precisa ser conferida diretamente, porque a presença de uma interface funcionando não prova que os controles de acesso estejam corrigidos. O pacote atualizado é a resposta indicada pelas fontes para reduzir os riscos descritos de execução remota de código e manipulação de comandos.

Para equipes responsáveis por uma instalação do AIT-GUI, o primeiro passo prático é identificar se o ambiente ainda utiliza a versão **2.5.1 ou anterior**. Em seguida, a atualização para a 2.5.2 deve ser tratada como uma correção de segurança, não como uma melhoria opcional de interface. A verificação também precisa considerar as funções que criam sessões e encaminham comandos, porque o registro CVE aponta especificamente para **Sessions.create()** e para a chamada posterior de handle_cmd(). O objetivo não é decorar siglas, e sim conferir se a versão vulnerável continua presente no ponto em que o sistema recebe conexões e no ponto em que transforma uma solicitação em comando. Assim, a correção deixa de ser apenas um número no changelog e passa a ser uma ação verificável.

## O próximo passo para desbugar o alerta

O próximo passo anunciado é objetivo: atualizar o AIT-GUI para a **versão 2.5.2** e retirar das operações a versão até 2.5.1, que aparece nas fontes como afetada. O caso também deixa uma regra simples para qualquer software de controle: se uma sessão pode ser criada sem credenciais, então a autenticação não está protegendo a operação; se essa sessão alcança uma função de comando, então o administrador precisa tratar o caminho inteiro, não apenas a tela de login. A NASA confirmou a resolução por meio do JPL, enquanto o alerta de segurança recomenda a atualização imediata. A caixa de ferramentas, portanto, é curta e concreta: conferir a versão, aplicar a 2.5.2 e validar os pontos de sessão e comando antes de considerar o problema encerrado.