puppet CVE Vulnerabilities & Metrics

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

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.

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

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.

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.

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.

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.

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

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

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

PuppetDB logging included potentially sensitive system information.

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.

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.

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.

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.

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

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.

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

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.

mcollective has a default password set at install

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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

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.

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

Puppet Enterprise (PE) before 2.6.1 does not properly invalidate sessions when the session secret has changed, which allows remote authenticated users to retain access via unspecified vectors.

Multiple cross-site scripting (XSS) vulnerabilities in Puppet Dashboard 1.0 before 1.2.5 and Enterprise 1.0 before 1.2.5 and 2.x before 2.0.1 allow remote attackers to inject arbitrary web script or HTML via unspecified fields.

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.

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 2.6.0 through 2.6.3 does not properly restrict access to node resources, which allows remote authenticated Puppet nodes to read or modify the resources of other nodes via unspecified vectors.

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

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.

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.

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 does not use a session timeout, which makes it easier for attackers to gain privileges by leveraging an unattended workstation.

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.

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

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

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.

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

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

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.

lib/puppet/ssl/certificate_authority.rb in Puppet before 2.6.17 and 2.7.x before 2.7.18, and Puppet Enterprise before 2.5.2, does not properly restrict the characters in the Common Name field of a Certificate Signing Request (CSR), which makes it easier for user-assisted remote attackers to trick administrators into signing a crafted agent certificate via ANSI control sequences.

lib/puppet/defaults.rb in Puppet 2.7.x before 2.7.18, and Puppet Enterprise before 2.5.2, uses 0644 permissions for last_run_report.yaml, which allows local users to obtain sensitive configuration information by leveraging access to the puppet master server to read this file.

Directory traversal vulnerability in lib/puppet/reports/store.rb in Puppet before 2.6.17 and 2.7.x before 2.7.18, and Puppet Enterprise before 2.5.2, when Delete is enabled in auth.conf, allows remote authenticated users to delete arbitrary files on the puppet master server via a .. (dot dot) in a node name.

Puppet before 2.6.17 and 2.7.x before 2.7.18, and Puppet Enterprise before 2.5.2, allows remote authenticated users to read arbitrary files on the puppet master server by leveraging an arbitrary user's certificate and private key in a GET request.

lib/puppet/network/authstore.rb in Puppet before 2.7.18, and Puppet Enterprise before 2.5.2, supports use of IP addresses in certnames without warning of potential risks, which might allow remote attackers to spoof an agent by acquiring a previously used IP address.

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

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.

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

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

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

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.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 allows local users to overwrite arbitrary files via a symlink attack on the .k5login 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 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.