CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
1908 vulnerabilities reference this CWE, most recent first.
GHSA-WC6F-CJCP-CC33
Vulnerability from github – Published: 2022-01-06 19:45 – Updated: 2021-05-25 20:27An issue was found in Apache IoTDB .9.0 to 0.9.1 and 0.8.0 to 0.8.2. When starting IoTDB, the JMX port 31999 is exposed with no certification.Then, clients could execute code remotely.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.iotdb:iotdb-parent"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-1952"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-25T20:27:25Z",
"nvd_published_at": "2020-04-27T17:15:00Z",
"severity": "HIGH"
},
"details": "An issue was found in Apache IoTDB .9.0 to 0.9.1 and 0.8.0 to 0.8.2. When starting IoTDB, the JMX port 31999 is exposed with no certification.Then, clients could execute code remotely.",
"id": "GHSA-wc6f-cjcp-cc33",
"modified": "2021-05-25T20:27:25Z",
"published": "2022-01-06T19:45:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1952"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3d2ff899ead64d2952fdc1fbb1f520ca42011ed2b4c7f786e921f6b9%40%3Cdev.iotdb.apache.org%3E"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Improper Certificate Validation in Apache IoTDB"
}
GHSA-WCFR-WFM2-2RJM
Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01An exploitable denial of service vulnerability exists within the reading of proprietary server certificates in FreeRDP 2.0.0-beta1+android11. A specially crafted challenge packet can cause the program termination leading to a denial of service condition. An attacker can compromise the server or use man in the middle to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2017-2836"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-24T19:29:00Z",
"severity": "MODERATE"
},
"details": "An exploitable denial of service vulnerability exists within the reading of proprietary server certificates in FreeRDP 2.0.0-beta1+android11. A specially crafted challenge packet can cause the program termination leading to a denial of service condition. An attacker can compromise the server or use man in the middle to trigger this vulnerability.",
"id": "GHSA-wcfr-wfm2-2rjm",
"modified": "2022-05-13T01:01:23Z",
"published": "2022-05-13T01:01:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2836"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2017/dsa-3923"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0338"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99942"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WCW9-6J3M-22M2
Vulnerability from github – Published: 2026-03-11 21:31 – Updated: 2026-03-11 21:31An improper certificate validation vulnerability was reported in the Lenovo Filez application that could allow a user capable of intercepting network traffic to execute arbitrary code.
{
"affected": [],
"aliases": [
"CVE-2026-2368"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T21:16:15Z",
"severity": "HIGH"
},
"details": "An improper certificate validation vulnerability was reported in the Lenovo Filez application that could allow a user capable of intercepting network traffic to execute arbitrary code.",
"id": "GHSA-wcw9-6j3m-22m2",
"modified": "2026-03-11T21:31:04Z",
"published": "2026-03-11T21:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2368"
},
{
"type": "WEB",
"url": "https://www.filez.com/securityPolicy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/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-WF9J-M9FV-92GQ
Vulnerability from github – Published: 2022-05-17 19:57 – Updated: 2024-10-08 12:56ovirt-engine-sdk-python before 3.4.0.7 and 3.5.0.4 does not verify that the hostname of the remote endpoint matches the Common Name (CN) or subjectAltName as specified by its x.509 certificate in a TLS/SSL session. This could allow man-in-the-middle attackers to spoof remote endpoints via an arbitrary valid certificate.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ovirt-engine-sdk-python"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "ovirt-engine-sdk-python"
},
"ranges": [
{
"events": [
{
"introduced": "3.5.0.0"
},
{
"fixed": "3.5.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2014-0161"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-19T17:37:44Z",
"nvd_published_at": "2020-01-02T18:15:00Z",
"severity": "HIGH"
},
"details": "ovirt-engine-sdk-python before 3.4.0.7 and 3.5.0.4 does not verify that the hostname of the remote endpoint matches the Common Name (CN) or subjectAltName as specified by its x.509 certificate in a TLS/SSL session. This could allow man-in-the-middle attackers to spoof remote endpoints via an arbitrary valid certificate.",
"id": "GHSA-wf9j-m9fv-92gq",
"modified": "2024-10-08T12:56:21Z",
"published": "2022-05-17T19:57:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-0161"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/cve-2014-0161"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-0161"
},
{
"type": "PACKAGE",
"url": "https://github.com/oVirt/python-ovirt-engine-sdk4"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/ovirt-engine-sdk-python/PYSEC-2020-245.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "ovirt-engine-sdk-python improper validation of hostname in x.509 certificate"
}
GHSA-WFQV-66VQ-46RM
Vulnerability from github – Published: 2026-02-19 22:09 – Updated: 2026-02-20 16:43Summary
When verifying artifact signatures using a certificate, Cosign first verifies the certificate chain using the leaf certificate's "not before" timestamp and later checks expiry of the leaf certificate using either a signed timestamp provided by the Rekor transparency log or from a timestamp authority, or using the current time. The root and all issuing certificates are assumed to be valid during the leaf certificate's validity. An issuing certificate with a validity that expires before the leaf certificate will be considered valid during verification even if the provided timestamp would mean the issuing certificate should be considered expired.
Impact
No impact to users of the public Sigstore infrastructure. This may affect private deployments with customized PKIs. In practice, this is unlikely to occur as CAs should not be issuing certificates that outlive the validity of the CA and its parents.
Workarounds
Upgrade to the latest release, or verify the certificate chain out of band.
Example to Reproduce
- Root CA certificate is valid from 12pm-2pm
- Intermediate CA certificate is valid from 12:30pm-1:30pm
- Leaf certificate is valid from 1pm-3pm - Note that this is unlikely to happen in practice, as a CA shouldn't issue a certificate that would be valid after the issuing CA certificate expires
- Signature generated at 2:30pm with a signed timestamp
- During verification, the leaf certificate's not before time (1pm) is used to verify the chain - 1pm is in the validity windows for the root and intermediate CA certificates
- The timestamp's time is checked to be in the validity window of only the leaf certificate - 2:30pm is in the validity window for the leaf
- Even though the root and intermediate would be expired at 2:30pm, verification succeeds
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.4"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/cosign"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24122"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-19T22:09:12Z",
"nvd_published_at": "2026-02-19T23:16:24Z",
"severity": "LOW"
},
"details": "## Summary\n\nWhen verifying artifact signatures using a certificate, Cosign first verifies the certificate chain using the leaf certificate\u0027s \"not before\" timestamp and later checks expiry of the leaf certificate using either a signed timestamp provided by the Rekor transparency log or from a timestamp authority, or using the current time. The root and all issuing certificates are assumed to be valid during the leaf certificate\u0027s validity. An issuing certificate with a validity that expires before the leaf certificate will be considered valid during verification even if the provided timestamp would mean the issuing certificate should be considered expired.\n\n## Impact\n\nNo impact to users of the public Sigstore infrastructure. This may affect private deployments with customized PKIs. In practice, this is unlikely to occur as CAs should not be issuing certificates that outlive the validity of the CA and its parents.\n\n## Workarounds\n\nUpgrade to the latest release, or verify the certificate chain out of band.\n\n## Example to Reproduce\n\n* Root CA certificate is valid from 12pm-2pm\n* Intermediate CA certificate is valid from 12:30pm-1:30pm\n* Leaf certificate is valid from 1pm-3pm - **Note that this is unlikely to happen in practice**, as a CA shouldn\u0027t issue a certificate that would be valid after the issuing CA certificate expires\n* Signature generated at 2:30pm with a signed timestamp\n* During verification, the leaf certificate\u0027s not before time (1pm) is used to verify the chain - 1pm is in the validity windows for the root and intermediate CA certificates\n* The timestamp\u0027s time is checked to be in the validity window of only the leaf certificate - 2:30pm is in the validity window for the leaf\n* Even though the root and intermediate would be expired at 2:30pm, verification succeeds",
"id": "GHSA-wfqv-66vq-46rm",
"modified": "2026-02-20T16:43:55Z",
"published": "2026-02-19T22:09:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/security/advisories/GHSA-wfqv-66vq-46rm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24122"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/commit/3c9a7363f563db76d78e2de2cabd945450f3781e"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/cosign"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/releases/tag/v3.0.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Cosign considered signatures valid with expired intermediate certificates when transparency log verification is skipped"
}
GHSA-WFR5-454P-MJC2
Vulnerability from github – Published: 2026-05-08 20:48 – Updated: 2026-06-08 23:34Summary
The OpenTelemetry.Exporter.Instana NuGet package does not validate HTTPS/TLS certificates are valid when sending telemetry to a configured Instana back-end when a proxy is configured using the INSTANA_ENDPOINT_PROXY environment variable.
If a network attacker can Man-in-the-Middle (MitM) the proxy connection, all OpenTelemetry telemetry data and the Instana API key are exposed to the attacker.
Details
The Transport.ConfigureBackendClient() method creates an HttpClient instance that completely disables TLS server certificate validation if the INSTANA_ENDPOINT_PROXY is configured with a valid proxy URL with no ability to re-enable it.
Impact
If the configured proxy is attacker-controlled (or a network attacker MitM the connection), or if it is possible for the process' configuration to be changed to add an attacker-provided value for INSTANA_ENDPOINT_PROXY then all Instana telemetry could be read by an unauthorized party and the service's Instana API key compromised, potentially before being forwarded to Instana presenting no noticeable loss of telemetry data without a valid TLS server certificate being presented to the client that matches the expected hostname or IP address.
Mitigation
The proxy configured by the INSTANA_ENDPOINT_PROXY environment variable must be malicious or be possible to be subject to a MitM attack.
Workarounds
Do not configure the INSTANA_ENDPOINT_PROXY environment variable.
Remediation
#4153 refactors HttpClient creation so that TLS certificate validation is no longer disabled by default when using a proxy.
In environments where this capability is required, for example for local development, the previous behaviour can be restored using the `` option:
builder.AddInstanaExporter((options) =>
{
options.HttpClientFactory = () =>
{
var handler = new HttpClientHandler()
{
#if NET
ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator,
#else
ServerCertificateCustomValidationCallback = static (_, _, _, _) => true,
#endif
};
return new HttpClient(handler, disposeHandler: true);
};
});
Resources
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.7"
},
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Exporter.Instana"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44213"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T20:48:02Z",
"nvd_published_at": "2026-05-26T22:16:42Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe `OpenTelemetry.Exporter.Instana` NuGet package does not validate HTTPS/TLS certificates are valid when sending telemetry to a configured Instana back-end when a proxy is configured using the `INSTANA_ENDPOINT_PROXY` environment variable.\n\nIf a network attacker can Man-in-the-Middle (MitM) the proxy connection, all OpenTelemetry telemetry data and the Instana API key are exposed to the attacker.\n\n### Details\n\nThe [`Transport.ConfigureBackendClient()`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/b53b6a74fde21a4cee344e584b51a0fe5bf1f337/src/OpenTelemetry.Exporter.Instana/Implementation/Transport.cs#L132-L158) method creates an `HttpClient` instance that completely disables TLS server certificate validation if the `INSTANA_ENDPOINT_PROXY` is configured with a valid proxy URL with no ability to re-enable it.\n\n### Impact\n\nIf the configured proxy is attacker-controlled (or a network attacker MitM the connection), or if it is possible for the process\u0027 configuration to be changed to add an attacker-provided value for `INSTANA_ENDPOINT_PROXY` then all Instana telemetry could be read by an unauthorized party and the service\u0027s Instana API key compromised, potentially before being forwarded to Instana presenting no noticeable loss of telemetry data without a valid TLS server certificate being presented to the client that matches the expected hostname or IP address.\n\n### Mitigation\n\nThe proxy configured by the `INSTANA_ENDPOINT_PROXY` environment variable must be malicious or be possible to be subject to a MitM attack.\n\n### Workarounds\n\nDo not configure the `INSTANA_ENDPOINT_PROXY` environment variable.\n\n### Remediation\n\n[#4153](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153) refactors `HttpClient` creation so that TLS certificate validation is no longer disabled by default when using a proxy.\n\nIn environments where this capability is required, for example for local development, the previous behaviour can be restored using the `` option:\n\n```csharp\nbuilder.AddInstanaExporter((options) =\u003e\n{\n options.HttpClientFactory = () =\u003e\n {\n var handler = new HttpClientHandler()\n {\n#if NET\n ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator,\n#else\n ServerCertificateCustomValidationCallback = static (_, _, _, _) =\u003e true,\n#endif\n };\n return new HttpClient(handler, disposeHandler: true);\n };\n});\n```\n\n### Resources\n\n- [PR #4153](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153)",
"id": "GHSA-wfr5-454p-mjc2",
"modified": "2026-06-08T23:34:50Z",
"published": "2026-05-08T20:48:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-wfr5-454p-mjc2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44213"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenTelemetry.Exporter.Instana bypasses TLS certificate validation when a proxy is configured"
}
GHSA-WG96-RRCF-J3MH
Vulnerability from github – Published: 2025-05-20 15:30 – Updated: 2025-05-20 15:30IBM Security ReaQta EDR 3.12 could allow an attacker to spoof a trusted entity by interfering with the communication path between the host and client.
{
"affected": [],
"aliases": [
"CVE-2023-33861"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T15:15:52Z",
"severity": "MODERATE"
},
"details": "IBM Security ReaQta EDR 3.12 could allow an attacker to spoof a trusted entity by interfering with the communication path between the host and client.",
"id": "GHSA-wg96-rrcf-j3mh",
"modified": "2025-05-20T15:30:41Z",
"published": "2025-05-20T15:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33861"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7233972"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WGR2-97VR-J8X2
Vulnerability from github – Published: 2023-07-06 15:30 – Updated: 2024-04-04 05:26A misconfiguration vulnerability exists in the urvpn_client functionality of Milesight UR32L v32.3.0.5. A specially-crafted man-in-the-middle attack can lead to increased privileges. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2023-23546"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-06T15:15:11Z",
"severity": "HIGH"
},
"details": "A misconfiguration vulnerability exists in the urvpn_client functionality of Milesight UR32L v32.3.0.5. A specially-crafted man-in-the-middle attack can lead to increased privileges. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.",
"id": "GHSA-wgr2-97vr-j8x2",
"modified": "2024-04-04T05:26:47Z",
"published": "2023-07-06T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23546"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1705"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WH57-PFPG-3FFF
Vulnerability from github – Published: 2022-05-14 01:37 – Updated: 2022-05-14 01:37Multiple +Message Apps (Softbank +Message App for Android prior to version 10.1.7, Softbank +Message App for iOS prior to version 1.1.23, NTT DOCOMO +Message App for Android prior to version 42.40.2800, NTT DOCOMO +Message App for iOS prior to version 1.1.23, KDDI +Message App for Android prior to version 1.0.6, and KDDI +Message App for iOS prior to version 1.1.23) do not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.
{
"affected": [],
"aliases": [
"CVE-2018-0691"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-15T15:29:00Z",
"severity": "MODERATE"
},
"details": "Multiple +Message Apps (Softbank +Message App for Android prior to version 10.1.7, Softbank +Message App for iOS prior to version 1.1.23, NTT DOCOMO +Message App for Android prior to version 42.40.2800, NTT DOCOMO +Message App for iOS prior to version 1.1.23, KDDI +Message App for Android prior to version 1.0.6, and KDDI +Message App for iOS prior to version 1.1.23) do not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.",
"id": "GHSA-wh57-pfpg-3fff",
"modified": "2022-05-14T01:37:00Z",
"published": "2022-05-14T01:37:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0691"
},
{
"type": "WEB",
"url": "https://www.au.com/information/notice_mobile/service/2018-002"
},
{
"type": "WEB",
"url": "https://www.nttdocomo.co.jp/info/notice/page/180927_00.html"
},
{
"type": "WEB",
"url": "https://www.softbank.jp/mobile/info/personal/news/service/20180927a"
},
{
"type": "WEB",
"url": "http://jvn.jp/en/jp/JVN37288228/index.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-WHX9-2VF8-4HVM
Vulnerability from github – Published: 2024-06-29 06:31 – Updated: 2025-11-04 00:30IBM Cognos Analytics 11.2.0, 11.2.1, 11.2.2, 11.2.3, 11.2.4, 12.0.0, 12.0.1, and 12.0.2 is vulnerable to improper certificate validation when using the IBM Planning Analytics Data Source Connection. This could allow an attacker to spoof a trusted entity by interfering in the communication path between IBM Planning Analytics server and IBM Cognos Analytics server. IBM X-Force ID: 283364.
{
"affected": [],
"aliases": [
"CVE-2024-25053"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-28T19:15:04Z",
"severity": "MODERATE"
},
"details": "IBM Cognos Analytics 11.2.0, 11.2.1, 11.2.2, 11.2.3, 11.2.4, 12.0.0, 12.0.1, and 12.0.2 is vulnerable to improper certificate validation when using the IBM Planning Analytics Data Source Connection. This could allow an attacker to spoof a trusted entity by interfering in the communication path between IBM Planning Analytics server and IBM Cognos Analytics server. IBM X-Force ID: 283364.",
"id": "GHSA-whx9-2vf8-4hvm",
"modified": "2025-11-04T00:30:50Z",
"published": "2024-06-29T06:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25053"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/283364"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241108-0002"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7156941"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/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.