FR
live

A forged agent report runs code on Puppet Server and steals the CA signing key

On November 3, 2026, Puppet by Perforce and the OpenVox fork fixed CVE-2026-115731: a deserialization flaw in report handling lets any agent holding a signed certificate run code on the Puppet server and steal the CA signing key. A public exploit is available, and autosigning environments become effectively unauthenticated.

A set of identical padlocks chained to a single master key hanging in a dark room, one padlock left open with an amber indicator glowing inside.

November 3, 2026. Puppet by Perforce and the OpenVox fork, run by Vox Pupuli, ship a coordinated fix for CVE-2026-115731, rated 9.4 under CVSS 4.0. November 4, 2026. A public exploit lands in advisory GHSA-ffr6-rwpm-p5wq, with a working malicious report that runs a shell command. November 5, 2026. No in-the-wild exploitation has been confirmed yet. The bottom line fits in one sentence: any agent holding a signed certificate can run code on the Puppet server, steal the CA signing key, and from there reach every node it manages.

For an SRE running a fleet on Puppet, this is not just another bug. It is the compromise of the configuration control plane — the single point from which you push packages, files, and settings to hundreds of machines.

The mechanics: a legitimate channel, weaponized

The flaw, CVE-2026-115731, is deserialization of untrusted data in report handling. Puppet agents send a report to the server after every run — that is normal product behavior. The problem is that the report was deserialized without checking whether its contents were safe.

An agent holding a CA-signed certificate can therefore submit a forged report that executes arbitrary code on the Puppet server, running as the service user.

  • CVE-2026-115731: remote code execution via a forged report, CVSS 9.4.
  • CVE-2026-115732: one node can impersonate another, CVSS 9.0.

The requirement for a signed certificate looks like a barrier. It is not, everywhere.

Autosigning, or how the barrier disappears

The friction point is a setting that is common in enterprises: autosigning. When it is on, the server automatically signs any certificate presented to it. An attacker does not even need to have compromised an agent first: they request a certificate and receive one.

The chain becomes effectively unauthenticated: anyone who can reach the server gets a certificate, then exploits the flaw to steal the CA signing key.

And that key is the nerve center. The CA signing key is the root of trust for every managed node. An attacker who holds it can mint certificates the entire infrastructure accepts as legitimate — and those forged identities survive the patch until the trust material is rotated.

The blast radius: every node the server manages

The severity of CVE-2026-115731 comes not from the flaw’s complexity but from its position in the architecture. A configuration management server sits at the center of the environment: it pushes packages, files, and settings to many machines, often with elevated privileges.

The reasoning of Neodyme, which took part in the disclosure, is stark: once code runs on the server, the attacker recovers the CA signing key and uses it to run commands as root on managed agents. A single compromise turns into durable access to the whole fleet.

  • Manual signing: the risk shifts to any already-compromised agent that holds a valid certificate.
  • Autosigning: the risk is open to anyone who can reach the server.

The public exploit shortens the defenders’ timeline further. The working malicious report shipped in the advisory is both a test fixture for teams and an instruction manual for attackers. That is the double-edged nature of coordinated disclosure: the patch ships alongside the exploitable detail.

What this changes for an infrastructure team

This flaw illustrates a truth infrastructure teams know but underweight: the configuration management server is the most profitable asset to compromise, not the most visible one. You harden applications and segment networks, then forget that the Puppet server already holds the keys to everything.

The priority order is clear.

  • Apply the patch to OpenVox and Puppet Enterprise without delay, prioritizing environments where autosigning is on.
  • Rotate the CA and agent certificates after patching. A stolen key only becomes harmless once the trust material changes.
  • Re-examine autosigning. If it is not essential, turn it off and return to controlled manual signing.
  • Watch for unusual report submissions in server logs until you can confirm the state of each host.

It is also worth measuring the absence of confirmed exploitation for what it is: a first-day status, not a guarantee. A public exploit that grants control of a management server is exactly the material attackers test quickly. The current silence is a window, not a conclusion.

For defenders, the detection problem is subtle. The attack rides the normal report channel — agents submit reports after every run — so a malicious report does not stand out the way a network scan would. Teams that have not enabled report-level auditing will struggle to tell a legitimate run from an exploitation attempt after the fact. That is why rotating the CA, rather than merely patching, is the deciding step: it removes the attacker’s ability to mint valid identities regardless of what the logs do or do not show.

Two branches, one control plane

The fork context matters here. In 2025, Perforce moved Puppet onto a less open licensing model, and the community — led by Vox Pupuli — launched the OpenVox fork. The two branches share the same code lineage, and therefore the same flaw.

  • Puppet Enterprise (Perforce) and OpenVox (community) each published a coordinated fix on November 3.
  • Both advisories came out of a coordinated disclosure involving Perforce, Vox Pupuli, and Neodyme.

For an operator, that means two things. First, knowing which product you run is not enough — you must know which branch: the fixed version numbers differ between the two lines. Second, coordination between a vendor and its fork is a healthy sign — the flaw was handled on both sides simultaneously, rather than leaving one branch exposed while the other patched.

It is also a reminder that a tool’s license does not protect it from flaws: OpenVox and Puppet Enterprise share the same report-handling code, and therefore the same risk. The security of your configuration management depends on your update cadence, not on the name on the banner.

Verdict

CVE-2026-115731 is the flaw infrastructure teams dread: it turns the configuration server into a skeleton key for the entire fleet. The good news is coordinated disclosure — patch and detail published together, at both Perforce and OpenVox — which hands defenders the same weapons as attackers.

If you run Puppet Enterprise or OpenVox, apply the patch this week and rotate the CA; do not consider the upgrade complete until the trust material has changed. If autosigning is on, treat this flaw as a 10.0: the certificate barrier has already vanished. The configuration server is a king whose crown — the signing key — can only be repaired by a full rotation.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

GitHub rebuilds its Git storage to absorb 5,000 agents on a single repository

On November 5, 2026, GitHub detailed “Project Rubicon”, its new Git storage architecture capable of 7,200 pushes per second to one repository and 5,000 concurrent agents, built on a simple insight: only reference updates need coordination. Immutable Git objects go to Azure Blob Storage; the tiny mutable state goes to a replicated log.

Terraform 1.17 graduates policy-as-code out of experimental

On October 21, 2026, HashiCorp shipped Terraform 1.17.0, which makes Terraform Policy generally available in the CLI with no experimental build or dedicated flag, and adds the -minimal-refresh planning option plus variables in provider requirements. For IaC teams, it is the moment to decide: adopt native policy in the plan, or stick with OPA/Conftest and Sentinel.

← Back to the feed

Type at least two characters.

↑ ↓ navigate ↵ open esc dismiss