Puppet Server RCE: Why OpenVox CVE-2026-115731 and Autosign Put Your Whole Fleet at Risk

Nov 9, 2026 · 6 min read threat-intelligencepuppetopenvoxvulnerability-managementcloud-security

Your configuration-management server is not “just another internal tool”. A Puppet or OpenVox server compiles the configuration for every node it manages, and it runs the certificate authority those nodes use to prove who they are. That is why the Puppet Server RCE pair disclosed on 3 November 2026 — CVE-2026-115731 and CVE-2026-115732, both rated CVSSv4 9.0 or higher, with a sample exploit already public in the advisory — deserves attention this week even if nobody has confirmed exploitation in the wild yet.

What was disclosed

The coordinated disclosure, posted to the oss-security mailing list by the Vox Pupuli community with Perforce (Puppet’s owner) and the researchers at Neodyme, covers two issues:

  • CVE-2026-115731 — report deserialization leading to remote code execution (CVSSv4 9.4). Agents send run reports back to the server. A crafted report can be deserialized in a way that leads to code execution on the server itself.
  • CVE-2026-115732 — certificate-name impersonation (CVSSv4 9.0). A flaw in the authorization layer (trapperkeeper-authorization) lets a client be treated as a different certname than the one it should be, so access rules written per node can be bypassed.

Affected versions (per the oss-security advisory):

  • OpenVox Server up to 9.1.0 and 8.17.0
  • OpenVox Agent up to 9.2.0 and 8.31.1
  • Puppet Enterprise before 2023.8.13, 2025.12.1 and 2026.0.1 (per Perforce’s fix versions as reported by SecurityOnline)
  • Open-source Puppet: no further updates are being published, so there is no upstream fix on that line.

Fixed versions: openvox-server 9.2.0 / 8.18.0, openvox-agent 9.3.0 / 8.32.0 and openvoxdb 9.2.0 / 8.18.0. Debian has shipped DLA-4885-1 (bookworm) and DSA-6609-1 (trixie).

Technical analysis: why autosign changes the picture

On its own, a deserialization bug in the report endpoint needs an attacker who can submit a report — normally that means holding a valid, signed agent certificate. That is the guardrail most teams quietly rely on.

Autosign removes that guardrail. When a Puppet or OpenVox server is configured to sign certificate requests automatically — globally, by wildcard, or through a weak policy script — anyone who can reach the server on the network can request a certificate, receive one and become a “node”. From there, the report path is reachable. The advisory notes that with autosign the chain becomes effectively unauthenticated.

The certname impersonation issue makes it worse. Many Puppet estates use per-node rules in auth.conf to decide which node may fetch which catalog or file. If a client can be treated as another certname, those rules stop being a boundary.

Put together, the realistic attack path looks like this:

  1. Reach the Puppet/OpenVox server (by default on TCP 8140).
  2. Obtain a certificate — trivially, if autosign is permissive.
  3. Send a crafted report to trigger CVE-2026-115731, or use CVE-2026-115732 to pose as a more privileged node.
  4. Run code on the server that holds the CA and compiles every node’s configuration.

We are deliberately not reproducing the sample exploit here. It is public in the project’s GitHub advisory, which means the barrier to step 3 is now low.

Impact assessment

Risk rating: Critical for any internet-reachable or flat-network Puppet/OpenVox server; High otherwise.

Code execution on a configuration-management server is rarely the end of an incident. It is the beginning of a fleet-wide one:

  • Every managed node pulls its configuration from that server. An attacker who controls catalog compilation can push packages, users, SSH keys or services to all of them.
  • The CA private key lives on the server. With it, an attacker can mint certificates that your infrastructure trusts.
  • Secrets used in manifests — via Hiera, eyaml or lookup backends — are often readable from that host.
  • Cloud fleets are frequently built and maintained by Puppet. A server that provisions VMs across AWS, Azure or GCP gives an attacker reach into all of them.

On exploitation status: as of this morning we have not been able to verify any report of in-the-wild exploitation. One secondary outlet cited an unconfirmed forum thread; that is not evidence. Treat this as “public exploit, patch now”, not “confirmed active campaign”.

If this pattern sounds familiar, it is the same one we covered last week in the Airbyte Connector Builder RCE checklist: internal automation platforms hold more credentials and more reach than most production apps, and they get patched last.

The CloudShieldSecure perspective

The hardest part of responding to a bug like this is not the upgrade. It is answering three questions quickly: Where are our configuration-management servers? Which of them can be reached from places they should not be? And what do they hold?

This is the gap CloudShieldSecure is built to close. CloudShieldSecure keeps a continuous inventory of cloud assets and their network exposure, so a Puppet or OpenVox server that has drifted onto a public IP — or into a security group that allows 8140 from anywhere — shows up as a finding rather than a surprise. We recommend tagging configuration-management, CI and secrets servers as Tier-0 in any asset inventory: the same tier as your identity provider and domain controllers, with the same alerting thresholds.

As we wrote in our explainer on how internal systems become internet-exposed, exposure usually comes from a migration or a convenience change, not a decision. Continuous checking is what catches it.

Today

  1. Inventory every Puppet Server, OpenVox Server and Puppet Enterprise primary and compiler in your estate, including test and legacy environments.
  2. Upgrade to openvox-server 9.2.0 / 8.18.0 (and matching agent and openvoxdb releases), or the fixed Puppet Enterprise release for your line. Debian users: apply DLA-4885-1 or DSA-6609-1.
  3. Restrict network access to the server port (8140 by default) so only managed subnets can reach it. Nothing on the internet should.
  4. Review autosign. Check whether autosign is enabled in the server’s configuration, whether an autosign.conf allowlist uses broad wildcards, and whether any policy-based autosign script actually validates the request. Disable or tighten it until you are patched.

This week

  1. Review custom auth.conf rules after upgrading, as the advisory recommends. Per-node rules were the target of CVE-2026-115732.
  2. Audit recently signed certificates. Look for certnames you do not recognise, or a burst of new signings that does not match a provisioning event.
  3. Check report and server logs for unusual report submissions or errors around report processing since late October.
  4. If you are on open-source Puppet, plan a move to OpenVox or Puppet Enterprise. No further upstream security fixes are coming.

If you find signs of compromise: assume the CA key and every secret reachable from the server are exposed. Plan CA rotation and secret rotation as one incident, not two.

Sources and references

CSS Daily is published by CloudKonsult Limited, the team behind CloudShieldSecure — continuous cloud security posture and exposure monitoring. Learn more at https://cloudshieldsecure.cloudkonsult.cloud.

Assess your security posture today

CloudShield Secure scans, validates, and prioritises threats across your entire attack surface.

Explore CloudShield Secure →
← How Internal Systems Become Internet-Exposed: The … RMM Agent Inventory: What the N-able N-central … →