Pacotes Lightning e Intercom foram adulterados para roubo de credenciais em cadeia de suprimentos

Versões maliciosas no PyPI, npm e Packagist executavam payloads durante instalação ou importação para coletar tokens, chaves e segredos de ambientes de desenvolvimento e CI/CD.

Componente	Pacote Python lightning nas versões 2.6.2 e 2.6.3, pacote npm intercom-client@7.0.4 e pacote Packagist intercom/intercom-php@5.0.2.
Vetor	Publicação de builds adulterados em registros de pacotes, com execução automática por importação do módulo, hooks preinstall, hooks Composer post-install-cmd e post-update-cmd.
Impacto	Coleta de tokens GitHub, credenciais npm, chaves SSH, segredos de cloud, Kubernetes, Vault, Docker, arquivos .env e credenciais presentes em ambientes de desenvolvedor e CI/CD.
Prioridade	Bloquear e remover as versões afetadas, retornar o lightning para 2.6.1, auditar instalações recentes, rotacionar credenciais expostas e revisar publicações automatizadas.
Versões	lightning 2.6.2 e 2.6.3 ficaram disponíveis por 42 minutos antes da quarentena e foram removidas; a versão segura indicada no contexto é 2.6.1.
Artefatos	Diretório _runtime, scripts start.py, setup-intercom.sh, payload router_runtime.js, arquivos .claude/settings.json e .vscode/tasks.json.
IoCs	Endpoint GitHub api.github[.]com/user para validação de tokens e exfiltração primária para zero.masscan[.]cloud:443/v1/telemetry no fluxo PHP.
Mitigação	Invalidar tokens GitHub e npm, chaves SSH e credenciais de cloud possivelmente acessíveis ao processo de instalação, além de inspecionar pacotes republicados a partir de máquinas afetadas.

Resumo técnico

Uma sequência de comprometimentos em registros de pacotes atingiu componentes usados em ambientes de desenvolvimento Python, JavaScript e PHP. O pacote Python lightning, associado ao ecossistema PyTorch Lightning, teve as versões 2.6.2 e 2.6.3 publicadas com conteúdo malicioso no PyPI em 30 de abril de 2026. Essas builds não vieram do fluxo legítimo de código-fonte: o comprometimento descrito no contexto ocorreu no canal de publicação do PyPI, com uso de credenciais de publicação, clonagem do código aberto, inserção do payload e envio direto dos pacotes adulterados ao registro. A investigação posterior indicou que o repositório GitHub do projeto não apresentou evidência de comprometimento. As versões afetadas ficaram disponíveis por 42 minutos, foram colocadas em quarentena, removidas, e a versão limpa indicada é 2.6.1.

O incidente se expandiu para o ecossistema Intercom por meio de pacotes publicados em npm e Packagist. O intercom-client@7.0.4 foi comprometido por uma publicação associada a uma conta GitHub invadida, com uso de um ramo removido que acionou um fluxo automatizado de CI para publicar o pacote. Em paralelo, o pacote PHP intercom/intercom-php@5.0.2 incorporou uma técnica equivalente adaptada ao Composer. O elo técnico informado para essa segunda onda foi uma instalação local de pyannote-audio, que trouxe o lightning comprometido como dependência transitiva. O resultado operacional é importante: uma única dependência maliciosa em uma estáção de desenvolvimento pôde atuar como ponte para comprometer credenciais de publicação e contaminar outros registros de pacotes.

Fluxo técnico

No caso do lightning, o pacote adulterado continha um diretório oculto _runtime com um downloader e um payload JavaScript ofuscado. A execução ocorria quando o módulo lightning era importado, após a instalação, sem exigir uma ação interativa adicional do usuário além do uso normal do pacote. A cadeia acionava o script Python start.py, responsável por baixar e executar o runtime JavaScript Bun. Esse runtime era então usado para iniciar o payload router_runtime.js, descrito como um arquivo ofuscado de aproximadamente 11 MB voltado à coleta ampla de credenciais. Essa escolha reduz a dependência de ferramentas já presentes no ambiente e permite transportar a lógica principal em JavaScript mesmo dentro de um pacote Python.

Depois da coleta, os tokens GitHub encontrados eram validados contra api.github[.]com/user. Tokens com permissão de escrita eram usados para inserir um payload com comportamento de propagação em até 50 ramos de cada repositório acessível ao token. A operação fazia criação ou sobrescrita silenciosa de arquivos, sem verificação prévia de conteúdo existente, e os commits adulterados usavam uma identidade fixa projetada para parecer associada ao Claude Code. Além do caminho GitHub, o malware também possuía propagação via npm: modificava pacotes locais do desenvolvedor, adicionava um hook postinstall ao package.json, incrementava a versão de patch e reempacotava tarballs .tgz. Se o desenvolvedor publicasse esses pacotes a partir da máquina afetada, a contaminação passava a alcançar usuários downstream pelo registro npm.

O comprometimento do intercom-client@7.0.4 reutilizou a ideia de execução no momento da instalação, mas por meio de hook preinstall. No Packagist, intercom/intercom-php@5.0.2 adaptou a cadeia para o Composer: o script setup-intercom.sh era chamado em eventos post-install-cmd e post-update-cmd, baixava o Bun e iniciava o router_runtime.js. O payload PHP mirava o mesmo tipo de material sensível observado nos demais ambientes: tokens GitHub, credenciais npm, chaves SSH, credenciais de cloud, Kubernetes, Vault, Docker, arquivos .env e outros segredos presentes em estáções de desenvolvimento e pipelines. No fluxo PHP, os dados roubados eram criptografados antes da exfiltração para zero.masscan[.]cloud:443/v1/telemetry; se esse caminho falhasse, havia fallback por abuso de tokens GitHub roubados, com criação de repositório público e descrição associada à campanha Mini Shai-Hulud.

Superfície afetada

A superfície de risco não se limita a aplicações que executaram código em produção. O alvo central foram ambientes capazes de instalar, importar, empacotar ou publicar dependências, incluindo notebooks de desenvolvimento, estáções de mantenedores, runners de CI/CD e máquinas com credenciais persistidas para múltiplos registros. Qualquer instalação ou atualização que tenha recebido lightning 2.6.2 ou 2.6.3 do PyPI durante a janela de exposição precisa ser tratada como potencial execução de código malicioso. O mesmo raciocínio vale para intercom-client@7.0.4 em npm e intercom/intercom-php@5.0.2 em Packagist, especialmente quando a instalação ocorreu em contexto com tokens GitHub, npm, chaves SSH, arquivos .env ou credenciais de infraestrutura disponíveis ao processo.

A cadeia é grave porque combina roubo de segredos com capacidade de publicação e propagação. Um token GitHub com escopo de escrita permite alterar repositórios; um token npm pode permitir repacotar e republicar artefatos; credenciais de cloud, Docker, Kubernetes e Vault podem ampliar o acesso para ambientes operacionais. A presença de hooks de instalação também torna builds automatizados uma zona crítica, pois pipelines normalmente executam comandos de instalação com variáveis de ambiente, secrets de deploy e credenciais de registro disponíveis em tempo de execução. Mesmo quando o pacote comprometido foi instalado em uma máquina de desenvolvimento sem acesso direto à produção, os segredos locais e permissões de publicação podem ter sido suficientes para contaminar outros artefatos.

• Instalações de lightning==2.6.2 ou lightning==2.6.3 feitas a partir do PyPI em 30 de abril de 2026, durante a janela de 42 minutos em que as versões ficaram disponíveis.
• Projetos npm que instalaram intercom-client@7.0.4 ou que publicaram pacotes a partir de máquinas onde o malware alterou package.json, incrementou versão de patch e reempacotou .tgz.
• Projetos PHP que instalaram ou atualizaram intercom/intercom-php@5.0.2 e executaram eventos Composer post-install-cmd ou post-update-cmd.
• Ambientes de CI/CD e estáções de mantenedores com tokens GitHub, npm, chaves SSH, credenciais de cloud, Kubernetes, Vault, Docker ou arquivos .env acessíveis durante a instalação.

Hunting e telemetria

A investigação deve começar pelo inventário de dependências e pela reconstrução temporal das instalações. Em Python, equipes devem revisar logs de pip, caches de pacote, artefatos de build e imagens de contêiner criadas no período em que lightning 2.6.2 e 2.6.3 estiveram disponíveis. Em JavaScript, vale procurar evidências de execução de hook preinstall ou postinstall, alterações inesperadas em package.json, incremento não planejado de patch version e geração de tarballs .tgz após a instalação. Em PHP, a telemetria relevante inclui execução de Composer com post-install-cmd ou post-update-cmd, presença de setup-intercom.sh e qualquer tentativa de baixar ou iniciar Bun a partir de um pacote que normalmente não exigiria esse runtime.

No endpoint, os sinais de maior valor são criação do diretório _runtime, presença de start.py, router_runtime.js, execução de Bun em contexto de instalação de dependências e gravação de arquivos .claude/settings.json ou .vscode/tasks.json. Em identidade e SCM, a análise deve buscar validações de tokens contra api.github[.]com/user, criação ou modificação de arquivos em múltiplos ramos de repositórios, commits com identidade fixa estranha ao projeto e criação de repositórios públicos fora do padrão operacional da organização. Em rede, a tentativa de conexão para zero.masscan[.]cloud:443/v1/telemetry é um indicador relevante para o fluxo PHP descrito; sua ausência não encerra a investigação, porque o payload possuía fallback por GitHub quando a exfiltração primária não funcionava.

• Consultas em logs de instalação por lightning==2.6.2, lightning==2.6.3, intercom-client@7.0.4 e intercom/intercom-php@5.0.2.
• Busca em endpoints e artefatos de build por _runtime, start.py, router_runtime.js, setup-intercom.sh, .claude/settings.json e .vscode/tasks.json.
• Revisão de eventos GitHub envolvendo api.github[.]com/user, commits inesperados em vários ramos, criação de repositórios públicos e alterações feitas por identidades não reconhecidas.
• Inspeção de pacotes npm locais com hooks postinstall, alteração de patch version e tarballs .tgz gerados depois da instalação de dependências suspeitas.
• Telemetria de rede para zero.masscan[.]cloud:443/v1/telemetry, considerando que a campanha possuía mecanismo alternativo de exfiltração por GitHub.

Mitigação

A resposta deve tratar a instalação dos pacotes afetados como possível execução de código com acesso ao mesmo conjunto de permissões do usuário ou runner que executou o gerenciador de pacotes. A primeira ação é bloquear as versões maliciosas nos controles de dependência, remover instalações existentes e fixar lightning em 2.6.1 quando o projeto depender desse pacote. Também é necessário invalidar caches de build e artefatos que possam ter incorporado os pacotes adulterados. Em CI/CD, a prioridade é interromper pipelines que tenham executado instalações durante a janela de exposição, preservar logs e identificar quais secrets estavam disponíveis no ambiente de execução.

A rotação de credenciais precisa ser ampla o suficiente para cobrir o que o payload buscava. Tokens GitHub e npm usados em estáções ou pipelines afetados devem ser revogados e recriados; chaves SSH, credenciais de cloud, Kubernetes, Vault, Docker e variáveis em arquivos .env devem ser consideradas expostas se estavam acessíveis ao processo. Depois da rotação, repositórios e pacotes publicados por contas afetadas precisam ser revisados em busca de commits, ramos, hooks ou versões geradas fora do fluxo normal. Controles preventivos devem incluir publicação com identidade separada, tokens de curta duração, escopos mínimos, proteção de ramos, revisão de workflows de CI que publicam automaticamente a partir de ramos temporários e políticas de bloqueio para versões conhecidamente comprometidas em PyPI, npm e Packagist.

A validação final não deve depender apenas de remover o pacote. Como a cadeia tinha propagação, a organização precisa confirmar que nenhum pacote interno foi reempacotado e republicado com hook malicioso, que nenhum repositório recebeu arquivos de payload e que nenhum segredo antigo continua válido. Em ambientes com múltiplos times, o escopo da resposta deve incluir mantenedores que instalaram dependências localmente, runners compartilhados, imagens base reutilizadas e qualquer automação com permissão de publicar pacotes. O ponto técnico central é reduzir a chance de uma estáção contaminada continuar servindo como canal de distribuição depois que a versão inicial já foi removida dos registros públicos.

• Bloquear lightning 2.6.2 e 2.6.3, intercom-client@7.0.4 e intercom/intercom-php@5.0.2 em mirrors, proxies e políticas de dependência.
• Remover instalações afetadas, limpar caches de gerenciadores de pacotes e reconstruir artefatos a partir de dependências verificadas.
• Rotacionar tokens GitHub e npm, chaves SSH, credenciais de cloud, Kubernetes, Vault, Docker e segredos presentes em .env acessíveis durante instalações suspeitas.
• Auditar repositórios para commits inesperados em até 50 ramos, arquivos de payload, identidades de commit não reconhecidas e repositórios públicos criados por automação comprometida.
• Revisar workflows de publicação automática para impedir que um ramo transitório ou uma estáção de mantenedor comprometida publique pacotes sem aprovação e sem credenciais de escopo mínimo.