CVE-2022-21657 (GCVE-0-2022-21657)
Vulnerability from cvelistv5 – Published: 2022-02-22 22:30 – Updated: 2025-04-23 19:01
VLAI?
Title
X.509 Extended Key Usage and Trust Purposes bypass in Envoy
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.
Severity ?
6.8 (Medium)
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
| URL | Tags | |||||||
|---|---|---|---|---|---|---|---|---|
|
||||||||
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| envoyproxy | envoy |
Affected:
>= 1.20.0, < 1.20.2
Affected: >= 1.19.0, < 1.19.3 Affected: < 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": {
"fkie_nvd": {
"configurations": "[{\"nodes\": [{\"operator\": \"OR\", \"negate\": false, \"cpeMatch\": [{\"vulnerable\": true, \"criteria\": \"cpe:2.3:a:envoyproxy:envoy:*:*:*:*:*:*:*:*\", \"versionEndExcluding\": \"1.18.6\", \"matchCriteriaId\": \"0EFC93D0-C206-417C-81D0-F18145E3D768\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:a:envoyproxy:envoy:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"1.19.0\", \"versionEndExcluding\": \"1.19.3\", \"matchCriteriaId\": \"2812AC62-44B5-4077-862D-A221CD88981D\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:a:envoyproxy:envoy:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"1.20.0\", \"versionEndExcluding\": \"1.20.2\", \"matchCriteriaId\": \"F5441B2D-F807-4ED9-AFB9-ED4DE07CE5F8\"}]}]}]",
"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.\"}, {\"lang\": \"es\", \"value\": \"Envoy es un proxy de borde y servicio de c\\u00f3digo abierto, dise\\u00f1ado para aplicaciones nativas de la nube. En las versiones afectadas, Envoy no restringe el conjunto de certificados que acepta del par, ya sea como cliente TLS o como servidor TLS, a s\\u00f3lo aquellos certificados que contienen el extendedKeyUsage necesario (id-kp-serverAuth e id-kp-clientAuth, respectivamente). Esto significa que un par puede presentar un certificado de correo electr\\u00f3nico (por ejemplo, id-kp-emailProtection), ya sea como certificado de hoja o como CA en la cadena, y ser\\u00e1 aceptado para TLS. Esto es particularmente malo cuando es combinado con el problema descrito en la petici\\u00f3n #630, en el sentido de que permite que una CA de PKI de la Web que est\\u00e1 destinada s\\u00f3lo a ser usada con S/MIME, y por lo tanto exenta de auditor\\u00eda o supervisi\\u00f3n, emita certificados TLS que ser\\u00e1n aceptados por Envoy. En consecuencia, Envoy confiar\\u00e1 en certificados de origen que no deber\\u00edan ser confiables. No se conocen medidas de mitigaci\\u00f3n a este problema. Es recomendado a usuarios actualizar\"}]",
"id": "CVE-2022-21657",
"lastModified": "2024-11-21T06:45:10.227",
"metrics": "{\"cvssMetricV31\": [{\"source\": \"security-advisories@github.com\", \"type\": \"Secondary\", \"cvssData\": {\"version\": \"3.1\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N\", \"baseScore\": 6.8, \"baseSeverity\": \"MEDIUM\", \"attackVector\": \"NETWORK\", \"attackComplexity\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"userInteraction\": \"NONE\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"HIGH\", \"integrityImpact\": \"HIGH\", \"availabilityImpact\": \"NONE\"}, \"exploitabilityScore\": 1.6, \"impactScore\": 5.2}, {\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"3.1\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N\", \"baseScore\": 6.5, \"baseSeverity\": \"MEDIUM\", \"attackVector\": \"NETWORK\", \"attackComplexity\": \"LOW\", \"privilegesRequired\": \"LOW\", \"userInteraction\": \"NONE\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"HIGH\", \"availabilityImpact\": \"NONE\"}, \"exploitabilityScore\": 2.8, \"impactScore\": 3.6}], \"cvssMetricV2\": [{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"2.0\", \"vectorString\": \"AV:N/AC:L/Au:S/C:N/I:P/A:N\", \"baseScore\": 4.0, \"accessVector\": \"NETWORK\", \"accessComplexity\": \"LOW\", \"authentication\": \"SINGLE\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"PARTIAL\", \"availabilityImpact\": \"NONE\"}, \"baseSeverity\": \"MEDIUM\", \"exploitabilityScore\": 8.0, \"impactScore\": 2.9, \"acInsufInfo\": false, \"obtainAllPrivilege\": false, \"obtainUserPrivilege\": false, \"obtainOtherPrivilege\": false, \"userInteractionRequired\": false}]}",
"published": "2022-02-22T23:15:11.277",
"references": "[{\"url\": \"https://github.com/envoyproxy/envoy/pull/630\", \"source\": \"security-advisories@github.com\", \"tags\": [\"Patch\", \"Third Party Advisory\"]}, {\"url\": \"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g\", \"source\": \"security-advisories@github.com\", \"tags\": [\"Issue Tracking\", \"Third Party Advisory\"]}, {\"url\": \"https://github.com/envoyproxy/envoy/pull/630\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Patch\", \"Third Party Advisory\"]}, {\"url\": \"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Issue Tracking\", \"Third Party Advisory\"]}]",
"sourceIdentifier": "security-advisories@github.com",
"vulnStatus": "Modified",
"weaknesses": "[{\"source\": \"security-advisories@github.com\", \"type\": \"Primary\", \"description\": [{\"lang\": \"en\", \"value\": \"CWE-295\"}]}]"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2022-21657\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2022-02-22T23:15:11.277\",\"lastModified\":\"2024-11-21T06:45:10.227\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"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.\"},{\"lang\":\"es\",\"value\":\"Envoy es un proxy de borde y servicio de c\u00f3digo abierto, dise\u00f1ado para aplicaciones nativas de la nube. En las versiones afectadas, Envoy no restringe el conjunto de certificados que acepta del par, ya sea como cliente TLS o como servidor TLS, a s\u00f3lo aquellos certificados que contienen el extendedKeyUsage necesario (id-kp-serverAuth e id-kp-clientAuth, respectivamente). Esto significa que un par puede presentar un certificado de correo electr\u00f3nico (por ejemplo, id-kp-emailProtection), ya sea como certificado de hoja o como CA en la cadena, y ser\u00e1 aceptado para TLS. Esto es particularmente malo cuando es combinado con el problema descrito en la petici\u00f3n #630, en el sentido de que permite que una CA de PKI de la Web que est\u00e1 destinada s\u00f3lo a ser usada con S/MIME, y por lo tanto exenta de auditor\u00eda o supervisi\u00f3n, emita certificados TLS que ser\u00e1n aceptados por Envoy. En consecuencia, Envoy confiar\u00e1 en certificados de origen que no deber\u00edan ser confiables. No se conocen medidas de mitigaci\u00f3n a este problema. Es recomendado a usuarios actualizar\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N\",\"baseScore\":6.8,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":1.6,\"impactScore\":5.2},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N\",\"baseScore\":6.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":2.8,\"impactScore\":3.6}],\"cvssMetricV2\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"2.0\",\"vectorString\":\"AV:N/AC:L/Au:S/C:N/I:P/A:N\",\"baseScore\":4.0,\"accessVector\":\"NETWORK\",\"accessComplexity\":\"LOW\",\"authentication\":\"SINGLE\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"PARTIAL\",\"availabilityImpact\":\"NONE\"},\"baseSeverity\":\"MEDIUM\",\"exploitabilityScore\":8.0,\"impactScore\":2.9,\"acInsufInfo\":false,\"obtainAllPrivilege\":false,\"obtainUserPrivilege\":false,\"obtainOtherPrivilege\":false,\"userInteractionRequired\":false}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-295\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:envoyproxy:envoy:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"1.18.6\",\"matchCriteriaId\":\"0EFC93D0-C206-417C-81D0-F18145E3D768\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:envoyproxy:envoy:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"1.19.0\",\"versionEndExcluding\":\"1.19.3\",\"matchCriteriaId\":\"2812AC62-44B5-4077-862D-A221CD88981D\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:envoyproxy:envoy:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"1.20.0\",\"versionEndExcluding\":\"1.20.2\",\"matchCriteriaId\":\"F5441B2D-F807-4ED9-AFB9-ED4DE07CE5F8\"}]}]}],\"references\":[{\"url\":\"https://github.com/envoyproxy/envoy/pull/630\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Patch\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Issue Tracking\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/envoyproxy/envoy/pull/630\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Issue Tracking\",\"Third Party Advisory\"]}]}}",
"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 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.
Loading…
Loading…