Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

The product does not validate, or incorrectly validates, a certificate.

1905 vulnerabilities reference this CWE, most recent first.

GHSA-WR99-8G6H-68JX

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-05-24 19:07
VLAI
Details

A vulnerability has been identified in SINUMERIK Analyse MyCondition (All versions), SINUMERIK Analyze MyPerformance (All versions), SINUMERIK Analyze MyPerformance /OEE-Monitor (All versions), SINUMERIK Analyze MyPerformance /OEE-Tuning (All versions), SINUMERIK Integrate Client 02 (All versions >= V02.00.12 < 02.00.18), SINUMERIK Integrate Client 03 (All versions >= V03.00.12 < 03.00.18), SINUMERIK Integrate Client 04 (V04.00.02 and all versions >= V04.00.15 < 04.00.18), SINUMERIK Integrate for Production 4.1 (All versions < V4.1 SP10 HF3), SINUMERIK Integrate for Production 5.1 (V5.1), SINUMERIK Manage MyMachines (All versions), SINUMERIK Manage MyMachines /Remote (All versions), SINUMERIK Manage MyMachines /Spindel Monitor (All versions), SINUMERIK Manage MyPrograms (All versions), SINUMERIK Manage MyResources /Programs (All versions), SINUMERIK Manage MyResources /Tools (All versions), SINUMERIK Manage MyTools (All versions), SINUMERIK Operate V4.8 (All versions < V4.8 SP8), SINUMERIK Operate V4.93 (All versions < V4.93 HF7), SINUMERIK Operate V4.94 (All versions < V4.94 HF5), SINUMERIK Optimize MyProgramming /NX-Cam Editor (All versions). Due to an error in a third-party dependency the ssl flags used for setting up a TLS connection to a server are overwitten with wrong settings. This results in a missing validation of the server certificate and thus in a possible TLS MITM szenario.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-31892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-13T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SINUMERIK Analyse MyCondition (All versions), SINUMERIK Analyze MyPerformance (All versions), SINUMERIK Analyze MyPerformance /OEE-Monitor (All versions), SINUMERIK Analyze MyPerformance /OEE-Tuning (All versions), SINUMERIK Integrate Client 02 (All versions \u003e= V02.00.12 \u003c 02.00.18), SINUMERIK Integrate Client 03 (All versions \u003e= V03.00.12 \u003c 03.00.18), SINUMERIK Integrate Client 04 (V04.00.02 and all versions \u003e= V04.00.15 \u003c 04.00.18), SINUMERIK Integrate for Production 4.1 (All versions \u003c V4.1 SP10 HF3), SINUMERIK Integrate for Production 5.1 (V5.1), SINUMERIK Manage MyMachines (All versions), SINUMERIK Manage MyMachines /Remote (All versions), SINUMERIK Manage MyMachines /Spindel Monitor (All versions), SINUMERIK Manage MyPrograms (All versions), SINUMERIK Manage MyResources /Programs (All versions), SINUMERIK Manage MyResources /Tools (All versions), SINUMERIK Manage MyTools (All versions), SINUMERIK Operate V4.8 (All versions \u003c V4.8 SP8), SINUMERIK Operate V4.93 (All versions \u003c V4.93 HF7), SINUMERIK Operate V4.94 (All versions \u003c V4.94 HF5), SINUMERIK Optimize MyProgramming /NX-Cam Editor (All versions). Due to an error in a third-party dependency the ssl flags used for setting up a TLS connection to a server are overwitten with wrong settings. This results in a missing validation of the server certificate and thus in a possible TLS MITM szenario.",
  "id": "GHSA-wr99-8g6h-68jx",
  "modified": "2022-05-24T19:07:44Z",
  "published": "2022-05-24T19:07:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31892"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-729965.pdf"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-194-04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-WRGJ-7835-QFH2

Vulnerability from github – Published: 2026-01-29 06:30 – Updated: 2026-01-29 06:30
VLAI
Details

Multiple MFPs provided by Brother Industries, Ltd. does not properly validate server certificates, which may allow a man-in-the-middle attacker to replace the set of root certificates used by the product with a set of arbitrary certificates.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-53869"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-29T04:15:51Z",
    "severity": "MODERATE"
  },
  "details": "Multiple MFPs provided by Brother Industries, Ltd. does not properly validate server certificates, which may allow a man-in-the-middle attacker to replace the set of root certificates used by the product with a set of arbitrary certificates.",
  "id": "GHSA-wrgj-7835-qfh2",
  "modified": "2026-01-29T06:30:17Z",
  "published": "2026-01-29T06:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53869"
    },
    {
      "type": "WEB",
      "url": "https://faq.brother.co.jp/app/answers/detail/a_id/13716"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU92878805"
    },
    {
      "type": "WEB",
      "url": "https://www.konicaminolta.com/global-en/security/advisory/pdf/km-2026-0001.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.ricoh.com/products/security/vulnerabilities/vul?id=ricoh-2026-000001"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/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-WRMR-2JQG-XW9R

Vulnerability from github – Published: 2022-06-02 00:00 – Updated: 2022-06-09 00:00
VLAI
Details

Dell BSAFE Micro Edition Suite, versions prior to 4.5.1, contain an Improper Certificate Validation vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-26184"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-01T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "Dell BSAFE Micro Edition Suite, versions prior to 4.5.1, contain an Improper Certificate Validation vulnerability.",
  "id": "GHSA-wrmr-2jqg-xw9r",
  "modified": "2022-06-09T00:00:16Z",
  "published": "2022-06-02T00:00:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26184"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/article/en-us/sln322935/dsa-2020-245-dell-bsafe-micro-edition-suite-multiple-vulnerabilities?lang=en"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2022.html"
    }
  ],
  "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-WRPJ-755P-X363

Vulnerability from github – Published: 2026-03-31 00:31 – Updated: 2026-04-01 23:10
VLAI
Summary
Apache Airflow Provider for Databricks: TLS Certificate Verification is Disabled in Databricks Provider K8s Token Exchange
Details

Improper Certificate Validation vulnerability in Apache Airflow Provider for Databricks. Provider code did not validate certificates for connections to Databricks back-end which could result in a man-of-a-middle attack that traffic is intercepted and manipulated or credentials exfiltrated w/o notice.

This issue affects Apache Airflow Provider for Databricks: from 1.10.0 before 1.12.0.

Users are recommended to upgrade to version 1.12.0, which fixes the issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-airflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32794"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T23:10:14Z",
    "nvd_published_at": "2026-03-30T22:16:18Z",
    "severity": "MODERATE"
  },
  "details": "Improper Certificate Validation vulnerability in Apache Airflow Provider for Databricks. Provider code did not validate certificates for connections to Databricks back-end which could result in a man-of-a-middle attack that traffic is intercepted and manipulated or credentials exfiltrated w/o notice.\n\nThis issue affects Apache Airflow Provider for Databricks: from 1.10.0 before 1.12.0.\n\nUsers are recommended to upgrade to version 1.12.0, which fixes the issue.",
  "id": "GHSA-wrpj-755p-x363",
  "modified": "2026-04-01T23:10:14Z",
  "published": "2026-03-31T00:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32794"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/pull/63704"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/airflow"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/hn17yqsgsdtl81llvhf80rkp53hnz5nb"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/03/30/9"
    }
  ],
  "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": "Apache Airflow Provider for Databricks: TLS Certificate Verification is Disabled in Databricks Provider K8s Token Exchange"
}

GHSA-WRW6-8JH4-QVCX

Vulnerability from github – Published: 2026-06-25 18:30 – Updated: 2026-06-26 18:33
VLAI
Details

X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_cert() returned success based only on the last verified link rather than on reaching a trust anchor: when the supplied chain is deeper than the verifier's maximum path depth (default 100), path building runs out of depth while still walking untrusted intermediates and the chain is accepted even though it never reaches a configured trust anchor, allowing acceptance of an attacker-controlled certificate. The default TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only applications doing manual or deferred verification through this API are.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-11999"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T18:16:37Z",
    "severity": "HIGH"
  },
  "details": "X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_cert() returned success based only on the last verified link rather than on reaching a trust anchor: when the supplied chain is deeper than the verifier\u0027s maximum path depth (default 100), path building runs out of depth while still walking untrusted intermediates and the chain is accepted even though it never reaches a configured trust anchor, allowing acceptance of an attacker-controlled certificate. The default TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only applications doing manual or deferred verification through this API are.",
  "id": "GHSA-wrw6-8jh4-qvcx",
  "modified": "2026-06-26T18:33:48Z",
  "published": "2026-06-25T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11999"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wolfSSL/wolfssl/pull/10674"
    },
    {
      "type": "WEB",
      "url": "https://www.wolfssl.com/docs/security-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/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/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-WVMP-6R4V-J6CV

Vulnerability from github – Published: 2026-07-16 20:09 – Updated: 2026-07-16 20:09
VLAI
Summary
kuma-dp connects to control plane without verifying TLS certificate when no CA is configured
Details

When kuma-dp is started against an HTTPS control plane and the operator did not pass a CA certificate, the data plane connects with TLS peer verification disabled. The dataplane authentication token is sent over this unverified connection

Impact

An on-path attacker can intercept the dataplane authentication token and impersonate the control plane to the data plane, allowing them to inject a forged bootstrap configuration and take over the proxy

Affected configurations

  • Universal mode kuma-dp started against an HTTPS control plane without --ca-cert-file (or KUMA_CONTROL_PLANE_CA_CERT unset)

Not affected

  • Kubernetes installs done through the standard installers (kumactl install control-plane or the official Helm chart). In both cases the control plane's mutating admission webhook injects KUMA_CONTROL_PLANE_CA_CERT into every sidecar at pod admission, so each kuma-dp starts with the CA already configured

Workarounds

Set --ca-cert-file (or KUMA_CONTROL_PLANE_CA_CERT) on every Universal mode data plane and point it at the control plane's serving CA. Alternatively, terminate the control plane behind a publicly trusted certificate; the patched releases will verify successfully against the operating system trust store with no further configuration

Resources

  • Fix: https://github.com/kumahq/kuma/pull/16777
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kumahq/kuma/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kumahq/kuma/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.9.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kumahq/kuma/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.10.0"
            },
            {
              "fixed": "2.11.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kumahq/kuma/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.0"
            },
            {
              "fixed": "2.12.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kumahq/kuma/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.13.0"
            },
            {
              "fixed": "2.13.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kumahq/kuma"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52724"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-16T20:09:12Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "When kuma-dp is started against an HTTPS control plane and the operator did not pass a CA certificate, the data plane connects with TLS peer verification disabled. The dataplane authentication token is sent over this unverified connection\n\n## Impact\n\nAn on-path attacker can intercept the dataplane authentication token and impersonate the control plane to the data plane, allowing them to inject a forged bootstrap configuration and take over the proxy\n\n## Affected configurations\n\n- Universal mode `kuma-dp` started against an HTTPS control plane without `--ca-cert-file` (or `KUMA_CONTROL_PLANE_CA_CERT` unset)\n\n## Not affected\n\n- Kubernetes installs done through the standard installers (`kumactl install control-plane` or the official Helm chart). In both cases the control plane\u0027s mutating admission webhook injects `KUMA_CONTROL_PLANE_CA_CERT` into every sidecar at pod admission, so each `kuma-dp` starts with the CA already configured\n\n## Workarounds\n\nSet `--ca-cert-file` (or `KUMA_CONTROL_PLANE_CA_CERT`) on every Universal mode data plane and point it at the control plane\u0027s serving CA. Alternatively, terminate the control plane behind a publicly trusted certificate; the patched releases will verify successfully against the operating system trust store with no further configuration\n\n## Resources\n\n- Fix: https://github.com/kumahq/kuma/pull/16777",
  "id": "GHSA-wvmp-6r4v-j6cv",
  "modified": "2026-07-16T20:09:12Z",
  "published": "2026-07-16T20:09:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kumahq/kuma/security/advisories/GHSA-wvmp-6r4v-j6cv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kumahq/kuma/pull/16777"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kumahq/kuma/commit/2ecadac1aa2fd8cded4c2ab768949f4c2ec83e2a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kumahq/kuma"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "kuma-dp connects to control plane without verifying TLS certificate when no CA is configured"
}

GHSA-WW4W-R53V-2M63

Vulnerability from github – Published: 2022-05-17 00:28 – Updated: 2022-05-17 00:28
VLAI
Details

Rakuten card App for iOS 5.2.0 through 5.2.4 does not verify SSL certificates which might allow remote attackers to execute man-in-the-middle attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2015-2988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-10T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "Rakuten card App for iOS 5.2.0 through 5.2.4 does not verify SSL certificates which might allow remote attackers to execute man-in-the-middle attacks.",
  "id": "GHSA-ww4w-r53v-2m63",
  "modified": "2022-05-17T00:28:36Z",
  "published": "2022-05-17T00:28:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-2988"
    },
    {
      "type": "WEB",
      "url": "http://jvn.jp/en/jp/JVN81207766/index.html"
    },
    {
      "type": "WEB",
      "url": "http://jvndb.jvn.jp/en/contents/2015/JVNDB-2015-000120.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/76531"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WWRQ-59MQ-V8W2

Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-06-02 00:00
VLAI
Details

A flaw was found in stunnel before 5.57, where it improperly validates client certificates when it is configured to use both redirect and verifyChain options. This flaw allows an attacker with a certificate signed by a Certificate Authority, which is not the one accepted by the stunnel server, to access the tunneled service instead of being redirected to the address specified in the redirect option. The highest threat from this vulnerability is to confidentiality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-20230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-23T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in stunnel before 5.57, where it improperly validates client certificates when it is configured to use both redirect and verifyChain options. This flaw allows an attacker with a certificate signed by a Certificate Authority, which is not the one accepted by the stunnel server, to access the tunneled service instead of being redirected to the address specified in the redirect option. The highest threat from this vulnerability is to confidentiality.",
  "id": "GHSA-wwrq-59mq-v8w2",
  "modified": "2022-06-02T00:00:23Z",
  "published": "2022-05-24T17:42:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20230"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mtrojnar/stunnel/commit/ebad9ddc4efb2635f37174c9d800d06206f1edf9"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1925226"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202105-02"
    }
  ],
  "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-WXV5-Q299-W25J

Vulnerability from github – Published: 2025-10-15 15:30 – Updated: 2025-10-15 15:30
VLAI
Details

A vulnerability was reported in the Lenovo LeCloud client application that, under certain conditions, could allow information disclosure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-10699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-15T15:16:03Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was reported in the Lenovo LeCloud client application that, under certain conditions, could allow information disclosure.",
  "id": "GHSA-wxv5-q299-w25j",
  "modified": "2025-10-15T15:30:29Z",
  "published": "2025-10-15T15:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10699"
    },
    {
      "type": "WEB",
      "url": "https://iknow.lenovo.com.cn/detail/432379"
    },
    {
      "type": "WEB",
      "url": "https://lecloud.lenovo.com/index"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/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-WXVR-H7G5-RFC7

Vulnerability from github – Published: 2022-05-14 03:15 – Updated: 2025-04-12 13:04
VLAI
Details

The TLS protocol 1.2 and earlier supports the rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, and ecdsa_fixed_ecdh values for ClientCertificateType but does not directly document the ability to compute the master secret in certain situations with a client secret key and server public key but not a server secret key, which makes it easier for man-in-the-middle attackers to spoof TLS servers by leveraging knowledge of the secret key for an arbitrary installed client X.509 certificate, aka the "Key Compromise Impersonation (KCI)" issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2015-8960"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-09-21T02:59:00Z",
    "severity": "HIGH"
  },
  "details": "The TLS protocol 1.2 and earlier supports the rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, and ecdsa_fixed_ecdh values for ClientCertificateType but does not directly document the ability to compute the master secret in certain situations with a client secret key and server public key but not a server secret key, which makes it easier for man-in-the-middle attackers to spoof TLS servers by leveraging knowledge of the secret key for an arbitrary installed client X.509 certificate, aka the \"Key Compromise Impersonation (KCI)\" issue.",
  "id": "GHSA-wxvr-h7g5-rfc7",
  "modified": "2025-04-12T13:04:24Z",
  "published": "2022-05-14T03:15:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-8960"
    },
    {
      "type": "WEB",
      "url": "https://kcitls.org"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20180626-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf"
    },
    {
      "type": "WEB",
      "url": "http://twitter.com/matthew_d_green/statuses/630908726950674433"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2016/09/20/4"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/93071"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design Implementation

Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

Mitigation
Implementation

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.