Composer 2.10.3 et 2.2.30 viennent de débarquer, et — accrochez-vous — ce n'est pas une release « game changer ». Non, là on parle rustines de sécurité, et pas n'importe lesquelles! Comme le relaie le changelog officiel sur GitHub, quatre failles ont été colmatées dans le gestionnaire de paquets qu'on utilise (quasiment) tous les jours. Pour une fois, ce n'est pas une RFC qui va faire débat trois mois sur Hacker News: c'est un patch à pousser avant la pause café.
Ce qui a été corrigé (et pourquoi c'est moche)
Commençons par la star du lot, la fameuse CVE-2026-59944: une vulnérabilité de traversée de chemin déclenchée via des entrées bin liées symboliquement. Dit autrement, un attaquant peut faire sortir Composer de son répertoire prévu en lui faisant suivre un lien symbolique malicieux. Pas idéal.
À côté, on trouve une injection de commande via des URL Perforce malveillantes (oui, certaines boîtes tournent encore sur Perforce en 2026, mais passons) — un grand classique qui rappelle que Composer a longtemps fait confiance aux URLs sans trop regarder ce qu'on lui donnait à avaler.
Cerise sur le gâteau: des credentials embarqués dans les URL qui fuitent à plus d'endroits que prévu, et un appariement d'URL GitLab qui pouvait envoyer vos précieux tokens vers le mauvais domaine. Autour d'un café noir, on appelle ça une mauvaise journée.
Pourquoi ça nous concerne (même si « on n'est pas cible »)
On se dit souvent: « mon projet perso, mon legacy, mon petit site marchand… personne ne va venir chercher Composer chez moi ». Sauf que (roulement de tambour) Composer télécharge et exécute des scripts. Beaucoup. Sur chaque CI, sur chaque conteneur de build, sur chaque poste de dev. C'est la cible idéale pour une attaque de supply chain: un simple composer install et on ouvre la porte à du code arbitraire.
Et puis, soyons sérieux: la faille Perforce combinée à l'injection de commande, c'est exactement le genre de vecteur qui fait transpirer les RSSI. Même dans une PME qui bricole du Symfony, le scénario reste plausible. Bref, personne n'est « trop petit ».
Quoi faire concrètement (le mode patch & chill)
Trois réflexes, dans l'ordre:
1. composer self-update --2.10.3 (ou 2.2.30 si vous êtes sur la branche LTS).
2. Scruter vos lockfiles: les entrées bin suspectes ou les URLs custom qui pointent vers du Perforce exotique, c'est le moment de faire le ménage.
3. Auditer les gitlab.com (et apparentés) dans vos composer.json: si l'URL de votre registry ressemble vaguement à du GitLab, vérifier que les credentials vont bien au bon endroit.
Pour le contexte plus large, la revue hebdomadaire d'Andrew Nesbitt rappelle que toute la chaîne d'outillage bouge en ce moment: pnpm 12.0 stable — la fameuse réécriture en Rust — pointe enfin le bout de son nez, et Renovate a aussi publié une flopée d'avis sur son CLI (dix au total, dont neuf classés High). Bref, ce n'est pas que Composer qui fait du bruit — c'est tout l'écosystème qui se durcit.
En attendant la prochaine release excitante (avec, on l'espère, un peu de nouveauté fonctionnelle cette fois-ci), filez patcher vos Composer. Vous savez que c'est la chose responsable à faire — et ça vous évitera l'ironie d'être compromis via un outil censé, justement, sécuriser vos dépendances. À vous les studios!