{"vulnerability": "CVE-2022-21657", "sightings": [{"uuid": "64f1ca4a-f090-464d-ad06-1a228ba4ee36", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-21657", "type": "seen", "source": "https://t.me/cibsecurity/37917", "content": "\u203c CVE-2022-21657 \u203c\n\nEnvoy 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.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-02-23T02:13:01.000000Z"}]}