Pacotes PHP do Laravel-Lang foram comprometidos para entregar ladrão de credenciais

Tags publicadas em massa nos pacotes laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes e laravel-lang/actions acionavam um dropper em src/helpers.php por meio do autoload do Composer.

Componente	Pacotes PHP da organização Laravel-Lang: laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes e laravel-lang/actions.
Vetor	Tags publicadas em rápida sucessão em 22 e 23 de maio de 2026 incluíam src/helpers.php registrado em composer.json sob autoload.files, o que executava o código automaticamente em requisições PHP da aplicação comprometida.
Impacto	Fingerprint do host, contato com flipboxstudio[.]info, download de payload PHP multiplataforma e coleta de credenciais, tokens, arquivos de configuração, dados de CI/CD, carteiras de criptomoedas, cofres locais e sessões de aplicativos.
Prioridade	Auditar dependências Composer desses pacotes, remover versões publicadas no período suspeito, procurar execução de src/helpers.php, bloquear comunicação com flipboxstudio[.]info e rotacionar segredos expostos em hosts afetados.
Versões	Mais de 700 versões associadas aos pacotes foram identificadas, com padrão compatível com marcação ou republicação automatizada em massa.
IoCs	Domínio de comando e exfiltração citado: flipboxstudio[.]info; endpoint de exfiltração citado: flipboxstudio[.]info/exfil.
Artefatos	src/helpers.php, composer.json, autoload.files, cscript, exec(), .env, wp-config.php, docker-compose.yml, .gitconfig, .git-credentials e .netrc.

Resumo técnico

Uma campanha de comprometimento de cadeia de suprimentos atingiu pacotes PHP mantidos sob a organização Laravel-Lang e passou a distribuir um framework de roubo de credenciais por meio de versões publicadas nos repositórios afetados. Os pacotes mencionados são laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes e laravel-lang/actions. A característica central do incidente é que a funcionalidade maliciosa não depende de uma chamada explícita do desenvolvedor para uma função suspeita: ela foi posicionada em src/helpers.php e registrada no composer.json em autoload.files, mecanismo que faz o Composer carregar arquivos automaticamente quando a aplicação inicializa o autoloader. Em aplicações PHP que usam esses pacotes comprometidos, esse caminho pode transformar uma simples atualização ou instalação de dependência em execução automática do dropper durante o processamento de requisições.

O padrão de publicação indica uma operação voltada ao processo de release, não apenas a uma versão isolada. As tags foram publicadas em rápida sequência em 22 e 23 de maio de 2026, com muitas versões aparecendo com diferença de segundos, e mais de 700 versões associadas aos pacotes foram identificadas. Esse volume sustenta a hipótese técnica de marcação ou republicação automatizada em massa. O acesso usado para isso pode ter envolvido credenciais no nível da organização, automação de repositório ou infraestrutura de release, mas o dado disponível não confirma qual desses caminhos foi efetivamente abusado. Para defesa, a leitura operacional é direta: a investigação precisa cobrir não só um pacote específico, mas também a cadeia de publicação, os artefatos Composer consumidos por builds e os hosts que executaram aplicações PHP com essas versões.

Fluxo técnico

O fluxo malicioso começa no carregamento de src/helpers.php. Como o arquivo está registrado em autoload.files, ele entra no ciclo normal de inicialização de uma aplicação PHP que carrega dependências Composer. A partir daí, o código faz fingerprint do host infectado e tenta contatar flipboxstudio[.]info para recuperar um payload PHP de roubo de credenciais. O mecanismo gera um marcador único por máquina usando um hash MD5 composto pelo caminho do diretório, pela arquitetura do sistema e pelo inode. A finalidade operacional desse marcador é limitar a execução do payload a uma vez por host, reduzindo execuções redundantes e diminuindo sinais repetidos que poderiam aparecer em logs, monitoramento de processo ou análise forense posterior.

A cadeia tem comportamento diferente conforme o sistema operacional. Em Windows, o dropper entrega um lançador em Visual Basic Script e o executa por meio de cscript. Em Linux e macOS, o payload do ladrão de credenciais é executado via exec(). O payload recuperado é descrito como um stealer PHP com cerca de 5.900 linhas e quinze módulos coletores especializados. Após a coleta, os resultados são criptografados com AES-256 e enviados para flipboxstudio[.]info/exfil; em seguida, o payload se remove do disco para limitar evidências forenses. O conjunto de módulos mira credenciais de cloud, CI/CD, controle de versão, carteiras de criptomoedas, cofres locais, clientes de mensagem, e-mail, FTP, VPN, Kubernetes, Docker, SSH, bancos de dados e arquivos de configuração de aplicações.

Superfície afetada

A superfície exposta inclui aplicações PHP que consumiram versões comprometidas dos pacotes Laravel-Lang citados e executaram o autoload do Composer em hosts Windows, Linux ou macOS. O risco não se limita ao código da aplicação em si: como o payload coleta dados do ambiente local, estáções de desenvolvimento, servidores de build, runners de CI/CD e servidores de aplicação podem concentrar segredos de alto valor. Em ambientes de desenvolvimento, arquivos como .env, wp-config.php, docker-compose.yml, históricos de shell, históricos de banco de dados, chaves SSH privadas, credenciais Git, .gitconfig, .git-credentials e .netrc podem existir no mesmo perfil de usuário ou no diretório de trabalho. Em servidores, metadados de instância e funções IAM podem estar acessíveis por endpoints locais de cloud quando a configuração permite.

O impacto também alcança plataformas e ferramentas usadas para entrega de software. O stealer procura tokens de DigitalOcean, Heroku, Vercel, Netlify, Railway e Fly.io, além de tokens e configurações de Jenkins, GitLab Runners, GitHub Actions, CircleCI, TravisCI e ArgoCD. Em paralelo, busca dados de carteiras e extensões de criptomoedas, incluindo Electrum, Exodus, Atomic, Ledger Live, Trezor, Wasabi, Sparrow, MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare e Rabby. Também há coleta de cofres e dados de extensões de 1Password, Bitwarden, LastPass, KeePass, Dashlane e NordPass; sessões de Discord, Slack e Telegram; dados de Microsoft Outlook, Thunderbird, FileZilla, WinSCP e CoreFTP; configurações de OpenVPN, WireGuard, NetworkManager, NordVPN, ExpressVPN, CyberGhost e Mullvad.

Como o ponto de entrada é um pacote de idioma e utilidades relacionadas ao ecossistema Laravel-Lang, o comprometimento pode parecer improvável para equipes que priorizam auditoria apenas em dependências com lógica de autenticação, pagamento ou rede. Essa é uma condição relevante para triagem: pacotes aparentemente auxiliares ainda podem executar código se estiverem registrados no autoload. A presença de autoload.files muda o perfil de risco porque o arquivo é carregado independentemente de uma classe específica ser instanciada pela aplicação.

• laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes e laravel-lang/actions aparecem como pacotes afetados.
• src/helpers.php é o arquivo malicioso descrito dentro das tags comprometidas.
• Hosts Windows recebem lançador em Visual Basic Script via cscript; Linux e macOS executam o payload por exec().
• Mais de 700 versões foram associadas ao padrão de publicação suspeito.

Hunting e telemetria

A investigação deve começar pela cadeia de dependências. Equipes devem revisar composer.lock, caches de artefatos, registros de instalação e histórico de builds para identificar uso dos pacotes afetados em versões publicadas no período de 22 e 23 de maio de 2026. Em repositórios, procure mudanças inesperadas que incluam src/helpers.php dentro desses pacotes ou qualquer referência a autoload.files que carregue esse arquivo. Em servidores de aplicação, a existência do arquivo por si só já exige correlação com data de instalação, execução do PHP, conexões de saída e presença de segredos no host. Em ambientes com builds reproduzíveis, comparar o conteúdo baixado do pacote com uma versão previamente confiável ajuda a separar instalações limpas de artefatos contaminados.

Na camada de endpoint, sinais relevantes incluem criação ou execução de scripts Visual Basic em Windows, execução de cscript originada de contexto relacionado a PHP ou Composer, chamadas a exec() em Linux e macOS durante requisições ou inicialização da aplicação, e criação seguida de remoção rápida de arquivos temporários compatíveis com payload. Na rede, qualquer resolução DNS, conexão HTTP ou tráfego de saída para flipboxstudio[.]info deve ser tratado como indicador forte de comprometimento. Em logs de proxy, EDR e firewall, a investigação deve correlacionar o processo de origem, o usuário do sistema, o diretório da aplicação e o horário da primeira execução. Como o malware tenta rodar uma vez por máquina, a ausência de repetição não deve ser interpretada como ausência de execução.

A telemetria de identidade e segredos deve ser revisada com foco em uso posterior. Tokens de cloud, CI/CD, Git e plataformas de deploy coletados pelo stealer podem permitir ações fora do host original, portanto a análise não deve terminar no servidor PHP. Procure uso de tokens de DigitalOcean, Heroku, Vercel, Netlify, Railway, Fly.io, Jenkins, GitLab Runners, GitHub Actions, CircleCI, TravisCI e ArgoCD em horários incompatíveis, de endereços ou agentes incomuns, ou em operações de leitura de segredos, criação de jobs, alteração de pipelines e acesso a repositórios. Para Kubernetes, Docker e SSH, revise autenticações recentes e alterações de configuração após a possível execução do payload.

• Presença de src/helpers.php em versões dos pacotes Laravel-Lang afetados.
• Referência a src/helpers.php em composer.json sob autoload.files.
• Execução de cscript em Windows partindo de contexto de aplicação PHP ou diretório Composer.
• Chamadas de saída, DNS ou proxy para flipboxstudio[.]info e flipboxstudio[.]info/exfil.
• Acesso incomum a arquivos .env, wp-config.php, docker-compose.yml, .git-credentials, .netrc, configurações Kubernetes, chaves SSH e históricos de shell ou banco de dados.
• Uso anômalo de tokens de CI/CD, plataformas de deploy, provedores cloud, Git, VPN e mensageria após a instalação de dependências.

Mitigação

A contenção inicial deve bloquear a comunicação com flipboxstudio[.]info em DNS, proxy e firewall, preservar evidências do host e impedir novas instalações das versões suspeitas nos pipelines. Em seguida, revise todos os projetos que dependem de laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes ou laravel-lang/actions. A ação defensiva precisa incluir composer.lock, caches internos, mirrors de pacotes, imagens de contêiner, artefatos de build e servidores que já executaram a aplicação. Remover apenas o pacote do código-fonte atual pode ser insuficiente se imagens, releases ou caches ainda carregarem o arquivo comprometido.

Depois da remoção das versões afetadas e da reconstrução de artefatos a partir de fontes confiáveis, a rotação de segredos deve seguir a lista de dados visados pelo stealer. Priorize credenciais de cloud e IAM, tokens de CI/CD, chaves SSH, credenciais Git, tokens de Docker, configurações Kubernetes, tokens de plataformas de deploy, segredos em .env, credenciais de banco de dados e sessões de ferramentas de colaboração. Se um host tinha carteiras de criptomoedas, cofres locais ou extensões de navegador com segredos, trate esse host como comprometido para fins de credencial. A rotação deve ser acompanhada por revogação explícita, invalidação de sessões e revisão de logs de uso dos tokens antigos.

A validação final deve confirmar que o autoload do Composer não carrega mais o arquivo malicioso, que o domínio de exfiltração não aparece em tráfego recente e que não há processos, scripts ou arquivos temporários remanescentes ligados ao dropper. Em paralelo, organizações que mantêm pacotes ou automações de release devem revisar credenciais de publicação, tokens de automação, permissões no nível da organização e trilhas de auditoria de tags. O padrão de tags em massa mostra que a segurança da cadeia de publicação é parte do perímetro: repositórios, automações e credenciais de release precisam ter escopo mínimo, rotação periódica e alertas para publicação anormal em volume ou cadência.

• Bloquear flipboxstudio[.]info e investigar qualquer tentativa de conexão já registrada.
• Auditar composer.lock, caches Composer, mirrors internos, imagens de contêiner e artefatos de CI/CD para os quatro pacotes afetados.
• Remover versões comprometidas e reconstruir aplicações PHP a partir de dependências verificadas.
• Rotacionar tokens de cloud, CI/CD, Git, Docker, Kubernetes, deploy, SSH, bancos de dados, VPN e segredos de aplicação presentes nos hosts afetados.
• Revisar permissões e credenciais usadas para publicação de tags, automações de repositório e infraestrutura de release.
• Criar detecção para alterações inesperadas em autoload.files e para publicação em massa de tags em pacotes internos ou de terceiros críticos.