dependency management
7 artigos com esta tag
bee-js 13.3.0 da Ethersphere e Swarm Desktop 0.56.2 distribuíram malware (novembro de 2026): versões afetadas e o que os usuários devem fazer
A versão 13.3.0 do pacote npm @ethersphere/bee-js, da Ethersphere, a desenvolvedora da rede de armazenamento descentralizado Swarm, continha código malicioso. Um aviso do GitHub (GHSA-hh7j-5m3j-23pf) publicado em 9 de novembro de 2026 lista a 13.3.0 como a única versão afetada e diz que não há versão corrigida. Diz que qualquer computador que tenha o pacote instalado ou em execução deve ser considerado totalmente comprometido, e que todos os segredos e chaves nele devem ser trocados imediatamente a partir de outro computador. Remover o pacote pode não eliminar todo o software malicioso causado pela instalação. Quanto ao Swarm Desktop, as notas de versão da Ethersphere dizem que a versão 0.56.3, lançada em 9 de novembro, substitui a 0.56.2 comprometida. Segundo a análise de uma empresa de segurança, o bee-js 13.3.0 apareceu no npm por volta das 00:09 UTC de 9 de novembro (09:09 no horário do Japão) e foi removido cerca de 75 minutos depois. O Swarm Desktop 0.56.2 ficou público por cerca de 8,5 horas e também foi entregue por atualização automática no Windows x64 e no Apple Silicon. Relata-se que o bee-js 13.2.0 e anteriores, e o Swarm Desktop 0.56.1, não são afetados. A mesma análise diz que o arquivo de configuração do nó Bee (que guarda uma senha em texto simples) e sua chave de carteira foram alvos, e que credenciais usadas pela automação oficial de publicação foram abusadas. Nossa conclusão: reconstrua qualquer máquina ou ambiente de CI que instalou uma versão afetada, mova a carteira para uma chave nova e os fundos com ela, e troque as credenciais a partir de outra máquina.
LiteLLM 1.107.0 distribuiu um ladrão de credenciais (outubro de 2026): versão afetada no PyPI e imagens Docker, e o que os usuários devem fazer
Em 21 de outubro de 2026 (UTC), a BerriAI, empresa por trás do LiteLLM, anunciou que seu pipeline de lançamento havia sido comprometido e que uma v1.107.0 contendo malware que rouba credenciais e carrega ferramentas de execução remota de código foi publicada. Foram afetados o litellm==1.107.0 no PyPI (das 11:39 às 13:23 UTC) e as tags v1.107.0, latest, main-latest e main-stable no Docker Hub (das 11:46 às 14:20 UTC) e no GHCR (a partir das 11:46 UTC até serem retiradas, no máximo às 13:51 UTC, cerca de duas horas). A tag oficial do código-fonte v1.107.0 no GitHub não contém os arquivos maliciosos; os artefatos foram construídos a partir de um repositório semelhante controlado pelo atacante. Todas as versões anteriores estão fora deste comprometimento, e a empresa pede que os usuários fixem a 1.106.2 ou outra versão anterior explícita. Em 24 de outubro (UTC) a empresa publicou as versões 1.103.8, 1.104.6, 1.105.4 e 1.106.3, e a partir dessas versões as imagens Docker e os Helm charts são assinados com uma nova chave cosign (a chave anterior não os verifica mais). Em 23 de outubro a empresa publicou uma análise de causa raiz e corrigiu sua primeira hipótese de que os tokens teriam sido obtidos dos logs de uma implantação interna do LiteLLM. Segundo a análise, um arquivo de configuração enviado por engano a um repositório público em 27 de maio continha a chave mestra de uma plataforma interna de agentes; o commit foi sobrescrito, mas a chave nunca foi revogada. Em 10 de outubro o atacante usou essa chave para chamar a API da plataforma e obteve o token do GitHub CLI de um proprietário da organização no GitHub configurado ali. Com ele, o atacante exfiltrou segredos de CI para obter os tokens de mais dois mantenedores e, em 21 de outubro, desativou a proteção de branch, alterou o workflow de lançamento e aprovou o lançamento. Conclusão deste site: reconstrua todo ambiente que instalou ou iniciou a 1.107.0 durante a janela e rotacione todas as chaves que ele podia acessar, incluindo chaves de provedores de LLM, a chave mestra do proxy, a senha do banco de dados e as funções de nuvem.
osv-scanner na prática — pnpm, ignorar CVEs, modo offline e os erros que aparecem
Só as dúvidas do segundo dia, respondidas com base na documentação oficial. O pnpm-lock.yaml é suportado; exceções ficam no osv-scanner.toml em IgnoredVulns e podem ter data de validade; o modo offline são três flags com três funções diferentes. A visão deste site: um scanner relata vulnerabilidades conhecidas e não diz nada sobre uma versão que você mesmo fixou ficando desatualizada — isso exige um mecanismo separado.
Segurança do Express (Node.js) — uma referência de hardening para produção
O Express é minimalista — ele quase não protege nada por padrão, então você adiciona as defesas. Esta é uma referência de trabalho: (1) um checklist de hardening priorizado (P0–P2), (2) orientação por área — cabeçalhos de segurança (helmet) + desabilitar x-powered-by, CVEs de dependências npm, validação de entrada e injeção (operador SQL/NoSQL), autenticação e autorização com escopo de dono, limitação de taxa e limites de tamanho, sessões/cookies/CSRF, SSRF, tratamento de erros em produção (sem exposição de stack), NODE_ENV, e (3) um checklist de autoverificação. Apenas defensivo — sem passos de ataque.
Segurança do Next.js — uma referência de hardening para produção
Os padrões do Next.js são bastante seguros, mas os incidentes acontecem na fronteira servidor/cliente. Esta é uma referência de trabalho: (1) uma lista de verificação de hardening por ordem de prioridade (P0–P2), (2) orientação por área — a fronteira e as variáveis de ambiente (NEXT_PUBLIC_), CVEs de dependências (incluindo RCE no núcleo), autorização em Server Actions / Route Handlers + validação de entrada, SSRF em buscas do lado do servidor, cabeçalhos de segurança/CSP, autenticação/sessão/cookies, limitação de taxa, e (3) uma lista de autoverificação. Apenas defensivo — sem passos de ataque.
Segurança do Ruby on Rails — uma referência de hardening de produção
O Rails entrega convenções e padrões seguros (proteção CSRF, Strong Parameters, um ORM), mas os incidentes de produção vêm da operação. Esta é uma referência de trabalho: (1) um checklist de hardening ordenado por prioridade (P0–P2), (2) orientação por área — segredos e credentials (master key/secret_key_base), config de produção (force_ssl, sem exposição de exceções), CVEs de gems, Strong Parameters/Mass Assignment, autorização (Pundit, escopo de proprietário), injeção e métodos perigosos (interpolação em where/send/constantize), sessões/cookies/CSRF, SSRF/uploads e (3) um checklist de autoverificação. Só defensivo — sem passos de ataque.
Segurança do Spring Boot — uma referência de hardening para produção
O Spring Boot é um framework estável, mas os incidentes vêm de dependências, configuração e autorização. Esta é uma referência de trabalho: (1) um checklist de hardening priorizado (P0–P2), (2) orientação por área — CVEs de dependências (classe Log4Shell, julgue pela versão em execução), configuração de produção e segredos externalizados, autorização no Spring Security (negação por padrão/segurança em nível de método/checagens de dono), redução da exposição do Actuator/gerenciamento, desserialização insegura, injeção, cabeçalhos/CSRF/sessão, SSRF, e (3) um checklist de autoverificação. Apenas defensivo — sem passos de ataque.