CVE-2026-115731 · Puppet Server report processing unsafe deserialization via crafted…

01 · The Real Story

A poison-pen report that walks into the config-management control room

CVE-2026-115731 is an unsafe deserialization in Puppet Server's report-processing endpoint. A client that holds any CA-signed agent certificate can submit a report containing a crafted *rich-data* type via PUT /puppet/v3/report, causing Puppet Server to deserialize attacker-controlled data and execute arbitrary code as the puppet service user. Affected components include Puppet Core / Puppet Server, Puppet Enterprise, and Puppet Enterprise Advanced; the initial advisory does not yet publish a clean affected-version list.

No official Perforce/Puppet score is available, but third-party sources classify this as CRITICAL (Rapid7 CVSS 4.0 9.4, Red Hat CVSS v3 9.9, VulDB 10.0). That matches the deployment reality: Puppet Server is not a random app server—it is the policy and trust center for an estate of managed nodes. The default authentication requirement is a CA-signed cert, but if autosigning is misconfigured, that precondition evaporates.

"Puppet Server report deserialization turns a stolen or autosigned agent cert into fleet-wide compromise; assess as CRITICAL."

02 · The Attack Path

6 steps from start to impact.

STEP 01

Reach the Puppet Server report endpoint

The attacker needs TCP connectivity to the Puppet Server listener, normally tcp/8140. The endpoint is part of the Puppet Server HTTP API and is reachable from any host that can talk to the master.

Conditions required:

Network path to tcp/8140
Puppet Server configured and running

Where this breaks in practice:

Puppet masters are usually internal-only and firewalled from the internet
Some deployments expose 8140 only on a management VLAN

Detection/coverage: Port scans or flow logs may show unusual host-to-master connections from non-agent IPs.

STEP 02

Obtain or already hold an accepted CA-signed agent certificate

The report endpoint requires client SSL authentication. The attacker can use any valid agent certificate. If the Puppet CA autosigns requests without strong verification, an unauthenticated remote attacker can submit a certificate request and receive a signed agent certificate.

Conditions required:

Possession of a CA-signed agent cert (extracted from a compromised node, or obtained via weak autosign)
Autosign policy missing or permissive

Where this breaks in practice:

Puppet's autosign is disabled by default in many hardened installs
A stolen cert may be detected if Certificate Revocation List (CRL) / revocation is enforced for agent connection

Detection/coverage: Puppet CA logs certificate requests/signings; population of new agent certs is generally logged.

STEP 03

Craft a malicious rich-data report

The attacker builds a report document that abuses Puppet's rich-data serialization format to carry a deserialization gadget. The report is valid enough to pass the HTTP request parsing and reach the vulnerable deserialization sink.

Conditions required:

Understanding of report schema and Puppet rich-data types
Ability to generate a serialized payload; no public PoC is currently known, but Java deserialization toolchains can be adapted

Where this breaks in practice:

No public exploit as of disclosure; attacker must develop or modify a gadget chain
Puppet report format differences across versions may require adaptation

Detection/coverage: Content-aware HTTP inspection is unlikely to flag custom rich-data payloads; IDS may miss the pattern.

STEP 04

Submit the report via PUT

The crafted report is submitted to PUT /puppet/v3/report/<name>. Puppet Server processes the report by deserializing the rich-data portion without sufficient validation.

Conditions required:

Valid report endpoint path and content type accepted
Attacker holds a cert accepted by the server's trust store

Where this breaks in practice:

The master may reject report submissions if node names don't match cert; the attacker must know/guess a valid node name
Server may have request size limits

Detection/coverage: Web server or reverse proxy logs may show a PUT to /puppet/v3/report from an unexpected host.

STEP 05

Execute code as the Puppet service user

The deserialization bug gives arbitrary code execution as the puppet/pe-puppet service account. On a typical Puppet Server this account owns the CA private key, compiled catalogs, and code directories, so the compromise quickly escalates to trust-plane impact.

Conditions required:

Puppet Server has network-accessible report endpoint and vulnerable code
JDK/CLR environment available for code execution

Where this breaks in practice:

Service may run in a container or unprivileged user, but the process still has access to Puppet SSL/CA material in most installs
OS-level hardening could limit lateral movement from the puppet account

Detection/coverage: Endpoint detection (EDR) may flag suspicious child processes or deserialization behavior; post-exploitation command execution may appear in auditd logs.

STEP 06

Pivot to fleet-wide compromise via catalog/CA trust

With code execution on the master, the attacker can read the CA key, issue trusted certificates for any host, inject code into catalogs or plugins, and have every managed node pull and execute the next catalog run. This converts a single server compromise into a domain-equivalent or fleet-wide backdoor.

Conditions required:

Puppet Server is the enterprise config-management authority
Managed nodes run Puppet agents and apply catalogs from the master

Where this breaks in practice:

Highly segmented estates with per-environment masters limit one compromise to one environment
Code signing/peer-review and protected code deployment may slow catalog injection

Detection/coverage: File integrity monitoring on /etc/puppetlabs/code, certificate issuance logs, and drift detection on managed nodes may identify rapid unauthorized changes.

03 · Compensating Control

CRITICAL 9.1→LOW 2.0

SEVERITY REDUCED

Apply the vendor patch as soon as it is published — This is the only complete fix; without a fixed version, treat all current Puppet Server/OpenVox installs exposed on the report endpoint as vulnerable. Deploy within 3 days of a CRITICAL patch release under the noisgate mitigation SLA, and complete fleet remediation within 90 days.

CRITICAL 9.1→HIGH 8.0

SEVERITY REDUCED

Disable unverified certificate autosigning immediately — If autosign=true or autosign.conf accepts policy-less names, any unauth network attacker can get the required certificate. Set autosign to verify challenge/policy or turn it off entirely. This removes the unattended path and forces attackers to first compromise an endpoint. Deploy within 3 days.

CRITICAL 9.1→MEDIUM 7.0

SEVERITY REDUCED

Restrict tcp/8140 to known Puppet agents only — Segment the Puppet Server listener so only host-management networks can reach the report endpoint. This rejects external/unknown clients before the cert handshake. Deploy within 3 days for CRITICAL.

CRITICAL 9.1→MEDIUM 5.0

SEVERITY REDUCED

Run Puppet Server with least privilege and remove CA private key access from the service account — Isolate CA functions to a separate, offline/signing process or at minimum ensure the puppet service account cannot read the CA private key. This limits post-RCE blast radius from fleet trust compromise to application disruption. Deploy within 30 days.

CRITICAL 9.1→HIGH 8.5

SEVERITY REDUCED

Enable EDR/allowlisting and audit puppet service activity — Monitor for suspicious child processes, code directory changes, and unexpected certificate issuance from the Puppet Server host. This won't prevent exploitation, but catches post-RCE movement. Deploy within 30 days.

What doesn't work

WAF / HTTP signature blocking alone: rich-data deserialization payloads may look like normal report bodies and can bypass generic pattern matching.
Certificate revocation lists (CRL) alone: if the attacker holds a valid, non-revoked agent cert from a compromised host, CRL won't help.
TLS inspection at the perimeter: Puppet Server agent traffic is already mTLS; interception cannot distinguish malicious reports without endpoint context.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	None known as of 2026-11-03; no exploitation reported by VulDB or Mallory; CISA KEV not listed.
Proof of concept	No public PoC on GitHub, ExploitDB, Nuclei, or pocindex.io as of Nov 3; VulDB says no exploit exists.
EPSS	0.00366 (0.366% 30-day exploit probability) — low predicted early exploitation at disclosure.
KEV status	Not listed in CISA Known Exploited Vulnerabilities as of 2026-11-03.
CVSS vector / interpretation	Rapid7 CVSS 4.0 9.4 CRITICAL (`AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H`); Red Hat CVSS v3 9.9; both reflect network reach, low complexity, and high downstream impact.
CWE mapping	Third-party sources list CWE-502 (deserialization of untrusted data); the supplied record field says CWE-94, likely a mapping discrepancy.
Affected versions	No precise version list in initial advisory; affected components are Puppet Server / Puppet Enterprise / OpenVox per Red Hat Bugzilla.
Fixed versions	No fixed version published in the searched sources as of Nov 3; check vendor advisory/Red Hat errata for backports.
Exposure / scanning	Puppet Server should be internal-only; public Shodan/Censys exposure for `tcp/8140` is uncommon, but misconfigurations happen.
Disclosure date	2026-11-03 (Red Hat Bugzilla reported 2026-11-03; VulDB entry 2026-11-02).
Reporter / organization	Reported via OSIDB/Red Hat bug import; original researcher not named in the sources reviewed.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.1/10)

Why this verdict

Assessed baseline: No official Perforce/Puppet score exists; third-party anchors are CRITICAL (Rapid7 9.4, Red Hat 9.9, VulDB 10.0) so this is an assessed CRITICAL, not an upgrade/downgrade.
Role multiplier: Puppet Server is canonical configuration-management infrastructure. RCE as the service user gives access to the CA private key and catalog/code pipeline, so the worst realistic outcome is fleet-wide/domain-equivalent compromise. That floors the verdict at CRITICAL under the deployment-role rule.
Friction audit: The chain needs network reach to tcp/8140 and a CA-signed cert. Weak autosign removes the cert hurdle, but even a stolen agent cert from one endpoint is enough. The lack of public PoC and internal-only placement are real but do not reduce the end-state severity.
Privilege/impact: The puppet service account typically owns /etc/puppetlabs/puppet/ssl and /etc/puppetlabs/code; compromise of that account is trust-boundary crossing, not a low-value host.

Why not higher?

No known in-the-wild exploitation and no public PoC as of Nov 3, with a low EPSS 0.366%. The attack normally requires an internal network path and a CA-signed agent certificate unless autosigning is weak. If autosigning is properly hardened, the unauth-to-RCE shortcut is closed, but any one compromised agent still gets there.

Why not lower?

This is a critical-by-role component: a successful report deserialization gives code execution on the config-management server, which can push arbitrary content to every node it manages. Third-party CVSS scores of 9.4–9.9 reflect that chain, and the only friction is obtaining a cert—which autosigning misconfiguration or a single compromised endpoint can satisfy.

06 · Verification

Crowdsourced verification payload.

Run this on each Puppet Server / OpenVox Server host as root. Supply the first fixed version from the vendor advisory as the argument to compare against: sudo bash check_cve_2026_115731.sh 9.99.0.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-115731 verification for Puppet Server / OpenVox Server on Linux
set -uo pipefail

installed=""
for bin in puppetserver openvox-server; do
  if command -v "$bin" >/dev/null 2>&1; then
    installed=$("$bin" --version 2>/dev/null | head -n1)
    [ -n "$installed" ] && break
  fi
done

if [ -z "$installed" ]; then
  echo "UNKNOWN: no puppetserver/openvox-server binary found"
  exit 3
fi

echo "Installed server version: $installed"

if [ -z "${1:-}" ]; then
  echo "UNKNOWN: no fixed version supplied; cannot determine PATCHED/VULNERABLE"
  exit 3
fi

fixed="$1"
version_cmp=$(printf '%s\n%s\n' "$installed" "$fixed" | sort -V | head -n1)
if [ "$version_cmp" = "$fixed" ] && [ "$installed" != "$fixed" ]; then
  echo "VULNERABLE: installed $installed appears older than fixed $fixed"
  exit 1
elif [ "$installed" = "$fixed" ]; then
  echo "PATCHED: installed version equals fixed $fixed"
  exit 0
else
  echo "PATCHED: installed $installed appears newer than fixed $fixed"
  exit 0
fi