Introdução
O ecossistema de desenvolvimento PHP enfrenta uma crise de credenciais após uma falha no gerenciador de dependências Composer expor tokens de autenticação do GitHub Actions em logs públicos. A Packagist, a principal fonte de pacotes PHP, emitiu um alerta urgente recomendando atualizações imediatas e auditoria de logs para milhares de projetos ativos.
Origem do Vazamento de Credenciais
O problema foi desencadeado por uma mudança na estrutura dos tokens de autenticação do GitHub Actions, introduzida no final de abril de 2026. A nova versão dos tokens incluiu um hífen na string, um formato que o código de validação interna do Composer não foi projetado para lidar. Quando o Composer encontrava tokens nesse novo formato, ele rejeitava a autenticação e imprimia o valor completo do token diretamente nos logs de erro da Actions.
Essa exposição ocorria sem qualquer sinalização visível para o desenvolvedor que configurou o workflow. Pesquisadores da Socket.dev foram os primeiros a flagrar a gravidade do problema, demonstrando que não se tratava de um caso de borda teórico, mas de um risco real capaz de afetar qualquer projeto PHP que utilize o Composer dentro de um workflow do GitHub Actions.
Impacto nos Projetos e Cadeia de Suprimentos
A exposição decorre de como muitos workflows de configuração populares operam na prática. Quando desenvolvedores utilizam ações de helper comuns do GitHub Actions, como shivammathur/setup-php, o token GITHUB_TOKEN é registrado automaticamente na configuração de autenticação global do Composer. Se o token coincidir com o novo formato durante a janela de rollout, o Composer o expõe no log.
Embora a Packagist.org não tenha sido afetada, pois o registro público não utiliza tokens de instalação de aplicativos do GitHub, o risco permanece real para qualquer projeto que execute o Composer dentro de ambientes de CI/CD. A Packagist privada também aplicou a correção e auditou seus logs, não encontrando exposição de tokens em suas atividades registradas.
Versões Corrigidas e Mitigação
Três versões do Composer agora contêm o patch oficial para esta questão. Desenvolvedores em setups modernos devem atualizar para o Composer 2.9.8 ou a versão de suporte de longo prazo 2.2.28 LTS sem demora. Usuários de versões legadas ainda em ramos mais antigos podem atualizar para o Composer 1.10.28, embora a Packagist recomenda mover para a linha Composer 2.x para maior segurança a longo prazo.
A correção funciona removendo o valor do token rejeitado da saída de erro do Composer e também relaxa a lógica de validação para que a ferramenta não verifique mais os tokens contra um padrão de caracteres fixo. Isso torna o Composer muito mais resiliente a futuras mudanças de formato de tokens de qualquer plataforma.
O que as Equipes DevOps Devem Fazer Agora
As equipes devem começar atualizando o Composer para uma das três versões corrigidas imediatamente. Em seguida, devem revisar os logs recentes do GitHub Actions para quaisquer execuções falhas do Composer que possam ter impresso acidentalmente um valor de token na saída. Sempre que possível, essas entradas de log devem ser excluídas para prevenir exposição adicional.
Tokens de runners hospedados no GitHub geralmente expiram quando o job termina ou após seis horas, mas tokens em runners auto-hospedados podem permanecer válidos por até 24 horas. Qualquer token que se acredite ter sido exposto deve ser tratado como comprometido e rotacionado imediatamente.
Conclusão e Lições Aprendidas
A lição mais ampla é clara: ferramentas devem tratar tokens de acesso como strings opacas e nunca fazer suposições sobre seu comprimento, estrutura ou conjunto de caracteres, especialmente quando plataformas estão evoluindo ativamente esses formatos. A segurança da cadeia de suprimentos de software depende da resiliência das ferramentas de build e CI/CD frente a mudanças de infraestrutura de autenticação.