O worm do npm entrou pelo build nativo

A gente confia muito no que parece rotina: instalar dependência, abrir dashboard, pedir para um modelo revisar segurança. O problema é que esses caminhos normais também executam código, carregam sessão e encostam em credencial.

Miasma achou execução no build nativo durante npm install

Na edição de 1 de junho, a gente falou de Miasma no npm no caminho de instalação. A atualização agora é mais específica: a StepSecurity descreveu uma variação chamada Phantom Gyp, em que o gatilho sai dos scripts óbvios de instalação e entra no arquivo de build nativo.

Esse arquivo costuma aparecer quando um pacote precisa compilar um addon nativo. O npm vê aquilo, chama node-gyp rebuild, e a instalação segue como se estivesse preparando código nativo legítimo. No caso descrito pela StepSecurity, um binding.gyp de 157 bytes bastava para puxar a execução maliciosa durante o install.

Segundo a empresa, até a análise publicada, a campanha atingia 57 pacotes e 286+ versões maliciosas. A lista inclui @vapi-ai/server-sdk e ai-sdk-ollama; no caso de ai-sdk-ollama, a StepSecurity aponta as versões 3.8.5, 2.2.1, 1.1.1 e 0.13.1. Esse detalhe dói porque muita gente trata integração com modelo local como uma zona mais segura por natureza. O modelo pode estar na sua máquina, mas a cola que liga tudo ainda pode vir do npm.

A carga citada pela análise passa por um index.js ofuscado de 4,5 MB, baixa Bun v1.3.13 e procura credenciais de ambiente de dev e CI. O computador da pessoa é só uma parte do alcance. Em GitHub Actions e outros runners com segredo por perto, um install de dependência pode alcançar token de GitHub, cloud, Vault, Kubernetes e registry antes de a aplicação sequer rodar.

Para defesa, o trabalho chato é o correto: revisar lockfiles e logs de instalação, trocar versões afetadas por versões limpas ou alternativas confiáveis, procurar sinais estranhos no build e girar segredos que ficaram acessíveis ao ambiente de instalação. Scanner e revisão também precisam olhar binding.gyp e comportamento de build nativo, além de preinstall e postinstall.

Os números ainda podem mudar. A atualização publicada já basta: supply chain continua sendo supply chain, inclusive quando o pacote serve para plugar modelo local em produto bonito.

Fontes: StepSecurity e Microsoft Security Blog.

Um nome no MeshCore virou XSS crítico no Home Assistant

MeshCore é uma rede de mensagens que usa LoRa, um rádio de longo alcance e baixa banda. O rádio só transporta o texto; a falha descrita por Sasha Romijn aparece quando esse conteúdo externo entra em um painel do Home Assistant sem escape adequado.

O componente afetado é o meshcore-card, usado via HACS. MeshCore anuncia nós com um campo de nome de 32 bytes, e esses nomes podiam ser renderizados no dashboard como HTML. Com um nome preparado para isso, bastava o painel com o card ser visualizado para JavaScript rodar na sessão do frontend.

O advisory no GitHub registra CVE-2026-45323, GHSA-5vrg-xpcj-xppc, CVSS 9.6 e correção no meshcore-card 0.3.3. Versões anteriores a 0.3.3 entram na área afetada. A interação do usuário também importa: alguém precisa abrir ou visualizar o dashboard. Só que, em Home Assistant OS ou Supervised, uma sessão administrativa no frontend fica perto de add-ons, tokens e automações de casa. A palavra “casa” deixa a coisa menos abstrata.

A pesquisadora também cita variantes panel-v2 e sites analisadores que ainda pareciam expostos, com a ressalva de que nem toda variante foi verificada em runtime. Para quem usa esse caminho, a ação direta é atualizar o card, evitar variantes sem correção clara e tratar qualquer nome de nó, dispositivo ou contato vindo de rádio como entrada não confiável.

Tem um detalhe quase didático no meio da história: o analisador CoreScope tinha uma função safeEsc que checava um global inexistente e, quando não encontrava, devolvia a entrada sem escape. A autora aponta isso como uma aparente alucinação de LLM. A cautela aqui é proporcional: uma função com nome de segurança não garante segurança.

Fontes: Sasha Romijn e GitHub Advisory Database.

Um experimento de US$ 1.500 testou LLMs contra Firebase

Kasra Rahjerdi montou um experimento simples de entender e difícil de exagerar com honestidade. Ele criou um app falso em React Native Expo, com backend Python/FastAPI aparentemente bem protegido, mas com uma camada Firebase/Firestore vulnerável. O caminho certo para explorar era usar informações em google-services.json e acessar dados privados direto pelo Firebase.

Isso é muito parecido com erro real de produto: a API oficial parece segura, mas o cliente mobile entrega uma pista para uma camada de dados com regra de autorização frouxa. Quem só testa o backend bonito pode passar reto pelo buraco.

O autor relata ter gasto cerca de US$ 1.500, com intenção de fazer 10 rodadas por modelo, limite de US$ 10 por rodada e janela de duas horas. Ele também deixa a cautela na mesa: avaliação científica ficou fora da proposta, o relato é self-report, houve limite de custo e a conta da OpenAI usada tinha aprovação para pesquisa de segurança. Já ajuda bastante quando o próprio experimento não finge ser oráculo.

Nos resultados reportados, GPT-5.5 resolveu 7 de 10 rodadas. Deepseek V4 Pro resolveu 3 de 10. Claude Sonnet 4.6 e Claude Opus 4.8 resolveram 2 de 10 cada. Outros modelos ficaram em 0 nas rodadas completas, e Gemini 3.1 Pro Preview teve recusa imediata no desenho testado.

Os erros contam bastante. Alguns modelos encontravam Firebase, mas insistiam no caminho da API protegida. Outros recusavam cedo demais ou tarde demais. Pelo relato, o desafio era persistir no caminho certo quando a arquitetura escondia o bug em uma camada que parecia secundária.

Para dev, o trabalho depois da leitura é bem menos divertido que ranking de modelo: revisar regras de Firebase, Firestore, Supabase e qualquer data layer direto pelo cliente. LLM pode ajudar a explorar hipótese, fazer checklist e olhar logs. Ele não substitui teste explícito de autorização, especialmente quando o dado está a um arquivo de configuração de distância.

Fonte: Kasra Rahjerdi.

Destaques rápidos

• libinput corrigiu um caminho local para root via udev. O advisory upstream fala em texto de atributo de dispositivo sem escape sendo importado pelo udev como propriedades extras. As versões corrigidas, segundo a fonte primária, são libinput 1.31.3 e 1.30.4; o pré-requisito envolve dispositivo uinput ou uhid malicioso, muitas vezes root-only, mas regras como steam-devices, antimicrox e kdeconnectd no Fedora podem mudar esse alcance. Atualize pelo pacote da distro. Fontes: freedesktop.org advisory, freedesktop.org announce e Phoronix.

• Relatos ligados à Sophos mostram agentes acelerando laboratório de evasão de EDR. Leia como pesquisa ofensiva assistida por IA, não como malware autônomo rodando solto em vítima. Segundo Help Net Security e BleepingComputer, o ambiente usava Cursor, Claude Opus 4.5, MCP e Ludus para desenvolver e testar quase 80 módulos e mais de 70 técnicas contra ambientes Sophos, CrowdStrike e Microsoft Defender; a própria Sophos teria visto que algumas alegações internas de sucesso não batiam com os dados revisados. Fontes: Help Net Security e BleepingComputer.

• pgBackRest funcionou com pg_tde, mas backup criptografado cobra a conta em outro lugar. O teste de pgstef usou pgBackRest 2.58.0, Percona Server for PostgreSQL 18, pg_tde e OpenBao como provedor de chaves. O arquivamento assíncrono funcionou, mas o autor precisou ajustar archive-header-check=n e checksum-page=n; dados criptografados também comprimem mal e reduzem a eficiência de backup incremental por bloco. Antes de comemorar TDE, teste restore, chaves e retenção no seu próprio ambiente. Fonte: pgstef / Planet PostgreSQL.

• sydtest colocou mutation testing como juiz externo para testes gerados por IA. A novidade é de Haskell, mas a lógica vale fora dele: o sistema muda o código de propósito e espera que a suíte falhe. Se a mudança sobrevive, o teste não pegou um erro simulado; se morre, o teste pelo menos gritou naquele caso. O sydtest agora oferece mutation testing geralmente disponível, com checks em Nix e relatórios legíveis por humano ou máquina. Fonte: CS SYD.

Tendência do dia

A ligação entre essas histórias é bem prática: quando uma ferramenta gera código, conduz teste, analisa segurança ou renderiza dado externo, precisa existir alguma verificação fora da própria conversa.

No MeshCore, o nome de um nó vindo do rádio deveria ter sido tratado como texto hostil no ponto de renderização. No CoreScope, uma função chamada safeEsc parecia prometer escape e devolvia entrada crua em um caminho importante. No experimento do Firebase, os modelos precisavam abandonar a API segura e insistir na camada de dados onde a autorização realmente falhava.

Mutation testing entra como exemplo menor e bom: ele não pergunta se o teste parece bonito. Ele quebra o código e vê se a suíte percebe. CI determinístico, regras de autorização testadas diretamente, sanitização no limite certo e sandbox em volta de agente fazem esse mesmo papel em outras áreas. São controles sem poesia, o que costuma ser uma qualidade.

Para quem usa IA no fluxo de desenvolvimento, vale separar ajuda de prova. Um modelo pode sugerir, resumir, achar caminho estranho e economizar tempo. A checagem que protege build, dashboard, banco e credencial precisa sobreviver mesmo quando a resposta parece convincente demais.

Fontes de contexto: Sasha Romijn, CS SYD e Kasra Rahjerdi.

Nota: gerado por IA (The Paper LLM), com fontes originais listadas por bloco.