Alerta sobre ataque à cadeia de suprimentos do Laravel Lang

Ataque à cadeia de suprimentos do Laravel-Lang: mais de 700 versões históricas do Packagist comprometidas

Atualização — 25 de maio de 2026: Atualizamos esta publicação com novas descobertas da investigação em andamento. A atualização esclarece o mecanismo do comprometimento, substitui referências anteriores a um fluxo de publicação baseado em fork e inclui orientações para usuários do Composer/Packagist sobre como determinar se um projeto foi afetado. Como os números das versões afetadas foram posteriormente associados novamente a código legítimo, talvez não seja possível confirmar o impacto apenas pelos números das versões. Clientes da Snyk devem consultar a seção “Detectando o ataque à cadeia de suprimentos do Laravel Lang com a Snyk” para ver as orientações atualizadas de análise, triagem e correção.

Em resumo

Em 22 e 23 de maio de 2026, um invasor republicou centenas de versões maliciosas sob tags de versões históricas de quatro bibliotecas de localização do Laravel mantidas pela comunidade e publicadas no Packagist no namespace laravel-lang.

Um arquivo helpers.php injetado foi incluído na entrada autoload.files do Composer, fazendo com que fosse executado a cada solicitação PHP assim que o pacote fosse instalado. Esse mecanismo acessa flipboxstudio[.]info, baixa um segundo estágio multiplataforma e executa um ladrão de credenciais que coleta chaves de nuvem, segredos do Kubernetes e do Vault, tokens de CI/CD, dados de SSH, arquivos de ambiente, dados de navegadores, cofres de gerenciadores de senhas, carteiras de criptomoedas e tokens de mensagens.

Todo ambiente que instalou uma das versões afetadas da biblioteca de localização do Laravel deve ser considerado comprometido até que se prove o contrário.

Sobre o componente afetado

Os pacotes em questão estão no namespace laravel-lang/* no Packagist e no GitHub.

A comunidade Laravel os utiliza amplamente para distribuir strings de tradução, mensagens de validação, descrições de status HTTP e outros recursos localizados em mais de setenta idiomas.

A equipe principal do Laravel não mantém esses pacotes, e eles não fazem parte do framework oficial do Laravel, embora sejam instalados no diretório típico de aplicações Laravel e apareçam com frequência como dependências transitivas em outros auxiliares de localização. Como os pacotes são instalados pelo Composer e registrados por meio de composer.json, qualquer código malicioso incluído neles é carregado e executado automaticamente pelo ambiente de execução da aplicação.

Pacotes afetados

Todas as versões publicadas dos quatro pacotes a seguir foram consideradas comprometidas. O Packagist removeu temporariamente os pacotes da lista, mas eles voltaram a ser listados após a correção.

Estimativas iniciais de pesquisadores apontavam cerca de 233 versões envenenadas, mas o número aumentou à medida que o invasor continuou publicando tags. As informações mais recentes indicam aproximadamente 700 versões históricas nos quatro pacotes.

Linha do tempo conhecida

Como ocorreu o comprometimento

O invasor obteve acesso aos repositórios comprometidos por meio de um token de acesso pessoal (PAT) do GitHub que vazou, possivelmente em decorrência de uma violação de dados recente do GitHub. Com esse acesso, substituiu muitas ou todas as tags de lançamento em quatro repositórios laravel-lang/ por versões maliciosas semelhantes, que apontavam para commits próprios contendo malware. Os demais repositórios legítimos, incluindo todos os commits anteriores, permaneceram intactos durante todo o comprometimento.

Depois que uma tag maliciosa era publicada, qualquer nova instalação do Composer que resolvesse uma das versões afetadas baixava o código do commit semelhante criado pelo invasor. A carga maliciosa ficava oculta em um arquivo recém-adicionado, src/helpers.php, registrado em composer.json na seção autoload.files. O autoloader do Composer inclui incondicionalmente todos os arquivos dessa lista, então o código malicioso é executado no início do ciclo de vida da solicitação PHP, inclusive durante a execução de comandos, processos em segundo plano e manipuladores de filas.

Comportamento da carga maliciosa

A primeira etapa, incluída em src/helpers.php, é intencionalmente discreta. Ela grava um marcador de infecção em um diretório temporário específico do host para infectá-lo apenas uma vez. Em seguida, busca uma segunda etapa em https://flipboxstudio\[.\]info/payload e a executa em segundo plano. O mecanismo de inicialização reconhece a plataforma e funciona em Linux, macOS e Windows.

A segunda etapa rouba credenciais e segredos. Depois de chegar ao sistema, percorre uma longa lista de fontes em busca de dados valiosos:

• Credenciais e tokens de provedores de nuvem (por exemplo, arquivos de perfil da AWS, GCP e Azure).

• Arquivos kubeconfig do Kubernetes, tokens do HashiCorp Vault e segredos de CI/CD presentes no ambiente.

• Chaves privadas SSH e dados de known_hosts.

• Arquivos .env de aplicações com credenciais de banco de dados, API e serviços.

• Dados de navegadores, incluindo cookies, histórico e logins salvos.

• Cofres de gerenciadores de senhas acessíveis no disco.

• Arquivos de carteiras de criptomoedas e keystores.

• Tokens de mensagens e colaboração de ferramentas como Slack, Discord e Telegram.

Os dados coletados são criptografados e enviados para https://flipboxstudio\[.\]info/exfil. Após a exfiltração, o ladrão tenta excluir os arquivos que criou para dificultar a recuperação forense. Em hosts Windows, a cadeia inclui um script de inicialização .vbs e um executável chamado DebugChromium.exe, identificado em sistemas infectados.

Indicadores de comprometimento

Use os indicadores a seguir para procurar sistemas afetados. O domínio C2 e os URLs devem ser considerados maliciosos.

Orientações para detecção e análise

Considere suspeito qualquer host que tenha resolvido um dos quatro pacotes entre 22 e 23 de maio de 2026, mesmo que tenha sido reconstruído desde então. O sinal mais rápido está no nível das dependências: examine composer.lock e composer.json em todos os seus projetos em busca de referências aos pacotes laravel-lang listados acima. Veja algumas verificações práticas.

• Pesquise artefatos de build e implantação por laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes ou laravel-lang/actions e registre a versão e o hash de integridade indicados em composer.lock.

• Inspecione qualquer cópia instalada em vendor/laravel-lang/*/ para verificar se há um arquivo src/helpers.php e se composer.json o declara na chave files de autoload. Um pacote legítimo de localização não tem motivo para incluir um arquivo helpers que seja carregado automaticamente em cada solicitação.

• Em hosts Linux e macOS, procure nos diretórios $TMPDIR e /tmp uma pasta .laravel_locale — qualquer conteúdo nela indica execução. Antes da limpeza, capture os arquivos para análise forense.

• Em hosts Windows, procure no diretório temporário do usuário (normalmente %TEMP%) uma pasta .laravel_locale com arquivos .vbs descartados cujos nomes tenham oito caracteres hexadecimais aleatórios. Separadamente, examine o sistema de arquivos em busca de qualquer executável chamado DebugChromium.exe.

• Verifique os logs do proxy de saída, DNS e firewall em busca de consultas ou conexões com flipboxstudio[.]info. Bloqueie o domínio no resolvedor e no perímetro.

• Nos logs de EDR e endpoints, procure execuções inesperadas de processos PHP ou CScript em segundo plano. Em Linux e macOS, monitore também leituras em /var/run/secrets/ e `/proc/[pid]/environ`, acessados pelo ladrão de credenciais durante a coleta de segredos.

Esclarecimento sobre as orientações para ignorar o alerta

Devido à natureza do comprometimento e às correções posteriores, os sistemas da Snyk talvez reconheçam atualmente apenas a versão mais recente instalada. Clientes devem realizar uma análise histórica para confirmar se o pacote malicioso foi instalado entre 22 e 23 de maio de 2026, sem se basear apenas no status da versão mais recente. Considere afetado qualquer host que tenha instalado um dos quatro pacotes durante o período do comprometimento, até que se prove o contrário.

Detectando o ataque à cadeia de suprimentos do Laravel Lang com a Snyk

Para usuários da Snyk, o produto Open Source e a Snyk Vulnerability Database já sinalizam todas as versões dos pacotes afetados. Durante o comprometimento, tags maliciosas foram publicadas usando números de versões legítimos. Após a recuperação dos projetos, essas mesmas tags legítimas foram desvinculadas dos commits maliciosos. Portanto, os números das versões, por si só, não permitem determinar se um pacote instalado foi ou está afetado por esse comprometimento. (Consulte acima as seções Indicadores de comprometimento e Orientações para detecção e análise.) Faça uma análise imediata de todos os repositórios baseados em Composer e dê atenção especial a monorepos e ao código de plataformas compartilhadas.

Se, após revisar seu composer.lock, o build, o momento da instalação e os indicadores de comprometimento disponíveis, você concluir que seu projeto não foi afetado, poderá usar o recurso Ignore da Snyk para impedir que esse problema apareça em análises futuras. Consulte a documentação da Snyk sobre como ignorar problemas para saber mais.

A CLI da Snyk detecta automaticamente seu arquivo de lock do Composer e identifica pacotes vulneráveis e maliciosos:

1snyk test

A CLI da Snyk é gratuita. Se você ainda não a instalou, siga a documentação de usuário da CLI da Snyk.

Se você conectar a Snyk aos seus repositórios Git, a Snyk poderá abrir PRs automaticamente para atualizar pacotes vulneráveis no arquivo composer.lock para versões seguras.

Para clientes da Snyk Enterprise, já executamos novas análises em seu nome. Acesse Analytics → Reports → Zero-Day → Active Security Incident Assessment para consultar o ataque à cadeia de suprimentos do Laravel-Lang.

Mitigação e correção

Se houver confirmação de que os pacotes afetados foram instalados, considere exfiltrado tudo o que podia ser lido pelo processo PHP durante a execução e aja de acordo. A ordem abaixo reflete a sequência típica de resposta a incidentes.

• Isole os hosts afetados. Retire de operação quaisquer serviços expostos à internet que tenham executado as versões afetadas, faça snapshots dos discos para análise forense e reconstrua os sistemas a partir de uma imagem comprovadamente limpa, em vez de limpar os hosts existentes.

• Evite baixar o conjunto de pacotes Laravel Lang afetado (e, provavelmente, outros pacotes desse mantenedor/equipe). Como o invasor reescreveu tags históricas do Git, não é possível confiar apenas no número de nenhuma versão publicada: uma versão mais antiga pode agora apontar para o commit malicioso.

• Troque todas as credenciais que o processo PHP poderia ter lido. Isso inclui chaves de provedores de nuvem, senhas de banco de dados, credenciais de filas e cache, tokens de APIs de terceiros, segredos de clientes OAuth, chaves SSH, chaves de assinatura, tokens do Vault e do Kubernetes e quaisquer segredos injetados pelo CI/CD.

• Audite as contas de pessoas que compartilham as mesmas estações de trabalho. Logins salvos no navegador, cofres de gerenciadores de senhas, carteiras de criptomoedas e tokens do Slack ou Discord também podem ter sido roubados. Troque as senhas salvas no navegador, invalide as sessões e revise os métodos de MFA cadastrados.

• Bloqueie o domínio C2. Adicione flipboxstudio[.]info às listas de bloqueio de DNS sinkhole, proxy e detecções de EDR. Até mesmo uma única tentativa de resolução é um forte indício de exposição.

• Revise as permissões do SCM e dos registros de pacotes, pois laravel-lang/* pode ter sido baixado de forma transitiva. Confirme que suas organizações no GitHub, GitLab e Packagist usam MFA com respaldo de hardware, tokens com escopo restrito e uma etapa de revisão para criação de tags e publicação de pacotes.

Lições aprendidas e defesa em profundidade

Este incidente é um lembrete importante de que o limite de confiança de um pacote não é o repositório de origem aberto na aba do navegador. É a cadeia de sistemas que determina qual commit se torna um artefato publicado. Algumas práticas reduzem o impacto de ataques semelhantes:

• Verifique a integridade durante a instalação. O Composer registra hashes do conteúdo dos pacotes no composer.lock; use --no-cache e a verificação de integridade no CI para identificar adulterações.

• Adote controles de saída em ambientes de build. Runners de CI e contêineres de produção não devem conseguir acessar domínios arbitrários. Neste caso, uma lista de permissões teria impedido o download do segundo estágio.

• Use segredos com escopo restrito e validade curta. Credenciais de longa duração em arquivos .env ampliam os danos causados pelo roubo de segredos em qualquer processo.

A declaração oficial do projeto afetado, que inclui detalhes sobre o GitHub, está disponível aqui: Declaração oficial sobre o incidente.

Também recomendamos revisar suas práticas de segurança e aprender como proteger o framework PHP Laravel em um artigo que publicamos anteriormente, além de consultar o recurso Snyk Learn sobre práticas de desenvolvimento seguro em PHP.

Status da Snyk

Os produtos e a infraestrutura da Snyk não foram afetados por este incidente. Os avisos da Snyk sobre os pacotes afetados já foram publicados, e o Snyk Vulnerability Database está sendo atualizado à medida que novos intervalos de versões são confirmados. A Snyk continua monitorando a situação e revisará este aviso à medida que mais detalhes forem conhecidos.