CVE-2022-21657: CWE-295: Improper Certificate Validation in envoyproxy envoy
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.
AI Analysis
Technical Summary
CVE-2022-21657 is a vulnerability in Envoy proxy versions prior to 1.20.2, 1.19.3, and 1.18.6, involving improper certificate validation (CWE-295). Envoy is a widely used open source edge and service proxy designed for cloud-native applications, often deployed in microservices architectures and service mesh environments. The vulnerability arises because Envoy does not properly restrict the set of certificates it accepts from peers during TLS handshakes. Specifically, Envoy fails to enforce that certificates presented by peers contain the appropriate extendedKeyUsage (EKU) attributes: id-kp-serverAuth for TLS servers and id-kp-clientAuth for TLS clients. Instead, Envoy accepts certificates with unrelated EKUs, such as id-kp-emailProtection, which are intended for S/MIME email protection. This flaw allows a peer to present an email certificate either as a leaf certificate or as a CA in the chain, and Envoy will erroneously accept it as valid for TLS authentication. The issue is exacerbated by a related problem (referenced in pull request #630) that allows Web PKI CAs, which are only audited for email certificates and not for TLS certificates, to issue certificates that Envoy will trust for TLS connections. Consequently, an attacker who can obtain such a certificate could impersonate legitimate upstream services or clients, potentially enabling man-in-the-middle (MitM) attacks, interception, or unauthorized access. No known workarounds exist, and the recommended remediation is to upgrade Envoy to a fixed version. There are no known exploits in the wild at this time, but the vulnerability poses a significant risk in environments relying on Envoy for secure communications.
Potential Impact
For European organizations, the improper certificate validation in Envoy can undermine the confidentiality and integrity of TLS-protected communications within cloud-native and microservices infrastructures. Organizations using Envoy as a service proxy or in service mesh deployments may be vulnerable to MitM attacks or unauthorized access if an attacker can present a misissued certificate with inappropriate EKUs. This could lead to data leakage, unauthorized command execution, or disruption of service integrity. Given the widespread adoption of Envoy in modern cloud environments, especially in sectors such as finance, telecommunications, and critical infrastructure, the impact could be substantial. Compromise of TLS trust could also affect compliance with GDPR and other data protection regulations, potentially resulting in legal and reputational consequences. The lack of workarounds increases the urgency of patching. While no active exploitation is reported, the vulnerability lowers the barrier for attackers to exploit certificate misissuance or weak CA controls, which are known issues in the Web PKI ecosystem.
Mitigation Recommendations
1. Immediate upgrade of Envoy to versions 1.20.2, 1.19.3, 1.18.6 or later where the certificate validation logic has been corrected. 2. Audit current Envoy deployments to identify affected versions and prioritize patching in high-risk environments such as public-facing proxies and critical internal service meshes. 3. Implement strict certificate pinning or validation policies where possible, including manual verification of EKUs in certificates used within internal PKI or trusted CA hierarchies. 4. Monitor certificate issuance from CAs trusted by Envoy, especially those issuing certificates with non-standard EKUs, to detect anomalous or unauthorized certificates. 5. Employ network-level monitoring and anomaly detection to identify unusual TLS handshake behaviors or unexpected certificate chains. 6. For organizations using Envoy in multi-tenant or hybrid cloud environments, segregate workloads and limit trust boundaries to reduce the blast radius of potential exploitation. 7. Engage with certificate authorities to ensure proper issuance policies and auditing, particularly for CAs issuing email certificates that could be misused. 8. Incorporate this vulnerability into threat modeling and incident response plans to prepare for potential exploitation scenarios.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Italy, Spain
CVE-2022-21657: CWE-295: Improper Certificate Validation in envoyproxy 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.
AI-Powered Analysis
Technical Analysis
CVE-2022-21657 is a vulnerability in Envoy proxy versions prior to 1.20.2, 1.19.3, and 1.18.6, involving improper certificate validation (CWE-295). Envoy is a widely used open source edge and service proxy designed for cloud-native applications, often deployed in microservices architectures and service mesh environments. The vulnerability arises because Envoy does not properly restrict the set of certificates it accepts from peers during TLS handshakes. Specifically, Envoy fails to enforce that certificates presented by peers contain the appropriate extendedKeyUsage (EKU) attributes: id-kp-serverAuth for TLS servers and id-kp-clientAuth for TLS clients. Instead, Envoy accepts certificates with unrelated EKUs, such as id-kp-emailProtection, which are intended for S/MIME email protection. This flaw allows a peer to present an email certificate either as a leaf certificate or as a CA in the chain, and Envoy will erroneously accept it as valid for TLS authentication. The issue is exacerbated by a related problem (referenced in pull request #630) that allows Web PKI CAs, which are only audited for email certificates and not for TLS certificates, to issue certificates that Envoy will trust for TLS connections. Consequently, an attacker who can obtain such a certificate could impersonate legitimate upstream services or clients, potentially enabling man-in-the-middle (MitM) attacks, interception, or unauthorized access. No known workarounds exist, and the recommended remediation is to upgrade Envoy to a fixed version. There are no known exploits in the wild at this time, but the vulnerability poses a significant risk in environments relying on Envoy for secure communications.
Potential Impact
For European organizations, the improper certificate validation in Envoy can undermine the confidentiality and integrity of TLS-protected communications within cloud-native and microservices infrastructures. Organizations using Envoy as a service proxy or in service mesh deployments may be vulnerable to MitM attacks or unauthorized access if an attacker can present a misissued certificate with inappropriate EKUs. This could lead to data leakage, unauthorized command execution, or disruption of service integrity. Given the widespread adoption of Envoy in modern cloud environments, especially in sectors such as finance, telecommunications, and critical infrastructure, the impact could be substantial. Compromise of TLS trust could also affect compliance with GDPR and other data protection regulations, potentially resulting in legal and reputational consequences. The lack of workarounds increases the urgency of patching. While no active exploitation is reported, the vulnerability lowers the barrier for attackers to exploit certificate misissuance or weak CA controls, which are known issues in the Web PKI ecosystem.
Mitigation Recommendations
1. Immediate upgrade of Envoy to versions 1.20.2, 1.19.3, 1.18.6 or later where the certificate validation logic has been corrected. 2. Audit current Envoy deployments to identify affected versions and prioritize patching in high-risk environments such as public-facing proxies and critical internal service meshes. 3. Implement strict certificate pinning or validation policies where possible, including manual verification of EKUs in certificates used within internal PKI or trusted CA hierarchies. 4. Monitor certificate issuance from CAs trusted by Envoy, especially those issuing certificates with non-standard EKUs, to detect anomalous or unauthorized certificates. 5. Employ network-level monitoring and anomaly detection to identify unusual TLS handshake behaviors or unexpected certificate chains. 6. For organizations using Envoy in multi-tenant or hybrid cloud environments, segregate workloads and limit trust boundaries to reduce the blast radius of potential exploitation. 7. Engage with certificate authorities to ensure proper issuance policies and auditing, particularly for CAs issuing email certificates that could be misused. 8. Incorporate this vulnerability into threat modeling and incident response plans to prepare for potential exploitation scenarios.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2021-11-16T00:00:00.000Z
- Cisa Enriched
- true
Threat ID: 682d9842c4522896dcbf244c
Added to database: 5/21/2025, 9:09:22 AM
Last enriched: 6/23/2025, 5:33:46 PM
Last updated: 8/18/2025, 2:23:30 AM
Views: 18
Related Threats
CVE-2025-53948: CWE-415 Double Free in Santesoft Sante PACS Server
HighCVE-2025-52584: CWE-122 Heap-based Buffer Overflow in Ashlar-Vellum Cobalt
HighCVE-2025-46269: CWE-122 Heap-based Buffer Overflow in Ashlar-Vellum Cobalt
HighCVE-2025-54862: CWE-79 Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') in Santesoft Sante PACS Server
MediumCVE-2025-54759: CWE-79 Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') in Santesoft Sante PACS Server
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.