{"id":"CVE-2022-21657","aliases":["BIT-envoy-2022-21657","EUVD-2022-26875","GHSA-837m-wjrv-vm5g"],"status":"published","title":"X.509 Extended Key Usage and Trust Purposes bypass in Envoy","description":"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.","severity":{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00522,"percentile":0.44611,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-295"],"published":"2022-02-22T22:30:12Z","modified":"2026-10-28T10:25:06Z","fixes":[{"ecosystem":"Bitnami","package":"envoy","fixed_in":["1.18.6","1.19.3","1.20.2"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Bitnami","package":"envoy","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.18.6"},{"introduced":"1.19.0"},{"fixed":"1.19.3"},{"introduced":"1.20.0"},{"fixed":"1.20.2"}]}]}],"products":[{"vendor":"envoyproxy","product":"envoy"}],"references":[{"url":"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g","tags":["x_refsource_CONFIRM","x_transferred","Issue Tracking","Third Party Advisory","advisory"]},{"url":"https://github.com/envoyproxy/envoy/pull/630","tags":["x_refsource_MISC","x_transferred","Patch","Third Party Advisory","advisory","fix"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-21657","tags":["web","advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/21xxx/CVE-2022-21657.json","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2022-21657","title":"X.509 Extended Key Usage and Trust Purposes bypass in Envoy","description":"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.","status":"published","published":"2022-02-22T22:30:12Z","modified":"2025-04-23T19:01:32.824Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T14:34:28.707644Z"}],"euvd":[{"id":"EUVD-2022-26875","description":"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.","status":"published","published":"2022-02-22T22:30:12Z","modified":"2025-04-23T19:01:32Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T20:52:07.453218Z"}],"nvd":[{"id":"CVE-2022-21657","description":"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.","status":"published","published":"2022-02-22T23:15:11.277Z","modified":"2026-06-17T04:26:41.99Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"secondary"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N","level":"medium","assessor":"primary"},{"version":"2.0","score":4,"vector":"AV:N/AC:L/Au:S/C:N/I:P/A:N","level":"medium","assessor":"primary"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T14:07:12.711288Z"}],"osv":[{"id":"CVE-2022-21657","title":"X.509 Extended Key Usage and Trust Purposes bypass in Envoy","description":"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.","status":"published","published":"2022-02-22T22:30:12Z","modified":"2026-10-28T10:25:06.622723055Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T15:44:23.655778Z"},{"id":"BIT-envoy-2022-21657","title":"X.509 Extended Key Usage and Trust Purposes bypass in Envoy","description":"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.","status":"published","published":"2024-03-06T10:55:54.594Z","modified":"2026-09-08T08:47:26.502676552Z","updated_at":"2026-11-02T15:28:29.563843Z"}]}}