Resumen

La Vulnerabilidad

Composer puede resolver paquetes de varios sistemas de control de versiones. Para Perforce, el repositorio se identifica mediante una URL p4:// que codifica el host, puerto y usuario/stream. Cuando el controlador Perforce de Composer construye la línea de comandos subyacente de p4, los campos tomados de la URL controlada por el atacante no se sanitizan suficientemente antes de pasarse a un shell.

Debido a que el autor del manifiesto controla completamente la URL del repositorio, un atacante que pueda lograr que una víctima ejecute composer update/composer install contra un composer.json malicioso (por ejemplo, una dependencia envenenada, un repositorio hostil o un trabajo de CI que procese archivos de proyecto no confiables) puede escapar de la invocación prevista de p4 y ejecutar comandos arbitrarios del sistema operativo con los privilegios del proceso de Composer.

Esto pertenece a la misma familia que los problemas históricos de inyección de argumentos en los controladores VCS de Composer, donde los valores de URL/rama/stream fluyen hacia comandos de shell sin escape. Composer 2.9.6 refuerza el controlador Perforce para que el payload inyectado ya no se ejecute.

La descripción autorizada del comportamiento demostrado aquí es el código fuente de la PoC (CVE202640176Test.php); consulte el aviso oficial y el registro de cambios de Composer para obtener detalles sobre la corrección upstream.

Cómo Funciona la PoC

La PoC es una única clase, CVE202640176Test, que realiza un experimento controlado A/B (diferencial):

1. Verificación previa — consulta --version tanto en el binario afectado (2.9.5) como en el corregido (2.9.6) de Composer y aborta temprano si alguno no puede invocarse.
2. Ejecución afectada (2.9.5)
   • Crea un directorio temporal aislado bajo la ruta temporal del sistema.
   • Escribe un composer.json cuya sección repositories contiene una entrada perforce con una URL p4:// maliciosa que lleva un payload de shell inyectado.
   • Ejecuta composer update en ese directorio.
   • Valida el resultado.
3. Ejecución corregida (2.9.6) — repite exactamente los mismos pasos contra el binario parcheado.
4. Restauración — un bloque finally siempre restaura el composer.json original en el directorio del proyecto.
5. Veredicto — imprime PASS solo cuando la ejecución afectada muestra el efecto secundario y la ejecución corregida no.

Validación (qué cuenta como "explotado")

Para cada ejecución, validateRun() verifica tres cosas:

Una ejecución es "OK" solo cuando las tres pasan. La prueba general pasa cuando la ejecución afectada es OK y la ejecución corregida no — la firma precisa de una vulnerabilidad real que fue parcheada posteriormente.

El Payload de Inyección (Explicado)

La URL del repositorio malicioso se construye en writeComposerJson():

Desglosándola:

• p4://127.0.0.1:1666:attacker_user — una URL de Perforce de aspecto bien formado (host, puerto 1666, usuario).
• ;touch <marcador> && echo '<idEjecucion>' > <marcador> — los comandos de shell inyectados. El ; inicial termina el comando p4 previsto; touch crea el archivo marcador, y echo '<idEjecucion>' > <marcador> escribe el ID de ejecución único en él para que la PoC pueda confirmar que el payload (y no algún proceso no relacionado) produjo el archivo.
• :client_test — texto final para mantener el resto del análisis de la URL plausible.

En el controlador afectado, los metacaracteres del shell se respetan y se crea el archivo marcador. En el controlador corregido, el valor se escapa/entrecomilla adecuadamente, por lo que la misma cadena se trata como datos inertes y no aparece ningún marcador.

Nota: la PoC utiliza un ID de ejecución único con marca de tiempo y escribe su marcador dentro de un directorio temporal aislado, por lo que el payload es benigno y se autolimpia en lugar de ser destructivo.

Requisitos

• PHP 7.4+ (desarrollado/probado contra PHP 8.x CLI). La PoC en sí usa solo funciones principales — no se requieren paquetes de Composer para ejecutar el arnés.
• Dos binarios de Composer disponibles como PHARs:
  • Composer 2.9.5 (afectado)
  • Composer 2.9.6 (corregido)
• Un entorno de shell similar a POSIX (exec() ejecuta cd … && php …). Diseñado para Linux/macOS.
• Un composer.json base en el directorio del proyecto (se lee al inicio, se copia en cada ejecución temporal y se restaura después).

Generalmente no necesita un servidor Perforce en funcionamiento: la vulnerabilidad está en cómo Composer construye la línea de comandos de p4, y el payload inyectado se ejecuta antes/alrededor de cualquier conexión real a p4. Composer puede registrar un error de conexión de Perforce — eso es esperado y no afecta la prueba del archivo marcador.

Configuración

1. Clone / coloque la PoC en un directorio de trabajo.

2. Proporcione un composer.json en el mismo directorio que la PoC. Uno mínimo es suficiente:

   root@kitploit:~

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

3. Obtenga los dos binarios de Composer y colóquelos donde la PoC los espera (valores predeterminados mostrados):

   root@kitploit:~

   /usr/local/bin/composer-2.9.5.phar   # afectado
   /usr/local/bin/composer-2.9.6.phar   # corregido
   

   Puede descargar versiones específicas de Composer desde el archivo oficial, por ejemplo:

   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
   

   Si sus rutas son diferentes, edite los dos argumentos del constructor al final de CVE202640176Test.php.

Uso

El arnés ejecuta ambas versiones de Composer por turnos e imprime un veredicto final. El composer.json original se restaura automáticamente incluso si una ejecución falla (el trabajo se realiza en directorios temporales desechables).

Ejecución en Docker (recomendado)

El repositorio incluye un laboratorio contenerizado que replica el entorno exactamente: un runtime PHP CLI más las dos versiones fijadas de Composer en las rutas que la PoC espera, completamente aislado de la red en tiempo de ejecución.

Esto construye cve-2026-40176-lab:latest (descargando Composer 2.9.5 y 2.9.6 y verificando cada --version durante la construcción) y ejecuta la prueba diferencial dentro de un contenedor no privilegiado y sin salida de red.

Qué garantiza el laboratorio:

• Binarios reales. Ambas versiones de Composer se obtienen del archivo oficial y se verifica su versión en el momento de la construcción; la construcción falla de forma notoria si una versión fijada no está disponible.
• Aislamiento. El servicio poc se ejecuta en una red puente internal (sin salida al host/internet), con cap_drop: ALL y no-new-privileges. El payload de inyección permanece contenido.
• Sin configuración del host. No es necesario colocar PHARs en su host ni editar rutas manualmente.

Puede cambiar las versiones (deben estar sincronizadas con las dos rutas del constructor en la PoC) mediante argumentos de construcción:

Opcional — servidor Perforce en vivo. Hay un servicio p4d disponible bajo el perfil full-lab (docker compose --profile full-lab up). La prueba basada en marcadores no lo necesita; existe para investigadores que deseen un endpoint p4:// en vivo. Tenga en cuenta que el payload de la PoC apunta a 127.0.0.1:1666, por lo que el enrutamiento a través de un contenedor p4d separado requiere apuntar la URL de la PoC al host p4d.

Estado de Reproducción (observado)

Resultado honesto: contra las versiones reales, publicadas de Composer 2.9.5 y 2.9.6, la PoC no se activa actualmente, y el laboratorio informa INCONCLUSIVO / FALLO.

Ejecutar el Composer afectado (2.9.5) contra el manifiesto malicioso de la PoC lanza, dentro de Composer, antes de que se construya cualquier comando p4/shell:

PerforceDriver::initialize() lee $this->repoConfig['depot'] lo primero, pero la entrada de repositorio de la PoC solo proporciona type y url (sin clave depot). El controlador aborta en ese punto, por lo que el payload inyectado ;touch <marcador> en la URL nunca se alcanza y no se crea ningún marcador. El aislamiento de red no es la causa: el mismo error ocurre con salida de red completa.

Qué significa esto:

• El laboratorio Docker en sí es correcto y ejecuta fielmente el arnés diferencial contra los binarios genuinos afectados/corregidos. El resultado INCONCLUSIVO es una propiedad del payload de la PoC, no del entorno.
• Para ejercitar la ruta real de construcción de comandos de Perforce, la configuración del repositorio de la PoC necesitaría al menos una clave depot (y, de forma realista, un endpoint p4d en vivo bajo el perfil full-lab). Refinar el payload hasta ese punto es desarrollo de exploits más allá de "montar el laboratorio" y queda intencionalmente fuera del alcance aquí.

La "Salida Esperada" a continuación es el resultado previsto/idealizado de la PoC, mantenido como referencia; no es lo que el payload actual produce contra el controlador real.

Salida Esperada

Una demostración exitosa se ve aproximadamente así (las rutas e IDs variarán):

Un código de salida de Composer distinto de cero es normal — composer update finalmente falla al obtener el paquete (falso). La prueba es el archivo marcador, no el estado de salida de Composer.

Interpretación del Resultado

Causas comunes de un resultado inconcluso:

• El controlador aborta en PerforceDriver.php:40 con Undefined array key "depot" — la configuración del repositorio carece de una clave depot, por lo que Composer nunca alcanza la ruta de construcción del comando p4. Esto es lo que sucede con el payload actual de la PoC contra las versiones reales 2.9.5/2.9.6 (consulte Estado de Reproducción).
• Las rutas de los binarios de Composer son incorrectas o los PHARs no son realmente 2.9.5 / 2.9.6.
• El shell del host o exec() de PHP está en un entorno limitado/deshabilitado.
• La salida de Composer no contiene la cadena literal p4 (ruta del controlador no alcanzada).

Estructura del Proyecto

Toda la PoC está en un archivo:

• __construct() — almacena las dos rutas de binarios, acuña un ID de ejecución con marca de tiempo, captura una instantánea del composer.json original.
• run() — orquesta la verificación previa, la ejecución afectada, la ejecución corregida, la restauración y el veredicto.
• prepareTempDir() — crea un directorio de trabajo aislado por ejecución.
• writeComposerJson() — construye el manifiesto malicioso con la URL p4:// inyectada.
• runComposer() — ejecuta composer update (argumentos escapados con escapeshellarg()) y captura la salida + código de salida.
• validateRun() — verifica versión, archivo marcador y actividad del controlador Perforce.
• preflightVersion() — lee --version de un binario dado.

Notas de Diseño

• Aislamiento y limpieza. Cada ejecución usa su propio directorio temporal; el composer.json original se restaura en un bloque finally independientemente del resultado.
• Escapado del arnés vs. payload. El arnés escapa sus propios argumentos de shell con escapeshellarg() (para que la PoC no se inyecte accidentalmente en sus propias llamadas exec()). La vulnerabilidad reside una capa más profunda — en cómo Composer mismo construye el comando p4 — que es exactamente lo que el payload ataca.
• Prueba diferencial. Ejecutar tanto el binario vulnerable como el parcheado en una sola pasada elimina ambigüedades: la misma entrada produce un comportamiento divergente, lo que es una evidencia mucho más sólida que una única observación positiva.
• Payload benigno. Los comandos inyectados solo hacen touch/echo en un marcador temporal único, lo que hace que la PoC sea segura de ejecutar repetidamente sin efectos secundarios en el host.

Limitaciones y Problemas Conocidos

• Rutas de binario hardcodeadas. Las dos rutas de los PHARs se pasan en línea al final del archivo. Edítelas para su entorno (o refactorice para leer de argumentos CLI / variables de entorno).
• Suposición POSIX. El patrón exec("cd … && php …") y el payload con ;/&& asumen un shell tipo Unix; Windows no es compatible tal cual.
• Condición de carrera / permisos en mkdir. Los directorios temporales se crean con modo 0777; ajuste si se ejecuta en un entorno compartido.
• La detección de versión se basa en expresiones regulares. Analiza Composer X.Y.Z de la salida; banners inusuales de Composer podrían impedir la coincidencia.

Uso Responsable

Este repositorio existe para entender y defenderse contra CVE-2026-40176.

• Ejecútelo solo contra sistemas e instalaciones de Composer que posea o para los que tenga autorización explícita para realizar pruebas.
• La conclusión para los defensores: actualice Composer a 2.9.6 o posterior, y nunca ejecute composer install/update en archivos composer.json no confiables (por ejemplo, en pipelines de CI que procesen código fuente de terceros) sin aislamiento.
• No utilice la técnica de inyección contra sistemas que no controle. La explotación no autorizada es ilegal y poco ética.

Referencias

• Composer — proyecto oficial
• Archivo de versiones de Composer (para obtener PHARs específicos de 2.9.5 / 2.9.6)
• Aviso oficial de CVE-2026-40176 y el registro de cambios de Composer 2.9.6 (consulte el rastreador de seguridad de su distribución / la Base de Datos de Avisos de GitHub para obtener detalles autorizados de la corrección)
• Antecedentes sobre la inyección de argumentos en controladores VCS de Composer (la misma clase de vulnerabilidad), por ejemplo, CVE-2021-29472

Autor: Ikarolaborda · PoC fechada 2026-06-10.