CVE-2026-40176 — Injeção de Comando no Driver Perforce do Composer (Prova de Conceito)

Uma prova de conceito autossuficiente, em estilo OOP em PHP, que demonstra e verifica diferencialmente uma vulnerabilidade de injeção de comandos no driver de repositório Perforce do Composer.

O PoC executa o mesmo composer.json malicioso contra duas versões do Composer — uma afetada (2.9.5) e uma corrigida (2.9.6) — e comprova a falha observando um efeito colateral (um arquivo marcador escrito por um comando shell injetado) que ocorre na versão afetada, mas não na corrigida.

⚠️ Apenas para pesquisa de segurança autorizada e testes defensivos. Consulte Uso Responsável.

Índice

• Resumo
• A Vulnerabilidade
• Como o PoC Funciona
• O Payload de Injeção
• Requisitos
• Configuração
• Uso
• Saída Esperada
• Interpretando o Resultado
• Estrutura do Projeto
• Notas de Design
• Limitações e Problemas Conhecidos
• Uso Responsável
• Referências

Resumo

A Vulnerabilidade

O Composer pode resolver pacotes de vários sistemas de controle de versão. Para o Perforce, o repositório é identificado por uma URL p4:// que codifica o host, porta e usuário/stream. Quando o driver Perforce do Composer constrói a linha de comando p4 subjacente, campos retirados da URL controlada pelo atacante não são suficientemente sanitizados antes de serem passados para um shell.

Como o autor do manifesto controla completamente a URL do repositório, um atacante que consiga fazer uma vítima executar composer update/composer install contra um composer.json malicioso (por exemplo, uma dependência envenenada, um repositório hostil ou um job de CI processando arquivos de projeto não confiáveis) pode escapar da invocação pretendida do p4 e executar comandos arbitrários do sistema operacional com os privilégios do processo Composer.

Isso pertence à mesma família de problemas históricos de injeção de argumentos em drivers VCS do Composer, onde valores de URL/branch/stream fluem para comandos shell sem escape. O Composer 2.9.6 endurece o driver Perforce para que o payload injetado não seja mais executado.

A descrição autoritativa do comportamento demonstrado aqui é o próprio código-fonte do PoC (CVE202640176Test.php); consulte o aviso oficial e o changelog do Composer para obter detalhes da correção upstream.

Como o PoC Funciona

O PoC é uma única classe, CVE202640176Test, que realiza um experimento controlado A/B (diferencial) :

1. Pré-verificação — consulta --version em ambas as versões do Composer (a afetada 2.9.5 e a corrigida 2.9.6) e aborta cedo se alguma não puder ser invocada.
2. Execução afetada (2.9.5)
   • Cria um diretório temporário isolado dentro do caminho temporário do sistema.
   • Escreve um composer.json cuja seção repositories contém uma entrada perforce com uma URL p4:// maliciosa carregando um payload shell injetado.
   • Executa composer update nesse diretório.
   • Valida o resultado.
3. Execução corrigida (2.9.6) — repete exatamente os mesmos passos contra o binário corrigido.
4. Restauração — um bloco finally sempre restaura o composer.json original no diretório do projeto.
5. Veredito — imprime PASS apenas quando a execução afetada mostra o efeito colateral a execução corrigida não.

Validação (o que conta como "explorado")

Para cada execução, validateRun() verifica três coisas:

Uma execução é "OK" apenas quando todos os três passam. O teste geral passa quando a execução afetada é OK e a executada corrigida não é — a assinatura precisa de uma vulnerabilidade real que foi subsequentemente corrigida.

O Payload de Injeção (Explicado)

A URL maliciosa do repositório é construída em writeComposerJson():

p4://127.0.0.1:1666:attacker_user;touch <marcador> && echo '<runId>' > <marcador>:client_test

Detalhando:

• p4://127.0.0.1:1666:attacker_user — uma URL Perforce com aparência bem formada (host, porta 1666, usuário).
• ;touch <marcador> && echo '<runId>' > <marcador> — os comandos shell injetados. O ; inicial termina o comando p4 pretendido; touch cria o arquivo marcador, e echo '<runId>' > <marcador> escreve o ID único da execução nele para que o PoC possa confirmar que o payload (e não algum outro processo) produziu o arquivo.
• :client_test — texto adicional para manter o restante da análise da URL plausível.

No driver afetado, os meta-caracteres do shell são respeitados e o arquivo marcador é criado. No driver corrigido, o valor é devidamente escapado/entre aspas, então a mesma string é tratada como dados inertes e nenhum marcador aparece.

Nota: o PoC usa um ID de execução único com timestamp e escreve seu marcador dentro de um diretório temporário isolado, portanto o payload é benigno e autolimpante, em vez de destrutivo.

Requisitos

• PHP 7.4+ (desenvolvido/testado contra PHP 8.x CLI). O PoC em si usa apenas funções principais — nenhum pacote Composer é necessário para executar o harness.
• Dois binários do Composer disponíveis como PHARs:
  • Composer 2.9.5 (afetado)
  • Composer 2.9.6 (corrigido)
• Um ambiente de shell semelhante ao POSIX (exec() executa cd … && php …). Projetado para Linux/macOS.
• Um composer.json base no diretório do projeto (ele é lido na inicialização, copiado para cada execução temporária e restaurado depois).

Geralmente você não precisa de um servidor Perforce ativo: a vulnerabilidade está em como o Composer constrói a linha de comando p4, e o payload injetado é executado antes/em torno de qualquer conexão p4 real. O Composer pode registrar um erro de conexão Perforce — isso é esperado e não afeta a prova do arquivo marcador.

Configuração

1. Clone / coloque o PoC em um diretório de trabalho.

2. Forneça um composer.json no mesmo diretório do PoC. Um mínimo é suficiente:

   root@kitploit:~

   {
     "name": "research/cve-2026-40176-poc",
     "description": "Manifesto base para o PoC diferencial CVE-2026-40176",
     "require": {}
   }
   

3. Obtenha os dois binários do Composer e coloque-os onde o PoC espera (padrões mostrados):

   root@kitploit:~

   /usr/local/bin/composer-2.9.5.phar   # afetado
   /usr/local/bin/composer-2.9.6.phar   # corrigido
   

   Você pode baixar versões específicas do Composer do arquivo oficial, por exemplo:

   root@kitploit:~

   curl -Lo /usr/local/bin/composer-2.9.5.phar https://getcomposer.org/download/2.9.5/composer.phar
   curl -Lo /usr/local/bin/composer-2.9.6.phar https://getcomposer.org/download/2.9.6/composer.phar
   

   Se seus caminhos forem diferentes, edite os dois argumentos do construtor no final de CVE202640176Test.php.

Uso

php CVE202640176Test.php

O harness executa ambas as versões do Composer em sequência e imprime um veredito final. O composer.json original é restaurado automaticamente mesmo se uma execução falhar (o trabalho acontece em diretórios temporários descartáveis).

Executar no Docker (recomendado)

O repositório inclui um laboratório containerizado que replica o ambiente exatamente: um runtime PHP CLI mais as duas versões fixadas do Composer nos caminhos que o PoC espera, totalmente isolado de rede em tempo de execução.

docker compose run --rm poc

Isso constrói cve-2026-40176-lab:latest (baixando Composer 2.9.5 e 2.9.6 e verificando cada --version durante a construção) e executa o teste diferencial dentro de um container sem privilégios e sem egresso.

O que o laboratório garante:

• Binários reais. Ambas as versões do Composer são buscadas do arquivo oficial e verificadas por versão em tempo de construção — a construção falha ruidosamente se uma versão fixada estiver indisponível.
• Isolamento. O serviço poc é executado em uma rede bridge internal (sem egresso para host/internet), com cap_drop: ALL e no-new-privileges. O payload de injeção permanece contido.
• Sem configuração no host. Não é necessário colocar PHARs no host ou editar caminhos manualmente.

Refixe as versões (devem permanecer sincronizadas com os dois caminhos do construtor no PoC) via argumentos de construção:

docker compose build --build-arg COMPOSER_AFFECTED_VERSION=2.9.5 --build-arg COMPOSER_FIXED_VERSION=2.9.6

Opcional — servidor Perforce ativo. Um serviço p4d está disponível sob o perfil full-lab (docker compose --profile full-lab up). A prova baseada em marcador não precisa dele; ele existe para pesquisadores que desejam um endpoint p4:// ao vivo. Observe que o payload do PoC tem como alvo 127.0.0.1:1666, portanto o roteamento através de um container p4d separado requer apontar a URL do PoC para o host p4d.

Status de Reprodução (observado)

Resultado honesto: contra as versões reais e publicadas do Composer 2.9.5 e 2.9.6, o PoC não é acionado atualmente, e o laboratório relata INCONCLUSIVE / FAIL.

Executar o Composer afetado (2.9.5) contra o manifesto malicioso do PoC gera, dentro do Composer, antes que qualquer comando p4/shell seja construído:

In PerforceDriver.php line 40:
  [ErrorException]
  Undefined array key "depot"

PerforceDriver::initialize() lê $this->repoConfig['depot'] logo de início, mas a entrada de repositório do PoC fornece apenas type e url (sem chave depot). O driver aborta nesse ponto, então o payload ;touch <marcador> injetado na URL nunca é alcançado e nenhum marcador é criado. O isolamento de rede não é a causa — o mesmo erro ocorre com egresso completo.

O que isso significa:

• O laboratório Docker em si está correto e executa fielmente o harness diferencial contra os binários genuínos afetado/corrigido. O resultado INCONCLUSIVE é uma propriedade do payload do PoC, não do ambiente.
• Para exercitar o caminho real de construção de comando Perforce, a configuração do repositório do PoC precisaria de pelo menos uma chave depot (e realisticamente um endpoint p4d ativo sob o perfil full-lab). Refinar o payload até esse ponto é desenvolvimento de exploração além de "montar o laboratório" e está intencionalmente fora do escopo aqui.

A "Saída Esperada" abaixo é o resultado pretendido/idealizado do PoC, mantido para referência; não é o que o payload atual produz contra o driver real.

Saída Esperada

Uma demonstração bem-sucedida parece aproximadamente assim (caminhos e IDs variarão):

=== CVE-2026-40176 PoC iniciado ===
- Versão do Composer 2.9.5: 2.9.5
- Versão do Composer 2.9.6: 2.9.6
Diretório temporário preparado: /tmp/cve20264176_5_20260610_142233
composer.json malicioso escrito em /tmp/cve20264176_5_20260610_142233
Executando Composer em /tmp/cve20264176_5_20260610_142233…
- Versão do Composer analisada: 2.9.5
- Marcador /tmp/cve20264176_5_.../poc_marker_5.txt criado com ID esperado.
- Saída mostra atividade do driver Perforce.
- Código de saída da execução afetada: 1
Diretório temporário preparado: /tmp/cve20264176_6_20260610_142233
composer.json malicioso escrito em /tmp/cve20264176_6_20260610_142233
Executando Composer em /tmp/cve20264176_6_20260610_142233…
- Versão do Composer analisada: 2.9.6
✘ Arquivo marcador /tmp/cve20264176_6_.../poc_marker_6.txt não encontrado.
- Saída mostra atividade do driver Perforce.
- Código de saída da execução corrigida: 1

=== CVE-2026-40176 PoC finalizado ===
=== RESULTADO DO TESTE: PASS (afetado bem-sucedido, corrigido falhou) ===

Um código de saída diferente de zero do Composer é normal — composer update eventualmente falha ao buscar o pacote (falso). A prova é o arquivo marcador, não o status de saída do Composer.

Interpretando o Resultado

Causas comuns de um resultado inconclusivo:

• O driver aborta em PerforceDriver.php:40 com Undefined array key "depot" — a configuração do repositório não possui uma chave depot, então o Composer nunca atinge o caminho de construção do comando p4. Isso é o que acontece com o payload atual do PoC contra o 2.9.5/2.9.6 real (consulte Status de Reprodução).
• Os caminhos dos binários do Composer estão errados ou os PHARs não são realmente 2.9.5 / 2.9.6.
• O shell do host ou exec() do PHP está em sandbox/desabilitado.
• A saída do Composer não contém a string literal p4 (caminho do driver não alcançado).

Estrutura do Projeto

CVE2026-40176/
├── CVE202640176Test.php   # O PoC: classe CVE202640176Test + ponto de entrada
├── composer.json          # Manifesto base que o PoC lê/restaura em tempo de execução
├── Dockerfile             # Imagem do laboratório: PHP CLI + Composer 2.9.5 & 2.9.6 fixados
├── docker-compose.yml     # Runner `poc` (+ `p4d` opcional sob perfil full-lab)
├── .dockerignore          # Apara o contexto de construção
├── README.md              # Este arquivo
└── .gitignore             # Exclui estado local de agente/ferramentas

O PoC inteiro é um arquivo:

• __construct() — armazena os dois caminhos dos binários, gera um ID de execução com timestamp, tira um snapshot do composer.json original.
• run() — orquestra a pré-verificação, a execução afetada, a execução corrigida, a restauração e o veredito.
• prepareTempDir() — cria um diretório de trabalho isolado por execução.
• writeComposerJson() — constrói o manifesto malicioso com a URL p4:// injetada.
• runComposer() — executa composer update (argumentos escapados com escapeshellarg()) e captura saída + código de saída.
• validateRun() — verifica versão, arquivo marcador e atividade do driver Perforce.
• preflightVersion() — lê --version de um determinado binário.

Notas de Design

• Isolamento e limpeza. Cada execução usa seu próprio diretório temporário; o composer.json original é restaurado em um bloco finally independentemente do resultado.
• Harness vs. escape de payload. O harness escapa seus próprios argumentos de shell com escapeshellarg() (para que o PoC não injete acidentalmente em suas próprias chamadas exec()). A vulnerabilidade vive uma camada mais profunda — em como o próprio Composer constrói o comando p4 — que é exatamente o alvo do payload.
• Prova diferencial. Executar ambos os binários (vulnerável e corrigido) em uma única passagem remove a ambiguidade: a mesma entrada produz comportamento divergente, o que é uma evidência muito mais forte do que uma única observação positiva.
• Payload benigno. Os comandos injetados apenas touch/echo em um marcador temporário único, tornando o PoC seguro para ser executado repetidamente sem efeitos colaterais no host.

Limitações e Problemas Conhecidos

• Caminhos binários fixos. Os dois caminhos dos PHARs são passados inline no final do arquivo. Edite-os para seu ambiente (ou refatore para ler de argumentos CLI / variáveis de ambiente).
• Suposição POSIX. O padrão exec("cd … && php …") e o payload ;/&& assumem um shell tipo Unix; Windows não é suportado como está.
• Condição de corrida / permissões do mkdir. Diretórios temporários são criados com modo 0777; aperte se estiver executando em um ambiente compartilhado.
• Detecção de versão baseada em regex. Analisa Composer X.Y.Z da saída; banners incomuns do Composer podem derrotar a correspondência.

Uso Responsável

Este repositório existe para entender e defender contra CVE-2026-40176.

• Execute-o apenas contra sistemas e instalações do Composer que você possui ou para os quais tem autorização explícita para testar.
• A lição para defensores: atualize o Composer para 2.9.6 ou posterior, e nunca execute composer install/update em arquivos composer.json não confiáveis (por exemplo, em pipelines de CI que processam código-fonte de terceiros) sem isolamento.
• Não use a técnica de injeção contra sistemas que você não controla. Exploração não autorizada é ilegal e antiética.

Referências

• Composer — projeto oficial
• Arquivo de lançamentos do Composer (para baixar PHARs específicos 2.9.5 / 2.9.6)
• Aviso oficial CVE-2026-40176 e o changelog do Composer 2.9.6 (consulte o rastreador de segurança da sua distribuição / o GitHub Advisory Database para obter detalhes autoritativos da correção)
• Contexto sobre injeção de argumentos em drivers VCS do Composer (a mesma classe de vulnerabilidade), por exemplo, CVE-2021-29472

Autor: Ikarolaborda · PoC datado de 2026-06-10.