PolinRider no npm: qual release chegou a executar?
Um pacote presente no lockfile e um processo que executou seu código representam evidências diferentes. A resposta precisa ligar a release ao entrypoint e à autoridade disponível no host.
Read in EnglishPor Pentesty
O que a pesquisa de novembro estabelece
Em sua análise de 4 de novembro de 2026, a Sonatype identificou loaders em 12 releases de dez pacotes npm comprometidos. Os manifests examinados não tinham hooks de instalação ou pós-instalação para o consumidor: o código podia ser acionado ao carregar um entrypoint afetado ou iniciar a aplicação empacotada. A presença no lockfile, isoladamente, não comprova execução.
Os loaders compartilham uma carteira Ethereum usada como resolvedor de infraestrutura, com sobreposição à atividade PolinRider documentada anteriormente. A Sonatype não estabelece, com isso, que GhostAction e PolinRider tenham o mesmo operador. O contexto de 27 de outubro da GitGuardian também preserva essa distinção. Esta análise de 9 de novembro trata de confiança na release, sem atribuir novos comprometimentos a empresas.
Monte uma trilha entre pacote e processo
Proponha uma ficha por serviço: repositório, release entregue, lockfile aprovado, artefato produzido e ambiente de execução. Vincule esses registros por identificadores e horários. Um inventário de dependências responde o que foi selecionado; os registros da entrega devem mostrar para onde aquela seleção foi distribuída.
Depois, identifique o arquivo efetivamente carregado. Um pacote pode oferecer caminhos distintos conforme a importação e a configuração da aplicação. A decisão deve documentar qual caminho foi usado, quais registros o sustentam e onde há lacunas. Ausência de telemetria exige uma conclusão limitada, acompanhada de prazo e responsável pela apuração.
A aprovação precisa atravessar a fronteira da instalação
Para um exercício autorizado, crie uma dependência interna inofensiva com uma função documentada e um marcador local quando essa função for chamada. Use um ambiente isolado, sem credenciais de produção. Compare a instalação, o teste da aplicação e sua inicialização, registrando em qual etapa aparece o marcador. Não reproduza o loader da campanha.
Esse exercício permite verificar se a revisão acompanha a função executada, além dos scripts declarados na instalação. Defina uma aprovação explícita para mudanças de entrypoint e para o artefato que seguirá à produção. O resultado esperado inclui um bloqueio demonstrável para uma release não aprovada e a continuidade da operação legítima.
Associe o host às credenciais que ele podia usar
Prepare uma matriz de autoridade por contexto: estação do desenvolvedor, runner, servidor de build e serviço implantado. Registre os emissores de credenciais, recursos permitidos e duração das sessões. Essa organização orienta decisões de contenção sem publicar valores secretos no relatório.
Use identidades sintéticas para testar a revogação no serviço emissor e a aceitação da substituta apenas no escopo previsto. Se a investigação encontrar execução maliciosa, coordene preservação de evidências e recuperação do host com os responsáveis. Remover uma versão do projeto não demonstra, por si só, o estado dos processos e acessos anteriores.
Defina quando a entrega pode voltar
O aceite deve reunir uma dependência substituta revisada, um artefato reconstruído e registros do ambiente que o recebeu. Especifique quem confirma cada etapa e como uma exceção será reavaliada. Um teste funcional confirma a atividade esperada; a avaliação de segurança precisa também cobrir a autoridade e os efeitos fora dessa atividade.
Compare também duas rotas de entrega autorizadas: uma que deve rejeitar o artefato não aprovado e outra que distribui a substituta revisada. Use apenas arquivos inofensivos nesse teste. Relacione a decisão do repositório interno ao identificador recebido pelo consumidor, para demonstrar que o bloqueio vale no ponto em que a equipe realmente obtém a dependência.
Preserve os registros da entrega anterior mesmo depois da substituição. Marque separadamente o período investigado e o início da operação aceita. Essa separação permite perguntar se uma credencial era válida quando o processo existia, sem apresentar o teste atual como prova de que não houve efeito no passado. A aprovação deve incluir o que continua desconhecido. Preserve a decisão do responsável junto ao identificador do artefato e ao registro de aceite do serviço.
Conecte esse trabalho à revisão de workflows e estações no caso GhostAction. São caminhos de execução diferentes que podem alcançar credenciais do mesmo negócio. A pergunta útil para a liberação é quais evidências sustentam a confiança naquele código, naquele processo e naquela identidade.
Perguntas frequentes
Bloquear scripts de instalação encerra a avaliação?
Não. A pesquisa descreve acionamento no carregamento de código ou na inicialização. A avaliação deve incluir o entrypoint que a aplicação realmente usa.
O lockfile comprova comprometimento do host?
Ele comprova uma seleção de dependência no registro examinado. A conclusão sobre execução precisa de outras evidências, com as limitações explicitadas.
A relação técnica prova um único operador?
Não. Infraestrutura e mecanismos compartilhados são vínculos técnicos; as fontes consultadas não estabelecem autoria comum entre GhostAction e PolinRider.
É necessário executar malware para testar o processo?
Não. Use uma dependência própria e inofensiva, marcadores locais e identidades sintéticas, dentro de um escopo autorizado e isolado.
Fontes e referências
- Sonatype: pesquisa sobre releases npm, 4 de novembro
- GitGuardian: contexto GhostAction e PolinRider, 27 de outubro
Análise original da Pentesty, publicada em 9 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.