Vulnerability from bitnami_vulndb
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.
{
"affected": [
{
"package": {
"ecosystem": "Bitnami",
"name": "envoy",
"purl": "pkg:bitnami/envoy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.18.6"
},
{
"introduced": "1.19.0"
},
{
"fixed": "1.19.3"
},
{
"introduced": "1.20.0"
},
{
"fixed": "1.20.2"
}
],
"type": "SEMVER"
}
],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
],
"aliases": [
"CVE-2022-21657"
],
"database_specific": {
"cpes": [
"cpe:2.3:a:envoyproxy:envoy:*:*:*:*:*:*:*:*"
],
"severity": "Medium"
},
"details": "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.",
"id": "BIT-envoy-2022-21657",
"modified": "2025-05-20T10:02:07.006Z",
"published": "2024-03-06T10:55:54.594Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/envoyproxy/envoy/pull/630"
},
{
"type": "WEB",
"url": "https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21657"
}
],
"schema_version": "1.5.0",
"summary": "X.509 Extended Key Usage and Trust Purposes bypass in Envoy"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.