Critical Puppet Server flaw puts CA and managed estate at risk

For any live Puppet Server, OpenVox Server or Red Hat Satellite control point, CVE-2026-115731 is an emergency. Red Hat rates the report-deserialisation flaw CVSS 9.9 on the Common Vulnerability Scoring System (CVSS): a client holding a certificate signed by the Puppet certificate authority (CA) can execute arbitrary code as the Puppet service user on the server. The immediate concern is server compromise. The bigger concern is what that service can reach, including the CA and the systems that trust it.

The prerequisite is a valid agent certificate, which is important but not reassuring. Permissive automatic certificate signing — autosign — can give an unauthenticated network attacker that foothold. In Red Hat Satellite, report processing is network-exposed by default. Don’t file this under “authenticated, review later”: patch it now, and apply the short-term controls below while the change is underway.

What Red Hat has confirmed

The defect is in the handling of agent reports submitted after clients apply configuration. Red Hat says untrusted data in report-processing code can be deserialised — converted from submitted data into objects for processing — in a way that permits arbitrary code execution when a crafted report is submitted by a holder of a CA-signed agent certificate. The code runs with the privileges of the Puppet service account.

That foothold is why Red Hat’s severity assessment matters: access to the central CA can enable wider compromise of the configuration-management trust boundary and the managed estate. Its CVSS vector records network reachability, low attack complexity, low privileges, no user interaction and changed scope. This doesn’t stay neatly contained on one management host.

On the information publicly available as of 12 November 2026, neither Red Hat’s CVE record nor Perforce’s Puppet security bulletin reports confirmed exploitation in the wild. That is not evidence that exploitation hasn’t occurred. Public technical material exists, and organisations using indiscriminate certificate autosigning should expect serious interest.

The exposure path is short in weakly governed estates

In a properly governed deployment, a certificate request is an enrolment decision: a new node proves enough about its identity for the CA to sign its certificate. Autosigning can make elastic provisioning less painful, but a broad rule can reduce that decision to “a system reached the endpoint”. Here, that turns an authenticated server-side flaw into a potentially unauthenticated network path.

Once an attacker can submit an accepted malicious report, the vulnerable Puppet or OpenVox server is the immediate target. Red Hat specifically warns that the central CA and downstream managed systems can then be compromised. The management plane — the systems used to control configuration across the estate — already has trusted relationships, credentials and authority to alter configuration at scale. The Keycloak SAML signature bypass is a useful reminder that failures at a trust-validation boundary rarely stay minor implementation details.

This does not mean every affected Puppet deployment is equally exposed to the internet. A server reachable only from a tightly segmented, managed network with manual certificate approval has a materially smaller initial attack surface. It remains vulnerable to a compromised managed node or stolen agent credentials, however. Segmentation cuts the number of plausible entry points; it doesn’t replace corrected deserialisation code.

Affected products and fixed releases

That foothold is why Red Hat's severity assessment matters: access to the central CA can enable wider compromise of the configuration-management trust boundary and the managed estate.

The version picture is messier than it should be because products package the same underlying capability differently. Use the fixed build for the supported product stream rather than comparing only a generic Puppet version string.

One documentation wrinkle is worth stating plainly. Puppet’s broader release summary refers to Puppet Core 8.22.1 alongside 9.1.3, while the more specific Perforce vulnerability bulletin and Red Hat’s revised CVE guidance identify 8.22.2 as the corrected 8.x release. Treat 8.22.2 as the minimum safe target unless the vendor confirms a different supported, backported package for a particular platform.

For Red Hat customers, the current errata ship openvox-server-8.18.0 for Satellite 6.16, 6.17 and 6.19, including the relevant Satellite Capsule packages. Satellite Client updates are also available through RHSA-2026:95653, which provides openvox-agent-8.32.0 across listed RHEL streams. Prioritise the server fix: that’s where code execution occurs. Fleet agent updates should follow the normal change plan, but must not delay server remediation.

Containment while the change window is being arranged

A patch is the remedy. These are compensating controls for the hours or days before it lands, not reasons to defer the maintenance window.

• Turn off permissive autosigning now. If automated enrolment is essential, restrict it to a strongly verified workflow and review existing rules for broad hostname patterns, source-based trust assumptions or catch-all approval.
• Restrict report submission. Limit the Puppet report endpoint to expected agent networks and known intermediaries. Do this carefully: agents still need to report, and a rushed firewall rule that breaks management visibility is not a win.
• Review which certificates can speak to the service. Revoke certificates that are stale, unexplained or tied to decommissioned systems, and investigate sudden bursts of enrolment or signing activity.
• Increase telemetry around the service account. Alert on unexpected child-process execution, shell activity, outbound connections and reads of sensitive CA material originating from the Puppet service. Red Hat specifically recommends looking for anomalous child processes launched by puppetserver.

Don’t expect a web application firewall-style control to solve this. The vulnerable functionality is a legitimate management protocol endpoint receiving data from authenticated clients. Basic port filtering and application signatures may reduce noise, but they cannot establish that a report is safe to deserialize.

Detection and recovery: treat the CA as a decision point

Review Puppet Server and proxy logs for unusual report submissions, unexpected client certificate names and enrolment activity. Correlate those records with operating-system telemetry for processes spawned by the Puppet service account. A report-processing request followed by abnormal command execution is strong reason to isolate the host and preserve relevant evidence.

Analysis: where compromise is suspected, assume CA private-key material may have been exposed. A package update and service restart don’t provide adequate assurance in that situation. Isolate the Puppet Server, engage the relevant vendor support route, rebuild the server from known-good material where appropriate, and plan certificate-authority replacement or certificate re-enrolment based on the estate’s trust model. It’s disruptive, but leaving a potentially stolen signing key in service preserves the attacker’s most useful advantage.

Review recent configuration changes delivered from the management plane as well. Don’t hunt for one mythical indicator. Establish whether the trusted automation channel was used to alter packages, accounts, scheduled tasks, service settings or secrets on managed machines.

Practical priorities for the next working day

1. Identify every Puppet Server, OpenVox Server, Red Hat Satellite and Capsule instance, including standby or disaster-recovery systems.
2. Check its installed server package against the fixed release or Red Hat erratum, and schedule the vendor-supported update immediately.
3. Disable broad autosigning and inspect certificate approval history.
4. Constrain report endpoint access to the networks that genuinely require it.
5. Review logs and endpoint telemetry before and after the change, especially around the Puppet service user and CA key access.
6. Document whether any server was exposed with permissive autosigning. That combination should drive the urgency of the compromise assessment.