TL;DR
- Puppet is a configuration management tool that companies run on their own servers to describe how each machine should be configured; a central server signs a certificate for every agent and hands out the configuration that agent applies.
- Two critical flaws fixed on 3 November 2026 let an agent holding a valid certificate run code on that server (CVE-2026-115731, CVSS 9.4) and let one host authenticate as another (CVE-2026-115732, CVSS 9.0).
- Code execution as the puppet service user reaches the certificate authority signing key, so a compromised server can mint certificates that other nodes accept.
- The impersonation bug sits in a hostname comparison that stopped at the shorter of two names, so a certificate issued for evil.target.lab.local authenticated as target.lab.local.
- Autosign turns the chain into a network attack: where a pattern issues certificates automatically, an attacker obtains the credential the other two bugs need.
- A third fix landed in the database container, where a startup script failed and left the certificate allowlist open.
- The upgrade path is OpenVox server 8.18.0 or 9.2.0, agent 8.32.0 or 9.3.0, and Puppet Enterprise 2023.8.13, 2025.12.1 or 2026.0.1, followed by a service restart and a re-read of custom auth.conf rules; open-source Puppet will receive no further updates.
The Neodyme technical write-up of 3 November 2026, which traces both flaws from the agent's report endpoint to code execution on the server. Capture taken 6 November 2026 from https://neodyme.io/en/blog/puppet\_rce/.
A configuration management server holds two things at once: a certificate authority and a remote execution channel into every machine in the estate. Puppet has held both since long before either was fashionable to discuss, and the disclosure published on 3 November 2026 by Vox Pupuli, OpenVox and Perforce describes what happens when the first of those two roles is reachable from the second.
The research comes from Neodyme, which found the flaws while preparing a red team engagement. The write-up is direct about the starting position: the goal was to compromise a Puppet server using a regular agent and a valid client certificate. That constraint is what makes the finding matter for anyone running the tool, because an agent certificate is the least valuable credential in such an estate.
Netics visual: the path Neodyme traced from a signed report on the report endpoint to code execution as the puppet service user, and the signing key that sits within reach afterwards.
What a report does on port 8140
Agents talk to the server over TLS on port 8140, and most endpoints under /puppet/v3/ require client authentication so the server can derive the agent's identity. One of those endpoints, /puppet/v3/report/{agent_name}?environment={env}, receives the document an agent sends after each enforcement run. It lists what changed, what failed, and every event that occurred.
The report is a JSON document, and Vox Pupuli's explanation is worth keeping in view. In some circumstances involving custom resource types, an event in that report can carry a serialized Ruby object. Processing the report turns those objects back into something the compiler can use, and a malicious event object can be constructed so that code executes on the server when that happens.
The OpenVox advisory for the report deserialization flaw, published alongside the fixes on 3 November 2026, listing the affected and patched versions for agent and server. Capture taken 6 November 2026 from https://github.com/OpenVoxProject/openvox/security/advisories/GHSA-ffr6-rwpm-p5wq.
The pieces that make this a real path are ordinary Ruby: the event body lands in the deserializer, a type name supplied by the client is looked up, an unregistered class goes through the generator, and the generated body reaches class_eval. Neodyme traced that chain and named the sink. Nothing in it depends on an unusual Puppet configuration.
Why the puppet user sits next to the certificate authority
The advisory states the consequence in one sentence: code execution as the puppet user "gives access to the CA signing key". From there an attacker can sign certificates carrying extended key usage for server and client authentication, which the advisory notes could enable direct command execution on other hosts where orchestration is configured that way.
Neodyme pushed the same point further and demonstrated it: a proof of concept copied the CA private key out, minted a certificate for the server itself, and used it. The write-up puts the broader impact plainly, covering ransomware deployment, mass data exfiltration and lateral movement.
Netics visual: autosign as the setting that issues an agent certificate on a name pattern, which is what turns both flaws into something reachable from the network.
This is the part of the disclosure that changes how a team should file the ticket. The Puppet server concentrates identity authority for the managed estate. A vulnerable Puppet server can issue credentials that every managed node in the estate already trusts, and rebuilding the server alone leaves those certificates valid.
A hostname comparison that stopped at the shorter name
The second flaw lives in trapperkeeper-authorization, the library that parses auth.conf. Rules there can be plain strings, wildcards or regular expressions, and the plain-string and wildcard cases shared one code path. Wildcard behaviour therefore leaked into every non-regex rule.
Neodyme's explanation of the mechanism is concrete: the hostname comparison splits a fully qualified name, reverses the labels, and compares them element by element until one list runs out. A rule allowing target.lab.local therefore also matches evil.target.lab.local, which matters because autosign patterns are commonly written as wildcards such as *.lab.local.
The alert table in Vox Pupuli's release post of 3 November 2026, with the agent, server and database versions on each branch. Reproduced from https://voxpupuli.org/blog/2026/11/03/critical-cve-updates/, retrieved 6 November 2026.
A successful impersonation can expose credentials and administrative tokens delivered through another node's catalog. A successful impersonation reads the catalog of another node; Neodyme describes one host whose catalog served a configuration file containing PostgreSQL credentials, admin API tokens and logins. It also allows facts and reports to be pushed for that host, and in cross-node coordination setups it allows exported resources to be inserted where another machine will realise them.
The container that accepted every certificate
The same release carries a third fix that received less attention. The container-openvoxdb image builds its certificate allowlist at startup from the OPENVOXDB_CERTIFICATE_ALLOWLIST environment variable. Vox Pupuli reports that the script failed because a required tool was missing from the image, and the result was that any certificate could reach the API.
The illustration Neodyme published with its Puppet research on 3 November 2026, retrieved 6 November 2026 from https://neodyme.io/en/blog/puppet\_rce/.
Three failures in one software family, and each one sits on the boundary that decides who may speak to the control plane. The container bug is the cheapest to find and the cheapest to fix, and it is also the one most likely to be missed by a team that patches only what its scanner flags as a server package.
What the upgrade leaves to you
The patched releases are OpenVox server 8.18.0 and 9.2.0, agent 8.32.0 and 9.3.0, database 8.18.0 and 9.2.0 including the container image, and Puppet Enterprise 2023.8.13, 2025.12.1 or 2026.0.1. Vox Pupuli asks for a restart of the service after the package upgrade.
The release guidance covers prevention and leaves post-compromise recovery unspecified. It tells operators to upgrade, restart, validate custom authentication rules and restrict network access or autosign. It provides no test for CA-key access and no procedure for rotating the CA or replacing certificates after suspected exploitation. Because the disclosed code execution reaches the signing key, evidence of exploitation should trigger a CA-compromise response; Vox Pupuli describes its mitigations as risk reduction with residual risk. The first is auth.conf: custom rules that were written against the buggy matching may have depended on that behaviour, and they need reading again once the fix is in place. The second is autosign. Where the certificate authority issues certificates on a pattern, tightening or disabling that policy removes the step an attacker needs to obtain a valid certificate in the first place.
Netics visual: the six steps the Vox Pupuli release note asks of an operator, from the version targets through the certificate policy review that the patch alone does not cover.
The end of open-source Puppet
There is a strategic point buried in the release note that outlasts this disclosure. Open-source Puppet will not receive further updates, security or otherwise, and the post recommends migrating to OpenVox. Consider a hypothetical SME that built its patching around open-source Puppet a decade ago: it now runs, on the machine that signs certificates for everything else, a component for which upstream will issue no fix.
Patch state requires continuous monitoring alongside controlled deployment, and keeping a fleet view with infrastructure monitoring with plain-language alerts is how a small team notices that one server still reports the old build. The disclosure of 3 November carries a specific operational lesson. The machine that holds the certificate authority is a control plane, and its agents hold credentials that the rest of the estate already trusts, so its patch window belongs with the identity systems.
Originally published on the Netics blog.
