CVE-2026-115732 · Puppet Server trapperkeeper-authorization certificate name matching…

01 · The Real Story

A bouncer checks only the first few letters of your ID and waves you into the VIP room

Puppet Server's trapperkeeper-authorization library compares a client's CA-signed certificate name (CN/SAN) to authorized hostname ACLs using a flawed prefix/suffix match. A certificate whose name extends or shortens an authorized name can satisfy the ACL entry, granting the client the victim host's permissions. Affected products include Puppet Server, Puppet Enterprise, openvox-server, and openvoxdb before the fixed 8.18.0/9.2.0 releases.

Red Hat and Rapid7 rate this CRITICAL (9.9 CVSS v3 / 9.0 CVSS 4.0), and for Puppet Server's role that headline is warranted — it is the configuration-management and CA control plane for managed fleets. The main restraint is the precondition: the attacker must already possess a CA-signed certificate with a colliding name, which the Puppet CA issues only by manual approval or autosign. That makes it a high-severity authorization flaw rather than a reachable unauthenticated remote exploit.

"A signed cert whose name merely collides with a Puppet ACL entry becomes a fleet-wide remote shell — patch before autosign lets it in."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain a CA-signed certificate with a colliding name

Generate a certificate signing request (CSR) whose CN or SAN is a prefix/suffix variant of an authorized hostname, such as web01.example.com.evil.example.com or puppetmaster.evil.example.com. Submit it to the Puppet CA. The CA signs it only if autosign is enabled or an administrator approves the CSR. An attacker who has already compromised a legitimate node can use that node's ability to request additional certificates.

Conditions required:

Network access to a Puppet CA endpoint that accepts CSRs
Autosign enabled or manual approval granted
Ability to generate a key/CSR

Where this breaks in practice:

Puppet autosign is disabled by default; default is manual approval
Colliding name must satisfy the flawed matcher and an existing ACL rule
Multiple certificate requests from one host may be unusual

Detection/coverage: Puppet Server logs certificate requests and signings; monitor unauthenticated CSR attempts and CN/SAN collisions in /var/log/puppetlabs/puppetserver/puppetserver.log.

STEP 02

Present the certificate to the vulnerable Puppet Server endpoint

Connect to the Puppet Server API (catalog, file bucket, CA, or PE console/API) using the signed colliding certificate. The vulnerable trapperkeeper-authorization function compares the presented hostname against ACL entries with an incorrect equality check, authorizing the client as the victim host.

Conditions required:

Network reachability to Puppet Server port 8140 or PE console 443
Target endpoint uses trapperkeeper-authorization for TLS identity

Where this breaks in practice:

Puppet Server is typically internal-only; not exposed to the internet
Modern deployments may enforce firewall ACLs and mTLS with exact-match policies

Detection/coverage: Compare client certificate CN with the requested node/action in Puppet Server API logs; a mismatch is a strong indicator.

STEP 03

Read catalogs, filebucket, and facts as the impersonated node

Using the victim identity, request the node's compiled catalog, file content, and facts. This often exposes service account names, file paths, and embedded secrets, enabling lateral movement and targeted attacks against other systems.

Conditions required:

The victim host has ACL grants for the requested resources
The endpoint does not have a separate authorization layer beyond the flawed TLS match

Where this breaks in practice:

Not every endpoint returns full content; file bucket may use separate rules
Anomalous client CN-to-IP binding may appear in logs

Detection/coverage: SIEM correlation of cert CN with source IP and requested node; alert on CN prefix/suffix collisions.

STEP 04

Escalate to CA administration and orchestrator RCE in Puppet Enterprise

In Puppet Enterprise, the same identity path reaches the PE console and orchestrator APIs. With the colliding certificate, an attacker can administer the CA (issue/revoke certs) and use puppet task / orchestrator to run commands on all managed nodes. This is the fleet-wide execution pivot.

Conditions required:

Target is Puppet Enterprise with PE console/orchestrator enabled
The impersonated hostname maps to PE admin/orchestrator privileges

Where this breaks in practice:

PE RBAC may require an additional session or token beyond TLS certificate identity
Not every node identity has orchestrator rights

Detection/coverage: PE console audit log records certificate actions and task runs; alert on unexpected commands and cert-name mismatches.

STEP 05

Turn Puppet itself into the malicious deployment pipeline

With control over Puppet code or orchestrator tasks, the attacker can classify nodes to deploy malicious manifests, run arbitrary commands, harvest credentials, and move laterally. This is the domain/fleet-compromise outcome that justifies the critical rating.

Conditions required:

Attacker obtains enough Puppet privileges from the impersonated identity
Managed agents continue to trust the Puppet Server

Where this breaks in practice:

Strict code review and RBAC on Puppet environments slow deployment of malicious code
EDR on managed agents may detect anomalous child processes from pxp-agent

Detection/coverage: Monitor Puppet code changes, PE task runs, and agent job execution for anomalies.

03 · Compensating Control

CRITICAL 9.0→HIGH 7.5

SEVERITY REDUCED

Disable or harden autosign immediately — Remove the easiest issuance path for a colliding cert. If autosign is required, replace it with challenge-based verification that rejects prefix/suffix variants and logs all attempts. Deploy within 3 days under the noisgate mitigation SLA for CRITICAL; this breaks the initial certification precondition.

CRITICAL 9.0→IGNORE 0.0

SEVERITY REDUCED

Upgrade to fixed trapperkeeper-authorization / Puppet Server releases — Apply openvox-server/openvoxdb 9.2.0 or 8.18.0, or corresponding Puppet Enterprise fixed release, then restart services. This is the vendor remediation and should be performed within the 90-day noisgate remediation SLA for CRITICAL; it eliminates the flawed matcher entirely.

CRITICAL 9.0→CRITICAL 9.0

Segment Puppet Server / PE console into a dedicated management VLAN — Restrict access to port 8140 and PE console 443 to authorized admin jump hosts and managed-node subnets only. This reduces network reachability for an attacker holding a malicious cert. Deploy within 3 days as a temporary mitigation; it helps but internal compromised nodes may still reach the service.

CRITICAL 9.0→CRITICAL 9.0

Alert on certificate name collisions and orchestrator executions — Feed Puppet Server and PE console audit logs to SIEM; alert when a cert CN differs from the requested host by prefix/suffix, or when unexpected puppet task runs occur. Deploy immediately so attempted exploitation is detected even before patching; detection-only does not prevent the chain.

What doesn't work

Disabling Puppet agents on managed nodes stops configuration enforcement but does not fix the server-side authorization flaw; the CA and console APIs remain reachable.
Exposing Puppet Server only to internal networks is necessary but insufficient; a compromised managed node already has internal reachability and can request new certificates.
Adding more hostname-based ACL rules does not resolve the flawed comparison; the matcher itself must be fixed.

04 · Intelligence Metadata

The supporting signals.

KEV status	Not listed in CISA KEV as of 2026-11-03; no known active exploitation campaign
Public PoC	No public exploit or PoC found in retrieved results; GitHub search names no repository specifically for CVE-2026-115732
EPSS	0.00745 (0.745%) — very low predicted short-term exploitation likelihood
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H` — Red Hat rates 9.9; Rapid7 CVSS 4.0 `AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H` rates 9.0
Affected components	`trapperkeeper-authorization`, Puppet Server, Puppet Enterprise, `openvox-server`, `openvoxdb`
Patched versions	Upgrade to `openvox-server`/`openvoxdb` 9.2.0 or 8.18.0; Puppet Enterprise fixed releases per Red Hat
Disclosed	2026-11-03 via Red Hat Bugzilla / OSIDB Bzimport
Reporter	Alain (Neodyme) credited as original reporter
Exposure data	No Shodan/Censys/GreyNoise data in retrieved results; Puppet Server normally internal-only mTLS on port 8140
Exploitation prerequisite	Requires CA-signed certificate whose name collides with authorized hostname — issued via autosign or manual approval

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.0/10)

Why this verdict

Role multiplier: Puppet Server is a canonical high-value control plane — CA plus configuration management plus PE orchestrator. A successful authorization bypass yields fleet-wide remote command execution and CA administration, not a single-host issue.
Precondition friction: exploitation requires a CA-signed colliding certificate. Default Puppet CA is manual approval (autosign disabled), so unauthenticated attackers cannot trivially exploit this; however autosign policies exist and a compromised managed node can request additional certs.
Impact if landed: In PE, the same identity reaches orchestrator APIs, enabling puppet task remote command on all managed nodes and CA admin — a domain-scale compromise.
No known active exploitation: EPSS 0.745%, not KEV-listed, no public PoC found. This lowers urgency slightly but not the severity floor set by the component's role.
Assessed from first principles: No vendor baseline supplied in prompt; Red Hat's 9.9 is used as a reference only.

Why not higher?

It is not a 10 because the attacker must first obtain a CA-signed certificate with a name that collides under the flawed matcher. Manual CA approval, default-disabled autosign, internal-only network placement, and lack of public PoC or in-the-wild exploitation limit the near-term likelihood. A score of 9.0 reflects high impact with a meaningful, but not insurmountable, precondition.

Why not lower?

Cannot drop below CRITICAL because the vulnerable component is the Puppet/OpenVox server — the fleet's configuration and certificate authority. If the precondition is met, the chain leads to arbitrary remote command on all managed nodes and CA admin. That is a high-value-role outcome by definition, and the floor holds even with low observed exploitation.

06 · Verification

Crowdsourced verification payload.

Run this on the Puppet Server / openvox-server host as root or the puppet user. Invoke with bash cve-2026-115732-check.sh. The script checks the installed package version against fixed releases and flags enabled autosign; outputs VULNERABLE, PATCHED, or UNKNOWN. Requires read access to package manager and Puppet config.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
set -euo pipefail

# CVE-2026-115732 check for Puppet Server / openvox-server.
# Fixed versions: 8.18.0 and 9.2.0.

ver=""
if command -v puppetserver >/dev/null 2>&1; then
    ver=$(puppetserver --version 2>/dev/null || true)
elif command -v openvox-server >/dev/null 2>&1; then
    ver=$(openvox-server --version 2>/dev/null || true)
elif rpm -q puppetserver >/dev/null 2>&1; then
    ver=$(rpm -q --qf '%{VERSION}' puppetserver)
elif rpm -q openvox-server >/dev/null 2>&1; then
    ver=$(rpm -q --qf '%{VERSION}' openvox-server)
elif dpkg-query -W -f='${Version}' puppetserver >/dev/null 2>&1; then
    ver=$(dpkg-query -W -f='${Version}' puppetserver)
elif dpkg-query -W -f='${Version}' openvox-server >/dev/null 2>&1; then
    ver=$(dpkg-query -W -f='${Version}' openvox-server)
fi

if [ -z "$ver" ]; then
    echo "UNKNOWN: no puppetserver/openvox-server package or CLI found"
    exit 3
fi

ver=$(echo "$ver" | sed 's/^v//' | cut -d'-' -f1)

major=$(echo "$ver" | cut -d. -f1)
vuln=0
if [ "$major" = "8" ]; then
    if [ "$(printf '%s\n%s' "$ver" "8.18.0" | sort -V | head -n1)" != "8.18.0" ]; then vuln=1; fi
elif [ "$major" = "9" ]; then
    if [ "$(printf '%s\n%s' "$ver" "9.2.0" | sort -V | head -n1)" != "9.2.0" ]; then vuln=1; fi
elif [ "$major" -lt 8 ] 2>/dev/null; then
    vuln=1
else
    vuln=0
fi

autosign_enabled=0
if [ -f /etc/puppetlabs/puppet/autosign.conf ]; then autosign_enabled=1; fi
if grep -qs '^autosign.*true' /etc/puppetlabs/puppet/puppet.conf 2>/dev/null; then autosign_enabled=1; fi
if grep -qs 'autosign' /etc/puppetlabs/puppet/puppet.conf 2>/dev/null; then autosign_enabled=1; fi

if [ "$vuln" -eq 1 ]; then
    if [ "$autosign_enabled" -eq 1 ]; then
        echo "VULNERABLE: version $ver is below fixed release and autosign is enabled"
    else
        echo "VULNERABLE: version $ver is below fixed release (autosign disabled)"
    fi
    exit 2
else
    echo "PATCHED: version $ver meets or exceeds fixed release"
    exit 0
fi