CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
2053 vulnerabilities reference this CWE, most recent first.
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-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"
}
]
}
GHSA-28GG-8QQJ-FHH5
Vulnerability from github – Published: 2025-10-15 20:37 – Updated: 2025-10-15 20:37Impact
The GeoIP processor and Kafka source and buffer were using the deprecated "SSL" protocol identifier when creating SSL contexts, potentially allowing the use of insecure SSL protocols instead of modern TLS versions.
Multiple Data Prepper plugins used SSLContext.getInstance("SSL") which could potentially allow the use of deprecated SSL protocols (SSLv2, SSLv3) that have known security vulnerabilities. While modern Java implementations typically default to secure TLS versions even with the "SSL" identifier, explicitly using "TLS" ensures that only secure TLS protocols are negotiated.
The affected components were:
-
GeoIP Processor: The
DBSource.initiateSSL()method used for downloading GeoIP databases from external sources -
Kafka Plugin: Both
CustomClientSslEngineFactoryandInsecureSslEngineFactoryclasses used for Kafka client connections
This could potentially allow connections to negotiate weaker SSL protocols instead of enforcing modern TLS versions, reducing the security of data transmission.
Patches
Data Prepper 2.12.2 contains a fix for this issue.
Workarounds
If upgrading is not immediately possible:
- Ensure your Java runtime is configured to disable deprecated SSL protocols
- Use network-level controls to enforce TLS-only connections
- Use external tools to verify that deprecated SSL protocols are not allowed.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.opensearch.dataprepper.plugins:geoip-processor"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-15T20:37:29Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nThe GeoIP processor and Kafka source and buffer were using the deprecated \"SSL\" protocol identifier when creating SSL contexts, potentially allowing the use of insecure SSL protocols instead of modern TLS versions.\n\nMultiple Data Prepper plugins used `SSLContext.getInstance(\"SSL\")` which could potentially allow the use of deprecated SSL protocols (SSLv2, SSLv3) that have known security vulnerabilities. While modern Java implementations typically default to secure TLS versions even with the \"SSL\" identifier, explicitly using \"TLS\" ensures that only secure TLS protocols are negotiated.\n\nThe affected components were:\n\n* GeoIP Processor: The `DBSource.initiateSSL()` method used for downloading GeoIP databases from external sources\n\n* Kafka Plugin: Both `CustomClientSslEngineFactory` and `InsecureSslEngineFactory` classes used for Kafka client connections\n\nThis could potentially allow connections to negotiate weaker SSL protocols instead of enforcing modern TLS versions, reducing the security of data transmission.\n\n### Patches\n\nData Prepper 2.12.2 contains a fix for this issue.\n\n### Workarounds\n\nIf upgrading is not immediately possible:\n\n1. Ensure your Java runtime is configured to disable deprecated SSL protocols\n2. Use network-level controls to enforce TLS-only connections\n3. Use external tools to verify that deprecated SSL protocols are not allowed.",
"id": "GHSA-28gg-8qqj-fhh5",
"modified": "2025-10-15T20:37:29Z",
"published": "2025-10-15T20:37:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opensearch-project/data-prepper/security/advisories/GHSA-28gg-8qqj-fhh5"
},
{
"type": "WEB",
"url": "https://github.com/opensearch-project/data-prepper/commit/fa21a601512b5193c4b5c84a5b30c6301dab0475"
},
{
"type": "PACKAGE",
"url": "https://github.com/opensearch-project/data-prepper"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenSearch Data Prepper uses deprecated SSL protocol identifier"
}
GHSA-29PC-8VPC-XRWF
Vulnerability from github – Published: 2025-11-24 18:31 – Updated: 2025-11-24 18:31A firmware downgrade vulnerability exists in the OTA Update functionality of GL-Inet GL-AXT1800 4.7.0. A specially crafted .tar file can lead to a firmware downgrade. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2025-44018"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-24T16:15:49Z",
"severity": "HIGH"
},
"details": "A firmware downgrade vulnerability exists in the OTA Update functionality of GL-Inet GL-AXT1800 4.7.0. A specially crafted .tar file can lead to a firmware downgrade. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.",
"id": "GHSA-29pc-8vpc-xrwf",
"modified": "2025-11-24T18:31:12Z",
"published": "2025-11-24T18:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-44018"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2025-2230"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2025-2230"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-29QQ-5C29-C3WM
Vulnerability from github – Published: 2022-05-17 02:20 – Updated: 2022-05-17 02:20The Restaurant Karaoke SHIDAX app 1.3.3 and earlier on Android does not verify SSL certificates, which allows remote attackers to obtain sensitive information via a man-in-the-middle attack.
{
"affected": [],
"aliases": [
"CVE-2015-0904"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-25T18:29:00Z",
"severity": "MODERATE"
},
"details": "The Restaurant Karaoke SHIDAX app 1.3.3 and earlier on Android does not verify SSL certificates, which allows remote attackers to obtain sensitive information via a man-in-the-middle attack.",
"id": "GHSA-29qq-5c29-c3wm",
"modified": "2022-05-17T02:20:39Z",
"published": "2022-05-17T02:20:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-0904"
},
{
"type": "WEB",
"url": "http://jvn.jp/en/jp/JVN68819526/index.html"
},
{
"type": "WEB",
"url": "http://jvndb.jvn.jp/ja/contents/2015/JVNDB-2015-000049.html"
}
],
"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"
}
]
}
GHSA-2C24-V83Q-9PWP
Vulnerability from github – Published: 2025-06-26 21:31 – Updated: 2025-06-26 21:31A vulnerability exists in the IEC 61850 in MicroSCADA X SYS600 product. The certificate validation of the TLS protocol allows remote Man-in-the-Middle attack due to missing proper validation.
{
"affected": [],
"aliases": [
"CVE-2025-39205"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-24T13:15:22Z",
"severity": "HIGH"
},
"details": "A vulnerability exists in the IEC 61850 in MicroSCADA X SYS600 product. The certificate validation of the TLS protocol allows remote Man-in-the-Middle attack due to missing proper validation.",
"id": "GHSA-2c24-v83q-9pwp",
"modified": "2025-06-26T21:31:06Z",
"published": "2025-06-26T21:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39205"
},
{
"type": "WEB",
"url": "https://publisher.hitachienergy.com/preview?DocumentID=8DBD000218\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/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"
}
]
}
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.