Falha crítica no Marimo permite shell remoto sem autenticação

A vulnerabilidade CVE-2026-39987 expõe o endpoint WebSocket de terminal do notebook Python Marimo, permitindo execução remota de comandos antes da autenticação e já foi explorada para roubo de credenciais e implantação de variante do NKAbuse.

Componente	Endpoint WebSocket /terminal/ws do Marimo, notebook Python de código aberto para ciência de dados e análise.
Vetor	Conexão WebSocket não autenticada ao terminal exposto, porque o endpoint valida modo de execução e suporte da plataforma, mas não executa validate_auth().
Impacto	Execução remota de comandos pré-autenticação com obtenção de shell PTY interativo completo em instâncias Marimo acessíveis pela rede.
Prioridade	Atualizar para Marimo 0.23.0, remover exposição direta do terminal, revisar segredos em .env, chaves SSH e tokens acessíveis no ambiente.
Versões	Todas as versões do Marimo até 0.20.4, inclusive, são indicadas como afetadas; a correção foi publicada na versão 0.23.0.
Exploração	A primeira tentativa observada ocorreu 9 horas e 41 minutos após a divulgação pública, sem PoC pública disponível naquele momento.
Artefatos	Atividade posterior incluiu dropper hospedado em espaço Hugging Face chamado vsccode-modetx e binário Go ELF chamado kagent, associado a variante do NKAbuse.
IoC	Um padrão operacional citado originou-se de 38.147.173[.]172; demais indicadores devem ser tratados por classe, como conexões ao endpoint vulnerável, criação de persistência e tráfego P2P NKN.

Resumo técnico

A CVE-2026-39987 é uma vulnerabilidade crítica de execução remota de código no Marimo, plataforma de notebook Python usada em fluxos de ciência de dados e análise. O problema está no endpoint WebSocket /terminal/ws, responsável por fornecer acesso de terminal. Diferentemente de outros endpoints WebSocket do mesmo produto, esse caminho aceita conexões depois de verificar apenas o modo de execução e o suporte da plataforma, sem passar pela validação de autenticação. Em uma instância exposta, essa diferença de controle permite que um invasor estabeleça um shell PTY interativo completo antes de apresentar credenciais.

O impacto é direto: a superfície vulnerável não exige conta válida, sessão existente nem token conhecido quando o terminal está acessível. O atacante pode executar comandos no contexto do processo e do usuário que executa o Marimo, observar arquivos locais, procurar segredos e interagir manualmente com o ambiente. A falha recebeu CVSS 9.3, afeta todas as versões até 0.20.4 inclusive e foi corrigida no Marimo 0.23.0. A janela entre divulgação e exploração foi extremamente curta, com tentativa observada 9 horas e 41 minutos após a publicação pública, ainda sem código de prova de conceito disponível.

Fluxo técnico

O fluxo de exploração começa com a identificação de uma instância Marimo acessível pela rede e com o endpoint /terminal/ws alcançável. Como a falha está na ausência de chamada a validate_auth(), a conexão WebSocket ao terminal não segue o mesmo caminho de autenticação aplicado a outros endpoints, como /ws. Depois de aceita, a sessão entrega ao operador um terminal interativo, o que elimina a necessidade de encadear uma segunda falha para executar comandos no sistema. A exploração descrita no contexto não depende de credenciais, mas depende de exposição do serviço e da presença do endpoint vulnerável.

A primeira atividade observada em ambiente honeypot foi manual. O operador conectou-se ao WebSocket de terminal, fez reconhecimento do sistema de arquivos e, em poucos minutos, procurou dados em arquivo .env, chaves SSH e outros arquivos potencialmente sensíveis. Cerca de uma hora depois, retornou para acessar novamente o conteúdo do .env e verificar se outros operadores estavam ativos na mesma janela. Nesse primeiro padrão, não houve instalação observada de minerador de criptomoedas, backdoor ou outro payload persistente, o que sugere foco inicial em coleta de credenciais e validação do ambiente comprometido.

A exploração evoluiu depois para implantação de malware. Entre 11 e 14 de abril de 2026 foram registrados 662 eventos de exploração contra a vulnerabilidade, originados de 11 endereços IP únicos distribuídos por 10 países. Um dos padrões operacionais partiu de 38.147.173[.]172 e usou um comando de download omitido para obter um script hospedado em um espaço Hugging Face chamado vsccode-modetx. O script atuava como dropper para lançar um binário chamado kagent, nome escolhido para se confundir com um framework legítimo de agente de inteligência artificial para Kubernetes.

O binário kagent é descrito como um ELF escrito em Go e como variante anteriormente não documentada do NKAbuse. A ameaça abusa do protocolo descentralizado NKN para comando e controle, usando infraestrutura P2P em vez de um ponto central tradicional. Além de capacidades associadas a DDoS, a variante analisada inclui mecanismos de execução remota e acesso, funcionamento como proxy sofisticado e suporte a protocolos como WebRTC e STUN. A persistência observada cobre Linux e macOS, com serviço de usuário systemd, tarefa agendada via crontab e LaunchAgent no macOS, além de encerramento de instâncias existentes chamadas kagent antes da implantação.

Superfície afetada

A superfície mais crítica envolve instâncias Marimo expostas à internet, a redes corporativas amplas, a ambientes de laboratório compartilhados ou a estáções de trabalho de cientistas de dados que executam notebooks com acesso a arquivos locais. Embora notebooks sejam frequentemente tratados como ferramentas de produtividade, eles costumam concentrar credenciais de nuvem, tokens de API, chaves SSH, variáveis de ambiente, dados de experimentos, acesso a repositórios e rotas internas. Quando o terminal do notebook entrega um shell sem autenticação, o impacto fica próximo ao de uma sessão local do usuário que iniciou o processo.

Ambientes de desenvolvimento e análise são especialmente sensíveis porque tendem a misturar código, segredos operacionais e conectividade interna. Um arquivo .env pode conter chaves de serviços, strings de conexão, tokens de provedores de nuvem ou credenciais de banco. Chaves SSH podem permitir acesso a repositórios, bastions ou hosts internos, dependendo da configuração. O risco confirmado no contexto é execução de comandos e coleta de credenciais no ambiente acessível; qualquer consequência posterior, como acesso a outros sistemas, depende dos segredos encontrados, permissões do usuário e segmentação de rede existente.

A inclusão da CVE-2026-39987 no catálogo KEV da CISA em 23 de abril de 2026 reforça que a falha estava sendo explorada de forma conhecida. Agências civis federais dos Estados Unidos receberam prazo até 7 de maio de 2026 para remediação. Para organizações fora desse escopo, a relevância operacional vem da velocidade de exploração: aplicações de nicho, quando expostas e acompanhadas de um aviso técnico claro, também entram rapidamente na fila de operadores.

• Instâncias Marimo até 0.20.4, inclusive, quando o endpoint /terminal/ws está acessível.
• Estáções de trabalho e servidores de notebook com arquivos .env, chaves SSH, tokens de API ou credenciais de nuvem no mesmo contexto de usuário.
• Ambientes Linux e macOS onde o payload kagent pode tentar persistência por systemd, crontab ou LaunchAgent.
• Redes em que notebooks de análise tenham alcance a serviços internos, repositórios ou infraestrutura de cloud.

Hunting e telemetria

A investigação deve começar por acessos ao endpoint /terminal/ws, especialmente conexões WebSocket sem sessão autenticada correspondente, origem externa inesperada ou sequência de sessões curtas com intervalos. Em proxies, balanceadores e logs de aplicação, a diferença importante é a presença de conexões ao terminal sem o mesmo contexto de autenticação que aparece em outros endpoints. Como a exploração pode ser manual, a telemetria pode mostrar navegação por diretórios, leitura de arquivos de configuração e consultas repetidas a caminhos de credenciais em vez de uma cadeia automatizada extensa.

No endpoint, os sinais principais são acesso a .env, buscas por chaves SSH, leitura de arquivos sensíveis pelo usuário do processo Marimo e criação de mecanismos de persistência. A variante NKAbuse descrita usa o nome kagent, portanto a defesa deve correlacionar novos binários com esse nome, encerramento de processos homônimos, serviços de usuário recém-criados, entradas de crontab e LaunchAgents fora do padrão. Como o malware usa NKN e capacidade de proxy com WebRTC e STUN, tráfego P2P incomum, conexões relacionadas a negociação de conectividade e comportamento de proxy em host de notebook merecem análise.

A telemetria de rede deve tratar indicadores pontuais como apoio, não como única detecção. O endereço 38.147.173[.]172 aparece em um padrão operacional, mas a campanha também envolveu múltiplas origens em países diferentes. A abordagem mais robusta é procurar classes de comportamento: exploração do WebSocket vulnerável, download de script de origem incomum, execução de binário Go ELF novo, persistência em múltiplos mecanismos e conexões P2P após comprometimento. Em ambientes com EDR, a linha de investigação deve conectar o processo Marimo aos processos filhos e às leituras de arquivos sensíveis.

• Conexões WebSocket para /terminal/ws sem evento de autenticação associado ou vindas de endereços externos inesperados.
• Processos filhos originados do Marimo executando enumeração de diretórios, leitura de .env ou acesso a diretórios de chaves SSH.
• Criação de serviço de usuário systemd, entrada de crontab ou LaunchAgent associada a binário chamado kagent.
• Execução de binário Go ELF novo em host de notebook, seguida de tráfego P2P NKN, WebRTC ou STUN incomum.
• Múltiplas sessões curtas no mesmo host em janela de aproximadamente 90 minutos, com retorno para confirmar arquivos ou atividade concorrente.

Mitigação

A ação principal é atualizar o Marimo para 0.23.0 ou versão posterior corrigida, priorizando qualquer instância acessível por usuários externos, redes compartilhadas ou ambientes de desenvolvimento com segredos locais. Até a atualização ser validada, o endpoint de terminal não deve ficar exposto diretamente. Controles compensatórios incluem bloqueio de acesso ao serviço em firewall ou proxy, exigência de autenticação antes de qualquer rota de notebook, restrição por VPN ou rede administrativa e desativação de exposição pública de ambientes de análise que não foram projetados como serviços de produção.

Depois da correção, a resposta deve assumir que instâncias expostas podem ter sido acessadas dentro de poucas horas da divulgação. A revisão precisa cobrir arquivos .env, chaves SSH, tokens de API, credenciais de cloud e qualquer segredo lido pelo usuário que executava o Marimo. Quando houver evidência de acesso ao terminal vulnerável, segredos presentes no host devem ser rotacionados conforme escopo, e chaves SSH devem ser avaliadas por uso recente, permissões e presença em repositórios ou hosts internos. A mitigação não termina na atualização, porque a falha entrega shell e pode ter permitido coleta silenciosa antes da aplicação do patch.

Para hosts com sinais de kagent ou NKAbuse, a contenção deve isolar o sistema, coletar artefatos voláteis conforme o procedimento interno e remover persistências identificadas somente depois de preservar evidências necessárias. Equipes devem revisar serviços de usuário, crontabs, LaunchAgents, binários recém-criados e conexões P2P. Também é recomendável revisar políticas de execução em estáções de ciência de dados, separação de segredos de notebooks, uso de identidades de menor privilégio e segmentação de rede para impedir que uma ferramenta de análise comprometida se torne ponte para recursos internos.

• Atualizar Marimo para 0.23.0 e confirmar que não existem instâncias antigas até 0.20.4 expostas.
• Bloquear acesso externo ao /terminal/ws e exigir controle de autenticação antes de qualquer funcionalidade de terminal.
• Rotacionar tokens, chaves SSH e credenciais de cloud presentes em hosts com evidência de exploração.
• Procurar e remover, após coleta de evidências, persistência por systemd, crontab e LaunchAgent relacionada a kagent.
• Revisar notebooks de desenvolvimento para reduzir segredos locais, limitar permissões do usuário de execução e segmentar acesso a recursos internos.