Compromised Nx Console version 18.95.0

Nx Console é a extensão de VSCode/Cursor para os monorepos Nx e Lerna, com uso amplo entre times que usam essas ferramentas. Em 18/05/2026 um atacante publicou uma versão maliciosa (18.95.0) no VS Marketplace e no OpenVSX usando a identidade legítima de um contribuidor cujo token OAuth do GitHub CLI havia sido roubado sete dias antes, num ataque de cadeia de suprimentos anterior contra pacotes @tanstack/*. A janela de exposição foi curta (18 a 36 minutos dependendo do marketplace), mas quem ativou essa versão teve credenciais roubadas por um payload obfuscado — por isso está no KEV da CISA como exploração confirmada, mesmo com EPSS baixo, já que não é uma falha de código explorável remotamente e sim um comprometimento pontual de pipeline de publicação.

A CWE associada pelo catálogo KEV é CWE-506 (Embedded Malicious Code), não uma falha de lógica ou memória no software em si. O vetor de origem foi externo ao repositório da Nx: em 11/05/2026, um contribuidor da Nx rodou `pnpm install` em um repositório externo cujo `.npmrc` definia `minimum-release-age=10080` (7 dias) — mas o campo `packageManager` do projeto travava numa versão de pnpm anterior à existência dessa flag, então a proteção foi silenciosamente ignorada e o pacote malicioso `@tanstack/zod-adapter@1.166.15` foi resolvido normalmente, executando um script `prepare` que baixou um harvester de credenciais de 2.3 MB.

Com o token OAuth do GitHub CLI do contribuidor em mãos, o atacante operou dentro dos repositórios da Nx por aproximadamente 7 dias sem detecção, incluindo duas varreduras de exclusão em massa de execuções do workflow 'CodeQL Analysis' — provavelmente para cobrir rastros e emprestar credibilidade ao nome do workflow. O pipeline de publicação da extensão Nx Console permitia que um único mantenedor publicasse uma nova versão sem aprovação de um segundo revisor (diferente do processo já usado nos pacotes @nx/*), o que deu ao atacante caminho livre para empacotar e publicar a versão 18.95.0 usando credenciais de um contribuidor legítimo e confiável.

O payload embutido na 18.95.0 era executado na ativação da extensão (ao abrir o VSCode/Cursor num workspace onde a extensão estava habilitada), sem exigir nenhuma ação adicional do usuário. Ele gravava artefatos de persistência em disco (um backdoor Python `cat.py`, um LaunchAgent no macOS, staging em `/tmp` e Windows `%TEMP%`, e em alguns casos um binário `bun.exe` malicioso), e em Linux tentava modificar `/etc/sudoers` para persistência com privilégio elevado.

Não há aqui uma vulnerabilidade de código exposta a um atacante remoto contra a lógica do software — o vetor real é supply chain: comprometimento de credencial de um mantenedor, seguido de abuso do pipeline de publicação para distribuir um pacote malicioso através de canais legítimos e confiáveis (VS Marketplace e OpenVSX). O único pré-requisito do lado da vítima é ter instalado exatamente a versão 18.95.0 durante a janela de exposição (12:30–12:48 UTC no VS Marketplace, 12:33–13:09 UTC no OpenVSX) e ter a extensão ativada — o que ocorre automaticamente ao abrir um projeto no editor. Usuários com auto-update habilitado corriam risco maior por puxarem a atualização maliciosa sem interação manual.

Após a ativação, o payload colhia credenciais de fontes amplas: tokens Vault, tokens do npm (`.npmrc`, troca OIDC), metadados IMDS/ECS da AWS, Secrets Manager, SSM e Web Identity tokens, tokens do GitHub (`ghp_`/`gho_`/`ghs_`) extraídos de arquivos de configuração, variáveis de ambiente e memória de processo, sessões ativas do CLI do 1Password, além de chaves SSH, arquivos `.env`, credenciais padrão do GCP e configuração do Docker no sistema de arquivos. A exfiltração ocorria por HTTPS, API do GitHub e um canal encoberto via DNS.

Os números oficiais de instalação reportados pelos marketplaces são baixos (28 no VS Marketplace, 41 no OpenVSX, de 21 IPs únicos), mas a telemetria interna da Nx registrou cerca de 6.000 ativações da extensão a partir da versão comprometida — quase todas em VSCode, com apenas uma em Cursor e nenhuma em outros forks —, uma discrepância de duas ordens de magnitude ainda em reconciliação com a Microsoft no momento da publicação do advisory.

Atualizar Nx Console para 18.100.0 ou posterior (a versão publicada mais recente confirmada segura no postmortem é 18.100.5). Isso interrompe a execução do payload, mas não desfaz um comprometimento já ocorrido — atualizar por si só não é suficiente se a versão 18.95.0 chegou a rodar na máquina.

Quem instalou ou teve auto-update habilitado durante a janela de exposição (18/05/2026, 12:30–13:09 UTC) deve tratar a máquina como comprometida independentemente de encontrar ou não os indicadores de comprometimento listados: matar processos Python executando `cat.py` e qualquer processo com `__DAEMONIZED=1` no ambiente; remover os artefatos de persistência (no macOS o LaunchAgent precisa ser descarregado com `launchctl unload` antes de ser apagado, senão permanece ativo no launchd); e rotacionar toda credencial alcançável daquela máquina — tokens GitHub, AWS, npm, Vault, 1Password e chaves SSH — auditando logs de acesso das contas afetadas.

Desinstalar a extensão sem executar os passos acima não resolve nada: o backdoor de persistência sobrevive à remoção da extensão, e credenciais já exfiltradas continuam válidas até serem rotacionadas manualmente.

Indicadores de comprometimento publicados pelo fornecedor: presença dos arquivos `~/.local/share/kitty/cat.py`, `~/Library/LaunchAgents/com.user.kitty-monitor.plist`, `/var/tmp/.gh_update_state` e `/tmp/kitty-*` no macOS/Linux; e `%USERPROFILE%\.local\share\kitty\cat.py`, `%TEMP%\kitty-*`, `%TEMP%\.gh_update_state` e `%USERPROFILE%\.bun\bin\bun.exe` no Windows. Também verificar processos Python executando `cat.py` ou qualquer processo com a variável de ambiente `__DAEMONIZED=1`, e no Linux checar modificações não autorizadas em `/etc/sudoers`.

Como sinal indireto em ambientes GitHub, o postmortem descreve exclusões em massa de execuções do workflow 'CodeQL Analysis' pelo token comprometido — auditar logs de auditoria da organização por exclusões de workflow runs fora do padrão, especialmente em janelas de dias antes de um publish suspeito, pode revelar atividade do mesmo padrão de ataque. Não há um sinal de rede único e confiável para detectar exploração após o fato, já que a exfiltração usava HTTPS, API do GitHub e DNS — a única confirmação definitiva é a presença dos artefatos de disco/processo listados acima ou confirmação de que a versão 18.95.0 esteve instalada e ativa durante a janela de exposição.