Axios comprometido no npm, o que as versões maliciosas realmente fizeram

Se seu ambiente instalou axios@1.14.1 ou axios@0.30.4Se o problema for a instalação de um patch ruim, a suposição inicial mais segura não é "nós fizemos um patch ruim". É "uma máquina pode ter executado um código hostil durante a instalação da dependência". A análise técnica pública da StepSecurity vinculou ambas as versões a uma conta de mantenedor comprometida, uma dependência recém-injetada chamada plain-crypto-js@4.2.1e um pós-instalação que buscava malware específico da plataforma para macOS, Windows e Linux. A recomendação da StepSecurity foi direta: tratar as instalações dessas versões como possíveis comprometimentos, reverter para versões reconhecidamente boas e rotacionar as credenciais expostas. (StepSecurity)

Esse enquadramento é importante porque não se trata de uma vulnerabilidade normal do produto Axios. As evidências públicas apontam para um comprometimento do caminho de lançamento. Os lançamentos públicos e as tags do GitHub para o axios mostraram v1.14.0 como a última versão visível 1.x, sem nenhuma versão pública correspondente v1.14.1 enquanto a Socket observou separadamente que a versão afetada do Axios não aparecia nas tags oficiais do projeto no GitHub. No momento em que este artigo foi escrito, o snippet da listagem pública de pacotes do npm também apontava para 1.14.0 como a versão pública mais recente novamente. (GitHub)

O Axios também não é uma dependência obscura. A telemetria de pacotes públicos difere de acordo com o provedor, mas tanto a Snyk quanto a Socket a colocam na casa das dezenas de milhões de downloads semanais, e é por isso que uma janela de lançamento malicioso de curta duração ainda é importante. Na prática, esse tipo de evento é perigoso menos por causa do nome da biblioteca em si e mais porque a biblioteca fica em laptops de desenvolvedores, executores de CI, scripts de automação, SDKs internos, CLIs, aplicativos Electron e ferramentas do lado do servidor em que a instalação da dependência ocorre perto de credenciais. (Guia do VulnInfo)

Vale a pena estudar com cuidado o restante do incidente, pois ele combina vários padrões que os defensores continuam vendo nos comprometimentos modernos do ecossistema de pacotes: controle da conta do mantenedor, lançamento de um patch mal-intencionado que não se alinha com a trilha de lançamento normal do projeto, um caminho de execução no tempo de instalação em vez de um exploit no tempo de execução do aplicativo, uma dependência fantasma adicionada apenas para acionar um script de ciclo de vida, entrega de segundo estágio entre plataformas e autolimpeza projetada para fazer com que uma revisão posterior do sistema de arquivos pareça comum. (StepSecurity)

Axios comprometeu o npm, a linha do tempo verificada e o estado de lançamento público

A StepSecurity publicou uma linha do tempo pública que deixa o padrão de preparação excepcionalmente claro. Primeiro veio plain-crypto-js@4.2.0publicado em 30 de março de 2026 às 05:57 UTC como um pacote de isca de aparência limpa. Mais tarde, no mesmo dia, plain-crypto-js@4.2.1 apareceu às 23:59 UTC com a mensagem maliciosa pós-instalação lógica. Somente após esse trabalho de preparação, o invasor publicou axios@1.14.1 às 00:21 UTC de 31 de março e axios@0.30.4 às 01:00 UTC usando uma identidade de mantenedor comprometida. A observação da linha do tempo separada do Socket também colocou o suspeito plain-crypto-js@4.2.1 publicou apenas alguns minutos antes do lançamento malicioso do Axios, o que reforça o argumento de que se tratava de uma operação coordenada de preparação de dependências, e não de uma publicação ruim acidental. (StepSecurity)

Linha do tempo pública verificada dos lançamentos maliciosos da Axios. (StepSecurity)

Hora UTC	Objeto	O que mudou	Por que é importante
2026-03-30 05:57	plain-crypto-js@4.2.0	Versão limpa do chamariz publicada	Estabelece o histórico do pacote e reduz as suspeitas
2026-03-30 23:59	plain-crypto-js@4.2.1	Malicioso pós-instalação adicionado	Transforma o pacote em um carregador de tempo de instalação
2026-03-31 00:21	axios@1.14.1	Injeção de dependência maliciosa	Atinge a linha principal do consumidor 1.x
2026-03-31 01:00	axios@0.30.4	O mesmo padrão aplicado	Estende a exposição à linha 0.x

Os metadados da versão pública acrescentaram mais sinais de alerta. A página de lançamentos públicos do GitHub mostrou v1.14.0 como a última versão visível e a página de tags mostrava v1.14.0 com uma assinatura verificada, mas sem uma assinatura pública v1.14.1 estava presente. O Socket explicitamente chamou a atenção para o fato de que a versão afetada do Axios não aparecia nas tags oficiais do GitHub, o que é o tipo de incompatibilidade que as equipes de segurança devem tratar como um alarme de integridade de lançamento, e não como uma manutenção inofensiva. (GitHub)

Essa distinção é mais do que cosmética. Em operações de lançamento saudáveis, a versão do pacote, a tag do repositório, a trilha de lançamento assinada e o caminho normal de publicação dos mantenedores tendem a se alinhar o suficiente para que links perdidos sejam incomuns. Esse caso parecia diferente em público: as versões maliciosas do npm existiam, mas a trilha de lançamento do GitHub não as apresentava como lançamentos comuns do projeto. Esse é um dos motivos pelos quais esse evento pertence à categoria de comprometimento de versão, e não à categoria de "axios enviou um patch com erros". (GitHub)

Por que esse foi um ataque à cadeia de suprimentos do axios npm, e não um bug no código do axios

O modelo mental mais importante para esse incidente é simples: o invasor não precisava encontrar uma falha de execução remota de código no axios. Ele precisava fazer com que os usuários instalassem um artefato malicioso que usasse o nome axios por tempo suficiente para executar o código durante a instalação. O relatório público da StepSecurity vinculou a publicação a credenciais npm comprometidas de um mantenedor líder e observou que o invasor alterou o e-mail da conta para ProtonMail. Esse é um evento da cadeia de suprimentos centrado na confiança do editor e na distribuição de pacotes, não na lógica de análise de solicitações do axios ou em alguma API de solicitação perigosa na própria biblioteca. (StepSecurity)

O StepSecurity também destacou anomalias de metadados que se alinham com essa interpretação. A análise pública disse que as versões mal-intencionadas não correspondiam ao fluxo habitual do OIDC Trusted Publisher baseado no GitHub do projeto e, em vez disso, pareciam ter sido enviadas por um caminho de credencial tradicional associado a uma conta de mantenedor comprometida. Seu artigo observou especificamente que faltavam trustedPublisher, faltando gitHeade a falta de uma tag correspondente do GitHub ou de um rastro de commit para a versão maliciosa. Mesmo que uma equipe nunca use esses campos exatos de metadados em ferramentas, a lição subjacente é clara: a autenticidade do pacote não é a mesma coisa que a autenticidade do repositório, e a proveniência da versão deve ser verificada independentemente. (StepSecurity)

A própria documentação do npm explica por que isso é importante. A publicação confiável com o OIDC destina-se a eliminar a necessidade de tokens npm de longa duração, permitindo publicações de um fluxo de trabalho de CI autorizado usando credenciais específicas de fluxo de trabalho de curta duração. Mas a mesma documentação também diz que o npm aceitará publicações do fluxo de trabalho confiável, além dos métodos de autenticação tradicionais, como tokens npm e publicações manuais, a menos que o proprietário do pacote restrinja ainda mais as configurações do pacote. Em outras palavras, habilitar um caminho mais seguro não é a mesma coisa que remover o caminho mais antigo e mais fraco. (Documentos do npm)

É fácil não perceber essa nuance nos postmortems. As equipes costumam dizer "agora usamos o OIDC" como se isso, por si só, encerrasse a história. A documentação do npm não suporta essa simplificação. Ela recomenda restringir o acesso tradicional à publicação baseada em tokens depois que os editores confiáveis forem configurados, incluindo a ativação da configuração do pacote que exige autenticação de dois fatores e não permite tokens e, em seguida, a revogação de tokens de automação antigos que não são mais necessários. Em termos de segurança da versão, o objetivo não é apenas adicionar um método de publicação mais seguro. O objetivo é remover caminhos alternativos dos quais um invasor ainda pode abusar. (Documentos do npm)

Portanto, a lição operacional do incidente da Axios é mais ampla do que "fique atento a versões maliciosas". É "tratar os caminhos de lançamento de pacotes como limites de segurança". Se o seu modelo de ameaças parar na revisão do código-fonte e nunca avaliar como os artefatos são publicados, você estará defendendo a borda errada. (StepSecurity)

Como as versões maliciosas do axios foram criadas

O núcleo técnico público desse incidente é surpreendentemente compacto. De acordo com a StepSecurity, a maior diferença em nível de dependência entre as versões limpa e maliciosa do Axios foi a adição de plain-crypto-js@^4.2.1. Sua análise então verificou o conteúdo do pacote da Axios e descobriu que criptografia simples nunca foi importado ou exigido em todos os 86 arquivos em axios@1.14.1. O pacote existia no gráfico de dependência sem ser usado no caminho do código funcional do próprio axios. (StepSecurity)

Esse é o tipo de anomalia da qual os defensores devem se lembrar, pois ela vai muito além desse incidente. Uma dependência que aparece no manifesto, mas nunca aparece no código-fonte, geralmente não tem nada de honesto em estar lá, especialmente quando ela também carrega a execução em tempo de instalação. O StepSecurity descreveu isso como uma dependência fantasma, e esse rótulo é útil porque captura o padrão de ataque com precisão: a dependência é real o suficiente para o gerenciador de pacotes buscar e executar, mas é operacionalmente "fantasma" do ponto de vista do aplicativo porque a biblioteca nunca precisa dela para fazer seu trabalho real. (StepSecurity)

O invasor não precisou modificar o tratamento de solicitações, os adaptadores, os interceptadores ou a mesclagem de configurações do axios. O invasor só precisava de um caminho que fosse executado antes que a vítima executasse o código do aplicativo. Ao inserir uma dependência que existia apenas para executar o pós-instalaçãoNa versão mal-intencionada, o cliente HTTP confiável foi transformado em um veículo de entrega para uma carga útil de segundo estágio sem deixar importações mal-intencionadas óbvias na base de código principal. (StepSecurity)

Liberação limpa versus liberação maliciosa em provas públicas. (StepSecurity)

Dimensão	Limpar a trilha de liberação pública do Axios	Comportamento malicioso do lançamento do Axios
Visibilidade da versão pública do GitHub	v1.14.0 visível como a versão 1.x mais recente	Não é público v1.14.1 liberação mostrada
Trilha de tags públicas do GitHub	v1.14.0 tag visível e verificada	Não é público v1.14.1 etiqueta mostrada
Forma de dependência	Não há necessidade de criptografia simples	plain-crypto-js@^4.2.1 adicionado
Uso da fonte	As dependências funcionais aparecem nos caminhos de código	criptografia simples não importado para nenhum lugar onde os analistas públicos tenham verificado
Comportamento em tempo de instalação	Instalação normal da biblioteca	pós-instalação corrente usada para lançar o segundo estágio
Liberar sinal de confiança	Alinhamento da trilha de recompra e de pacotes	A versão do pacote existe sem uma trilha de lançamento normal visível

Para os defensores, vale a pena declarar sem rodeios a heurística prática: uma nova dependência, sem uso visível de código e com um script de instalação não é "talvez suspeito". É um evento de alto sinal. Muitos pipelines de revisão de dependências ainda se concentram em alterações de versão, diferenças de licença ou avisos de vulnerabilidade e não classificam um "novo pacote com execução em tempo de instalação que o código nunca importa" como um bloqueador de lançamento. Esse incidente mostra por que eles deveriam. (StepSecurity)

Como o postinstall transformou um cliente HTTP comum em um carregador de malware

O comportamento documentado do ciclo de vida do npm explica por que esse caminho de ataque é tão eficaz. A documentação da CLI do npm mostra que tanto o npm install e npm ci executar scripts de ciclo de vida de instalação, incluindo pré-instalação, instalare pós-instalação. Uma página de configuração separada do npm afirma que ignore-scripts=true impede que o npm execute scripts definidos em package.json. Esses dois fatos, em conjunto, explicam o risco central: uma dependência pode executar código durante a instalação, muito antes de o aplicativo ser inicializado, executar testes ou importar a biblioteca que a puxou. (Documentos do npm)

Isso significa que o malware de tempo de instalação não é um caso isolado de nicho. Ele fica em um caminho que muitas equipes acionam todos os dias: clones novos, compilações de CI, criação de imagens do Docker, atualizações de dependências, falhas de cache, inicializações de espaços de trabalho monorepo, ambientes de teste efêmeros e scripts únicos em laptops de desenvolvedores. O pacote não precisa de uma inicialização bem-sucedida do aplicativo para vencer. Ele só precisa ser resolvido e descompactado pelo npm com os scripts de ciclo de vida ativados. (Documentos do npm)

No caso da Axios, a análise pública dizia plain-crypto-js@4.2.1 definido pós-instalação como node setup.js. Em seguida, o StepSecurity desofuscou esse arquivo e mostrou que ele agia como um dropper de arquivo único com informações de C2, verificações de sistema operacional e lógica de execução agrupadas em strings ofuscadas e auxiliares de decodificador. Os valores decodificados publicados incluíam referências a child_process, os, fse o URL de base http://sfrclak.com:8000/6202033que é uma estrutura típica de um thin loader cujo trabalho é buscar e entregar a um segundo estágio específico da plataforma em vez de conter toda a funcionalidade do malware no próprio primeiro script. (StepSecurity)

O ponto de segurança importante não é apenas o fato de que pós-instalação pode correr. É isso pós-instalação é executado em um contexto que geralmente tem exatamente o que um invasor deseja: acesso à rede, acesso ao sistema de arquivos, confiança no gerenciador de pacotes, variáveis de ambiente, material de repositório e, às vezes, segredos de CI ou credenciais de nuvem. É por isso que o abuso pós-instalação do ecossistema de pacotes continua retornando em diferentes formas. O próprio blog do GitHub, descrevendo a resposta aos recentes ataques ao ecossistema npm, apontou especificamente para uma onda de aquisição de contas e injeção maliciosa de scripts pós-instalação como um padrão sério, não uma anomalia única. (O blog do GitHub)

Você pode resumir a cadeia do Axios da seguinte forma:

npm install ou npm ci
    -> resolver versão maliciosa do axios
    -> resolver plain-crypto-js@4.2.1
    -> executar postinstall
    -> executar setup.js ofuscado
    -> Entre em contato com o servidor remoto
    -> baixar carga útil específica da plataforma
    -> lançar carga útil em segundo plano
    -> remover ou disfarçar evidências locais

Esse modelo é simples o suficiente para moldar tanto a detecção quanto a prevenção. Se os seus controles inspecionarem apenas a inicialização do aplicativo, as importações em tempo de execução ou o tráfego de saída depois que o aplicativo começar a ser veiculado, você estará procurando tarde demais. O dano nessa classe de incidente pode começar dentro da própria etapa de instalação da dependência. (StepSecurity)

O que a carga útil fez no macOS, no Windows e no Linux

A engenharia reversa pública publicada pela StepSecurity fornece detalhes suficientes para ir além de rótulos genéricos como "RAT" e falar concretamente sobre o que o instalador tentou fazer em cada sistema operacional. Isso é importante porque a resposta a incidentes depende de saber onde procurar, quais artefatos podem persistir e que tipo de risco subsequente a carga útil implica. (StepSecurity)

Versões maliciosas do axios no macOS

Para o macOS, o StepSecurity informou que o dropper usava o AppleScript para buscar a próxima etapa enviando o corpo POST packages.npm.org/product0 para o servidor controlado pelo invasor. A resposta foi salva em /Library/Caches/com.apple.act.monde, em seguida, marcado como executável e executado em segundo plano. A escolha de /Library/Caches e um nome de arquivo do tipo Apple não é aleatório. Ele combina com o tipo de caminho e as convenções de nomenclatura que os defensores podem ignorar durante uma triagem rápida do sistema de arquivos, especialmente se a primeira revisão for feita manualmente e sob pressão de tempo. (StepSecurity)

De um ponto de vista defensivo, a ramificação do macOS indica duas coisas. Primeiro, o invasor não estava apenas tentando travar as compilações ou adulterar o estado de dependência. O caminho leva ao fornecimento de executáveis arbitrários e à execução em segundo plano. Segundo, o alvo da infecção não se limita ao CI. Qualquer Mac de desenvolvedor que tenha instalado a versão maliciosa com scripts de ciclo de vida ativados pode ter baixado e lançado um artefato de segundo estágio antes que o engenheiro abrisse seu editor. (StepSecurity)

Versões maliciosas do axios no Windows

Para o Windows, a análise pública descreveu um caminho em mais camadas. O dropper procurava o PowerShell, copiava-o para %PROGRAMDATA%\wt.exe para fazer com que ele se parecesse mais com um utilitário legítimo e, em seguida, escreveu um arquivo temporário .vbs que invocava um shell oculto e extraía um script do PowerShell de segundo estágio. O corpo do POST usado para essa ramificação foi packages.npm.org/product1. Os arquivos temporários VBS e PS1 faziam parte da cadeia, mas o StepSecurity observou que %PROGRAMDATA%\wt.exe era o artefato mais durável que provavelmente sobreviveria por mais tempo do que os arquivos de preparação transitórios. (StepSecurity)

É útil estudar essa ramificação porque ela reflete um padrão recorrente de malware do Windows em comprometimentos do ambiente de compilação: estágio com script incorporado, ocultação da execução, renomeação ou cópia de um binário comum para um nome de arquivo plausível e, em seguida, pivô para um script de segundo estágio ou sequência de comandos. As equipes que procuram apenas nomes de pacotes nos diretórios de projetos do Node podem não perceber que as evidências interessantes podem ter caído em um local amplo em todo o sistema operacional, como ProgramData, em vez de na pasta do repositório que acionou a instalação.StepSecurity)

Versões maliciosas do axios no Linux

Para o Linux, a cadeia foi direta. O registro público diz que o instalador usou enrolar para buscar um payload Python para /tmp/ld.pye, em seguida, iniciou-o com nohup python3 para que o processo pudesse continuar após a conclusão do comando principal. O corpo do POST para essa ramificação foi packages.npm.org/product2. Na validação de tempo de execução do StepSecurity, a árvore de processos mostrou npm levando a sh, então nó, depois outro shell, depois enrolar e nohupe, finalmente python3 /tmp/ld.py. Eles também observaram a nohup órfão de processo para o PID 1, que é exatamente o que você esperaria de uma transferência em segundo plano com daemon projetado para sobreviver à etapa de instalação. (StepSecurity)

Isso torna os executores de CI do Linux especialmente importantes na triagem, pois o caminho é adequado para sistemas de compilação efêmeros que ainda têm segredos significativos durante a execução. Mesmo que o host tenha vida curta, os segredos que ele tocou podem não ter. Um processo mal-intencionado só precisa sobreviver por tempo suficiente para ler variáveis de ambiente, acessar credenciais de serviço ou exfiltrar material de origem e de compilação. (StepSecurity)

Comportamento da carga útil específica da plataforma e artefatos residuais da análise pública. (StepSecurity)

Plataforma	Detalhes da entrega	Detalhes da execução	Artefato residual a ser verificado primeiro
macOS	Corpo do POST packages.npm.org/product0	Faça o download para /Library/Caches/com.apple.act.mond, marcar executável, executar em segundo plano	/Library/Caches/com.apple.act.mond
Windows	Corpo do POST packages.npm.org/product1	Copie o PowerShell para %PROGRAMDATA%\wt.exeusar o VBS e a preparação do PS1	%PROGRAMDATA%\wt.exe
Linux	Corpo do POST packages.npm.org/product2	Baixar /tmp/ld.py, executado via nohup python3	/tmp/ld.pyhistórico de processos, registros de conexão de saída

Por que a autolimpeza foi mais importante do que o próprio conta-gotas

Muitos resumos de incidentes param depois de "o pacote tinha um RAT". Isso deixa de fora a parte que geralmente determina se uma organização subestima sua exposição. A StepSecurity relatou isso após a execução, setup.js se excluiu, removeu o arquivo malicioso package.jsone renomeado para um nome de aparência limpa package.md arquivo de volta para package.json. O resultado é que um respondente que inspeciona o diretório do pacote mais tarde pode encontrar algo que não parece notável, a menos que saiba com o que compará-lo. (StepSecurity)

Essa não é uma estrutura antiforense sofisticada no sentido de estado-nação, mas é mais do que suficiente para derrotar a forma preguiçosa de triagem de pacotes que muitas equipes utilizam nas primeiras horas de um incidente. Se todo o seu processo de análise for "abra o pacote instalado e veja se há um script mal-intencionado óbvio no package.json atual", você poderá sair com uma falsa sensação de segurança. O invasor levou isso em conta. (StepSecurity)

É por isso que um dos detalhes mais úteis na análise pública é também um dos mais simples: a presença de node_modules/plain-crypto-js/ é uma evidência significativa, mesmo que o arquivo de script mal-intencionado tenha desaparecido e os metadados do pacote agora pareçam limpos. Em um caso como esse, o próprio diretório de dependência é um sinal mais forte do que uma leitura ingênua do package.json pós-execução. (StepSecurity)

Há outra nuance específica do npm que vale a pena verificar durante a análise forense. A documentação do npm diz que as versões modernas do npm criam um arquivo de bloqueio oculto em node_modules/.package-lock.json e usá-lo para acelerar o processamento subsequente da árvore quando as condições forem atendidas. Ele também observa que o arquivo reflete o estado mais recente da árvore de dependências e pode ser ignorado ou invalidado se a árvore for alterada. Na prática, isso faz com que o arquivo de bloqueio oculto seja um artefato útil a ser analisado em um host afetado, pois pode preservar as informações da árvore que os desenvolvedores nunca comprometeram com o controle de origem. (Documentos do npm)

Um respondente que revisa apenas a raiz do repositório package-lock.json pode perder evidências criadas depois que o host resolveu as dependências localmente. No npm v7 e posteriores, o arquivo de bloqueio oculto não é apenas um detalhe de implementação. No meio de um incidente no ecossistema de pacotes, ele pode fazer parte do rastro. (Documentos do npm)

Detecção e verificação, comandos práticos que ajudam em ambientes reais

A maneira mais rápida de perder tempo em um incidente como esse é procurar apenas por axios@1.14.1 ou axios@0.30.4 no momento package.json arquivos. Muitos ambientes afetados não preservarão a história de forma tão clara. Alguns terão lockfiles gerados durante a janela ruim. Alguns terão espaços de trabalho de CI transitórios. Alguns terão árvores de dependência limpas, mas artefatos residuais de carga útil. Alguns já terão sido atualizados para fora da versão ruim após a execução da etapa de instalação. É necessário pesquisar a trilha de dependências, o host e os logs. O conjunto de IOCs abaixo vem da análise publicada pela StepSecurity. (StepSecurity)

Referência rápida conhecida do IOC a partir do registro técnico público. (StepSecurity)

Tipo de IOC	Valor
Versões maliciosas do Axios	1.14.1, 0.30.4
Dependência maliciosa	plain-crypto-js@4.2.1
Domínio C2	sfrclak.com
C2 IP	142.11.206.73
URL C2	http://sfrclak.com:8000/6202033
caminho do macOS	/Library/Caches/com.apple.act.mond
Caminho do Windows	%PROGRAMDATA%\wt.exe
Caminho do Linux	/tmp/ld.py
Corpos POST	packages.npm.org/product0, produto1, produto2
Shasums maliciosos	axios@1.14.1 2553649f2322049666871cea80a5d0d6adc700ca, axios@0.30.4 d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71, plain-crypto-js@4.2.1 07d889e2dadce6f3910dcbc253317d28ca61c766

Comece com os arquivos de bloqueio e o estado do espaço de trabalho que você ainda tem:

# Pesquise nos arquivos de bloqueio comuns as versões ruins e a dependência conhecidas
grep -RInE 'axios@1\.14\.1|axios@0\.30\.4|plain-crypto-js|sfrclak\.com' \
  package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml . 2>/dev/null

# Inspecione as árvores de dependência instaladas se node_modules ainda existir
find . -type d -name plain-crypto-js 2>/dev/null
find . -type f \( -name package-lock.json -o -path '*/node_modules/.package-lock.json' \) -print

A documentação do pacote-lock do npm diz que o arquivo de bloqueio registra a árvore resolvida exata e inclui campos como resolvido, integridadee hasInstallScript em formatos modernos. Isso torna os arquivos de bloqueio úteis não apenas para a fixação de versões, mas também para a inspeção pós-incidente. (Documentos do npm)

Se você tiver um package-lock.jsonO sistema de controle de acesso, que busca a execução em tempo de instalação, foi introduzido inesperadamente:

# Lista de pacotes que declaram um script de tempo de instalação no lockfile v2 ou v3
jq -r '
  .packages
  | to_entries[]
  | select(.value.hasInstallScript == true)
  | .key
' package-lock.json

# Extraia a fonte resolvida e a integridade de pacotes suspeitos
jq -r '
  .packages
  | to_entries[]
  | select(.key | test("plain-crypto-js$|axios$"))
  | {path: .key, version: .value.version, resolved: .value.resolved, integrity: .value.integrity, hasInstallScript: .value.hasInstallScript}
' package-lock.json

Esses campos são um comportamento documentado, não um acidente, portanto, são um local estável para criar a detecção. A maior oportunidade não é apenas verificar esse conjunto exato de IOCs. É ensinar seu processo de CI e revisão a sinalizar qualquer dependência recém-introduzida com hasInstallScript quando essa dependência não for claramente justificada pelo código do aplicativo. (Documentos do npm)

Em seguida, verifique os artefatos em nível de host que a análise pública associou à cadeia de entrega da RAT:

# macOS
ls -l /Library/Caches/com.apple.act.mond 2>/dev/null

# Linux
ls -l /tmp/ld.py 2>/dev/null
ps aux | grep -E 'ld\.py|nohup|python3' | grep -v grep

# Windows PowerShell
Get-Item "$env:ProgramData\wt.exe" -ErrorAction SilentlyContinue
Get-ChildItem $env:TEMP -Filter "6202033*" -Force -ErrorAction SilentlyContinue

Se você tiver registros de telemetria de rede ou de trabalho de CI, pesquise diretamente o domínio, o IP ou o caminho do URL:

grep -RInE 'sfrclak\.com|142\.11\.206\.73|6202033|packages\.npm\.org/product[012]' \
  /var/log .github/workflows build-logs ci-logs 2>/dev/null

Não pare quando não conseguir encontrar um artefato. A análise pública mostrou explicitamente um comportamento de autolimpeza após a execução, o que significa que algumas das pistas mais fáceis do sistema de arquivos podem estar ausentes no momento em que você começar a procurar. Em uma situação como essa, a concordância é mais importante do que um único resultado perfeito. Um registro de instalação suspeito, uma entrada de arquivo de bloqueio oculto, um diretório de dependência transitório e uma conexão de saída podem resultar em uma conclusão de alta confiança, mesmo quando o arquivo original setup.js se foi. (StepSecurity)

Lockfiles, npm ci e ignore-scripts, o que ajuda e o que não ajuda

A maneira mais fácil de errar nesse tipo de incidente é dizer que "os lockfiles resolvem o problema" ou que "os lockfiles são inúteis". Ambos são muito rudimentares. A documentação do npm diz package-lock.json registra a árvore de dependências exata para que futuras instalações possam reproduzir a mesma árvore, e npm ci foi projetado para ambientes automatizados com instalações congeladas que não reescrevem o arquivo de bloqueio. Essa repetibilidade é uma defesa real contra o desvio acidental de dependências. Se o seu repositório já tinha um arquivo de bloqueio limpo antes da janela de lançamento malicioso, npm ci normalmente manteria sua compilação nesse gráfico de dependência conhecido, em vez de resolver oportunamente para uma nova versão. (Documentos do npm)

Mas a mesma propriedade é válida para o outro lado. Se o arquivo de bloqueio foi gerado ou atualizado durante a janela maliciosa, então npm ci reinstalará fielmente e repetidamente a árvore maliciosa conforme registrado. Essa conclusão é uma inferência de engenharia do comportamento documentado do npm, não uma afirmação especial específica do Axios, mas é exatamente o tipo de inferência que os responsáveis pela resposta a incidentes precisam fazer corretamente sob pressão. As instalações determinísticas são boas. Reinstalar de forma determinística uma árvore envenenada não é. (Documentos do npm)

Há uma segunda nuance que muitas equipes não percebem. npm ci não é um modo de "instalação sem scripts". A documentação da CLI do npm mostra que npm ci, como npm install, ainda funciona pré-instalação, instalare pós-instalação a menos que você diga a ele para não fazer isso. Isso significa que um script de ciclo de vida mal-intencionado continua perigoso mesmo em pipelines que se sentem disciplinados porque usam comandos de instalação amigáveis à CI e lockfiles comprometidos. (Documentos do npm)

O controle que visa diretamente a esse risco é --ignore-scripts. o npm documenta que quando ignorar scripts for verdadeiro, ele não executará os scripts especificados em package.json arquivos. Essa configuração é uma das maneiras mais limpas de reduzir a exposição a malware de tempo de instalação em trabalhos de alta sensibilidade. A ressalva é que alguns pacotes legítimos usam scripts de tempo de instalação para compilar módulos nativos, baixar binários ou preparar ativos de tempo de execução, portanto, a configuração não é livre de atritos. Uma implementação madura trata isso como uma decisão de política com testes de compatibilidade, não como um sinalizador mágico que você coloca em cada repositório cegamente.Documentos do npm)

Um padrão de CI mais seguro para pipelines sensíveis geralmente se parece com o seguinte:

Nome: build-with-safer-dependency-install

on:
  push:
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    permissões:
      conteúdo: leitura
      id-token: gravação
    etapas:
      - usa: actions/checkout@v4

      - usa: actions/setup-node@v4
        com:
          node-version: 24
          URL de registro: https://registry.npmjs.org

      - nome: Frozen install without lifecycle scripts (Instalação congelada sem scripts de ciclo de vida)
        executar: npm ci --ignore-scripts

      - nome: Verificar assinaturas de registro
        execute: npm audit signatures

      - nome: Executar testes que não requerem compilação no momento da instalação
        executar: npm test -- --runInBand

A etapa de assinatura merece sua própria explicação. A documentação do npm diz Assinaturas de auditoria do npm verifica as assinaturas de registro ECDSA para os pacotes baixados e apresentará erros quando as versões não tiverem assinaturas nos registros que fornecem chaves de assinatura. Isso é valioso como uma verificação de integridade, mas não deve ser confundido com uma resposta completa ao comprometimento do editor. A inferência é importante aqui: a verificação de assinatura informa se o artefato que você baixou corresponde ao que o registro assinou, enquanto a publicação confiável e a proveniência falam mais diretamente sobre como e de onde o artefato foi criado e publicado. Você quer ambas as classes de controle, não uma no lugar da outra. (Documentos do npm)

A divisão de política mais prática geralmente é a seguinte: usar lockfiles confirmados e npm ci em todos os lugares, use --ignore-scripts nos caminhos mais sensíveis por padrão, tornar as exceções explícitas e tratar cada nova dependência com execução em tempo de instalação como um evento de revisão. Isso não é específico da Axios. A Axios acabou de fornecer um caso de prova doloroso. (Documentos do npm)

Resposta a incidentes após a instalação de versões maliciosas do axios

A análise de carga útil pública e a orientação de correção apoiam uma regra simples: se as versões ruins do Axios foram instaladas em um computador, não enquadre a resposta como uma tarefa de limpeza de pacote. Enquadre-a como um possível evento de exposição de host e segredo. A correção publicada pela StepSecurity recomendava explicitamente o downgrade para versões seguras, removendo criptografia simples, usando npm ci --ignore-scriptsA empresa está trabalhando na reconstrução dos sistemas afetados a partir de um estado conhecido como bom, onde foram encontrados artefatos de carga útil, alternando segredos de npm, nuvem, SSH e CI e bloqueando a infraestrutura do invasor. (StepSecurity)

Estações de trabalho do desenvolvedor

Em laptops de desenvolvedores, o primeiro objetivo é a preservação de evidências, não a limpeza estética. Capture a árvore de dependências atual, os lockfiles, os lockfiles ocultos, o histórico do shell, os registros recentes de conexão de saída e os caminhos de artefatos específicos da plataforma antes de começar a excluir diretórios. Se você limpar o espaço de trabalho imediatamente, poderá destruir a prova mais fácil de que a máquina executou a cadeia de instalação maliciosa. (StepSecurity)

Depois de obter evidências básicas, gire tudo o que possa ter sido acessado durante a instalação. Isso geralmente inclui tokens npm, credenciais do Git, chaves SSH, credenciais da CLI na nuvem, credenciais locais de .env segredos, credenciais de desenvolvimento armazenadas no navegador, caso a máquina tenha sido compartilhada entre fluxos de trabalho de código e de administração, e quaisquer PATs ou material de sessão armazenados em perfis de shell ou gerenciadores de senhas que tinham estado de desbloqueio automático durante a janela de comprometimento. A questão não é que o registro público prova que cada um desses armazenamentos foi exfiltrado. A questão é que a classe de carga útil e o contexto de execução os tornam acessíveis o suficiente para que seja difícil defendê-los mantendo-os inalterados. (StepSecurity)

Executores de CI e agentes de compilação

Os sistemas de CI merecem um tratamento mais agressivo porque são ambientes secretos de alta densidade. O blog do GitHub sobre o endurecimento do ecossistema npm descreveu especificamente a recente onda de ataques a pacotes orientados por sequestro de contas como séria o suficiente para acionar medidas de resposta em todo o registro, incluindo o bloqueio de IOCs de malware e a remoção de centenas de pacotes comprometidos. No caso da Axios, os testes de tempo de execução da StepSecurity mostraram que as conexões de saída continuam nas etapas do fluxo de trabalho e que um processo em segundo plano sobreviveu ao contexto de instalação original. Esse é exatamente o tipo de comportamento que faz com que o design do executor efêmero versus persistente seja importante. (O blog do GitHub)

Se o executor era efêmero, o host pode já ter desaparecido, mas os segredos usados no trabalho ainda estão no escopo da rotação. Se o executor era persistente, a suposição mais segura é que o computador precisa ser reconstruído a partir de uma imagem de base limpa, a menos que você tenha fortes evidências de que a ramificação maliciosa nunca foi concluída. Analise os logs de trabalho para ver as versões afetadas, pesquise os logs de rede para ver o domínio do IOC e o caminho do URL, invalide as credenciais de nuvem usadas no pipeline, gire as credenciais de registro de artefato e examine se o executor tinha acesso de gravação aos repositórios de origem ou aos destinos de implementação. (StepSecurity)

Artefatos de produção e compilações downstream

Nem toda instalação afetada significa que sua frota de produção executou o RAT diretamente, mas a confiança do artefato downstream ainda precisa ser revisada. Se uma máquina de compilação extraiu o pacote mal-intencionado do Axios e, em seguida, produziu uma imagem de contêiner, um pacote de desktop, um pacote de servidor ou um artefato de compilação de front-end, sua verdadeira pergunta não é apenas "o host foi infectado?". É também "quais saídas não devem mais ser confiáveis porque o próprio ambiente de compilação não era confiável no momento da compilação?" (StepSecurity)

Um precedente útil aqui é o aviso do GitHub para error-ex@1.3.3rastreado como CVE-2025-59330. Esse incidente de 2025 também foi descrito como uma apropriação de conta de publicação do npm, com a versão maliciosa funcionalmente semelhante ao patch anterior, exceto pela carga de malware incorporada. As recomendações de correção incluíam a remoção de módulos_nóO problema não se limitava ao diretório do pacote em si, limpando os caches do gerenciador de pacotes e reconstruindo os pacotes do navegador. O caso da Axios difere nos detalhes da carga útil, mas a lição é a mesma: não presuma que sua única unidade de limpeza seja uma única dependência. (GitHub)

Após a contenção inicial, a parte difícil é a validação reproduzível. As equipes geralmente precisam executar novamente apenas uma pequena parte do fluxo de trabalho em relação a dependências conhecidas como boas, confirmar se a atividade suspeita da rede desaparece e preservar evidências suficientes para que outro engenheiro possa reproduzir o raciocínio sem expor novamente o ambiente. Os materiais públicos da Penligent enfatizam os fluxos de trabalho agênticos controlados pelo operador, o bloqueio de escopo, as etapas editáveis e o resultado que prioriza as evidências. Na prática, essa é a postura correta para o reteste pós-incidente: manter um ser humano no circuito, restringir o escopo com firmeza e usar a automação para coletar evidências repetíveis em vez de improvisar em uma superfície comprometida. (Penligente)

Não reverta cegamente, os CVEs do axios relacionados ainda são importantes

Um dos erros mais fáceis após um evento de lançamento mal-intencionado é escolher um alvo de reversão apenas porque ele é mais antigo do que a versão ruim. Isso não é suficiente. Você também precisa de uma versão que seja realmente limpa e que não reintroduza vulnerabilidades já conhecidas do produto na própria biblioteca. O Axios é um bom exemplo porque teve problemas normais de segurança que não têm nada a ver com esse comprometimento de versão. (NVD)

O primeiro relevante é o CVE-2026-25639. O NVD o descreve como um problema de negação de serviço em mergeConfig onde o processamento de um objeto contendo __proto__ como uma propriedade própria pode travar o Axios com um TypeError. O aviso do GitHub para o mesmo problema enfatiza que isso não é uma poluição prática do protótipo porque o código falha antes que ocorra qualquer atribuição, mas ainda é um problema de disponibilidade acionável pela rede em padrões de uso expostos. As notas oficiais de lançamento do Axios mostram v1.13.5 e a versão de manutenção 0.x v0.30.3 como as correções para esse problema de DoS. (NVD)

Isso é importante aqui porque a orientação sobre incidentes públicos apontou os usuários para 1.14.0 ou 0.30.3 como pontos de restauração seguros após a versão maliciosa. Especialmente para usuários da versão 0.x, 0.30.3 não é apenas "uma versão limpa mais antiga". É também a versão de manutenção de segurança que abordou o problema de DoS de 2026 nessa ramificação. Em outras palavras, o conselho de reversão do incidente e o histórico de segurança do produto estão alinhados, o que é exatamente o que você deseja. (StepSecurity)

O segundo problema relacionado é o CVE-2024-39338. O NVD e o banco de dados consultivo do GitHub o descrevem como um problema de SSRF no Axios, em que URLs relativas a caminhos podem ser processadas como URLs relativas a protocolos nas versões afetadas da linha 1.x, com 1.7.4 como a versão corrigida. Essa vulnerabilidade é relevante aqui não porque causou a versão maliciosa de 2026, mas porque ilustra a regra mais ampla: um alvo de reversão deve ser avaliado em relação ao histórico real de vulnerabilidades da biblioteca, e não escolhido por instinto. (NVD)

A regra durável é simples. Em um incidente na cadeia de suprimentos, "bom conhecido" deve significar pelo menos três coisas ao mesmo tempo: não fazer parte da janela de publicação mal-intencionada, estar alinhado com a trilha de lançamento público do projeto e não fazer com que você regrida obviamente para defeitos de segurança conhecidos mais antigos. Muitas reversões apressadas falham no terceiro teste. (StepSecurity)

A lição mais ampla do npm: o controle de contas supera a revisão de código se os controles de liberação forem fracos

O incidente da Axios não ocorreu em um vácuo. O plano de setembro de 2025 do GitHub para uma cadeia de suprimentos npm mais segura descreveu explicitamente um aumento recente na aquisição de contas de registro de pacotes e apontou o ataque Shai-Hulud como um exemplo de injeção maliciosa de script pós-instalação por meio de contas de mantenedores comprometidas. O objetivo de mencionar isso aqui não é confundir os incidentes. É mostrar que o padrão está estabelecido o suficiente para que os defensores o tratem como uma classe de ameaça normal. (O blog do GitHub)

A mesma lição aparece em um precedente mais específico do pacote: o error-ex@1.3.3 de 2025, posteriormente rastreado como CVE-2025-59330. A assessoria do GitHub disse que o invasor obteve o controle da conta de publicação por meio de phishing, publicou uma versão maliciosa e o mantenedor emitiu posteriormente 1.3.4 acima dele para eliminar os caches e restaurar a linha limpa. Essa sequência é importante porque mostra a pouca alteração de código que um invasor às vezes precisa fazer. Uma publicação mal-intencionada pode parecer quase idêntica à versão anterior e ainda assim alterar o caminho de execução que importa. (GitHub)

É por isso que a revisão pura do código-fonte não é mais suficiente como modelo de confiança de liberação. A revisão de código pode lhe dizer muito sobre um repositório. Ela pode dizer muito menos sobre se o tarball que você instalou foi produzido pelo fluxo de trabalho que você acha que foi, se uma conta de mantenedor foi sequestrada ou se uma nova dependência foi inserida somente no momento da publicação. Proveniência, restrições de caminho de publicação, assinaturas de registro e verificações de consistência de lançamento para repositório existem porque o modelo antigo de "o repositório parecia bom" é inadequado por si só. (Documentos do npm)

A orientação de publicação confiável do próprio npm é excepcionalmente útil aqui, pois diz a parte mais tranquila em voz alta. Os tokens de longa duração podem ser expostos em registros ou configurações, exigem rotação manual e, se comprometidos, fornecem acesso persistente até serem revogados. A publicação confiável substitui isso por credenciais específicas de fluxo de trabalho e de curta duração, e o npm recomenda ir além, não permitindo tokens quando os editores confiáveis estiverem configurados e o fluxo de trabalho tiver sido verificado. Isso não é um endurecimento teórico. É uma resposta direta ao comportamento do invasor observado nessa classe de incidente. (Documentos do npm)

Fortalecimento do caminho de lançamento e do lado do consumidor

Para os mantenedores, os controles mais importantes são aqueles que reduzem a ambiguidade do editor. Use a publicação confiável sempre que possível. Restringir ou desativar a publicação tradicional baseada em tokens quando o fluxo de trabalho confiável funcionar. Revogar tokens de automação históricos. Mantenha a 2FA obrigatória. Preservar o alinhamento entre a versão pública e a tag para que os consumidores possam saber se uma versão realmente corresponde a uma versão visível do projeto. A documentação do npm também diz que a publicação confiável pode gerar automaticamente atestados de procedência para pacotes públicos publicados a partir de provedores compatíveis, o que dá aos consumidores evidências mais fortes sobre como um pacote foi criado. (Documentos do npm)

Para os consumidores, os controles precisam assumir que os editores ainda podem falhar. Arquivos de bloqueio comprometidos e npm ci reduzir o desvio acidental. --ignore-scripts reduz a exposição a malware em tempo de instalação em caminhos confidenciais. Assinaturas de auditoria do npm adiciona uma verificação de integridade. Mas você também precisa de uma lógica específica para essa classe de ameaça: alertar sobre novas dependências com scripts de instalação, alertar sobre dependências que aparecem na árvore, mas não na fonte, alertar quando as versões de pacotes públicos não estiverem alinhadas com a trilha de lançamento esperada e restringir o acesso à rede de saída de etapas de compilação que não deveriam estar buscando segundos estágios arbitrários na Internet. (Documentos do npm)

Uma regra especialmente útil em nível de lockfile vem diretamente da documentação do npm. Como os lockfiles modernos podem registrar hasInstallScript, resolvidoe integridadeSe você tiver um pacote de dados de instalação, poderá difundir esses campos em solicitações pull e falhar em compilações quando uma nova dependência introduzir inesperadamente a execução em tempo de instalação. Esse controle não impedirá todas as versões mal-intencionadas, mas visa exatamente a forma desse comprometimento da Axios: um pacote cuja finalidade real era executar durante a instalação em vez de oferecer suporte à funcionalidade do aplicativo. (Documentos do npm)

Uma pequena tabela de políticas geralmente é mais útil para as equipes do que uma longa lista de verificação abstrata, portanto, a pilha de proteção pode ser resumida assim. Os controles abaixo combinam o comportamento documentado do npm com o modo de falha exposto pelo incidente da Axios. (Documentos do npm)

Controle	Em que ele ajuda	O que ele não resolve
Publicação confiável com o OIDC	Reduz o risco de roubo de tokens de publicação de longa duração	Não ajuda totalmente se os métodos tradicionais de publicação continuarem sendo permitidos
Não permitir a publicação baseada em token	Fecha o caminho comum de fallback após a implementação do OIDC	Não corrige a fonte comprometida ou a lógica do fluxo de trabalho de CI
Arquivos de bloqueio comprometidos e npm ci	Evita o desvio surpresa da dependência	Repete um arquivo de bloqueio envenenado se ele tiver sido gerado durante a janela ruim
--ignore-scripts em trabalhos sensíveis	Bloqueia a execução em tempo de instalação das dependências	Pode quebrar pacotes legítimos que precisam de scripts de instalação
Assinaturas de auditoria do npm	Verifica a integridade do pacote assinado pelo registro	Não prova a intenção do editor nem o alinhamento entre o repositório e o pacote
Difusão de novas dependências do install-script	Captura injeções de estilo de dependência fantasma	Precisa de ajustes para evitar ruídos de fluxos de trabalho legítimos de módulos nativos
Controles rígidos de saída no CI	Torna as buscas de segundo estágio mais difíceis	Não impede danos locais causados por cargas úteis já baixadas

A parte em que muitas equipes ainda investem pouco

Um comprometimento de lançamento como esse expõe um problema organizacional mais profundo: muitas equipes têm uma boa varredura de vulnerabilidades, um inventário de dependências decente e quase nenhuma opinião forte sobre a execução em tempo de instalação. O modelo de risco ainda imagina que o perigo chega quando o aplicativo é executado na produção, e não quando o gerenciador de pacotes é executado em contextos de compilação ou desenvolvimento. A Axios é um lembrete de que essa suposição é obsoleta. O caminho do código hostil pode começar antes da conclusão de um único teste de unidade. (Documentos do npm)

Essa mudança é importante tanto para a engenharia de segurança quanto para a cultura de engenharia. Do ponto de vista técnico, o gerenciamento de pacotes deve ser incluído em seu modelo de ameaças como uma superfície de execução, e não como uma mera conveniência de distribuição. Do ponto de vista operacional, as atualizações de dependências precisam de verificações de procedência, exame minucioso de arquivos de bloqueio, revisão de scripts de instalação e expectativas de rede de compilação que sejam explícitas o suficiente para serem testáveis. "Veio do npm" não é um controle. É o início da questão da confiança. (Documentos do npm)

Julgamento final

O comprometimento da Axios é importante não porque produziu a cadeia de malware mais exótica que o ecossistema JavaScript já viu. É importante porque usou um caminho que muitas equipes ainda normalizam todos os dias: instalar um pacote confiável, permitir a execução de scripts de ciclo de vida, presumir que o nome do pacote é suficiente e seguir em frente. A análise pública mostrou uma lição mais limpa e mais perigosa. As versões maliciosas da Axios adicionaram uma dependência que o código nunca usou, contaram com a execução no momento da instalação, forneceram segundos estágios específicos da plataforma, colocaram um processo em segundo plano como daemon e, em seguida, limparam evidências locais suficientes para enganar a revisão superficial. (StepSecurity)

Se há uma conclusão duradoura, é que a revisão do código-fonte por si só não é uma defesa da cadeia de suprimentos. Você precisa de controles de caminho de liberação, publicação com reconhecimento de proveniência, disciplina de arquivo de bloqueio, ceticismo de script de instalação e resposta a incidentes que trate a instalação de dependência como um evento de execução de alta confiança. No caso da Axios, isso significaria detectar a trilha de lançamento anormal, sinalizar a dependência fantasma, restringir scripts de ciclo de vida em trabalhos confidenciais e responder às versões afetadas como um problema de comprometimento do host em vez de uma reversão de pacote de rotina. (StepSecurity)

Referências

• StepSecurity, axios comprometido no npm - versões maliciosas lançam um cavalo de Troia de acesso remoto - o passo a passo técnico público mais detalhado das versões maliciosas, injeção de dependência, comportamento de carga útil, validação de tempo de execução, IOCs e orientação de correção. (StepSecurity)
• Soquete, Pacote npm comprometido áxis - útil para o tempo público em torno de plain-crypto-js@4.2.1 e a observação de que a versão afetada do Axios não apareceu nas tags oficiais do GitHub. (Soquete)
• Lançamentos e tags do Axios GitHub - exibição da trilha de lançamento público v1.14.0 como a última versão visível 1.x e nenhuma versão pública v1.14.1 tag. (GitHub)
• Documentos do npm, Publicação confiável para pacotes npm - orientação oficial sobre publicação baseada em OIDC, os riscos de tokens de longa duração, restrição de acesso a tokens e proveniência automática. (Documentos do npm)
• Documentos do npm, npm ci e npm install - comportamento oficial para instalações congeladas e execução de scripts de ciclo de vida, incluindo por que npm ci por si só não bloqueia pós-instalação. (Documentos do npm)
• Documentos do npm, Verificação de assinaturas de registro ECDSA - referência oficial para Assinaturas de auditoria do npm. (Documentos do npm)
• Aviso do NVD e do GitHub para CVE-2026-25639 - o verdadeiro problema de DoS do Axios corrigido em 0.30.3 e 1.13.5relevante ao selecionar um destino de reversão. (NVD)
• Aviso do NVD e do GitHub para CVE-2024-39338 - o problema do Axios SSRF na linha 1.x, relevante para a regra mais ampla de que um alvo de reversão também deve ser seguro contra vulnerabilidades anteriores do produto. (NVD)
• Blog do GitHub, Nosso plano para uma cadeia de suprimentos npm mais segura - contexto mais amplo sobre a recente onda de invasões de contas de registro e injeções maliciosas pós-instalação no npm. (O blog do GitHub)
• Aviso do GitHub e NVD para CVE-2025-59330 em erro-ex - um exemplo anterior útil de uma aquisição de conta de publicação npm que produziu um lançamento de pacote malicioso e exigiu limpeza além de um único pino de versão. (GitHub)
• Penligente, CVE-2026-33634 e o comprometimento da cadeia de suprimentos da Trivy - como tags mutáveis transformaram um scanner de segurança em um ladrão de credenciais - relevante se você quiser um estudo de caso intimamente relacionado sobre confiança no caminho de lançamento, exposição de CI e por que o próprio canal de entrega de software se torna a vulnerabilidade. (Penligente)
• Penligente, VirusTotal, por que a varredura de habilidades de IA está se tornando uma linha de base de segurança - relevante para a discussão mais ampla sobre limites de confiança em torno da entrada, triagem, validação e execução em etapas de artefatos em ecossistemas de automação modernos. (Penligente)
• Página inicial da Penligent - relevante por seus fluxos de trabalho controlados pelo operador descritos publicamente, bloqueio de escopo e postura de validação que prioriza as evidências, que se encaixam melhor no problema de reteste e reprodutibilidade pós-incidente do que a automação cega não supervisionada. (Penligente)