CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
2363 vulnerabilities reference this CWE, most recent first.
GHSA-25VQ-3GFH-MVJ7
Vulnerability from github – Published: 2022-05-13 01:35 – Updated: 2022-05-13 01:35A vulnerability in the Secure Sockets Layer (SSL) Virtual Private Network (VPN) Client Certificate Authentication feature for Cisco Adaptive Security Appliance (ASA) could allow an unauthenticated, remote attacker to establish an SSL VPN connection and bypass certain SSL certificate verification steps. The vulnerability is due to incorrect verification of the SSL Client Certificate. An attacker could exploit this vulnerability by connecting to the ASA VPN without a proper private key and certificate pair. A successful exploit could allow the attacker to establish an SSL VPN connection to the ASA when the connection should have been rejected. This vulnerability affects Cisco Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) Software that is running on the following Cisco products: 3000 Series Industrial Security Appliances (ISA), ASA 5500 Series Adaptive Security Appliances, ASA 5500-X Series Next-Generation Firewalls, ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers, Adaptive Security Virtual Appliances (ASAv), Firepower 4110 Security Appliances, Firepower 9300 ASA Security Modules. Cisco Bug IDs: CSCvg40155.
{
"affected": [],
"aliases": [
"CVE-2018-0227"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-19T20:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the Secure Sockets Layer (SSL) Virtual Private Network (VPN) Client Certificate Authentication feature for Cisco Adaptive Security Appliance (ASA) could allow an unauthenticated, remote attacker to establish an SSL VPN connection and bypass certain SSL certificate verification steps. The vulnerability is due to incorrect verification of the SSL Client Certificate. An attacker could exploit this vulnerability by connecting to the ASA VPN without a proper private key and certificate pair. A successful exploit could allow the attacker to establish an SSL VPN connection to the ASA when the connection should have been rejected. This vulnerability affects Cisco Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) Software that is running on the following Cisco products: 3000 Series Industrial Security Appliances (ISA), ASA 5500 Series Adaptive Security Appliances, ASA 5500-X Series Next-Generation Firewalls, ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers, Adaptive Security Virtual Appliances (ASAv), Firepower 4110 Security Appliances, Firepower 9300 ASA Security Modules. Cisco Bug IDs: CSCvg40155.",
"id": "GHSA-25vq-3gfh-mvj7",
"modified": "2022-05-13T01:35:33Z",
"published": "2022-05-13T01:35:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0227"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSA-18-184-01"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180418-asa1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104018"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1040723"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-26PG-X7G5-9G43
Vulnerability from github – Published: 2026-08-12 21:31 – Updated: 2026-08-12 21:31When an operator adds an HTTPS control plane profile to kumactl without providing a CA certificate, kumactl disables TLS verification and sends API tokens over the unverified connection.
An attacker on the network path between the operator and the control plane can intercept user or admin API tokens and then act against the control plane as that user.
{
"affected": [],
"aliases": [
"CVE-2026-18678"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-12T19:17:31Z",
"severity": "MODERATE"
},
"details": "When an operator adds an HTTPS control plane profile to kumactl without providing a CA certificate, kumactl disables TLS verification and sends API tokens over the unverified connection.\n\n\n\nAn attacker on the network path between the operator and the control plane can intercept user or admin API tokens and then act against the control plane as that user.",
"id": "GHSA-26pg-x7g5-9g43",
"modified": "2026-08-12T21:31:39Z",
"published": "2026-08-12T21:31:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kumahq/kuma/security/advisories/GHSA-v95x-xhq5-4929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18678"
},
{
"type": "WEB",
"url": "https://github.com/kumahq/kuma/pull/16777"
},
{
"type": "WEB",
"url": "https://developer.konghq.com/mesh/changelog"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-26Q9-378G-G2F7
Vulnerability from github – Published: 2023-11-13 18:30 – Updated: 2023-11-13 18:30Improper Certificate Validation in FotaAgent prior to SMR Nov-2023 Release1 allows remote attacker to intercept the network traffic including Firmware information.
{
"affected": [],
"aliases": [
"CVE-2023-42532"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-07T08:15:15Z",
"severity": "HIGH"
},
"details": "Improper Certificate Validation in FotaAgent prior to SMR Nov-2023 Release1 allows remote attacker to intercept the network traffic including Firmware information.",
"id": "GHSA-26q9-378g-g2f7",
"modified": "2023-11-13T18:30:59Z",
"published": "2023-11-13T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42532"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2023\u0026month=11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2727-QGH5-485G
Vulnerability from github – Published: 2022-05-24 16:59 – Updated: 2024-04-04 02:31It was discovered that Dovecot before versions 2.2.36.1 and 2.3.4.1 incorrectly handled client certificates. A remote attacker in possession of a valid certificate with an empty username field could possibly use this issue to impersonate other users.
{
"affected": [],
"aliases": [
"CVE-2019-3814"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-03-27T13:29:01Z",
"severity": "MODERATE"
},
"details": "It was discovered that Dovecot before versions 2.2.36.1 and 2.3.4.1 incorrectly handled client certificates. A remote attacker in possession of a valid certificate with an empty username field could possibly use this issue to impersonate other users.",
"id": "GHSA-2727-qgh5-485g",
"modified": "2024-04-04T02:31:18Z",
"published": "2022-05-24T16:59:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3814"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3467"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3814"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4XLI55NGRDTGMVOPYFCPPFNPA5VKYSSY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QHFZ5OWRIZGIWZJ5PTNVWWZNLLNH4XYS"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4XLI55NGRDTGMVOPYFCPPFNPA5VKYSSY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QHFZ5OWRIZGIWZJ5PTNVWWZNLLNH4XYS"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201904-19"
},
{
"type": "WEB",
"url": "https://www.dovecot.org/list/dovecot/2019-February/114575.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00067.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-272M-GCWP-MPWG
Vulnerability from github – Published: 2026-07-22 21:43 – Updated: 2026-07-22 21:43Summary
Netty's OcspClient does not validate that the CertificateID in an OCSP response matches the requested CertificateID. A bad actor can replay a GOOD status response issued for an unrelated certificate (by the same CA) to bypass revocation checks for any certificate.
Details
io.netty.handler.ssl.ocsp.OcspClient#validateResponse fails to assert that the CertificateID within the returned BasicOCSPResp matches the original certificate being validated.
When OcspClient.query(...) executes, it builds an OCSP request using the victim certificate's serial number and issuer hash. It then sends this request and receives a response. While the client verifies the signature of the response against the trusted issuer (or a valid responder chain), it never checks the CertificateID inside the response payload.
A bad actor who has access to any other valid, non-revoked certificate issued by the same CA can obtain a legitimately signed OCSP response indicating that the unrelated certificate is GOOD. The bad actor can then return this valid response to the Netty client when it queries the status of any other certificate (e.g., a revoked certificate) issued by the same CA. Because the signature is valid (signed by the CA) and the CertificateID is ignored, the client will incorrectly accept the target certificate as valid.
As per https://datatracker.ietf.org/doc/html/rfc6960#section-3.2 we have:
Prior to accepting a signed response for a particular certificate as
valid, OCSP clients SHALL confirm that:
1. The certificate identified in a received response corresponds to
the certificate that was identified in the corresponding request;
PoC
The following test case in io.netty.handler.ssl.ocsp.OcspClientTest demonstrates how the implementation accepts a forged OCSP response for a completely unrelated certificate, proving the bypass.
@Test
void testCertIdBypass() throws Exception {
X509Bundle caRoot = new CertificateBuilder()
.algorithm(CertificateBuilder.Algorithm.rsa2048)
.subject("CN=TrustedRootCA")
.setIsCertificateAuthority(true)
.buildSelfSigned();
GeneralName ocspName = new GeneralName(GeneralName.uniformResourceIdentifier, "http://localhost/");
AuthorityInformationAccess aia = new AuthorityInformationAccess(new AccessDescription(AccessDescription.id_ad_ocsp, ocspName));
X509Bundle targetCert = new CertificateBuilder()
.algorithm(CertificateBuilder.Algorithm.rsa2048)
.subject("CN=TargetServer")
.addExtensionOctetString("1.3.6.1.5.5.7.1.1", false, aia.getEncoded())
.buildIssuedBy(caRoot);
X509CertificateHolder caHolder = new JcaX509CertificateHolder(caRoot.getCertificate());
BasicOCSPResp forgedBasicResp = createBasicOcspResponse(caRoot, new X509CertificateHolder[]{caHolder});
OCSPResp forgedResponse = new OCSPRespBuilder().build(OCSPRespBuilder.SUCCESSFUL, forgedBasicResp);
byte[] forgedResponseEncoded = forgedResponse.getEncoded();
EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory());
try {
IoTransport transport = IoTransport.create(group.next(), () -> {
NioSocketChannel channel = new NioSocketChannel();
channel.pipeline().addFirst(new ChannelOutboundHandlerAdapter() {
@Override
public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) {
promise.setSuccess();
ctx.executor().execute(() -> {
ctx.pipeline().fireChannelActive();
DefaultFullHttpResponse httpResponse = new DefaultFullHttpResponse(
HttpVersion.HTTP_1_1, HttpResponseStatus.OK, Unpooled.wrappedBuffer(forgedResponseEncoded));
httpResponse.headers().set(HttpHeaderNames.CONTENT_TYPE, "application/ocsp-response");
httpResponse.headers().set(HttpHeaderNames.CONTENT_LENGTH, httpResponse.content().readableBytes());
ctx.pipeline().fireChannelRead(httpResponse);
});
}
});
return channel;
}, NioDatagramChannel::new);
DnsNameResolver resolver = OcspServerCertificateValidator.createDefaultResolver(transport);
Promise<BasicOCSPResp> promise = OcspClient.query(targetCert.getCertificate(), caRoot.getCertificate(), false, transport, resolver);
promise.await();
assertFalse(promise.isSuccess(),
"Netty incorrectly accepted the response for the unrelated certificate. The CertificateID was ignored!");
} finally {
group.shutdownGracefully();
}
}
Impact
Certificate Validation Bypass. Any application using Netty's OcspClient to check certificate revocation status is impacted.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler-ssl-ocsp"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler-ssl-ocsp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56820"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:43:31Z",
"nvd_published_at": "2026-07-21T23:17:52Z",
"severity": "HIGH"
},
"details": "### Summary\nNetty\u0027s OcspClient does not validate that the CertificateID in an OCSP response matches the requested CertificateID. A bad actor can replay a `GOOD` status response issued for an unrelated certificate (by the same CA) to bypass revocation checks for any certificate.\n\n### Details\n`io.netty.handler.ssl.ocsp.OcspClient#validateResponse` fails to assert that the CertificateID within the returned `BasicOCSPResp` matches the original certificate being validated.\n\nWhen `OcspClient.query(...)` executes, it builds an OCSP request using the victim certificate\u0027s serial number and issuer hash. It then sends this request and receives a response. While the client verifies the signature of the response against the trusted issuer (or a valid responder chain), it never checks the CertificateID inside the response payload.\n\nA bad actor who has access to any other valid, non-revoked certificate issued by the same CA can obtain a legitimately signed OCSP response indicating that the unrelated certificate is `GOOD`. The bad actor can then return this valid response to the Netty client when it queries the status of any other certificate (e.g., a revoked certificate) issued by the same CA. Because the signature is valid (signed by the CA) and the CertificateID is ignored, the client will incorrectly accept the target certificate as valid.\n\nAs per https://datatracker.ietf.org/doc/html/rfc6960#section-3.2 we have:\n\n```\nPrior to accepting a signed response for a particular certificate as\n valid, OCSP clients SHALL confirm that:\n\n 1. The certificate identified in a received response corresponds to\n the certificate that was identified in the corresponding request;\n```\n\n### PoC\nThe following test case in `io.netty.handler.ssl.ocsp.OcspClientTest` demonstrates how the implementation accepts a forged OCSP response for a completely unrelated certificate, proving the bypass.\n\n```java\n @Test\n void testCertIdBypass() throws Exception {\n X509Bundle caRoot = new CertificateBuilder()\n .algorithm(CertificateBuilder.Algorithm.rsa2048)\n .subject(\"CN=TrustedRootCA\")\n .setIsCertificateAuthority(true)\n .buildSelfSigned();\n\n GeneralName ocspName = new GeneralName(GeneralName.uniformResourceIdentifier, \"http://localhost/\");\n AuthorityInformationAccess aia = new AuthorityInformationAccess(new AccessDescription(AccessDescription.id_ad_ocsp, ocspName));\n X509Bundle targetCert = new CertificateBuilder()\n .algorithm(CertificateBuilder.Algorithm.rsa2048)\n .subject(\"CN=TargetServer\")\n .addExtensionOctetString(\"1.3.6.1.5.5.7.1.1\", false, aia.getEncoded())\n .buildIssuedBy(caRoot);\n\n X509CertificateHolder caHolder = new JcaX509CertificateHolder(caRoot.getCertificate());\n BasicOCSPResp forgedBasicResp = createBasicOcspResponse(caRoot, new X509CertificateHolder[]{caHolder});\n OCSPResp forgedResponse = new OCSPRespBuilder().build(OCSPRespBuilder.SUCCESSFUL, forgedBasicResp);\n byte[] forgedResponseEncoded = forgedResponse.getEncoded();\n\n EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory());\n try {\n IoTransport transport = IoTransport.create(group.next(), () -\u003e {\n NioSocketChannel channel = new NioSocketChannel();\n channel.pipeline().addFirst(new ChannelOutboundHandlerAdapter() {\n @Override\n public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) {\n promise.setSuccess();\n\n ctx.executor().execute(() -\u003e {\n ctx.pipeline().fireChannelActive();\n\n DefaultFullHttpResponse httpResponse = new DefaultFullHttpResponse(\n HttpVersion.HTTP_1_1, HttpResponseStatus.OK, Unpooled.wrappedBuffer(forgedResponseEncoded));\n httpResponse.headers().set(HttpHeaderNames.CONTENT_TYPE, \"application/ocsp-response\");\n httpResponse.headers().set(HttpHeaderNames.CONTENT_LENGTH, httpResponse.content().readableBytes());\n\n ctx.pipeline().fireChannelRead(httpResponse);\n });\n }\n });\n return channel;\n }, NioDatagramChannel::new);\n\n DnsNameResolver resolver = OcspServerCertificateValidator.createDefaultResolver(transport);\n Promise\u003cBasicOCSPResp\u003e promise = OcspClient.query(targetCert.getCertificate(), caRoot.getCertificate(), false, transport, resolver);\n\n promise.await();\n\n assertFalse(promise.isSuccess(),\n \"Netty incorrectly accepted the response for the unrelated certificate. The CertificateID was ignored!\");\n } finally {\n group.shutdownGracefully();\n }\n }\n```\n\n### Impact\nCertificate Validation Bypass. Any application using Netty\u0027s OcspClient to check certificate revocation status is impacted.",
"id": "GHSA-272m-gcwp-mpwg",
"modified": "2026-07-22T21:43:31Z",
"published": "2026-07-22T21:43:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-272m-gcwp-mpwg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56820"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/5b68c61f37aa4a3045cba624cbea239655c9003b"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/bb2ff68a1fb71cb4b0eb9a9e17b66c52aff680c6"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty: Missing CertificateID Validation in OCSP Response Allows Replay Attacks"
}
GHSA-273V-G3X4-R3RC
Vulnerability from github – Published: 2022-05-14 03:47 – Updated: 2022-11-01 22:01DefaultHostnameVerifier in Ldaptive (formerly vt-ldap) does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "edu.vt.middleware:vt-ldap"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.3.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "edu.internet2.middleware:shibboleth-identityprovider"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2014-3607"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-01T22:01:42Z",
"nvd_published_at": "2018-01-08T19:29:00Z",
"severity": "MODERATE"
},
"details": "DefaultHostnameVerifier in Ldaptive (formerly vt-ldap) does not properly verify that the server hostname matches a domain name in the subject\u0027s Common Name (CN) field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.",
"id": "GHSA-273v-g3x4-r3rc",
"modified": "2022-11-01T22:01:42Z",
"published": "2022-05-14T03:47:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-3607"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1140438"
},
{
"type": "WEB",
"url": "https://code.google.com/archive/p/vt-middleware/issues/226"
},
{
"type": "WEB",
"url": "https://code.google.com/archive/p/vt-middleware/issues/227"
},
{
"type": "WEB",
"url": "https://code.google.com/archive/p/vt-middleware/issues/228"
},
{
"type": "WEB",
"url": "https://code.google.com/archive/p/vt-middleware/source/default/commits"
},
{
"type": "WEB",
"url": "https://code.google.com/p/vt-middleware/source/detail?r=3046"
},
{
"type": "WEB",
"url": "http://shibboleth.net/community/advisories/secadv_20140919.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Improper Certificate Validation in vt-ldap"
}
GHSA-27HX-XQX9-P6HQ
Vulnerability from github – Published: 2026-09-18 15:32 – Updated: 2026-09-18 15:32rustls-webpki (the Rust webpki fork used by rustls) versions >= 0.101.0 and prior to 0.103.12 and 0.104.0-alpha.6 incorrectly accepted permitted-subtree DNS name constraints for certificates asserting a wildcard name. For example, a name constraint of accept.example.com was treated as satisfied by a certificate for *.example.com, which could feasibly assert reject.example.com — a name outside the permitted subtree. Because name constraints are restrictions applied to otherwise properly issued certificates, the issue is only reachable after signature verification succeeds and requires a misissued wildcard certificate to exploit.
{
"affected": [],
"aliases": [
"CVE-2026-93601"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-18T14:19:11Z",
"severity": "LOW"
},
"details": "rustls-webpki (the Rust webpki fork used by rustls) versions \u003e= 0.101.0 and prior to 0.103.12 and 0.104.0-alpha.6 incorrectly accepted permitted-subtree DNS name constraints for certificates asserting a wildcard name. For example, a name constraint of accept.example.com was treated as satisfied by a certificate for *.example.com, which could feasibly assert reject.example.com \u2014 a name outside the permitted subtree. Because name constraints are restrictions applied to otherwise properly issued certificates, the issue is only reachable after signature verification succeeds and requires a misissued wildcard certificate to exploit.",
"id": "GHSA-27hx-xqx9-p6hq",
"modified": "2026-09-18T15:32:18Z",
"published": "2026-09-18T15:32:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rustls/webpki/security/advisories/GHSA-xgp8-3hg3-c2mh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93601"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/rustls-webpki-0.101.0-before-0.103.12-name-constraint-bypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-27VH-G9XH-6MC8
Vulnerability from github – Published: 2022-05-24 17:26 – Updated: 2022-12-03 15:30In versions 15.0.0-15.1.0.1, 14.1.0-14.1.2.3, 13.1.0-13.1.3.4, 12.1.0-12.1.5.1, and 11.6.1-11.6.5.2, the BIG-IP Server SSL profile ignores revoked certificates, even when a valid CRL is present. This impacts server-side connections and may result in a man-in-the-middle attack on the connections.
{
"affected": [],
"aliases": [
"CVE-2020-5913"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-26T15:15:00Z",
"severity": "HIGH"
},
"details": "In versions 15.0.0-15.1.0.1, 14.1.0-14.1.2.3, 13.1.0-13.1.3.4, 12.1.0-12.1.5.1, and 11.6.1-11.6.5.2, the BIG-IP Server SSL profile ignores revoked certificates, even when a valid CRL is present. This impacts server-side connections and may result in a man-in-the-middle attack on the connections.",
"id": "GHSA-27vh-g9xh-6mc8",
"modified": "2022-12-03T15:30:27Z",
"published": "2022-05-24T17:26:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5913"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K72752002"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-285G-J3FH-F4RF
Vulnerability from github – Published: 2022-05-24 17:13 – Updated: 2022-05-24 17:13An issue was discovered in Pulse Secure Pulse Connect Secure (PCS) through 2020-04-06. The applet in tncc.jar, executed on macOS, Linux, and Solaris clients when a Host Checker policy is enforced, accepts an arbitrary SSL certificate.
{
"affected": [],
"aliases": [
"CVE-2020-11580"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-06T21:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Pulse Secure Pulse Connect Secure (PCS) through 2020-04-06. The applet in tncc.jar, executed on macOS, Linux, and Solaris clients when a Host Checker policy is enforced, accepts an arbitrary SSL certificate.",
"id": "GHSA-285g-j3fh-f4rf",
"modified": "2022-05-24T17:13:24Z",
"published": "2022-05-24T17:13:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11580"
},
{
"type": "WEB",
"url": "https://git.lsd.cat/g/pulse-host-checker-rce"
},
{
"type": "WEB",
"url": "https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44426"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-28G5-J6GH-P2VW
Vulnerability from github – Published: 2022-03-05 00:00 – Updated: 2022-03-22 00:01In spring cloud gateway versions prior to 3.1.1+ , applications that are configured to enable HTTP2 and no key store or trusted certificates are set will be configured to use an insecure TrustManager. This makes the gateway able to connect to remote services with invalid or custom certificates.
{
"affected": [],
"aliases": [
"CVE-2022-22946"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-04T16:15:00Z",
"severity": "MODERATE"
},
"details": "In spring cloud gateway versions prior to 3.1.1+ , applications that are configured to enable HTTP2 and no key store or trusted certificates are set will be configured to use an insecure TrustManager. This makes the gateway able to connect to remote services with invalid or custom certificates.",
"id": "GHSA-28g5-j6gh-p2vw",
"modified": "2022-03-22T00:01:14Z",
"published": "2022-03-05T00:00:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22946"
},
{
"type": "WEB",
"url": "https://tanzu.vmware.com/security/cve-2022-22946"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
Mitigation
If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.
CAPEC-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-475: Signature Spoofing by Improper Validation
An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.