Ataque a pacotes Laravel-Lang compromete 700 versões e instala roubador de credenciais em ambientes PHP

502 tags reescritas em menos de uma hora

Na madrugada de 22 de maio de 2026, entre 22h32 e 23h24 UTC, um agente com acesso de escrita à organização Laravel-Lang no GitHub reescreveu as 502 tags históricas de quatro pacotes PHP mantidos pela comunidade: laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes e laravel-lang/actions. O incidente foi divulgado publicamente pelas firmas Socket e Aikido Security em 23 de maio, com uma issue aberta no repositório oficial do projeto confirmando o comprometimento na mesma data.

Esses pacotes não fazem parte do framework Laravel oficial. São bibliotecas de localização de terceiros, amplamente utilizadas por aplicações Laravel para internacionalização, distribuídas pelo Packagist, o repositório central de pacotes PHP. A Socket contabilizou mais de 700 versões comprometidas; a Aikido confirmou 233 artefatos de pacote afetados em três dos quatro repositórios. O montante varia porque a Socket inclui todas as tags históricas reescritas, enquanto a Aikido contabiliza apenas os artefatos com payload funcional verificado.

Como o payload executa sem alertas

O arquivo malicioso src/helpers.php foi adicionado a cada versão comprometida e registrado na chave autoload.files do composer.json. Qualquer desenvolvedor que executasse composer install ou composer update contra uma versão comprometida carregava o stealer automaticamente no primeiro request PHP da aplicação, sem nenhum aviso de segurança ou mudança de hash visível no Packagist. O código conecta-se ao domínio C2 flipboxstudio[.]info para baixar um segundo estágio multiplataforma, compatível com Windows, Linux e macOS.

Chaves de cloud (AWS, GCP e Azure), secrets do Kubernetes e do HashiCorp Vault, tokens de pipelines CI/CD, chaves SSH, arquivos .env, dados de navegadores Chromium e Firefox, cofres de gerenciadores de senhas e configurações locais de ferramentas como o Anthropic Claude Code figuram entre os dados-alvo do stealer. Para times de DevSecOps com múltiplos repositórios, um único composer update em uma máquina de build pode ter exposto toda a cadeia de credenciais organizacionais em questão de segundos.

Os metadados dos commits comprometidos listam o autor como "Your Name <you@example.com>", a configuração padrão do Git, o que sugere uso de um ambiente recém-configurado ou tentativa deliberada de não deixar rastros identificáveis.

O vetor que diferencia este ataque

O atacante não explorou nenhuma vulnerabilidade no Packagist ou no Composer. Obteve acesso de escrita direto à organização Laravel-Lang no GitHub e substituiu versões históricas que desenvolvedores consideram estáveis e auditadas. Diferente do typosquatting clássico ou da publicação de versões novas maliciosas, este ataque comprometeu versões antigas travadas em arquivos composer.lock sem alterar nenhum número de versão visível ao time de desenvolvimento. Pipelines de integração contínua configurados para fixar versões historicamente verificadas, justamente para evitar atualizações não auditadas, tornaram-se o principal vetor de distribuição do payload.

A StepSecurity, que rastreia a campanha Megalodon de comprometimento de pipelines de GitHub Actions ativa desde 18 de maio de 2026, conectou este incidente a um padrão mais amplo: o atacante obtém credenciais organizacionais do GitHub e opera em escala contra todos os repositórios acessíveis. O vetor inicial de acesso à organização Laravel-Lang ainda não foi confirmado publicamente pelas firmas de segurança.

Ações imediatas para times de segurança

Organizações com dependências nos quatro pacotes afetados devem auditar o grafo de dependências do Composer e comparar os hashes das versões instaladas com os registros legítimos do Packagist. O GitHub Advisory Database publicou um comando de detecção para verificar nos logs do sistema se houve exploração. Toda credencial presente em ambientes que executaram as versões comprometidas a partir de 22 de maio deve ser tratada como potencialmente exposta e rotacionada: no mínimo, tokens de GitHub Actions, chaves de acesso à cloud e certificados SSH.

A Packagist e a equipe do Laravel-Lang removeram as versões maliciosas e restauraram os repositórios a partir do histórico legítimo. O incidente aponta para uma lacuna estrutural persistente nas cadeias de dependência PHP: o Composer confia, por padrão, na integridade dos commits Git subjacentes às tags sem verificação criptográfica independente. Projetos com SLSA nível 3 ou assinatura via Sigstore detectariam a adulteração automaticamente; a maioria dos fluxos de trabalho PHP ainda não opera nesse nível de rastreabilidade, e a chegada do ataque via uma organização confiável do GitHub deve mudar esse cálculo para times de segurança que ainda adiavam a adoção.