Security · Puppet

Two Critical Puppet bugs are fixed, and your autosign config decides how exposed you were

CVE-2026-115731 (CVSS 4.0 9.4) lets anyone holding a CA-signed agent certificate run code on the Puppet Server by submitting a crafted report, and autosign without strong verification turns that into an unauthenticated chain. CVE-2026-115732 (9.0) accepts a certificate whose name extends or shortens an authorised hostname as that host. OpenVox patched on 3 November with server 9.2.0 and 8.18.0 and agent 9.3.0 and 8.32.0; the NVD records carry Perforce's Puppet Enterprise ranges, and nothing collected shows exploitation in the wild.

By BoneWednesday 4 November 20263 min readSecurity

entryread only

filedWednesday 4 November 2026

length3 min

sectionSecurity

subjectPuppet

sourceson the page

Two Critical vulnerabilities in Puppet’s server path were patched on 3 November, and the thing that decides how exposed you were is not the code but how your certificate authority issues certificates.

The bugs come from Neodyme, found while preparing a red-team engagement: “two critical CVSS 9+ vulnerabilities in Puppet, dating back to 2021”. Their summary of the first is blunt: “They allow RCE on the puppet management server in a default configuration.” Puppet is the configuration-management server agents check in with; OpenVox is the community fork that still ships public advisories after the software changed licence in mid 2025.

The report-processing bug

CVE-2026-115731 scores 9.4 under CVSS 4.0, Critical. NVD’s description is precise about the precondition: the flaw “allows a client that holds any CA-signed agent certificate to execute arbitrary code on the Puppet Server as its service user” by submitting a report containing a crafted rich-data type. Any signed agent certificate is enough.

Exposure turns on the next sentence: “Where the certificate authority autosigns requests without strong verification, an unauthenticated network attacker can obtain such a certificate.” The OpenVox advisory calls autosign “(which is common for enterprise deployment)” an unauthenticated chain, because a valid certificate can be requested from the client enrollment endpoint.

The advisory also says “Code execution as puppet gives access to the CA signing key”, which is the position that issues every other certificate in the estate.

The name-matching bug

CVE-2026-115732 scores 9.0, Critical. It sits in trapperkeeper-authorization, and NVD calls it incorrect authorization in certificate-name matching: a client holding “a CA-signed certificate whose name extends or shortens an authorized hostname” is authorized as that host. “This enables impersonation of other nodes and, in Puppet Enterprise, access to certificate-authority administration and remote command execution on managed nodes.” NVD adds the precondition: “Exploitation requires a certificate with a colliding name, which the certificate authority issues by approval or autosign.”

Which builds to move to

OpenVox Server is affected at 9.1.0 and earlier and at 8.17.0 and earlier, patched in 9.2.0 and 8.18.0. On the agent package the numbers differ: affected at 9.2.0 and earlier and at 8.31.1 and earlier, patched in 9.3.0 and 8.32.0, so 9.2.0 is a fixed server and an affected agent. The advisory was published on 3 November as “Authenticated RCE on OpenVox server via Event Deserialization”.

For Puppet Enterprise, the NVD records carry affected ranges supplied by Perforce, whose address appears as the CNA source on both: 2023.8.0 before 2023.8.13, 2025.0.0 before 2025.12.1, and 2026.0.0 before 2026.0.1, with 2023.8.13, 2025.12.1 and 2026.0.1 themselves marked unaffected. The records link a Perforce portal page for each CVE, which was not read here, so treat the ranges as NVD’s reporting of Perforce’s data, not a quoted advisory.

Neodyme names a second OpenVox advisory, GHSA-q4hm-33rc-572g, alongside GHSA-ffr6-rwpm-p5wq. That second page returned a 404 when research fetched it, so nothing in this piece is quoted from it; everything about the name-matching bug comes from NVD and from Neodyme’s account.

What the researchers say

Neodyme tested “the latest Puppet Enterprise 2025.11.2 primary server”, which uses Puppet 8.20.0, and says “the exploits also work for the open-source version 6.24.0, which dates back to July 2021”. The fixes landed on 3 November at 17:00 UTC, and the researchers say both bugs were reported to Perforce and OpenVox, who “cooperated for the patch release dates”. Nothing collected claims exploitation in the wild, and no exploit code is reproduced here.

Their own closing caveat is worth carrying: “even with the two critical bugs highlighted in this post, an environment hardened according to the best practices will mitigate direct impact significantly.” So the advice repeats: patch to the fixed builds, then look at who can get a certificate without a person approving it. That is the difference between a bug an agent can reach and one anybody on the network can.

Sources: Neodyme’s write-up, the OpenVox advisory GHSA-ffr6-rwpm-p5wq, and the NVD records for CVE-2026-115731 and CVE-2026-115732.

SecurityPyPI's new Security tab says where a release came from, and that is not a verdictPyPI's redesigned project pages went live on 6 November with a Security tab that reports a release's provenance: full, none, incomplete, inconsistent, changed or lost. The post is explicit that no provenance does not mean malicious, that it means the file origin cannot be cryptographically verified, and that the states worth checking before you install are the warnings.

SecurityPwnEscape Part 2: from a Firecracker guest to root on the host, in a setup without the jailerThe researchers behind October's kernel bug have published the other half: using that host-memory primitive to find Firecracker in memory, take over a live vCPU thread and redirect its return from KVM to a call of their choosing, with the VM left running and reachable. Their test used Firecracker v1.16.1 with the VMM launched as root and no jailer, and they say a jailer-hardened deployment needs a separate assessment. No new CVE, no vendor advisory and no Firecracker fix appears in the source.

SecurityAlpine's sshd could be logged into without a password, and the upgrade alone does not close itAlpine's advisory of 5 November describes a password authentication bypass in sshd built without PAM on musl: an attacker who can reach the SSH port logs in with a very long password as an account whose password field is *, provided another account on the machine has a $5$ or $6$ hash. Upstream OpenSSH 10.6p2 calls it a critical security workaround and puts the root cause outside sshd. Alpine's fixed packages run from edge 10.6_p2-r0 back to 3.16 9.0_p1-r6, the upgrade is not complete until sshd is restarted, and no CVE had been assigned.