Ataque à cadeia de suprimentos no Packagist usa `package.json` para executar binário Linux

O comprometimento atingiu oito pacotes Composer e deslocou a execução maliciosa para ganchos JavaScript, ampliando o risco em projetos PHP com etapas de construção baseadas em Node.js.

Componente	Oito pacotes Composer publicados no Packagist, com alteração maliciosa inserida em package.json e não em composer.json.
Vetor	Execução por gancho postinstall em projetos que instalam dependências JavaScript junto de código PHP; em pelo menos dois casos, o mesmo payload também foi posicionado em arquivos de workflow do GitHub Actions.
Impacto	O instalador tenta baixar um binário Linux de uma URL de GitHub Releases, gravá-lo em /tmp/.sshd, conceder permissão de execução e iniciá-lo em segundo plano, criando execução remota de código durante instalação ou construção.
Prioridade	Bloquear versões afetadas removidas do Packagist, revisar artefatos de pacote que combinem Composer e package.json, e procurar execuções anômalas em instalações, pipelines e ambientes Linux.
Artefatos	Caminho local /tmp/.sshd, nome observado gvfsd-network e repositório defangado github[.]com/parikhpreyash4/systemd-network-helper-aa5c751f.
Limite conhecido	A função final do binário de segundo estágio não foi determinada porque a conta do GitHub associada ao repositório não está mais disponível.

Resumo técnico

Uma campanha coordenada de cadeia de suprimentos comprometeu oito pacotes no Packagist ao inserir lógica maliciosa em package.json dentro de pacotes Composer. O aspecto central do caso é o deslocamento do ponto de execução: a alteração não foi feita em composer.json, que normalmente receberia mais atenção em auditorias de dependências PHP, mas em metadados usados por ferramentas JavaScript. Essa escolha cria uma zona de risco para aplicações que distribuem código PHP junto com etapas de construção, empacotamento ou instalação baseadas em Node.js, porque a dependência pode parecer inofensiva em uma revisão concentrada apenas no ecossistema Composer.

As versões maliciosas foram removidas do Packagist, mas o padrão observado continua importante para defesa porque demonstra uma técnica de posicionamento entre ecossistemas. Em vez de depender exclusivamente do instalador PHP, o operador aproveitou ganchos de ciclo de vida de package.json, em especial postinstall, para tentar executar um instalador em sistemas Linux. O fluxo descrito baixa um binário a partir de uma URL de GitHub Releases, salva o conteúdo em /tmp/.sshd, altera permissões para permitir execução por usuários e inicia o arquivo em segundo plano. Mesmo sem confirmação sobre as capacidades do binário final, a cadeia já é suficiente para caracterizar risco de execução remota de código em instalação local, imagem de construção, tarefa de integração contínua ou workflow de entrega.

O caso também envolve sinais de reutilização além dos oito pacotes afetados. Foram encontradas referências ao mesmo payload em 777 arquivos no GitHub, incluindo pelo menos dois arquivos de workflow. Esse número não confirma 777 compromissos distintos, porque pode incluir forks, artefatos duplicados, cópias em cache ou referências repetidas. Ainda assim, ele indica que a investigação defensiva não deve ficar limitada ao Packagist. O mesmo instalador pode aparecer em repositórios, automações e pipelines, com gatilhos diferentes conforme o ambiente em que o projeto é construído.

Fluxo técnico

O fluxo malicioso começa quando um projeto consome uma versão afetada de um dos pacotes Composer e também processa o package.json incluído no artefato. Essa condição é relevante: um pacote PHP pode carregar arquivos auxiliares usados por front-end, empacotamento, teste ou construção, e ambientes modernos frequentemente executam rotinas JavaScript durante preparação de releases ou imagens. Ao colocar o payload em postinstall, o operador depende de uma etapa legítima do ciclo de instalação do ecossistema JavaScript, não de uma exploração de memória ou de uma vulnerabilidade específica no Composer.

Quando acionado, o instalador tenta recuperar um binário Linux hospedado em GitHub Releases. O indicador de repositório foi observado como github[.]com/parikhpreyash4/systemd-network-helper-aa5c751f, defangado aqui para evitar link ativo. O arquivo baixado é gravado em /tmp/.sshd, um caminho que mistura diretório temporário com nome semelhante a serviço SSH, o que pode reduzir a atenção em revisões superficiais de processo ou arquivo. A cadeia também tenta conceder permissão de execução usando chmod e iniciar o binário em segundo plano, com supressão de erros e desativação de verificação TLS durante a recuperação do conteúdo.

A escolha do nome gvfsd-network para o malware é tecnicamente significativa porque remete a um daemon legítimo associado ao GNOME Virtual File System, usado para gerenciamento e navegação de compartilhamentos de rede em ambientes Linux. Essa semelhança não prova persistência, privilégio elevado ou movimentação lateral, mas pode dificultar análise visual em listas de processos quando operadores esperam encontrar componentes gráficos ou serviços do usuário. O dado confirmado é a tentativa de execução do binário; capacidades posteriores, coleta de dados, comunicação de comando e controle ou persistência não foram determinadas no material recebido.

A presença do mesmo payload em workflows do GitHub Actions amplia a superfície de execução. Em artefatos de pacote, o gatilho ocorre durante rotinas de instalação baseadas em package.json; em arquivos de workflow, a execução pode ocorrer no contexto de jobs de CI/CD. Esse ponto muda a telemetria relevante: além de endpoints de desenvolvedores, ambientes efêmeros de construção, runners e caches de dependências podem ter processado o instalador. Como o repositório do GitHub que hospedava o binário não está mais disponível, a resposta deve tratar a ausência do segundo estágio como lacuna de análise, não como evidência de baixa severidade.

Superfície afetada

A superfície primária é formada por projetos que instalaram versões afetadas dos oito pacotes Composer publicados no Packagist antes da remoção das versões maliciosas. O risco é maior quando a aplicação PHP também executa etapas de construção JavaScript, porque o payload foi colocado em package.json. Projetos que apenas resolvem dependências Composer sem processar ganchos JavaScript podem não acionar o mesmo caminho, mas ainda devem verificar artefatos baixados, caches e lockfiles para confirmar que não houve execução em alguma etapa automatizada.

Ambientes de desenvolvimento, imagens Docker de construção, runners de CI/CD e pipelines que instalam dependências de forma automática são pontos críticos. A execução do gancho pode ocorrer em máquinas de desenvolvedores, em servidores de build ou em jobs efêmeros, dependendo de onde a rotina de instalação JavaScript foi processada. Em pipelines, o impacto defensivo inclui possível exposição de segredos disponíveis ao job, como variáveis de ambiente, tokens de publicação, credenciais de registro e chaves temporárias. O contexto não confirma exfiltração desses dados, portanto a resposta deve tratar isso como risco condicionado à execução do binário em ambiente com segredos acessíveis.

A superfície secundária envolve repositórios que contenham cópias do payload em package.json, workflows do GitHub Actions ou artefatos derivados. As 777 referências identificadas no GitHub devem ser interpretadas com cautela: elas não equivalem automaticamente a 777 vítimas, nem indicam que todos os arquivos executaram o instalador. O valor operacional está em usar esse padrão para varredura interna, priorizando repositórios que tenham histórico recente de alterações em arquivos de manifesto, workflows ou scripts de instalação.

• Pacotes Composer no Packagist que incluíam package.json com gancho postinstall malicioso.
• Projetos PHP que também executam ferramentas JavaScript durante instalação, build, teste ou empacotamento.
• Runners de GitHub Actions e outros ambientes de CI/CD que possam ter processado workflows contendo o mesmo payload.
• Hosts Linux onde uma instalação poderia gravar e iniciar arquivo em /tmp/.sshd com processo apresentado como gvfsd-network.

Hunting e telemetria

A investigação deve começar pela cadeia de dependências. Times de AppSec e engenharia devem revisar lockfiles, caches de pacote, espelhos internos e histórico de instalação para identificar se alguma das versões removidas foi resolvida em ambiente local ou de CI/CD. Como os nomes dos oito pacotes não estão disponíveis no material recebido, a busca não deve inventar lista de pacotes; o caminho defensivo mais confiável é procurar o padrão técnico: presença de package.json inesperado em pacote Composer, ganchos postinstall que iniciem downloads externos e referências ao repositório defangado ou ao caminho /tmp/.sshd.

Em endpoints Linux e runners, a telemetria mais útil envolve criação de arquivo em diretório temporário, alteração de permissão seguida de execução e processo em segundo plano com nome semelhante a componente legítimo. Logs de EDR, auditd, histórico de processos, eventos de shell e rastros de rede podem revelar tentativa de conexão a GitHub Releases durante instalação de dependências. A defesa deve correlacionar o horário da execução com comandos de gerenciadores de pacote, jobs de CI/CD, criação de workspace e etapas de build. Esse encadeamento ajuda a separar atividade legítima de desenvolvimento de execução disparada por pacote comprometido.

Em repositórios, a busca deve cobrir package.json, arquivos de workflow e alterações recentes em scripts de instalação. O padrão de ataque se destaca por misturar pacote Composer com gancho JavaScript, então uma consulta limitada a composer.json ou a dependências PHP pode perder o ponto de execução. Também é importante revisar pull requests, commits de atualização de dependências e artefatos gerados por automação, porque payloads em cadeia de suprimentos podem entrar por atualização aparentemente rotineira e ser preservados em cache mesmo após remoção da versão maliciosa do registro público.

• Referências a /tmp/.sshd, gvfsd-network ou ao repositório defangado github[.]com/parikhpreyash4/systemd-network-helper-aa5c751f em logs, repositórios e artefatos.
• Execução de ganchos postinstall em pacotes que deveriam ser tratados primariamente como dependências Composer.
• Conexões para GitHub Releases durante instalação de dependências PHP ou durante jobs de construção.
• Eventos de criação de arquivo em /tmp, alteração de permissão de execução e processo iniciado em segundo plano no mesmo intervalo.
• Workflows do GitHub Actions modificados para incluir lógica de download e execução associada ao mesmo payload.

Mitigação

A mitigação deve priorizar contenção da cadeia de dependências e reconstrução de confiança nos ambientes que processaram os pacotes. A primeira ação é bloquear o uso das versões afetadas já removidas do Packagist e impedir que caches internos continuem oferecendo artefatos comprometidos. Em seguida, é necessário revisar registros de build e instalação para identificar onde o postinstall pode ter sido executado. Quando houver evidência de execução, o host ou runner deve ser tratado como potencialmente comprometido até que a investigação confirme ausência de processo remanescente, arquivo baixado e comunicação externa relacionada.

Em CI/CD, a resposta deve incluir invalidação de runners efêmeros, limpeza de workspaces, revisão de variáveis de ambiente disponíveis aos jobs e rotação de segredos expostos durante janelas de execução suspeita. O contexto não confirma roubo de credenciais, mas um binário executado em pipeline pode ter acesso aos mesmos privilégios do job. Por isso, a rotação deve ser guiada por escopo: tokens de publicação, credenciais de registro, chaves de acesso a infraestrutura e segredos de deploy usados nos workflows que processaram o pacote ou o payload devem receber prioridade.

Para reduzir recorrência, políticas de segurança de dependências devem inspecionar manifestos além do ecossistema principal da aplicação. Em projetos PHP, isso significa revisar também package.json, scripts de instalação, workflows e chamadas de download remoto embutidas em artefatos. Controles de saída de rede em build, permissões mínimas para jobs e aprovação explícita de scripts de ciclo de vida ajudam a conter técnicas de colocação cruzada. A validação final deve combinar revisão de repositório, telemetria de endpoint e auditoria de pipelines, porque a mesma cadeia pode aparecer em pacote publicado, workflow ou cópia preservada em cache.

• Remover ou bloquear versões afetadas em registries, espelhos internos, caches de dependência e imagens de construção.
• Revisar package.json dentro de pacotes Composer e negar ganchos postinstall que baixem binários ou executem conteúdo externo sem justificativa aprovada.
• Procurar e remover artefatos locais como /tmp/.sshd quando associados à janela de instalação suspeita, preservando evidências antes de limpeza em ambientes investigados.
• Rotacionar segredos acessíveis a jobs de CI/CD que possam ter executado o instalador, priorizando tokens de publicação e credenciais de deploy.
• Aplicar controle de saída de rede em pipelines para reduzir downloads arbitrários durante instalação de dependências.
• Auditar workflows do GitHub Actions em busca do mesmo padrão de download e execução, especialmente quando modificados recentemente.