{"containers":{"cna":{"affected":[{"product":"envoy","vendor":"envoyproxy","versions":[{"status":"affected","version":">= 1.20.0, < 1.20.2"},{"status":"affected","version":">= 1.19.0, < 1.19.3"},{"status":"affected","version":"< 1.18.6"}]}],"descriptions":[{"lang":"en","value":"Envoy is an open source edge and service proxy, designed for cloud-native applications. In affected versions Envoy does not restrict the set of certificates it accepts from the peer, either as a TLS client or a TLS server, to only those certificates that contain the necessary extendedKeyUsage (id-kp-serverAuth and id-kp-clientAuth, respectively). This means that a peer may present an e-mail certificate (e.g. id-kp-emailProtection), either as a leaf certificate or as a CA in the chain, and it will be accepted for TLS. This is particularly bad when combined with the issue described in pull request #630, in that it allows a Web PKI CA that is intended only for use with S/MIME, and thus exempted from audit or supervision, to issue TLS certificates that will be accepted by Envoy. As a result Envoy will trust upstream certificates that should not be trusted. There are no known workarounds to this issue. Users are advised to upgrade."}],"metrics":[{"cvssV3_1":{"attackComplexity":"HIGH","attackVector":"NETWORK","availabilityImpact":"NONE","baseScore":6.8,"baseSeverity":"MEDIUM","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"LOW","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","version":"3.1"}}],"problemTypes":[{"descriptions":[{"cweId":"CWE-295","description":"CWE-295: Improper Certificate Validation","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2022-02-22T22:30:12.000Z","orgId":"a0819718-46f1-4df5-94e2-005712e83aaa","shortName":"GitHub_M"},"references":[{"tags":["x_refsource_CONFIRM"],"url":"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g"},{"tags":["x_refsource_MISC"],"url":"https://github.com/envoyproxy/envoy/pull/630"}],"source":{"advisory":"GHSA-837m-wjrv-vm5g","discovery":"UNKNOWN"},"title":"X.509 Extended Key Usage and Trust Purposes bypass in Envoy","x_legacyV4Record":{"CVE_data_meta":{"ASSIGNER":"security-advisories@github.com","ID":"CVE-2022-21657","STATE":"PUBLIC","TITLE":"X.509 Extended Key Usage and Trust Purposes bypass in Envoy"},"affects":{"vendor":{"vendor_data":[{"product":{"product_data":[{"product_name":"envoy","version":{"version_data":[{"version_value":">= 1.20.0, < 1.20.2"},{"version_value":">= 1.19.0, < 1.19.3"},{"version_value":"< 1.18.6"}]}}]},"vendor_name":"envoyproxy"}]}},"data_format":"MITRE","data_type":"CVE","data_version":"4.0","description":{"description_data":[{"lang":"eng","value":"Envoy is an open source edge and service proxy, designed for cloud-native applications. In affected versions Envoy does not restrict the set of certificates it accepts from the peer, either as a TLS client or a TLS server, to only those certificates that contain the necessary extendedKeyUsage (id-kp-serverAuth and id-kp-clientAuth, respectively). This means that a peer may present an e-mail certificate (e.g. id-kp-emailProtection), either as a leaf certificate or as a CA in the chain, and it will be accepted for TLS. This is particularly bad when combined with the issue described in pull request #630, in that it allows a Web PKI CA that is intended only for use with S/MIME, and thus exempted from audit or supervision, to issue TLS certificates that will be accepted by Envoy. As a result Envoy will trust upstream certificates that should not be trusted. There are no known workarounds to this issue. Users are advised to upgrade."}]},"impact":{"cvss":{"attackComplexity":"HIGH","attackVector":"NETWORK","availabilityImpact":"NONE","baseScore":6.8,"baseSeverity":"MEDIUM","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"LOW","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","version":"3.1"}},"problemtype":{"problemtype_data":[{"description":[{"lang":"eng","value":"CWE-295: Improper Certificate Validation"}]}]},"references":{"reference_data":[{"name":"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g","refsource":"CONFIRM","url":"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g"},{"name":"https://github.com/envoyproxy/envoy/pull/630","refsource":"MISC","url":"https://github.com/envoyproxy/envoy/pull/630"}]},"source":{"advisory":"GHSA-837m-wjrv-vm5g","discovery":"UNKNOWN"}}},"adp":[{"providerMetadata":{"orgId":"af854a3a-2127-422b-91ae-364da2661108","shortName":"CVE","dateUpdated":"2024-08-03T02:46:39.291Z"},"title":"CVE Program Container","references":[{"tags":["x_refsource_CONFIRM","x_transferred"],"url":"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g"},{"tags":["x_refsource_MISC","x_transferred"],"url":"https://github.com/envoyproxy/envoy/pull/630"}]},{"metrics":[{"other":{"type":"ssvc","content":{"timestamp":"2025-04-23T15:55:44.646250Z","id":"CVE-2022-21657","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"total"}],"role":"CISA Coordinator","version":"2.0.3"}}}],"title":"CISA ADP Vulnrichment","providerMetadata":{"orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP","dateUpdated":"2025-04-23T19:01:32.824Z"}}]},"cveMetadata":{"assignerOrgId":"a0819718-46f1-4df5-94e2-005712e83aaa","assignerShortName":"GitHub_M","cveId":"CVE-2022-21657","datePublished":"2022-02-22T22:30:12.000Z","dateReserved":"2021-11-16T00:00:00.000Z","dateUpdated":"2025-04-23T19:01:32.824Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.1"}