Perforce corrige trois failles critiques qui ouvrent P4 Search sans authentification
Le 5 octobre 2026, Perforce a publié trois CVE critiques sur P4 Search, le moteur de recherche conteneurisé de Helix Core : un jeton d’authentification codé en dur (CVSS 10) et une interface de débogage JDWP laissée exposée permettent à un attaquant réseau non authentifié d’exécuter du code à côté du dépôt de code source. La parade tient en une mise à jour des images vers 2026.4.2 et un cloisonnement strict du service.
Lundi 5 octobre 2026. Perforce a publié trois CVE critiques visant P4 Search, le moteur de recherche de Helix Core : CVE-2026-100103 (CVSS 10.0), CVE-2026-100102 et CVE-2026-103510 (CVSS 9.5 chacune). Aucune authentification. Toutes trois ouvrent la porte à un attaquant réseau non authentifié — et deux d’entre elles mènent à l’exécution de code arbitraire avec les privilèges du service. À côté du code source. Le point sensible n’est pas la gravité, mais l’emplacement : P4 Search tourne généralement dans un conteneur juste à côté du P4 Server, là où vivent le code source et l’historique de l’entreprise.
Ce que P4 Search est, et pourquoi il est si proche du code
Helix Core (anciennement Perforce) est un système de gestion de versions centralisé massivement utilisé dans les studios de jeux, l’automobile, l’électronique et la finance. P4 Search est son moteur d’indexation et de recherche : il indexe les fichiers du dépôt et répond aux requêtes de recherche en texte intégral. Longtemps déployé comme un service supplémentaire, il est désormais distribué sous forme d’image de conteneur que les équipes lancent à côté du serveur.
C’est cette proximité qui rend les trois failles dangereuses. Un attaquant qui exécute du code dans P4 Search ne compromet pas seulement un index : il hérite d’un point d’appui sur le réseau où se trouve le P4 Server. Selon la segmentation en place, la distance qui le sépare du dépôt de code peut être nulle — et dans bien des organisations, le service de recherche n’a jamais été inclus dans le périmètre de durcissement, précisément parce qu’il n’est pas perçu comme un point d’entrée.
Les trois failles, de la pire à la plus discrète
CVE-2026-100103 (CVSS 10.0) est un jeton d’authentification codé en dur. Les images de conteneur de P4 Search embarquaient un jeton de service par défaut ; un attaquant qui connaît ce jeton contourne l’authentification, obtient des privilèges d’administration complets, puis exécute du code. La faille a été signalée par le chercheur Khoa Bui et enregistrée auprès du programme CVE dès le 25 septembre 2026, avant d’être rendue publique le 5 octobre.
CVE-2026-100102 (CVSS 9.5) est une interface de débogage JDWP (Java Debug Wire Protocol) laissée activée et exposée. N’importe qui atteignant le port de débogage — typiquement 8000 ou 5005 — peut s’y attacher et exécuter du code avec les privilèges du compte de service P4 Search.
CVE-2026-103510 (CVSS 9.5) est un contournement d’authentification : la validation des jetons de service est défaillante, ce qui permet à un attaquant non authentifié d’atteindre les mêmes privilèges administratifs.
Deux points communs unissent ces trois failles. D’abord, elles concernent toutes les images de conteneur antérieures à 2026.4.2 : la correction est identique pour les trois. Ensuite, deux d’entre elles relèvent de la configuration d’expédition plutôt que d’un bogue de logique applicative. Un jeton par défaut et un port de débogage laissé ouvert sont des défauts que l’on attend d’une image de développement, pas d’une image destinée à la production. Perforce a d’ailleurs publié d’autres correctifs autour du même lot — CVE-2026-103507 (CVSS 7.5), CVE-2026-85979 et CVE-2026-89212 (CVSS 8.6) — signe que la révision de P4 Search va au-delà des trois failles critiques.
Pourquoi ce n’est pas encore exploité, et pourquoi ça ne durera pas
Au 5 octobre 2026, aucun exploit public n’est disponible et les trois failles ne figurent pas encore au catalogue KEV de la CISA. C’est la fenêtre la plus confortable pour corriger : la faille est publique, les détails sont connus, mais personne n’a encore publié de code d’attaque clé en main.
Cette fenêtre est généralement courte. Une faille à CVSS 10 sur un outil de gestion de code source attire rapidement deux populations : les extorqueurs qui cherchent à dérober du code pour faire pression, et les acteurs de la chaîne d’approvisionnement qui veulent injecter du code malveillant dans des dépôts légitimes. Helix Core étant utilisé par des organisations riches en propriété intellectuelle, la valeur d’un accès est élevée. Le précédent de 2024 — la campagne mondiale qui a suivi la faille d’authentification CVE-2024-27198 sur TeamCity — rappelle à quelle vitesse un défaut sur un outil de build se transforme en compromission de masse : les attaquants exploitent rarement ce genre de faille « à la main », ils automatisent et ratissent.
La correction, et comment la vérifier
La correction tient en une action : faire passer toutes les images de conteneur P4 Search à la version 2026.4.2 ou ultérieure. Cette version retire le jeton par défaut et désactive l’interface JDWP.
En complément, trois vérifications valent la peine :
- Inventaire des images. Recensez chaque déploiement de P4 Search, y compris les environnements de recette et les sandbox, souvent oubliés, et vérifiez la version de l’image sur chacun.
- Cloisonnement réseau. Restreignez l’accès au service aux sous-réseaux de gestion ; une instance de recherche n’a aucune raison d’être joignable depuis Internet.
- Surveillance des ports de débogage. Dans les journaux, surveillez les connexions entrantes vers les ports 8000 et 5005, ainsi que les processus enfants inattendus sous le compte de service.
# Vérifier la version d'une image P4 Search déjà déployée
docker images | grep -i p4search
# Confirmer qu'aucun conteneur n'expose les ports JDWP (8000/5005)
docker ps --format '{{.Names}} {{.Ports}}' | grep -E '8000|5005' || echo "aucun port de débogage exposé"La première commande donne la version courante de l’image locale ; la seconde liste les conteneurs qui exposent un port de débogage. Si l’une renvoie une image antérieure à 2026.4.2 ou un port 8000/5005 ouvert, la correction n’est pas terminée.
Verdict
Si vous exploitez Helix Core avec P4 Search, mettez à jour les images vers 2026.4.2 cette semaine : trois failles critiques, dont une à CVSS 10, se corrigent par une seule action, et la fenêtre sans exploit public ne restera pas ouverte longtemps. Si vous ne pouvez pas mettre à jour immédiatement, cloisonnez le service derrière un pare-feu ou un groupe de sécurité et supprimez toute route publique vers lui : cela neutralise l’essentiel du risque tant que l’image n’est pas remplacée. Si vous n’êtes pas certain d’utiliser P4 Search, vérifiez quand même : l’image peut avoir été déployée par une équipe comme dépendance silencieuse d’un outil de recherche, sans que l’équipe infrastructure en ait connaissance. La leçon de fond dépasse Perforce — un jeton codé en dur et un port de débogage laissé ouvert dans une image de production sont des fautes d’expédition, pas des accidents, et le premier endroit où les chercher est la chaîne de livraison de vos propres conteneurs.