Résumé

La vulnérabilité

Composer peut résoudre des paquets depuis plusieurs systèmes de gestion de versions. Pour Perforce, le dépôt est identifié par une URL p4:// qui encode l'hôte, le port et l'utilisateur/flux. Lorsque le pilote Perforce de Composer construit la ligne de commande p4 sous-jacente, les champs extraits de l'URL contrôlée par l'attaquant ne sont pas suffisamment assainis avant d'être transmis à un shell.

Comme l'auteur du manifeste contrôle totalement l'URL du dépôt, un attaquant qui parvient à faire exécuter composer update/composer install à une victime sur un composer.json malveillant (par exemple, une dépendance empoisonnée, un dépôt hostile, ou un job CI traitant des fichiers de projet non fiables) peut s'échapper de l'invocation prévue de p4 et exécuter des commandes OS arbitraires avec les privilèges du processus Composer.

Cette vulnérabilité appartient à la même famille que les problèmes historiques d'injection d'arguments dans les pilotes VCS de Composer, où les valeurs d'URL/branche/flux sont transmises à des commandes shell sans échappement. Composer 2.9.6 durcit le pilote Perforce afin que la charge utile injectée ne s'exécute plus.

La description faisant autorité du comportement démontré ici est le code source du PoC lui-même (CVE202640176Test.php) ; consultez l'avis officiel et le journal des modifications de Composer pour les détails du correctif en amont.

Comment fonctionne le PoC

Le PoC est une classe unique, CVE202640176Test, qui réalise une expérience A/B (différentielle) contrôlée :

1. Vérification préalable — interroge --version sur les deux binaires Composer, affecté (2.9.5) et corrigé (2.9.6), et abandonne prématurément si l'un d'eux ne peut pas être invoqué.
2. Exécution affectée (2.9.5)
   • Crée un répertoire temporaire isolé sous le chemin temporaire système.
   • Écrit un composer.json dont la section repositories contient une entrée perforce avec une URL p4:// malveillante portant une charge utile shell injectée.
   • Exécute composer update dans ce répertoire.
   • Valide le résultat.
3. Exécution corrigée (2.9.6) — répète exactement les mêmes étapes avec le binaire corrigé.
4. Restauration — un bloc finally restaure toujours le composer.json original dans le répertoire du projet.
5. Verdict — affiche PASS uniquement lorsque l'exécution affectée montre l'effet secondaire et que l'exécution corrigée ne le montre pas.

Validation (ce qui compte comme "exploité")

Pour chaque exécution, validateRun() vérifie trois choses :

Une exécution est "OK" uniquement si les trois conditions sont remplies. Le test global réussit lorsque l'exécution affectée est OK et que l'exécution corrigée ne l'est pas — la signature précise d'une véritable vulnérabilité qui a ensuite été corrigée.

La charge utile d’injection (expliquée)

L'URL de dépôt malveillante est construite dans writeComposerJson() :

En détail :

• p4://127.0.0.1:1666:attacker_user — une URL Perforce d'apparence bien formée (hôte, port 1666, utilisateur).
• ;touch <marqueur> && echo '<runId>' > <marqueur> — les commandes shell injectées. Le ; initial termine la commande p4 prévue ; touch crée le fichier marqueur, et echo '<runId>' > <marqueur> écrit l'ID d'exécution unique dedans afin que le PoC puisse confirmer que la charge utile (et non un processus non lié) a produit le fichier.
• :client_test — texte de fin pour que le reste du parsing de l'URL reste plausible.

Sur le pilote affecté, les métacaractères shell sont honorés et le fichier marqueur est créé. Sur le pilote corrigé, la valeur est correctement échappée/encadrée, donc la même chaîne est traitée comme des données inertes et aucun marqueur n'apparaît.

Remarque : le PoC utilise un ID d'exécution unique horodaté et écrit son marqueur dans un répertoire temporaire isolé, de sorte que la charge utile est bénigne et auto-nettoyante plutôt que destructive.

Prérequis

• PHP 7.4+ (développé/testé avec PHP 8.x CLI). Le PoC lui-même n'utilise que des fonctions de base — aucun paquet Composer nécessaire pour exécuter le harnais.
• Deux binaires Composer disponibles sous forme de PHAR :
  • Composer 2.9.5 (affecté)
  • Composer 2.9.6 (corrigé)
• Un environnement shell de type POSIX (exec() exécute cd … && php …). Conçu pour Linux/macOS.
• Un composer.json de base dans le répertoire du projet (il est lu au démarrage, copié dans chaque exécution temporaire et restauré ensuite).

Vous n'avez généralement pas besoin d'un serveur Perforce en activité : la vulnérabilité réside dans la façon dont Composer construit la ligne de commande p4, et la charge utile injectée s'exécute avant/autour de toute connexion p4 réelle. Composer peut journaliser une erreur de connexion Perforce — c'est attendu et cela n'affecte pas la preuve par fichier marqueur.

Configuration

1. Clonez / placez le PoC dans un répertoire de travail.

2. Fournissez un composer.json dans le même répertoire que le PoC. Un minimal suffit :

   root@kitploit:~

   {
     "name": "research/cve-2026-40176-poc",
     "description": "Manifeste de base pour le PoC différentiel CVE-2026-40176",
     "require": {}
   }
   

3. Obtenez les deux binaires Composer et placez-les là où le PoC les attend (chemins par défaut indiqués) :

   root@kitploit:~

   /usr/local/bin/composer-2.9.5.phar   # affecté
   /usr/local/bin/composer-2.9.6.phar   # corrigé
   

   Vous pouvez télécharger des versions spécifiques de Composer depuis l'archive officielle, par exemple :

   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 vos chemins diffèrent, éditez les deux arguments du constructeur en bas de CVE202640176Test.php.

Utilisation

Le harnais exécute les deux versions de Composer tour à tour et affiche un verdict final. Le composer.json original est restauré automatiquement même si une exécution échoue (le travail se fait dans des répertoires temporaires jetables).

Exécution dans Docker (recommandé)

Le dépôt fournit un laboratoire conteneurisé qui reproduit exactement l'environnement : un runtime PHP CLI plus les deux versions de Composer épinglées aux chemins attendus par le PoC, complètement isolé réseau à l'exécution.

Cette commande construit cve-2026-40176-lab:latest (télécharge Composer 2.9.5 et 2.9.6 et vérifie chaque --version pendant la construction) et exécute le test différentiel dans un conteneur non privilégié, sans accès réseau sortant.

Ce que le laboratoire garantit :

• Vrais binaires. Les deux versions de Composer sont récupérées depuis l'archive officielle et vérifiées par version au moment de la construction — la construction échoue bruyamment si une version épinglée est indisponible.
• Isolation. Le service poc s'exécute sur un réseau pont internal (pas d'accès réseau sortant hôte/Internet), avec cap_drop: ALL et no-new-privileges. La charge utile injectée reste contenue.
• Pas de configuration hôte. Pas besoin de placer les PHAR sur votre hôte ni d'éditer manuellement les chemins.

Réépinglez les versions (doivent rester synchronisées avec les deux chemins du constructeur dans le PoC) via les arguments de construction :

Optionnel — serveur Perforce en direct. Un service p4d est disponible sous le profil full-lab (docker compose --profile full-lab up). La preuve par marqueur n'en a pas besoin ; il existe pour les chercheurs qui souhaitent un endpoint p4:// en direct. Notez que la charge utile du PoC cible 127.0.0.1:1666, donc un routage vers un conteneur p4d séparé nécessite de pointer l'URL du PoC vers l'hôte p4d.

Statut de reproduction (observé)

Résultat honnête : contre les versions réelles et publiées de Composer 2.9.5 et 2.9.6, le PoC ne se déclenche pas actuellement et le laboratoire rapporte INCONCLUSIF / ÉCHEC.

L'exécution de Composer affecté (2.9.5) sur le manifeste malveillant du PoC lève, à l'intérieur de Composer, avant la construction de toute commande p4/shell :

PerforceDriver::initialize() lit $this->repoConfig['depot'] en premier lieu, mais l'entrée de dépôt du PoC ne fournit que type et url (pas de clé depot). Le pilote abandonne à ce stade, donc la charge utile injectée ;touch <marqueur> dans l'URL n'est jamais atteinte et aucun marqueur n'est créé. L'isolation réseau n'en est pas la cause — la même erreur se produit avec un accès réseau complet.

Ce que cela signifie :

• Le laboratoire Docker lui-même est correct et exécute fidèlement le harnais différentiel sur les vrais binaires affecté/corrigé. Le résultat INCONCLUSIF est une propriété de la charge utile du PoC, pas de l'environnement.
• Pour exercer le véritable chemin de construction de commande Perforce, la configuration de dépôt du PoC nécessiterait au moins une clé depot (et réalistiquement un endpoint p4d en direct sous le profil full-lab). Affiner la charge utile jusqu'à ce point est du développement d'exploit au-delà de "mettre en place le laboratoire" et est intentionnellement laissé hors de portée ici.

La "Sortie attendue" ci-dessous est le résultat intentionnel/idéalisé du PoC, conservé pour référence ; ce n'est pas ce que la charge utile actuelle produit contre le vrai pilote.

Sortie attendue

Une démonstration réussie ressemble approximativement à ceci (les chemins et IDs varieront) :

Un code de sortie non nul de Composer est normal — composer update échoue finalement à récupérer le paquet (fictif). La preuve est le fichier marqueur, pas le statut de sortie de Composer.

Interprétation du résultat

Causes courantes d'un résultat inconclusif :

• Le pilote abandonne à PerforceDriver.php:40 avec Undefined array key "depot" — la configuration de dépôt manque d'une clé depot, donc Composer n'atteint jamais le chemin de construction de la commande p4. C'est ce qui se produit avec la charge utile actuelle du PoC contre les vrais 2.9.5/2.9.6 (voir Statut de reproduction).
• Les chemins des binaires Composer sont incorrects ou les PHAR ne sont pas réellement 2.9.5 / 2.9.6.
• Le shell hôte ou exec() de PHP est sandboxé/désactivé.
• La sortie de Composer ne contient pas la chaîne littérale p4 (chemin du pilote non atteint).

Structure du projet

Le PoC entier tient dans un fichier :

• __construct() — stocke les deux chemins de binaires, génère un ID d'exécution horodaté, prend un instantané du composer.json original.
• run() — orchestre la vérification préalable, l'exécution affectée, l'exécution corrigée, la restauration, et le verdict.
• prepareTempDir() — crée un répertoire de travail isolé par exécution.
• writeComposerJson() — construit le manifeste malveillant avec l'URL p4:// injectée.
• runComposer() — exécute composer update (arguments échappés avec escapeshellarg()) et capture la sortie + le code de sortie.
• validateRun() — vérifie la version, le fichier marqueur, et l'activité du pilote Perforce.
• preflightVersion() — lit --version depuis un binaire donné.

Notes de conception

• Isolation et nettoyage. Chaque exécution utilise son propre répertoire temporaire ; le composer.json original est restauré dans un bloc finally quel que soit le résultat.
• Échappement du harnais vs. de la charge utile. Le harnais échappe ses propres arguments shell avec escapeshellarg() (afin que le PoC n'injecte pas accidentellement dans ses propres appels exec()). La vulnérabilité se trouve une couche plus profond — dans la manière dont Composer lui-même construit la commande p4 — ce que cible exactement la charge utile.
• Preuve différentielle. Exécuter les deux binaires (vulnérable et corrigé) en une seule passe supprime l'ambiguïté : la même entrée produit des comportements divergents, ce qui est une preuve bien plus forte qu'une simple observation positive.
• Charge utile bénigne. Les commandes injectées ne font que touch/echo dans un marqueur temporaire unique, rendant le PoC sûr à exécuter de manière répétée sans effets secondaires sur l'hôte.

Limitations et problèmes connus

• Chemins de binaires codés en dur. Les deux chemins de PHAR sont passés en ligne en bas du fichier. Modifiez-les pour votre environnement (ou refactorisez pour les lire depuis des arguments CLI / variables d'environnement).
• Hypothèse POSIX. Le motif exec("cd … && php …") et la charge utile ;/&& supposent un shell de type Unix ; Windows n'est pas pris en charge en l'état.
• Race condition mkdir / permissions. Les répertoires temporaires sont créés avec le mode 0777 ; resserrez les droits si vous exécutez dans un environnement partagé.
• Détection de version basée sur une expression régulière. Elle analyse Composer X.Y.Z dans la sortie ; des bannières Composer inhabituelles pourraient faire échouer la correspondance.

Utilisation responsable

Ce dépôt existe pour comprendre et se défendre contre CVE-2026-40176.

• Exécutez-le uniquement sur des systèmes et installations Composer qui vous appartiennent ou pour lesquels vous êtes explicitement autorisé à tester.
• Le message pour les défenseurs : mettez à jour Composer vers 2.9.6 ou une version ultérieure, et n'exécutez jamais composer install/update sur des fichiers composer.json non fiables (par exemple, dans des pipelines CI qui traitent le code source de projets tiers) sans isolation.
• N'utilisez pas la technique d'injection contre des systèmes que vous ne contrôlez pas. L'exploitation non autorisée est illégale et contraire à l'éthique.

Références

• Composer — projet officiel
• Archive des versions Composer (pour récupérer les PHAR 2.9.5 / 2.9.6 spécifiques)
• Avis officiel CVE-2026-40176 et journal des modifications de Composer 2.9.6 (consultez le suivi de sécurité de votre distribution / la GitHub Advisory Database pour les détails du correctif faisant autorité)
• Contexte sur l'injection d'arguments dans les pilotes VCS de Composer (la même classe de vulnérabilité), par exemple CVE-2021-29472

Auteur : Ikarolaborda · PoC daté du 2026-06-10.