| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A user with specific node group editing permissions and a specially crafted class parameter could be used to execute commands as root on the primary host. It affects Puppet Enterprise versions 2018.1.8 through 2023.8.3 and 2025.3 and has been resolved in versions 2023.8.4 and 2025.4.0. |
| In Puppet Enterprise versions 2025.4.0 and 2025.5, the encryption key used for encrypting content in the Infra Assistant database was not excluded from the files gathered by Puppet backup. The key is only present on the system if the user has a Puppet Enterprise Advanced license and has enabled the Infra Assistant feature. The key is used for encrypting one particular bit of data in the Infra Assistant database: the API key for their AI provider account. This has been fixed in Puppet Enterprise version 2025.6, and release notes for 2025.6 have remediation steps for users of affected versions who can't update to the latest version. |
| A privilege escalation allowing remote code execution was discovered in the orchestration service. |
| Utilization of a module presented a security risk by allowing the deserialization of untrusted/user supplied data. This is resolved in the Puppet Agent 7.4.0 release. |
| On Windows installations of the mcollective-puppet-agent plugin, version 1.12.0, a non-administrator user can create an executable that will be executed with administrator privileges on the next "mco puppet" run. Puppet Enterprise users are not affected. This is resolved in mcollective-puppet-agent 1.12.1. |
| Versions of Puppet prior to 4.10.1 will deserialize data off the wire (from the agent to the server, in this case) with a attacker-specified format. This could be used to force YAML deserialization in an unsafe manner, which would lead to remote code execution. This change constrains the format of data on the wire to PSON or safely decoded YAML. |
| The mcollective-sshkey-security plugin before 0.5.1 for Puppet uses a server-specified identifier as part of a path where a file is written. A compromised server could use this to write a file to an arbitrary location on the client with the filename appended with the string "_pub.pem". |
| The console in Puppet Enterprise 2015.x and 2016.x prior to 2016.4.0 includes unsafe string reads that potentially allows for remote code execution on the console node. |
| The console in Puppet Enterprise 3.7.x, 3.8.x, and 2015.2.x does not set the secure flag for the JSESSIONID cookie in an HTTPS session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an HTTP session. |
| Versions of Puppet Agent prior to 1.6.0 included a version of the Puppet Execution Protocol (PXP) agent that passed environment variables through to Puppet runs. This could allow unauthorized code to be loaded. This bug was first introduced in Puppet Agent 1.3.0. |
| Cross-site scripting (XSS) vulnerability in the console in Puppet Enterprise before 2015.2.1 allows remote attackers to inject arbitrary web script or HTML via the string parameter, related to Login Redirect. |
| The Puppet Communications Protocol in Puppet Enterprise 2015.3.x before 2015.3.3 does not properly validate certificates for the broker node, which allows remote non-whitelisted hosts to prevent runs from triggering via unspecified vectors. |
| Open redirect vulnerability in the Console in Puppet Enterprise before 2015.2.1 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via the string parameter. |
| Versions of MCollective prior to 2.10.4 deserialized YAML from agents without calling safe_load, allowing the potential for arbitrary code execution on the server. The fix for this is to call YAML.safe_load on input. This has been tested in all Puppet-supplied MCollective plugins, but there is a chance that third-party plugins could rely on this insecure behavior. |
| Puppet Enterprise 3.7.x and 3.8.0 might allow remote authenticated users to manage certificates for arbitrary nodes by leveraging a client certificate trusted by the master, aka a "Certificate Authority Reverse Proxy Vulnerability." |
| The default vhost configuration file in Puppet before 3.6.2 does not include the SSLCARevocationCheck directive, which might allow remote attackers to obtain sensitive information via a revoked certificate when a Puppet master runs with Apache 2.4. |
| puppetlabs-mysql 3.1.0 through 3.6.0 allow remote attackers to bypass authentication by leveraging creation of a database account without a password when a 'mysql_user' user parameter contains a host with a netmask. |
| MCollective 2.7.0 and 2.8.x before 2.8.9, as used in Puppet Enterprise, allows remote attackers to execute arbitrary code via vectors related to the mco ping command. |
| The Puppet Communications Protocol (PCP) Broker incorrectly validates message header sizes. An attacker could use this to crash the PCP Broker, preventing commands from being sent to agents. This is resolved in Puppet Enterprise 2016.4.3 and 2016.5.2. |
| Versions of the puppetlabs-apache module prior to 1.11.1 and 2.1.0 make it very easy to accidentally misconfigure TLS trust. If you specify the `ssl_ca` parameter but do not specify the `ssl_certs_dir` parameter, a default will be provided for the `ssl_certs_dir` that will trust certificates from any of the system-trusted certificate authorities. This did not affect FreeBSD. |
