Falhas críticas no Composer permitem execução de comandos arbitrários em ambientes PHP, expondo diretamente servidores, pipelines de CI/CD e até aplicações em produção a riscos significativos. Duas vulnerabilidades de alta gravidade foram identificadas em uma das ferramentas centrais do ecossistema PHP, usada diariamente por desenvolvedores para gerenciar dependências. O problema vai além de um simples bug: ele toca no coração da cadeia de desenvolvimento de software.
As brechas estão relacionadas ao driver de integração com o sistema de versionamento Perforce, utilizado em cenários específicos para gestão de código-fonte. O núcleo do problema está em validações insuficientes e na falta de sanitização adequada de dados fornecidos ao Composer. Em outras palavras: entradas que deveriam ser tratadas como simples dados acabam sendo interpretadas como comandos pelo sistema operacional.
As vulnerabilidades foram catalogadas como CVE-2026-40176 (com pontuação CVSS 7.8) e CVE-2026-40261 (CVSS 8.8), ambas explorando o arquivo composer.json, que define as dependências e repositórios de um projeto PHP. Esse arquivo, normalmente visto como uma simples configuração de projeto, torna-se, nesse contexto, um vetor de ataque poderoso.
No primeiro caso, o invasor manipula a configuração de repositórios, inserindo um repositório malicioso que faz referência ao Perforce. Quando o desenvolvedor ou pipeline de automação executa comandos do Composer (como install ou update), os parâmetros maliciosos contidos na configuração são processados e podem disparar a execução de comandos no sistema alvo, sem que o usuário perceba.
Na segunda vulnerabilidade, o ataque é ainda mais direto: o agressor injeta metacaracteres de shell em campos como referências de código (source reference) ou outros parâmetros interpretados pelo sistema subjacente. Esses caracteres especiais – comuns em comandos de terminal – são entendidos pelo sistema operacional como parte de um comando real, o que permite ao atacante executar instruções arbitrárias com os mesmos privilégios do usuário que está rodando o Composer.
Um ponto especialmente preocupante ressaltado pelos mantenedores do projeto é que essas falhas podem ser exploradas mesmo em ambientes onde o Perforce não está instalado. O simples fato de o driver existir e ser processado pelo Composer já é suficiente para que o payload malicioso seja interpretado. Isso amplia enormemente a superfície de ataque, pois elimina uma barreira de entrada que, em tese, poderia mitigar o problema.
Esse tipo de vulnerabilidade se encaixa perfeitamente no modelo de ataque à cadeia de suprimentos de software (supply chain). Em vez de mirar diretamente o servidor final ou o usuário da aplicação, o atacante compromete o processo de desenvolvimento, construção e distribuição do software. O fluxo típico desse ataque pode ser resumido assim:
1. O invasor cria ou altera um repositório com configurações maliciosas no composer.json.
2. Um desenvolvedor, ou um pipeline automatizado de CI/CD, adiciona esse repositório como dependência.
3. Ao executar o Composer para instalar ou atualizar dependências, o conteúdo malicioso é processado.
4. O sistema passa a interpretar partes dessa configuração como comandos, executando-os no contexto do usuário que disparou o processo.
5. A partir dessa primeira brecha, o atacante pode estabelecer persistência, se mover lateralmente pela infraestrutura ou exfiltrar dados sensíveis.
Esse cenário é particularmente perigoso em ambientes de integração e entrega contínua, nos quais pipelines de build rodam com permissões elevadas, acesso a variáveis de ambiente críticas, chaves de API, tokens de acesso à nuvem e segredos que permitem controlar grande parte da infraestrutura de TI da organização. Um único pipeline comprometido pode servir de porta de entrada para ataques em larga escala.
Mesmo sem registros públicos de exploração ativa até o momento, o risco é considerado alto. Ferramentas como o Composer são onipresentes no desenvolvimento moderno: qualquer falha nesse nível impacta potencialmente milhares de projetos simultaneamente, desde aplicações internas corporativas até grandes plataformas de alto tráfego.
Os possíveis impactos incluem:
– Comprometimento de servidores de build e pipelines CI/CD.
– Execução de código malicioso em redes internas corporativas.
– Exposição e roubo de credenciais, chaves privadas e outros segredos.
– Inserção de backdoors em bibliotecas e aplicações distribuídas a clientes.
– Contaminação de toda a cadeia de desenvolvimento, da máquina do desenvolvedor ao ambiente de produção.
Esse incidente reforça uma tendência clara: atacantes estão direcionando esforços para ferramentas de desenvolvimento, automação e distribuição de software, explorando a confiança implícita nesses componentes. Ao contrário de aplicações voltadas ao usuário final, ferramentas como o Composer são frequentemente tratadas como “seguras por padrão”, o que leva organizações a relaxarem controles de segurança sobre elas.
As vulnerabilidades atingem as seguintes faixas de versões do Composer:
– Versões >= 2.3 e = 2.0 e < 2.2.27 (corrigida na versão 2.2.27).
A principal orientação é objetiva: atualizar imediatamente o Composer para as versões corrigidas. Essa ação deve ser tratada não como manutenção de rotina, mas como resposta a incidente em potencial, especialmente em ambientes corporativos com forte dependência de automação.
Além da atualização, especialistas recomendam uma revisão criteriosa de todos os arquivos composer.json utilizados em projetos sensíveis. É importante conferir origens de repositórios, referências a sistemas como Perforce e parâmetros inesperados. Qualquer dependência ou repositório desconhecido, pouco documentado ou de origem duvidosa deve ser investigado ou removido.
Outra prática essencial é restringir a instalação de dependências apenas a fontes e repositórios confiáveis, mantidos por organizações ou mantenedores com reputação consolidada. Em ambientes sensíveis, vale a pena criar espelhos internos de repositórios e utilizar artefatos previamente auditados, reduzindo a probabilidade de introdução de código malicioso diretamente na cadeia de construção.
Em pipelines automatizados, a recomendação é reduzir ao máximo os privilégios de execução. Isso inclui rodar processos de build com usuários sem acesso administrativo, isolar ambientes por containerização, limitar o acesso a variáveis de ambiente críticas e segmentar redes de CI/CD para evitar movimentação lateral fácil em caso de comprometimento.
Outro ponto de atenção é o uso de configurações como –prefer-dist ou preferred-install: dist em ambientes não confiáveis. Embora muitas vezes adotadas para otimizar tempo de build, essas opções podem influenciar de que forma o código é obtido e processado, abrindo margens para comportamentos inesperados quando combinados com repositórios maliciosos.
Como medida emergencial, o repositório oficial de pacotes PHP desativou temporariamente a publicação de metadados relacionados ao Perforce, reduzindo a possibilidade de abusos em massa dessa integração específica. Além disso, atualizações dedicadas foram preparadas para clientes de soluções privadas de hospedagem de pacotes, reforçando o controle sobre dependências internas.
Para organizações que usam Composer em escala, uma resposta estruturada deve incluir não só a atualização da ferramenta, mas também um inventário detalhado dos projetos afetados, análise de logs de builds recentes e revisão de atividades suspeitas em pipelines. Em alguns casos, pode ser necessário reemitir credenciais, rodar scans adicionais de segurança e até reconstruir imagens de containers ou artefatos a partir de fontes consideradas limpas.
Do ponto de vista estratégico, o episódio revela a urgência de tratar segurança de supply chain como prioridade. Isso envolve práticas como geração e manutenção de SBOM (Software Bill of Materials), assinatura de artefatos, verificação de integridade de dependências e adoção de políticas formais para aprovação de novos pacotes de terceiros.
Equipes de desenvolvimento também precisam ser treinadas para adotar uma postura de desconfiança saudável em relação a dependências externas. Isso inclui revisar atentamente mudanças em composer.json em pull requests, questionar a inclusão de novos repositórios, monitorar atualizações de segurança dos principais pacotes e evitar o uso de dependências abandonadas.
Ferramentas de análise estática, scanners de vulnerabilidades em dependências e soluções específicas de segurança de pipeline podem ajudar a detectar anomalias, mas não substituem processos bem definidos de governança. A combinação de automação com revisão humana continua sendo uma das formas mais eficazes de mitigar riscos crescentes na cadeia de desenvolvimento.
No longo prazo, o caso do Composer soma-se a uma sequência de incidentes recentes envolvendo bibliotecas, registries de pacotes, integrações de CI/CD e plugins de desenvolvimento, deixando evidente que o foco dos atacantes migrou para onde há maior retorno com menor esforço: o elo de confiança entre desenvolvedores, ferramentas e código de terceiros. Quem não tratar a segurança dessa cadeia como tema central corre o risco de ver seu ambiente comprometido antes mesmo da aplicação chegar ao usuário final.