Puppet 0.24.x before 0.24.9 and 0.25.x before 0.25.2 allows local users to overwrite arbitrary files via a symlink attack on the (1) /tmp/daemonout, (2) /tmp/puppetdoc.txt, (3) /tmp/puppetdoc.tex, or (4) /tmp/puppetdoc.aux temporary file.

Directory traversal vulnerability in Puppet 2.6.x before 2.6.10 and 2.7.x before 2.7.4 allows remote attackers to write X.509 Certificate Signing Request (CSR) to arbitrary locations via (1) a double-encoded key parameter in the URI in 2.7.x, (2) the CN in the Subject of a CSR in 2.6 and 0.25.

Puppet 2.7.x before 2.7.5, 2.6.x before 2.6.11, and 0.25.x allows local users to overwrite arbitrary files via a symlink attack on the .k5login file.

Puppet 2.7.x before 2.7.5, 2.6.x before 2.6.11, and 0.25.x allows local users to modify the permissions of arbitrary files via a symlink attack on the SSH authorized_keys file.

Puppet 2.7.x before 2.7.5, 2.6.x before 2.6.11, and 0.25.x, when running in --edit mode, uses a predictable file name, which allows local users to run arbitrary Puppet code or trick a user into editing arbitrary files.

Puppet 2.6.x before 2.6.12 and 2.7.x before 2.7.6, and Puppet Enterprise (PE) Users 1.0, 1.1, and 1.2 before 1.2.4, when signing an agent certificate, adds the Puppet master's certdnsnames values to the X.509 Subject Alternative Name field of the certificate, which allows remote attackers to spoof a Puppet master via a man-in-the-middle (MITM) attack against an agent that uses an alternate DNS name for the master, aka "AltNames Vulnerability."

The change_user method in the SUIDManager (lib/puppet/util/suidmanager.rb) in Puppet 2.6.x before 2.6.14 and 2.7.x before 2.7.11, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x before 2.0.3 does not properly manage group privileges, which allows local users to gain privileges via vectors related to (1) the change_user not dropping supplementary groups in certain conditions, (2) changes to the eguid without associated changes to the egid, or (3) the addition of the real gid to supplementary groups.

Puppet 2.6.x before 2.6.14 and 2.7.x before 2.7.11, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x before 2.0.3, when managing a user login file with the k5login resource type, allows local users to gain privileges via a symlink attack on .k5login.

Puppet 2.6.x before 2.6.15 and 2.7.x before 2.7.13, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x, and 2.5.x before 2.5.1 uses predictable file names when installing Mac OS X packages from a remote source, which allows local users to overwrite arbitrary files or install arbitrary packages via a symlink attack on a temporary file in /tmp.

Puppet 2.6.x before 2.6.15 and 2.7.x before 2.7.13, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x, and 2.5.x before 2.5.1 allows remote authenticated users with an authorized SSL key and certain permissions on the puppet master to read arbitrary files via a symlink attack in conjunction with a crafted REST request for a file in a filebucket.

Unspecified vulnerability in Puppet 2.6.x before 2.6.15 and 2.7.x before 2.7.13, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x, and 2.5.x before 2.5.1 allows remote authenticated users with agent SSL keys to (1) cause a denial of service (memory consumption) via a REST request to a stream that triggers a thread block, as demonstrated using CVE-2012-1986 and /dev/random; or (2) cause a denial of service (filesystem consumption) via crafted REST requests that use "a marshaled form of a Puppet::FileBucket::File object" to write to arbitrary file locations.

Puppet 2.6.x before 2.6.15 and 2.7.x before 2.7.13, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x, and 2.5.x before 2.5.1 allows remote authenticated users with agent SSL keys and file-creation permissions on the puppet master to execute arbitrary commands by creating a file whose full pathname contains shell metacharacters, then performing a filebucket request.

telnet.rb in Puppet 2.7.x before 2.7.13 and Puppet Enterprise (PE) 1.2.x, 2.0.x, and 2.5.x before 2.5.1 allows local users to overwrite arbitrary files via a symlink attack on the NET::Telnet connection log (/tmp/out.log).

The pe_mcollective module in Puppet Enterprise (PE) before 2.7.1 does not properly restrict access to a catalog of private SSL keys, which allows remote authenticated users to obtain sensitive information and gain privileges by leveraging root access to a node, related to the master role.

Multiple cross-site request forgery (CSRF) vulnerabilities in the (1) node request management, (2) live management, and (3) user administration components in the console in Puppet Enterprise (PE) before 2.7.1 allow remote attackers to hijack the authentication of unspecified victims via unknown vectors.

The (1) template and (2) inline_template functions in the master server in Puppet before 2.6.18, 2.7.x before 2.7.21, and 3.1.x before 3.1.1, and Puppet Enterprise before 1.2.7 and 2.7.x before 2.7.2 allows remote authenticated users to execute arbitrary code via a crafted catalog request.

Puppet before 2.6.18, 2.7.x before 2.7.21, and 3.1.x before 3.1.1, and Puppet Enterprise before 1.2.7 and 2.7.x before 2.7.2 allows remote authenticated users with a valid certificate and private key to read arbitrary catalogs or poison the master's cache via unspecified vectors.

Puppet before 2.6.18, 2.7.x before 2.7.21, and 3.1.x before 3.1.1, and Puppet Enterprise before 1.2.7 and 2.7.x before 2.7.2, when listening for incoming connections is enabled and allowing access to the "run" REST endpoint is allowed, allows remote authenticated users to execute arbitrary code via a crafted HTTP request.

Puppet 2.7.x before 2.7.21 and 3.1.x before 3.1.1, and Puppet Enterprise 2.7.x before 2.7.2, does not properly negotiate the SSL protocol between client and master, which allows remote attackers to conduct SSLv2 downgrade attacks against SSLv3 sessions via unspecified vectors.

Puppet 2.7.x before 2.7.21 and 3.1.x before 3.1.1, when running Ruby 1.9.3 or later, allows remote attackers to execute arbitrary code via vectors related to "serialized attributes."

Puppet 2.6.x before 2.6.18 and Puppet Enterprise 1.2.x before 1.2.7 allows remote authenticated users to execute arbitrary code on the puppet master, or an agent with puppet kick enabled, via a crafted request for a report.

The default configuration for puppet masters 0.25.0 and later in Puppet before 2.6.18, 2.7.x before 2.7.21, and 3.1.x before 3.1.1, and Puppet Enterprise before 1.2.7 and 2.7.x before 2.7.2, allows remote authenticated nodes to submit reports for other nodes via unspecified vectors.

Puppet Labs Puppet Enterprise before 2.8.0 does not use a "randomized secret" in the CAS client config file (cas_client_config.yml) when upgrading from older 1.2.x or 2.0.x versions, which allows remote attackers to obtain console access via a crafted cookie.

Puppet 2.7.x before 2.7.22 and 3.2.x before 3.2.2, and Puppet Enterprise before 2.8.2, deserializes untrusted YAML, which allows remote attackers to instantiate arbitrary Ruby classes and execute arbitrary code via a crafted REST API call.

Unspecified vulnerability in Puppet 2.7.x before 2.7.23 and 3.2.x before 3.2.4, and Puppet Enterprise 2.8.x before 2.8.3 and 3.0.x before 3.0.1, allows remote attackers to execute arbitrary Ruby programs from the master via the resource_type service. NOTE: this vulnerability can only be exploited utilizing unspecified "local file system access" to the Puppet Master.

Puppet Enterprise before 3.0.1 does not sufficiently invalidate a session when a user logs out, which might allow remote attackers to hijack sessions by obtaining an old session ID.

Open redirect vulnerability in the login page in Puppet Enterprise before 3.0.1 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the service parameter.

Puppet Module Tool (PMT), as used in Puppet 2.7.x before 2.7.23 and 3.2.x before 3.2.4, and Puppet Enterprise 2.8.x before 2.8.3 and 3.0.x before 3.0.1, installs modules with weak permissions if those permissions were used when the modules were originally built, which might allow local users to read or modify those modules depending on the original permissions.

The dashboard report in Puppet Enterprise before 3.0.1 allows attackers to execute arbitrary YAML code via a crafted report-specific type.

Puppet Enterprise before 3.0.1 does not use a session timeout, which makes it easier for attackers to gain privileges by leveraging an unattended workstation.

Puppet Enterprise before 3.0.1 uses HTTP responses that contain sensitive information without the "no-cache" setting, which might allow local users to obtain sensitive information such as (1) host name, (2) MAC address, and (3) SSH keys via the web browser cache.

Puppet Enterprise before 3.0.1 includes version information for the Apache and Phusion Passenger products in its HTTP response headers, which allows remote attackers to obtain sensitive information.

The reset password page in Puppet Enterprise before 3.0.1 does not force entry of the current password, which allows attackers to modify user passwords by leveraging session hijacking, an unattended workstation, or other vectors.

Multiple cross-site request forgery (CSRF) vulnerabilities in Puppet Enterprise (PE) before 3.0.1 allow remote attackers to hijack the authentication of users for requests that deleting a (1) report, (2) group, or (3) class or possibly have other unspecified impact.

Puppet Enterprise before 3.0.1 does not set the secure flag for the session cookie in an https session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an http session.

Puppet Enterprise before 3.1.0 does not properly restrict the number of authentication attempts by a console account, which makes it easier for remote attackers to bypass intended access restrictions via a brute-force attack.

The master external node classification script in Puppet Enterprise before 3.2.0 does not verify the identity of consoles, which allows remote attackers to create arbitrary classifications on the master by spoofing a console.

Puppet Enterprise before 3.0.1 allows remote attackers to obtain the database password via vectors related to how the password is "seeded as a console parameter," External Node Classifiers, and the lack of access control for /nodes.

Puppet Enterprise before 3.0.1 allows remote attackers to (1) conduct clickjacking attacks via unspecified vectors related to the console, and (2) conduct cross-site scripting (XSS) attacks via unspecified vectors related to "live management."

Puppet before 3.3.3 and 3.4 before 3.4.1 and Puppet Enterprise (PE) before 2.8.4 and 3.1 before 3.1.1 allows local users to overwrite arbitrary files via a symlink attack on unspecified files.

Puppet Enterprise before 3.2.0 does not properly restrict access to node endpoints in the console, which allows remote attackers to obtain sensitive information via unspecified vectors.

mcollective has a default password set at install

Untrusted search path vulnerability in Puppet Enterprise 2.8 before 2.8.7, Puppet before 2.7.26 and 3.x before 3.6.2, Facter 1.6.x and 2.x before 2.0.2, Hiera before 1.3.4, and Mcollective before 2.5.2, when running with Ruby 1.9.1 or earlier, allows local users to gain privileges via a Trojan horse file in the current working directory, as demonstrated using (1) rubygems/defaults/operating_system.rb, (2) Win32API.rb, (3) Win32API.so, (4) safe_yaml.rb, (5) safe_yaml/deep.rb, or (6) safe_yaml/deep.so; or (7) operatingsystem.rb, (8) operatingsystem.so, (9) osfamily.rb, or (10) osfamily.so in puppet/confine.

Puppet Enterprise 2.8.x before 2.8.7 allows remote attackers to obtain sensitive information via vectors involving hiding and unhiding nodes.

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.

The MCollective aes_security plugin, as used in Puppet Enterprise before 3.3.0 and Mcollective before 2.5.3, does not properly validate new server certificates based on the CA certificate, which allows local users to establish unauthorized Mcollective connections via unspecified vectors related to a race condition.

Race condition in Puppet Server 0.2.0 allows local users to obtain sensitive information by accessing it in between package installation or upgrade and the start of the service.

Puppet Enterprise before 3.7.1 allows remote authenticated users to obtain licensing and certificate signing request information by leveraging access to an unspecified API endpoint.

The puppetlabs-stdlib module 2.1 through 3.0 and 4.1.0 through 4.5.x before 4.5.1 for Puppet 2.8.8 and earlier allows remote authenticated users to gain privileges or obtain sensitive information by prepopulating the fact cache.

Puppet Labs Facter 1.6.0 through 2.4.0 allows local users to obtains sensitive Amazon EC2 IAM instance metadata by reading a fact for an Amazon EC2 node.

verify_certificate_identity in the OpenSSL extension in Ruby before 2.0.0 patchlevel 645, 2.1.x before 2.1.6, and 2.2.x before 2.2.2 does not properly validate hostnames, which allows remote attackers to spoof servers via vectors related to (1) multiple wildcards, (1) wildcards in IDNA names, (3) case sensitivity, and (4) non-ASCII characters.

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."

Parts of the Puppet Enterprise Console 3.x were found to be susceptible to clickjacking and CSRF (Cross-Site Request Forgery) attacks. This would allow an attacker to redirect user input to an untrusted site or hijack a user session.

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.

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.

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.

Puppet Server in Puppet Enterprise before 3.8.x before 3.8.3 and 2015.2.x before 2015.2.3 uses world-readable permissions for the private key of the Certification Authority (CA) certificate during the initial installation and configuration, which might allow local users to obtain sensitive information via unspecified vectors.

Puppet Enterprise 2015.3 before 2015.3.1 allows remote attackers to bypass a host whitelist protection mechanism by leveraging the Puppet communications protocol.

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.

Puppet Server before 2.3.2 and Ruby puppetmaster in Puppet 4.x before 4.4.2 and in Puppet Agent before 1.4.2 might allow remote attackers to bypass intended auth.conf access restrictions by leveraging incorrect URL decoding.

The pxp-agent component in Puppet Enterprise 2015.3.x before 2015.3.3 and Puppet Agent 1.3.x before 1.3.6 does not properly validate server certificates, which might allow remote attackers to spoof brokers and execute arbitrary commands via a crafted certificate.

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.

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.

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.

Puppet Enterprise 2015.3.3 and 2016.x before 2016.4.0, and Puppet Agent 1.3.6 through 1.7.0 allow remote attackers to bypass a host whitelist protection mechanism and execute arbitrary code on Puppet nodes via vectors related to command validation, aka "Puppet Execution Protocol (PXP) Command Whitelist Validation Vulnerability."

Open redirect vulnerability in the Console in Puppet Enterprise 2015.x and 2016.x before 2016.4.0 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a // (slash slash) followed by a domain in the redirect parameter. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-6501.

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 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.

In previous versions of Puppet Agent it was possible to install a module with world writable permissions. Puppet Agent 5.3.4 and 1.10.10 included a fix to this vulnerability.

In previous versions of Puppet Agent it was possible for the agent to retrieve facts from an environment that it was not classified to retrieve from. This was resolved in Puppet Agent 5.3.4, included in Puppet Enterprise 2017.3.4

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 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.

Versions of Puppet Enterprise prior to 2016.4.5 or 2017.2.1 shipped with an MCollective configuration that allowed the package plugin to install or remove arbitrary packages on all managed agents. This release adds default configuration to not allow these actions. Customers who rely on this functionality can change this policy.

Versions of Puppet Enterprise prior to 2016.4.5 or 2017.2.1 failed to mark MCollective server private keys as sensitive (a feature added in Puppet 4.6), so key values could be logged and stored in PuppetDB. These releases use the sensitive data type to ensure this won't happen anymore.

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.

In Puppet Enterprise 2017.1.x and 2017.2.1, using specially formatted strings with certain formatting characters as Classifier node group names or RBAC role display names causes errors, effectively causing a DOS to the service. This was resolved in Puppet Enterprise 2017.2.2.

Puppet Enterprise versions prior to 2016.4.5 and 2017.2.1 did not correctly authenticate users before returning labeled RBAC access tokens. This issue has been fixed in Puppet Enterprise 2016.4.5 and 2017.2.1. This only affects users with labeled tokens, which is not the default for tokens.

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".

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.

Nginx versions since 0.5.6 up to and including 1.13.2 are vulnerable to integer overflow vulnerability in nginx range filter module resulting into leak of potentially sensitive information triggered by specially crafted request.

In Puppet Discovery prior to 1.2.0, when running Discovery against Windows hosts, WinRM connections can fall back to using basic auth over insecure channels if a HTTPS server is not available. This can expose the login credentials being used by Puppet Discovery.

Previously, Puppet Discovery was shipped with a default generated TLS certificate in the nginx container. In version 1.4.0, a unique certificate will be generated on installation or the user will be able to provide their own TLS certificate for ingress.

Previous releases of the Puppet device_manager module creates configuration files containing credentials that are world readable. This issue has been resolved as of device_manager 2.7.0.

When users are configured to use startTLS with RBAC LDAP, at login time, the user's credentials are sent via plaintext to the LDAP server. This affects Puppet Enterprise 2018.1.3, 2017.3.9, and 2016.4.14, and is fixed in Puppet Enterprise 2018.1.4, 2017.3.10, and 2016.4.15. It scored an 8.5 CVSS score.

Previous releases of the Puppet cisco_ios module did not validate a host's identity before starting a SSH connection. As of the 0.4.0 release of cisco_ios, host key checking is enabled by default.

Previous versions of Puppet Agent didn't verify the peer in the SSL connection prior to downloading the CRL. This issue is resolved in Puppet Agent 6.4.0.

Previous releases of the Puppet cisco_ios module output SSH session debug information including login credentials to a world readable file on every run. These issues have been resolved in the 0.4.0 release.

Puppet Enterprise 2017.3.x prior to 2017.3.3 are vulnerable to a remote execution bug when a specially crafted string was passed into the facter_task or puppet_conf tasks. This vulnerability only affects tasks in the affected modules, if you are not using puppet tasks you are not affected by this vulnerability.

A cross-site scripting vulnerability in Puppet Enterprise Console of Puppet Enterprise allows a user to inject scripts into the Puppet Enterprise Console when using the Orchestrator. Affected releases are Puppet Puppet Enterprise: 2017.3.x versions prior to 2017.3.6.

A cross-site scripting vulnerability in Puppet Enterprise Console of Puppet Enterprise allows a user to inject scripts into the Puppet Enterprise Console when using the Puppet Enterprise Console. Affected releases are Puppet Puppet Enterprise: 2017.3.x versions prior to 2017.3.6.

The previous version of Puppet Enterprise 2018.1 is vulnerable to unsafe code execution when upgrading pe-razor-server. Affected releases are Puppet Enterprise: 2018.1.x versions prior to 2018.1.1 and razor-server and pe-razor-server prior to 1.9.0.0.

Puppet Enterprise 2016.4.x prior to 2016.4.12, Puppet Enterprise 2017.3.x prior to 2017.3.7, Puppet Enterprise 2018.1.x prior to 2018.1.1, Puppet Agent 1.10.x prior to 1.10.13, Puppet Agent 5.3.x prior to 5.3.7, and Puppet Agent 5.5.x prior to 5.5.2, were vulnerable to an attack where an unprivileged user on Windows agents could write custom facts that can escalate privileges on the next puppet run. This was possible through the loading of shared libraries from untrusted paths.

In Puppet Agent 1.10.x prior to 1.10.13, Puppet Agent 5.3.x prior to 5.3.7, Puppet Agent 5.5.x prior to 5.5.2, Facter on Windows is vulnerable to a DLL preloading attack, which could lead to a privilege escalation.

Puppet Agent 1.10.x prior to 1.10.13, Puppet Agent 5.3.x prior to 5.3.7, and Puppet Agent 5.5.x prior to 5.5.2 on Windows only, with a specially crafted configuration file an attacker could get pxp-agent to load arbitrary code with privilege escalation.

On Windows only, with a specifically crafted configuration file an attacker could get Puppet PE client tools (aka pe-client-tools) 16.4.x prior to 16.4.6, 17.3.x prior to 17.3.6, and 18.1.x prior to 18.1.2 to load arbitrary code with privilege escalation.

Prior to version 0.3.0, chloride's use of net-ssh resulted in host fingerprints for previously unknown hosts getting added to the user's known_hosts file without confirmation. In version 0.3.0 this is updated so that the user's known_hosts file is not updated by chloride.

The express install, which is the suggested way to install Puppet Enterprise, gives the user a URL at the end of the install to set the admin password. If they do not use that URL, there is an overlooked default password for the admin user. This was resolved in Puppet Enterprise 2019.0.3 and 2018.1.9.

When using the cd4pe::root_configuration task to configure a Continuous Delivery for PE installation, the root user’s username and password were exposed in the job’s Job Details pane in the PE console. These issues have been resolved in version 1.2.1 of the puppetlabs/cd4pe module.

Previously, Puppet operated on a model that a node with a valid certificate was entitled to all information in the system and that a compromised certificate allowed access to everything in the infrastructure. When a node's catalog falls back to the `default` node, the catalog can be retrieved for a different node by modifying facts for the Puppet run. This issue can be mitigated by setting `strict_hostname_checking = true` in `puppet.conf` on your Puppet master. Puppet 6.13.0 and 5.5.19 changes the default behavior for strict_hostname_checking from false to true. It is recommended that Puppet Open Source and Puppet Enterprise users that are not upgrading still set strict_hostname_checking to true to ensure secure behavior. Affected software versions: Puppet 6.x prior to 6.13.0 Puppet Agent 6.x prior to 6.13.0 Puppet 5.5.x prior to 5.5.19 Puppet Agent 5.5.x prior to 5.5.19 Resolved in: Puppet 6.13.0 Puppet Agent 6.13.0 Puppet 5.5.19 Puppet Agent 5.5.19

Puppet Server and PuppetDB provide useful performance and debugging information via their metrics API endpoints. For PuppetDB this may contain things like hostnames. Puppet Server reports resource names and titles for defined types (which may contain sensitive information) as well as function names and class names. Previously, these endpoints were open to the local network. PE 2018.1.13 & 2019.5.0, Puppet Server 6.9.2 & 5.3.12, and PuppetDB 6.9.1 & 5.2.13 disable trapperkeeper-metrics /v1 metrics API and only allows /v2 access on localhost by default. This affects software versions: Puppet Enterprise 2018.1.x stream prior to 2018.1.13 Puppet Enterprise prior to 2019.5.0 Puppet Server prior to 6.9.2 Puppet Server prior to 5.3.12 PuppetDB prior to 6.9.1 PuppetDB prior to 5.2.13 Resolved in: Puppet Enterprise 2018.1.13 Puppet Enterprise 2019.5.0 Puppet Server 6.9.2 Puppet Server 5.3.12 PuppetDB 6.9.1 PuppetDB 5.2.13

In Continuous Delivery for Puppet Enterprise (CD4PE) before 3.4.0, changes to resources or classes containing Sensitive parameters can result in the Sensitive parameters ending up in the impact analysis report.

Local registry credentials were included directly in the CD4PE deployment definition, which could expose these credentials to users who should not have access to them. This is resolved in Continuous Delivery for Puppet Enterprise 4.0.1.

The mechanism which performs certificate validation was discovered to have a flaw that resulted in certificates signed by an internal certificate authority to not be properly validated. This issue only affects clients that are configured to utilize Tenable.sc as the vulnerability data source.

PuppetDB logging included potentially sensitive system information.

Puppet Enterprise presented a security risk by not sanitizing user input when doing a CSV export.

A flaw was discovered in Puppet DB, this flaw results in an escalation of privileges which allows the user to delete tables via an SQL query.

A flaw was discovered in bolt-server and ace where running a task with sensitive parameters results in those sensitive parameters being logged when they should not be. This issue only affects SSH/WinRM nodes (inventory service nodes).

A flaw was discovered in Puppet Agent and Puppet Server that may result in a leak of HTTP credentials when following HTTP redirects to a different host. This is similar to CVE-2018-1000007

A flaw was discovered in Continuous Delivery for Puppet Enterprise (CD4PE) that results in a user with lower privileges being able to access a Puppet Enterprise API token. This issue is resolved in CD4PE 4.10.0

A flaw was discovered in Puppet Agent where the agent may silently ignore Augeas settings or may be vulnerable to a Denial of Service condition prior to the first 'pluginsync'.

A flaw was divered in Puppet Enterprise and other Puppet products where sensitive plan parameters may be logged

In certain situations it is possible for an unmanaged rule to exist on the target system that has the same comment as the rule specified in the manifest. This could allow for unmanaged rules to exist on the target system and leave the system in an unsafe state.

Command injection is possible in the puppetlabs-apt module prior to version 9.0.0. A malicious actor is able to exploit this vulnerability only if they are able to provide unsanitized input to the module. This condition is rare in most deployments of Puppet and Puppet Enterprise.

Command injection is possible in the puppetlabs-mysql module prior to version 13.0.0. A malicious actor is able to exploit this vulnerability only if they are able to provide unsanitized input to the module. This condition is rare in most deployments of Puppet and Puppet Enterprise.

A Regular Expression Denial of Service (ReDoS) issue was discovered in Puppet Server 7.9.2 certificate validation. An issue related to specifically crafted certificate names significantly slowed down server operations.

A privilege escalation allowing remote code execution was discovered in the orchestration service.

In Puppet Bolt versions prior to 3.27.4, a path to escalate privileges was identified.

For certificates that utilize the auto-renew feature in Puppet Server, a flaw exists which prevents the certificates from being revoked.

Versions of Puppet Enterprise prior to 2021.7.6 and 2023.5 contain a flaw which results in broken session management for SAML implementations.

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.