Des attaquants disposant d’un certificat client valide pour OpenVox ou Puppet peuvent provoquer une exécution de code à distance sur le serveur Puppet grâce à une vulnérabilité de désérialisation en Ruby. Selon l’annonce de github.com, cette faille permet à un code malveillant d’être exécuté directement sur le serveur openvox-server en ciblant le point de terminaison PUT /puppet/v3/report.

Le mécanisme est précis. Lorsque les agents OpenVox / Puppet envoient des « événements » au serveur Puppet, le JSON reçu est traité par la méthode Puppet::Pops::Serialization::FromDataConverter.convert dans le fichier puppet/transaction/event.rb. C’est là que la désérialisation se produit, permettant à l’attaquant de fournir un type personnalisé. Ce type est ensuite utilisé pour exécuter RubyGenerator.new.create_class(self), ce qui entraîne une exécution de code arbitraire.

L’impact est sévère. La preuve de concept montre comment un événement JSON spécifiquement construit peut déclencher l’exécution de la commande touch /tmp/pwned sous l’utilisateur puppet sur le serveur hôte. Dans les déploiements d’entreprise utilisant l’authentification automatique (autosign), l’obtention d’un certificat valide est possible via le point d’inscription client, transformant cette vulnérabilité en une menace authentifiée potentiellement critique.

Les conséquences d’une compromission du serveur

L’exécution de code sous l’utilisateur puppet n’est pas anodine. Elle donne à l’attaquant accès à la clé de la CA de signature. Si l’orchestration est configurée ainsi, l’attaquant peut signer des certificats avec les attributs nécessaires (serverAuth, clientAuth), ouvrant potentiellement la voie à des commandes directes sur d’autres machines.

Le rapport CVE-2026-115731 classe cette faille avec un score CVSS 4.0 de 9,4, ce qui est critique. Cette vulnérabilité affecte également Puppet Enterprise et ses composants intégrés.

Que faire maintenant

Pour les équipes administratives, le message est clair : les versions affectées doivent être mises à jour immédiatement. L’annonce de github.com indique que des versions corrigées sont disponibles. Il faut vérifier rigoureusement l’environnement avant d’appliquer le correctif.

Parallèlement, d’autres alertes circulent. JPCERT/CC a récemment signalé des vulnérabilités dans XenServer, et Airbyte a publié des notes de version 2.2 détaillant des changements importants dans sa gestion de Helm, notamment l’obsolescence de certaines clés de configuration pour les déploiements communautaires.

Si vous opérez un serveur OpenVox / Puppet, la priorité absolue est de migrer vers une version patchée. En attendant, si la configuration le permet, surveillez de près les logs d’activité pour détecter toute tentative inhabituelle de soumission d’événements au point de terminaison /puppet/v3/report par des entités possédant des certificats valides. Il faut considérer que l’obtention de ce certificat est le premier pas vers la compromission complète de l’infrastructure.

Fiche technique

Données : NVD (NIST) et GitHub Advisory Database (CC BY 4.0, données adaptées).

Sources

• Authenticated RCE on OpenVox server via Event Deserialization, github.com
• Airbyte 2.2 | Airbyte Docs, docs.airbyte.com
• Weekly Report: Cloud Software GroupのXenServerに複数の脆弱性, JPCERT/CC, 11 novembre 2026
• N-able issues advisory on critical vulnerabilities, Sophos, 10 novembre 2026
• Chrome-Update stopft attackiertes Sicherheitsleck, Heise, 10 novembre 2026
• GHSA-c73h-2jmc-4mfp : An out-of-bounds write vulnerability in the CGI program of Zyxel GS1900-24E firmware…, GitHub Advisory Database (CC BY 4.0)
• CVE-2026-107441, NVD (NIST)

Crédits photo

• Image en une : EFTA00002634 – Server rack filled with tangled cables and networking equipment in a cluttered…, par Federal Bureau of Investigation, Public domain, via Wikimedia Commons (recadrée)
• Image dans l’article : EFTA00002636 – Cluttered server rack filled with tangled cables and equipment in a dimly lit…, par Federal Bureau of Investigation, Public domain, via Wikimedia Commons (recadrée)