Un rapport d’agent falsifié exécute du code sur Puppet Server et vole la clé de signature CA

3 novembre 2026. Puppet by Perforce et le fork OpenVox, porté par Vox Pupuli, publient un correctif coordonné pour CVE-2026-115731, noté 9,4 en CVSS 4.0. 4 novembre 2026. Un exploit public est intégré à l’avis GHSA-ffr6-rwpm-p5wq, avec un rapport malveillant fonctionnel qui exécute une commande shell. 5 novembre 2026. Aucune exploitation en conditions réelles n’a encore été confirmée. La conclusion tient en une phrase : tout agent muni d’un certificat signé peut exécuter du code sur le serveur Puppet, voler la clé de signature CA et, de là, atteindre chaque nœud géré.

Pour un SRE qui administre une flotte avec Puppet, ce n’est pas un bug de plus. C’est la compromission du plan de contrôle de la configuration, le point unique d’où l’on pousse des paquets, des fichiers et des réglages vers des centaines de machines.

La mécanique : un canal légitime détourné

La faille, CVE-2026-115731, est une désérialisation de données non fiables dans le traitement des rapports. Les agents Puppet envoient un rapport au serveur après chaque exécution — c’est le fonctionnement normal du produit. Le problème, c’est que ce rapport était désérialisé sans vérifier que son contenu était sûr.

Un agent qui détient un certificat signé par la CA peut donc soumettre un rapport falsifié qui exécute du code arbitraire sur le serveur Puppet, avec les privilèges de l’utilisateur du service.

• CVE-2026-115731 : exécution de code à distance via un rapport falsifié, CVSS 9,4.
• CVE-2026-115732 : un nœud peut usurper l’identité d’un autre, CVSS 9,0.

L’exigence d’un certificat signé ressemble à une barrière. Elle ne l’est pas partout.

L’autosigning, ou comment la barrière disparaît

Le point de friction tient dans un réglage courant en entreprise : l’autosigning. Quand il est activé, le serveur signe automatiquement tout certificat qui lui est présenté. Un attaquant n’a alors même pas besoin d’avoir déjà compromis un agent : il demande un certificat et le reçoit.

La chaîne devient effectivement sans authentification : n’importe qui pouvant joindre le serveur obtient un certificat, puis exploite la faille pour voler la clé de signature CA.

Et cette clé est le point névralgique. La clé de signature CA est la racine de confiance de chaque nœud géré. L’attaquant qui la détient peut frapper des certificats que toute l’infrastructure acceptera comme légitimes — et ces identités forgées survivent au correctif, tant que le matériel de confiance n’est pas rotaté.

Le rayon d’impact : chaque nœud que le serveur gère

La gravité de CVE-2026-115731 ne vient pas de la complexité de la faille, mais de sa position dans l’architecture. Un serveur de gestion de configuration est au centre de l’environnement : il pousse des paquets, des fichiers et des réglages vers de nombreuses machines, souvent avec des privilèges élevés.

Le raisonnement de Neodyme, qui a participé à la divulgation, est limpide : une fois le code exécuté sur le serveur, l’attaquant récupère la clé de signature CA et l’utilise pour exécuter des commandes en root sur les agents gérés. Une seule compromission se transforme en accès durable à toute la flotte.

• Manuel de signature : le risque se déplace vers tout agent compromis qui détient déjà un certificat valide.
• Autosigning : le risque est ouvert à quiconque peut joindre le serveur.

L’exploit public raccourcit encore le délai des défenseurs. Le rapport malveillant fonctionnel livré dans l’avis sert à la fois de test aux équipes et de mode d’emploi aux attaquants. C’est la nature à double tranchant de la divulgation coordonnée : le correctif sort en même temps que le détail exploitable.

Ce que ça change pour une équipe d’infrastructure

Cette faille illustre une vérité que les équipes infrastructure connaissent mais sous-pondèrent : le serveur de gestion de configuration est l’actif le plus rentable à compromettre, pas le plus visible. On blinde les applications, on segmente les réseaux, et l’on oublie que le serveur Puppet détient déjà les clés de tout.

L’ordre des priorités est limpide.

• Appliquer le correctif sur OpenVox et Puppet Enterprise sans attendre, en priorité là où l’autosigning est actif.
• Rotater la CA et les certificats d’agents après le correctif. Une clé volée ne devient inoffensive que si le matériel de confiance change.
• Réinterroger l’autosigning. S’il n’est pas indispensable, désactivez-le et revenez à une signature manuelle contrôlée.
• Surveiller les soumissions de rapports inhabituelles dans les journaux du serveur, en attendant de pouvoir confirmer l’état de chaque hôte.

Il faut aussi mesurer l’absence d’exploitation confirmée pour ce qu’elle est : un état du premier jour, pas une garantie. Un exploit public qui donne le contrôle d’un serveur de gestion est exactement le type de matériel que les attaquants testent vite. Le silence actuel est une fenêtre, pas une conclusion.

Deux branches, un seul plan de contrôle

Le contexte du fork compte ici. En 2025, Perforce a fait évoluer la licence de Puppet vers un modèle moins ouvert, et la communauté, emmenée par Vox Pupuli, a lancé le fork OpenVox. Les deux branches partagent le même héritage de code, et donc la même faille.

• Puppet Enterprise (Perforce) et OpenVox (communauté) publient chacun un correctif coordonné le 3 novembre.
• Les deux avis sont issus d’une divulgation coordonnée impliquant Perforce, Vox Pupuli et Neodyme.

Pour un opérateur, cela veut dire deux choses. D’abord, il ne suffit pas de savoir quel produit vous utilisez, il faut savoir sur quelle branche : les numéros de version corrigés diffèrent entre les deux lignées. Ensuite, la coordination entre un éditeur et son fork est un bon signe de maturité — la faille a été traitée des deux côtés en même temps, sans laisser une branche exposée pendant que l’autre corrigeait.

C’est aussi un rappel que la licence d’un outil ne le protège pas des failles : OpenVox et Puppet Enterprise partagent le même code de traitement des rapports, et donc le même risque. La sécurité de votre gestion de configuration dépend de votre cadence de mise à jour, pas du nom affiché sur la bannière.

Verdict

CVE-2026-115731 est la faille que les équipes d’infrastructure redoutent : elle transforme le serveur de configuration en passe-partout pour toute la flotte. La bonne nouvelle est la divulgation coordonnée — correctif et détail publiés ensemble, chez Perforce comme chez OpenVox — qui donne aux défenseurs les mêmes armes qu’aux attaquants.

Si vous exploitez Puppet Enterprise ou OpenVox, appliquez le correctif cette semaine et rotater la CA ; ne considérez pas la mise à jour comme terminée tant que le matériel de confiance n’a pas changé. Si l’autosigning est actif, traitez cette faille comme une 10,0 : la barrière du certificat a déjà disparu. Le serveur de configuration est un roi dont la couronne, la clé de signature, ne se répare que par une rotation complète.

Références

• OpenVox — advisory GHSA-ffr6-rwpm-p5wq, CVE-2026-115731 (3 novembre 2026)
• Red Hat — CVE-2026-115731, Puppet report deserialization code execution
• Neodyme — technical write-up on the Puppet Server RCE
• Daily Security Review — Public Exploit Released for Puppet Server RCE CVE-2026-115731 (4 novembre 2026)