Ataque à cadeia de suprimentos compromete 233 pacotes Laravel-Lang via GitHub

Uma campanha sofisticada de ataque à cadeia de suprimentos comprometeu o ecossistema Laravel-Lang, injetando backdoors de execução remota de código (RCE) e roubo de credenciais em 233 versões de pacotes distribuídos através de 700 repositórios no GitHub. A descoberta foi realizada em maio de 2026 pelas empresas de segurança Socket e Aikido, revelando uma tática que explora o sistema de versionamento do GitHub para redirecionar tags legítimas para forks maliciosos.

Os atacantes contornaram verificações diretas de commits manipulando tags de versão, permitindo que o código malicioso fosse distribuído automaticamente quando desenvolvedores instalavam os pacotes via Composer. O vetor de ataque utiliza o diretivo autoload.files do Composer para executar um arquivo src/helpers.php infectado, garantindo que o malware seja carregado com permissões completas da aplicação web, permanecendo invisível para auditorias de repositório padrão.

Descoberta e escopo do incidente

O incidente representa um avanço significativo nas táticas de ataque à cadeia de suprimentos de software, focando especificamente em bibliotecas de internacionalização amplamente utilizadas em aplicações PHP. A escala do comprometimento é alarmante, com 233 versões de pacotes afetadas em um total de 700 repositórios. A manipulação das tags do GitHub permitiu que os atacantes mantivessem a aparência de atualizações legítimas, explorando a confiança que desenvolvedores e sistemas de CI/CD depositam nos metadados de versão.

A descoberta foi feita por meio de análise comportamental e detecção de anomalias nos fluxos de instalação do Composer. A equipe da Aikido observou que o payload desabilitava a verificação SSL e buscava scripts secundários de um servidor de comando e controle (C2) ofuscado. O dropper inicial se disfarça como uma função de localização padrão do Laravel, utilizando métricas de hardware específicas para identificar o sistema hospedeiro e criar um arquivo marcador temporário para evitar execuções redundantes.

Vetor e exploração técnica

A exploração ocorre durante o processo de autoload do Composer. Ao invés de modificar diretamente o código-fonte do repositório original, os atacantes criam um fork malicioso e alteram as tags de versão para apontar para esse fork. Quando um desenvolvedor executa composer require ou atualiza dependências, o Composer baixa o pacote da versão apontada pela tag, que agora contém o código malicioso.

O arquivo src/helpers.php é o ponto de entrada crítico. Devido à configuração autoload.files no composer.json, este arquivo é incluído automaticamente em todas as requisições PHP, garantindo a execução do payload sem necessidade de interação do usuário. O malware realiza um fingerprinting do sistema para determinar o sistema operacional e seleciona o método de execução apropriado, conforme detalhado na tabela abaixo:

Após a execução inicial, o payload principal é baixado do servidor C2. Trata-se de um coletor de credenciais PHP extensivo contendo 15 módulos especializados. O malware varre sistematicamente o ambiente em busca de segredos sensíveis, incluindo metadados de nuvem, credenciais de banco de dados e arquivos de configuração de ambiente.

Impacto e alcance

O impacto potencial deste ataque é vasto, dado o uso generalizado do Laravel em aplicações empresariais e governamentais, incluindo no Brasil. O malware foi projetado para extrair configurações e credenciais de alto valor, o que pode levar a comprometimentos secundários em infraestruturas críticas. A lista de alvos inclui:

• Chaves de acesso em nuvem para AWS, GCP, Azure e DigitalOcean.
• Configurações de infraestrutura, incluindo perfis do Kubernetes, tokens do Docker e segredos do HashiCorp Vault.
• Ativos de desenvolvedores, como chaves privadas SSH, credenciais do Git e arquivos de histórico de shell.
• Senhas salvas no navegador, carteiras de criptomoedas e bancos de dados de gerenciadores de senhas.

Após a coleta, o malware criptografa os dados roubados usando AES-256 e os exfiltra para a infraestrutura dos atacantes antes de se auto-deletar para evitar detecção forense. Isso torna a investigação e a recuperação extremamente difíceis, exigindo uma análise profunda dos logs de rede e do sistema de arquivos.

Indicadores de comprometimento (IOCs)

A identificação rápida dos indicadores de comprometimento é crucial para a contenção. Os seguintes IOCs foram confirmados pela equipe de pesquisa:

Nota: Os endereços IP e domínios estão intencionalmente desformateados (ex: [.]) para evitar resolução acidental. Devem ser reformatados apenas dentro de plataformas controladas de inteligência de ameaças, como MISP, VirusTotal ou SIEM.

Implicações regulatórias e LGPD

Para organizações brasileiras, este incidente carrega implicações diretas sob a Lei Geral de Proteção de Dados (LGPD). Se credenciais de acesso a sistemas que processam dados pessoais forem comprometidas, a empresa pode ser obrigada a notificar a Autoridade Nacional de Proteção de Dados (ANPD) e os titulares afetados.

O vazamento de chaves de API de nuvem pode resultar no acesso não autorizado a bancos de dados contendo dados pessoais, configurando um incidente de segurança que exige notificação em até 2 dias úteis, conforme a resolução da ANPD. A responsabilidade pela segurança da cadeia de suprimentos de software é cada vez mais atribuída às organizações, especialmente quando o comprometimento ocorre através de dependências de terceiros.

Medidas de mitigação recomendadas

Os pesquisadores de segurança recomendam ações imediatas para todas as equipes de desenvolvimento e operações:

1. Rotação de Segredos: Roteie imediatamente todas as chaves de aplicação, credenciais de banco de dados e chaves de API expostas em ambientes potencialmente comprometidos.
2. Auditoria de Dependências: Inspeção dos arquivos composer.lock para bloquear pacotes Laravel-Lang afetados e verificar a integridade das versões instaladas.
3. Monitoramento de Tráfego: Audite o tráfego de saída da rede em busca de conexões suspeitas para os domínios e IPs listados nos IOCs.
4. Reconstrução de Sistemas: Sistemas que executam pacotes comprometidos devem ser reconstruídos a partir de imagens conhecidas como boas para garantir a erradicação total da ameaça persistente.

O que os CISOs devem fazer imediatamente

Executivos de segurança devem priorizar a visibilidade sobre o software em uso. A implementação de um Software Bill of Materials (SBOM) para aplicações críticas é essencial para identificar rapidamente se pacotes vulneráveis estão em produção. Além disso, a adoção de ferramentas de análise de segurança de dependências (SCA) que verifiquem não apenas vulnerabilidades conhecidas, mas também anomalias no comportamento de pacotes, deve ser acelerada.

A comunicação com as equipes de desenvolvimento deve ser clara: a confiança cega em repositórios públicos deve ser substituída por verificação de integridade e assinatura de pacotes. A segurança deve ser integrada desde a fase de design (Shift Left), garantindo que a cadeia de suprimentos seja tão rigorosa quanto a infraestrutura interna.

Perguntas frequentes

Como saber se minha aplicação foi afetada?
Verifique se você utiliza pacotes da organização Laravel-Lang. Consulte o arquivo composer.lock e compare as versões com as listas de pacotes comprometidos divulgadas pelos pesquisadores. Monitore também logs de execução de scripts PHP não autorizados.

É necessário reiniciar os servidores?
Sim, a reconstrução a partir de imagens limpas é recomendada. Apenas a remoção do arquivo malicioso pode não ser suficiente, pois o malware pode ter deixado backdoors adicionais ou persistência no sistema operacional.

Qual o risco para dados sensíveis?
O risco é alto. O malware foi projetado especificamente para roubar credenciais de nuvem e bancos de dados. Se essas credenciais forem usadas para acessar sistemas de produção, dados sensíveis podem ser exfiltrados ou criptografados.