{"containers":{"cna":{"affected":[{"product":"Puppet","vendor":"Puppet","versions":[{"status":"affected","version":"5.5.x prior to 5.5.19"},{"status":"affected","version":"Fixed in 5.5.19"},{"status":"affected","version":"6.x prior to 6.13.0"},{"status":"affected","version":"Fixed in 6.13.0"}]},{"product":"Puppet Agent","vendor":"Puppet","versions":[{"status":"affected","version":"5.5.x prior to 5.5.19"},{"status":"affected","version":"Fixed in 5.5.19"},{"status":"affected","version":"6.x prior to 6.13.0"},{"status":"affected","version":"Fixed in 6.13.0"}]}],"descriptions":[{"lang":"en","value":"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"}],"problemTypes":[{"descriptions":[{"description":"Arbitrary retrieval","lang":"en","type":"text"}]}],"providerMetadata":{"dateUpdated":"2020-04-02T19:00:07.000Z","orgId":"ca2a266c-be2f-4d4b-92d0-47b76b1a9c4e","shortName":"puppet"},"references":[{"tags":["x_refsource_CONFIRM"],"url":"https://puppet.com/security/cve/CVE-2020-7942/"}],"x_legacyV4Record":{"CVE_data_meta":{"ASSIGNER":"security@puppet.com","ID":"CVE-2020-7942","STATE":"PUBLIC"},"affects":{"vendor":{"vendor_data":[{"product":{"product_data":[{"product_name":"Puppet","version":{"version_data":[{"version_value":"5.5.x prior to 5.5.19"},{"version_value":"Fixed in 5.5.19"},{"version_value":"6.x prior to 6.13.0"},{"version_value":"Fixed in 6.13.0"}]}},{"product_name":"Puppet Agent","version":{"version_data":[{"version_value":"5.5.x prior to 5.5.19"},{"version_value":"Fixed in 5.5.19"},{"version_value":"6.x prior to 6.13.0"},{"version_value":"Fixed in 6.13.0"}]}}]},"vendor_name":"Puppet"}]}},"data_format":"MITRE","data_type":"CVE","data_version":"4.0","description":{"description_data":[{"lang":"eng","value":"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"}]},"problemtype":{"problemtype_data":[{"description":[{"lang":"eng","value":"Arbitrary retrieval"}]}]},"references":{"reference_data":[{"name":"https://puppet.com/security/cve/CVE-2020-7942/","refsource":"CONFIRM","url":"https://puppet.com/security/cve/CVE-2020-7942/"}]}}},"adp":[{"providerMetadata":{"orgId":"af854a3a-2127-422b-91ae-364da2661108","shortName":"CVE","dateUpdated":"2024-08-04T09:48:24.553Z"},"title":"CVE Program Container","references":[{"tags":["x_refsource_CONFIRM","x_transferred"],"url":"https://puppet.com/security/cve/CVE-2020-7942/"}]}]},"cveMetadata":{"assignerOrgId":"ca2a266c-be2f-4d4b-92d0-47b76b1a9c4e","assignerShortName":"puppet","cveId":"CVE-2020-7942","datePublished":"2020-02-19T20:52:03.000Z","dateReserved":"2020-01-23T00:00:00.000Z","dateUpdated":"2024-08-04T09:48:24.553Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.1"}