CVE-2022-21657 (GCVE-0-2022-21657)
Vulnerability from cvelistv5
Published
2022-02-22 22:30
Modified
2025-04-23 19:01
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-295 - Improper Certificate Validation
Summary
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.
References
| ► | URL | Tags | ||||||
|---|---|---|---|---|---|---|---|---|
|
||||||||
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| envoyproxy | envoy |
Version: >= 1.20.0, < 1.20.2 Version: >= 1.19.0, < 1.19.3 Version: < 1.18.6 |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T02:46:39.291Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"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"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2022-21657",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-04-23T15:55:44.646250Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-04-23T19:01:32.824Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "envoy",
"vendor": "envoyproxy",
"versions": [
{
"status": "affected",
"version": "\u003e= 1.20.0, \u003c 1.20.2"
},
{
"status": "affected",
"version": "\u003e= 1.19.0, \u003c 1.19.3"
},
{
"status": "affected",
"version": "\u003c 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": "\u003e= 1.20.0, \u003c 1.20.2"
},
{
"version_value": "\u003e= 1.19.0, \u003c 1.19.3"
},
{
"version_value": "\u003c 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"
}
}
}
},
"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",
"vulnerability-lookup:meta": {
"vulnrichment": {
"containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g\", \"tags\": [\"x_refsource_CONFIRM\", \"x_transferred\"]}, {\"url\": \"https://github.com/envoyproxy/envoy/pull/630\", \"tags\": [\"x_refsource_MISC\", \"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-03T02:46:39.291Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2022-21657\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-04-23T15:55:44.646250Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-04-23T15:55:46.124Z\"}}], \"cna\": {\"title\": \"X.509 Extended Key Usage and Trust Purposes bypass in Envoy\", \"source\": {\"advisory\": \"GHSA-837m-wjrv-vm5g\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 6.8, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N\", \"integrityImpact\": \"HIGH\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"HIGH\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"HIGH\"}}], \"affected\": [{\"vendor\": \"envoyproxy\", \"product\": \"envoy\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003e= 1.20.0, \u003c 1.20.2\"}, {\"status\": \"affected\", \"version\": \"\u003e= 1.19.0, \u003c 1.19.3\"}, {\"status\": \"affected\", \"version\": \"\u003c 1.18.6\"}]}], \"references\": [{\"url\": \"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/envoyproxy/envoy/pull/630\", \"tags\": [\"x_refsource_MISC\"]}], \"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.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-295\", \"description\": \"CWE-295: Improper Certificate Validation\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2022-02-22T22:30:12.000Z\"}, \"x_legacyV4Record\": {\"impact\": {\"cvss\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 6.8, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N\", \"integrityImpact\": \"HIGH\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"HIGH\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"HIGH\"}}, \"source\": {\"advisory\": \"GHSA-837m-wjrv-vm5g\", \"discovery\": \"UNKNOWN\"}, \"affects\": {\"vendor\": {\"vendor_data\": [{\"product\": {\"product_data\": [{\"version\": {\"version_data\": [{\"version_value\": \"\u003e= 1.20.0, \u003c 1.20.2\"}, {\"version_value\": \"\u003e= 1.19.0, \u003c 1.19.3\"}, {\"version_value\": \"\u003c 1.18.6\"}]}, \"product_name\": \"envoy\"}]}, \"vendor_name\": \"envoyproxy\"}]}}, \"data_type\": \"CVE\", \"references\": {\"reference_data\": [{\"url\": \"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g\", \"name\": \"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g\", \"refsource\": \"CONFIRM\"}, {\"url\": \"https://github.com/envoyproxy/envoy/pull/630\", \"name\": \"https://github.com/envoyproxy/envoy/pull/630\", \"refsource\": \"MISC\"}]}, \"data_format\": \"MITRE\", \"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.\"}]}, \"problemtype\": {\"problemtype_data\": [{\"description\": [{\"lang\": \"eng\", \"value\": \"CWE-295: Improper Certificate Validation\"}]}]}, \"data_version\": \"4.0\", \"CVE_data_meta\": {\"ID\": \"CVE-2022-21657\", \"STATE\": \"PUBLIC\", \"TITLE\": \"X.509 Extended Key Usage and Trust Purposes bypass in Envoy\", \"ASSIGNER\": \"security-advisories@github.com\"}}}}",
"cveMetadata": "{\"cveId\": \"CVE-2022-21657\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-04-23T19:01:32.824Z\", \"dateReserved\": \"2021-11-16T00:00:00.000Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2022-02-22T22:30:12.000Z\", \"assignerShortName\": \"GitHub_M\"}",
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…