Ator desconhecido explorou CVE-2026-39987 em notebook Marimo exposto à internet, obteve credenciais em nuvem, recuperou chave SSH no AWS Secrets Manager e extraiu dados de PostgreSQL interno.
| Componente | Notebooks Marimo acessíveis pela internet em versões anteriores ou iguais a 0.20.4. |
| Vetor | Exploração pré-autenticada de CVE-2026-39987, permitindo execução de comandos de sistema sem credenciais válidas. |
| Impacto | Extração de duas credenciais em nuvem, recuperação de uma chave SSH no AWS Secrets Manager e cópia do esquema e do conteúdo completo de um banco PostgreSQL interno. |
| Prioridade | Atualizar Marimo para versão corrigida, remover instâncias públicas desnecessárias e rotacionar credenciais, chaves de API e chaves SSH expostas. |
| Versões | A vulnerabilidade afeta todas as versões do Marimo até 0.20.4; a correção foi disponibilizada na versão 0.23.0. |
| Artefatos | Foram observados uso de credenciais AWS, acesso ao AWS Secrets Manager, chave SSH privada, bastion SSH e banco PostgreSQL downstream. |
Um ator desconhecido explorou um notebook Marimo alcançável pela internet por meio de CVE-2026-39987, uma vulnerabilidade crítica de execução remota de comandos antes da autenticação. O caso é relevante não apenas pelo comprometimento inicial, mas pela forma como a atividade posterior foi conduzida: a sequência observada indica uso de um agente baseado em modelo de linguagem para adaptar comandos, interpretar resultados e avançar dentro do ambiente comprometido sem depender de um roteiro fixo.
A cadeia começou no host Marimo exposto, onde o invasor obteve duas credenciais em nuvem. Essas credenciais foram reutilizadas a partir de um conjunto distribuído de saídas de rede para consultar o AWS Secrets Manager e recuperar uma chave SSH privada. Minutos depois, essa chave foi usada para autenticação em um servidor bastion SSH downstream. A fase no bastion abriu oito sessões SSH curtas e paralelas, que resultaram na extração do esquema e do conteúdo completo de um banco PostgreSQL interno em menos de dois minutos. A atividade total, desde o acesso inicial até a conclusão da cadeia, durou pouco mais de uma hora.
A exploração de CVE-2026-39987 já vinha sendo observada em atividade ativa, incluindo reconhecimento manual contra honeypots e tentativas de coleta de dados sensíveis. Neste incidente, a diferença central foi o comportamento adaptativo depois da intrusão. O operador não aparentou depender de conhecimento prévio do esquema do banco, do nome das tabelas ou de artefatos previamente posicionados no disco. Em vez disso, a sequência de ações analisou o ambiente, descobriu caminhos úteis, extraiu valores de saídas anteriores e os reaproveitou em etapas seguintes.
A vulnerabilidade CVE-2026-39987 afeta versões do Marimo até 0.20.4 e permite que um atacante não autenticado execute comandos arbitrários de sistema. A pré-condição principal observada foi a exposição pública do notebook Marimo na rede. Após o comprometimento, o atacante realizou coleta de credenciais no host e encontrou dois segredos associados a ambiente em nuvem. O risco técnico imediato, nesse ponto, deixou de ser apenas execução de comandos no servidor vulnerável e passou a incluir acesso indireto a recursos controlados por identidade e permissões em nuvem.
Com as credenciais AWS coletadas, o ator realizou chamadas de API ao AWS Secrets Manager para obter uma chave SSH privada. A reutilização desse segredo expandiu a cadeia para fora do host Marimo e permitiu acesso ao bastion SSH. Esse padrão mostra uma falha clássica de contenção entre camadas: um serviço vulnerável exposto à internet tinha acesso a credenciais capazes de consultar um cofre de segredos, e o segredo recuperado fornecia caminho de autenticação para infraestrutura interna.
Na etapa do banco, o atacante usou múltiplas sessões SSH paralelas e extraiu o esquema e os dados completos de um PostgreSQL interno rapidamente. A análise da sequência apontou quatro sinais compatíveis com agente de IA em operação. O primeiro foi a criação de um fluxo de dump do banco sem conhecimento prévio do esquema. O segundo foi o vazamento de um comentário de planejamento em chinês na trilha de comandos, indicando uma etapa intermediária de raciocínio operacional. O terceiro foi a formatação voltada a consumo por máquina, com delimitadores, saídas limitadas, redução de ruído e supressão de erro padrão. O quarto foi o encadeamento de valores retirados de saídas anteriores, como quando informações de arquivos de credenciais e chaves foram usadas para orientar ações subsequentes.
Para defesa, o ponto mais importante é que o comportamento não se limita a uma sequência rígida de exploração. Um operador assistido por agente pode encontrar um arquivo inesperado, interpretar um erro, ajustar a busca, identificar uma credencial e continuar a cadeia. Isso muda a leitura de risco para ambientes com notebooks, ferramentas de dados, painéis internos ou serviços de automação expostos: a exploração inicial pode ser simples, mas o pós-comprometimento pode se adaptar rapidamente às permissões e artefatos disponíveis no host.
A superfície primária é composta por instâncias Marimo acessíveis pela internet em versões vulneráveis. Como a falha é pré-autenticada, a exposição pública eleva a criticidade mesmo quando o serviço não deveria manipular dados sensíveis diretamente. O host comprometido pode servir como ponto de coleta de variáveis de ambiente, arquivos de configuração, perfis de nuvem, credenciais de banco, arquivos de cliente SSH e outros segredos operacionais deixados no sistema para conveniência de execução.
A superfície secundária aparece nas permissões associadas às credenciais extraídas. No caso observado, as credenciais permitiram acesso ao AWS Secrets Manager e a recuperação de uma chave SSH privada. Isso indica que a avaliação defensiva não deve parar no Marimo: é necessário mapear quais identidades em nuvem estavam disponíveis no host, quais segredos podiam ser lidos, quais chaves SSH estavam armazenadas, quais bastions aceitavam essas chaves e quais bancos internos podiam ser alcançados a partir desses pontos.
- Instâncias Marimo públicas executando versões até 0.20.4.
- Hosts de notebook com credenciais AWS, arquivos de acesso a banco ou chaves SSH disponíveis em disco.
- Segredos armazenados no AWS Secrets Manager que possam ser lidos por credenciais presentes no host vulnerável.
- Bastions SSH downstream que aceitam chaves recuperadas de cofres de segredo.
- Bancos PostgreSQL internos acessíveis a partir do bastion ou de sessões SSH encadeadas.
A investigação deve começar por logs de acesso e execução em instâncias Marimo expostas. Procure requisições compatíveis com execução de comandos sem autenticação e atividade imediatamente posterior envolvendo leitura de arquivos de configuração, busca por credenciais, inspeção de diretórios de usuário e enumeração de artefatos relacionados a nuvem, SSH e bancos de dados. Como o caso envolveu coleta de credenciais no host, a presença de comandos orientados à descoberta de segredos deve ser tratada como sinal de comprometimento, não como simples reconhecimento.
Na camada AWS, revise eventos de API relacionados ao Secrets Manager no período próximo ao acesso ao Marimo. A sequência descrita inclui uso de uma chave de acesso coletada no host para recuperar uma chave SSH privada. Isso torna relevantes eventos de leitura de segredo, origem de rede incomum, volume anormal de chamadas e uso de credenciais a partir de endereços de saída que não correspondem ao padrão esperado da aplicação. A menção a um pool distribuído de egresso reforça a necessidade de correlacionar identidade, horário, recurso acessado e origem, em vez de depender apenas de endereço IP único.
No bastion SSH e no PostgreSQL, a telemetria deve focar em autenticações com chave, sessões curtas e paralelas, comandos de descoberta de banco, leitura de arquivos como ~/.pgpass e acesso rápido a esquema e tabelas. A extração completa em menos de dois minutos sugere que picos curtos de atividade podem ser mais relevantes do que transferências prolongadas. Também vale procurar padrões de saída formatada para consumo automatizado, delimitadores incomuns, limitação artificial de resultados e supressão de mensagens de erro.
- Execução de comandos em Marimo sem autenticação antes de atividade de coleta de credenciais.
- Chamadas ao AWS Secrets Manager feitas por credenciais presentes em hosts de notebook.
- Leitura ou enumeração de arquivos de credenciais, incluindo perfis de nuvem, configuração de banco e chaves SSH.
- Autenticação SSH com chave recuperada pouco depois de acesso ao cofre de segredos.
- Oito ou múltiplas sessões SSH curtas e paralelas contra bastion ou servidor downstream.
- Atividade PostgreSQL concentrada em enumeração de esquema e extração ampla de tabelas em janela curta.
- Comandos com saídas delimitadas, redução de ruído e reaproveitamento claro de valores extraídos de etapas anteriores.
A primeira ação é atualizar Marimo para a versão corrigida, com prioridade máxima para qualquer instância exposta à internet. A correção foi disponibilizada na versão 0.23.0, enquanto versões até 0.20.4 são descritas como afetadas. Quando a atualização imediata não for possível, a instância deve ser removida da exposição pública, colocada atrás de controles de acesso fortes e monitorada para sinais de execução de comandos e coleta de credenciais. Essa contenção reduz o vetor pré-autenticado, mas não substitui a correção.
Depois da correção do serviço, trate o host como potencialmente comprometido se ele esteve exposto enquanto vulnerável. Rotacione credenciais em nuvem, chaves de API e chaves SSH acessíveis a partir do sistema. Revogue sessões ou tokens associados, revise permissões no AWS Secrets Manager e confirme se as identidades usadas pelo notebook tinham escopo mínimo. Segredos que permitiam acesso ao bastion ou a bancos internos devem ser substituídos, e não apenas removidos do host, porque a análise indica que uma chave SSH privada foi recuperada e usada.
Também é necessário revisar a arquitetura de segredos e acesso. Notebooks e ferramentas de dados frequentemente acumulam permissões amplas para acelerar operações, mas esse padrão aumenta o impacto de uma falha de execução remota. Use identidades separadas por ambiente, aplique menor privilégio, restrinja leitura de segredos por aplicação, monitore chamadas sensíveis e limite caminhos de rede entre hosts expostos, bastions e bancos internos. A defesa precisa assumir que agentes automatizados podem adaptar a exploração ao ambiente e, portanto, reduzir a quantidade de informação útil disponível no primeiro host comprometido.
- Atualizar Marimo para 0.23.0 ou versão posterior corrigida.
- Inventariar e remover da internet instâncias Marimo que não precisam de exposição pública.
- Rotacionar credenciais AWS, chaves de API e chaves SSH presentes ou acessíveis no host comprometido.
- Revisar permissões de leitura no AWS Secrets Manager e reduzir escopo das identidades usadas por notebooks.
- Investigar acessos ao bastion SSH e ao PostgreSQL no período do comprometimento.
- Validar se houve cópia de esquema e conteúdo de banco e acionar resposta a incidente quando confirmado.
- Criar alertas para execução de comandos em serviços de notebook, leitura de segredos e sessões SSH paralelas de curta duração.
0 Comentários