Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

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

2267 vulnerabilities reference this CWE, most recent first.

GHSA-VP9F-WMXX-376H

Vulnerability from github – Published: 2022-05-17 02:45 – Updated: 2025-04-20 03:37
VLAI
Details

The State Bank of India State Bank Anywhere app 5.1.0 for iOS does 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.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-5901"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-05T07:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The State Bank of India State Bank Anywhere app 5.1.0 for iOS does 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-vp9f-wmxx-376h",
  "modified": "2025-04-20T03:37:14Z",
  "published": "2022-05-17T02:45:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5901"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/%40chronic_9612/follow-up-76-popular-apps-confirmed-vulnerable-to-silent-interception-of-tls-protected-data-64185035029f"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@chronic_9612/follow-up-76-popular-apps-confirmed-vulnerable-to-silent-interception-of-tls-protected-data-64185035029f"
    }
  ],
  "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-VQ58-8WP2-WC83

Vulnerability from github – Published: 2025-05-07 18:30 – Updated: 2025-05-07 18:30
VLAI
Details

A vulnerability in certificate validation processing of Cisco Catalyst SD-WAN Manager, formerly Cisco SD-WAN vManage, could allow an unauthenticated, remote attacker to gain access to sensitive information.

This vulnerability is due to improper validation of certificates that are used by the Smart Licensing feature. An attacker with a privileged network position could exploit this vulnerability by intercepting traffic that is sent over the Internet. A successful exploit could allow the attacker to gain access to sensitive information, including credentials used by the device to connect to Cisco cloud services.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-20157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-07T18:15:37Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in certificate validation processing of Cisco Catalyst SD-WAN Manager, formerly Cisco SD-WAN vManage, could allow an unauthenticated, remote attacker to gain access to sensitive information.\n\nThis vulnerability is due to improper validation of certificates that are used by the Smart Licensing feature. An attacker with a privileged network position could exploit this vulnerability by intercepting traffic that is sent over the Internet. A successful exploit could allow the attacker to gain access to sensitive information, including credentials used by the device to connect to Cisco cloud services.",
  "id": "GHSA-vq58-8wp2-wc83",
  "modified": "2025-05-07T18:30:48Z",
  "published": "2025-05-07T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20157"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-catalyst-tls-PqnD5KEJ"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQ7P-F4FV-RR5X

Vulnerability from github – Published: 2022-05-14 03:23 – Updated: 2022-12-12 21:29
VLAI
Summary
Jenkins vSphere Plugin disables SSL/TLS certificate validation by default
Details

A man in the middle vulnerability exists in Jenkins vSphere Plugin 2.16 and older in VSphere.java that disables SSL/TLS certificate validation by default. vSphere Plugin 2.17 now has SSL/TLS certificate validation enabled by default.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.16"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:vsphere-cloud"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-1000151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-12T21:29:46Z",
    "nvd_published_at": "2018-04-05T13:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A man in the middle vulnerability exists in Jenkins vSphere Plugin 2.16 and older in VSphere.java that disables SSL/TLS certificate validation by default. vSphere Plugin 2.17 now has SSL/TLS certificate validation enabled by default.",
  "id": "GHSA-vq7p-f4fv-rr5x",
  "modified": "2022-12-12T21:29:46Z",
  "published": "2022-05-14T03:23:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000151"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/vsphere-cloud-plugin/commit/f0fb143af340c7529dd9e50f5514334756019356"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/vsphere-cloud-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2018-03-26/#SECURITY-504"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins vSphere Plugin disables SSL/TLS certificate validation by default"
}

GHSA-VQHR-M87Q-9JQH

Vulnerability from github – Published: 2026-01-08 12:30 – Updated: 2026-01-08 15:31
VLAI
Details

When doing TLS related transfers with reused easy or multi handles and altering the CURLSSLOPT_NO_PARTIALCHAIN option, libcurl could accidentally reuse a CA store cached in memory for which the partial chain option was reversed. Contrary to the user's wishes and expectations. This could make libcurl find and accept a trust chain that it otherwise would not.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-14819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-08T10:15:46Z",
    "severity": "MODERATE"
  },
  "details": "When doing TLS related transfers with reused easy or multi handles and\naltering the  `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally\nreuse a CA store cached in memory for which the partial chain option was\nreversed. Contrary to the user\u0027s wishes and expectations. This could make\nlibcurl find and accept a trust chain that it otherwise would not.",
  "id": "GHSA-vqhr-m87q-9jqh",
  "modified": "2026-01-08T15:31:25Z",
  "published": "2026-01-08T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14819"
    },
    {
      "type": "WEB",
      "url": "https://curl.se/docs/CVE-2025-14819.html"
    },
    {
      "type": "WEB",
      "url": "https://curl.se/docs/CVE-2025-14819.json"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/01/07/5"
    }
  ],
  "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"
    }
  ]
}

GHSA-VQJM-CH4V-X2F4

Vulnerability from github – Published: 2024-09-18 21:30 – Updated: 2024-09-18 21:30
VLAI
Details

Anbox Management Service, in versions 1.17.0 through 1.23.0, does not validate the TLS certificate provided to it by the Anbox Stream Agent. An attacker must be able to machine-in-the-middle the Anbox Stream Agent from within an internal network before they can attempt to take advantage of this.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-8287"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-18T19:15:41Z",
    "severity": "HIGH"
  },
  "details": "Anbox Management Service, in versions 1.17.0 through 1.23.0, does not validate the TLS certificate provided to it by the Anbox Stream Agent. An attacker must be able to machine-in-the-middle the Anbox Stream Agent from within an internal network before they can attempt to take advantage of this.",
  "id": "GHSA-vqjm-ch4v-x2f4",
  "modified": "2024-09-18T21:30:48Z",
  "published": "2024-09-18T21:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8287"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/anbox-cloud/+bug/2077570"
    },
    {
      "type": "WEB",
      "url": "https://discourse.ubuntu.com/t/anbox-cloud-1-23-1-has-been-released/48141"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-8287"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQVM-4FM4-4H2W

Vulnerability from github – Published: 2024-05-31 18:31 – Updated: 2025-11-04 00:30
VLAI
Details

IBM Security Verify Access Docker 10.0.0 through 10.0.6 could allow a local user to escalate their privileges due to improper certificate validation. IBM X-Force ID: 292416.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-35140"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-31T17:15:08Z",
    "severity": "HIGH"
  },
  "details": "IBM Security Verify Access Docker 10.0.0 through 10.0.6 could allow a local user to escalate their privileges due to improper certificate validation.  IBM X-Force ID:  292416.",
  "id": "GHSA-vqvm-4fm4-4h2w",
  "modified": "2025-11-04T00:30:49Z",
  "published": "2024-05-31T18:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35140"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/292416"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7155356"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Nov/0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VR7C-R5GJ-J3W5

Vulnerability from github – Published: 2026-05-06 18:48 – Updated: 2026-05-13 16:41
VLAI
Summary
Lemur: LDAP Authentication Globally Disables TLS Certificate Verification When LDAP_USE_TLS Is Enabled
Details

Description

Overview

When LDAP TLS is enabled (LDAP_USE_TLS = True), Lemur's LDAP authentication module unconditionally disables TLS certificate verification at the global ldap module level. This allows a man-in-the-middle attacker positioned between Lemur and the LDAP server to intercept all authentication credentials.

Vulnerable Code

Location: lemur/auth/ldap.py, _bind() method, line ~172

if self.ldap_use_tls:
    ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)

Key issues:

  1. ldap.set_option() is a global call (as opposed to self.ldap_client.set_option()), meaning it disables TLS verification for the entire Python process, not just this connection
  2. OPT_X_TLS_NEVER means no certificate validation is performed whatsoever — self-signed, expired, wrong hostname, and revoked certificates are all silently accepted
  3. There is no configuration option to override this behavior — TLS verification is always disabled when TLS is enabled

Impact

A network-positioned attacker (man-in-the-middle) between Lemur and the LDAP server can:

  • Intercept all LDAP credentials (usernames and plaintext passwords) for every user who authenticates
  • Modify LDAP responses to inject arbitrary group memberships, granting admin access
  • Compromise the entire PKI infrastructure managed by Lemur, since authentication controls access to certificates and private keys

This is particularly severe because Lemur is a certificate management system — the tool designed to manage TLS security is itself vulnerable to a TLS attack.

Steps to Reproduce

  1. Deploy Lemur with LDAP TLS enabled: python LDAP_AUTH = True LDAP_USE_TLS = True LDAP_BIND_URI = "ldaps://dc.corp.example.com"

  2. Intercept the LDAP connection using a TLS proxy (e.g., mitmproxy or stunnel): ```bash # Generate a self-signed certificate openssl req -x509 -newkey rsa:2048 -keyout mitm.key -out mitm.crt -days 1 -nodes -subj "/CN=mitm"

# Proxy LDAP traffic stunnel -d 0.0.0.0:636 -r real-ldap-server:636 -p mitm.pem ```

  1. Point Lemur's LDAP_BIND_URI at the proxy (or perform ARP spoofing/DNS hijacking)

  2. Observe that Lemur connects without any certificate verification error

  3. All credentials are visible in the proxy's TLS session

Remediation

Remove the global TLS verification bypass and default to strict verification:

if self.ldap_use_tls:
    # Use instance-level option, not global
    self.ldap_client.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_DEMAND)
    self.ldap_client.set_option(ldap.OPT_PROTOCOL_VERSION, 3)
    if self.ldap_cacert_file:
        self.ldap_client.set_option(ldap.OPT_X_TLS_CACERTFILE, self.ldap_cacert_file)

If backward compatibility is needed, make it configurable with a secure default:

tls_require_cert = current_app.config.get("LDAP_TLS_REQUIRE_CERT", ldap.OPT_X_TLS_DEMAND)
self.ldap_client.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, tls_require_cert)

Resources

  • CWE-295: https://cwe.mitre.org/data/definitions/295.html
  • python-ldap TLS documentation: https://www.python-ldap.org/en/python-ldap-3.4.0/reference/ldap.html#tls-options
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lemur"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T18:48:12Z",
    "nvd_published_at": "2026-05-12T22:16:37Z",
    "severity": "MODERATE"
  },
  "details": "## Description\n\n### Overview\n\nWhen LDAP TLS is enabled (`LDAP_USE_TLS = True`), Lemur\u0027s LDAP authentication module unconditionally disables TLS certificate verification at the **global** `ldap` module level. This allows a man-in-the-middle attacker positioned between Lemur and the LDAP server to intercept all authentication credentials.\n\n### Vulnerable Code\n\n**Location:** `lemur/auth/ldap.py`, `_bind()` method, line ~172\n\n```python\nif self.ldap_use_tls:\n    ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)\n```\n\nKey issues:\n\n1. `ldap.set_option()` is a **global** call (as opposed to `self.ldap_client.set_option()`), meaning it disables TLS verification for the entire Python process, not just this connection\n2. `OPT_X_TLS_NEVER` means no certificate validation is performed whatsoever \u2014 self-signed, expired, wrong hostname, and revoked certificates are all silently accepted\n3. There is no configuration option to override this behavior \u2014 TLS verification is always disabled when TLS is enabled\n\n### Impact\n\nA network-positioned attacker (man-in-the-middle) between Lemur and the LDAP server can:\n\n- **Intercept all LDAP credentials** (usernames and plaintext passwords) for every user who authenticates\n- **Modify LDAP responses** to inject arbitrary group memberships, granting admin access\n- **Compromise the entire PKI infrastructure** managed by Lemur, since authentication controls access to certificates and private keys\n\nThis is particularly severe because Lemur is a certificate management system \u2014 the tool designed to manage TLS security is itself vulnerable to a TLS attack.\n\n### Steps to Reproduce\n\n1. Deploy Lemur with LDAP TLS enabled:\n   ```python\n   LDAP_AUTH = True\n   LDAP_USE_TLS = True\n   LDAP_BIND_URI = \"ldaps://dc.corp.example.com\"\n   ```\n\n2. Intercept the LDAP connection using a TLS proxy (e.g., `mitmproxy` or `stunnel`):\n   ```bash\n   # Generate a self-signed certificate\n   openssl req -x509 -newkey rsa:2048 -keyout mitm.key -out mitm.crt -days 1 -nodes -subj \"/CN=mitm\"\n\n   # Proxy LDAP traffic\n   stunnel -d 0.0.0.0:636 -r real-ldap-server:636 -p mitm.pem\n   ```\n\n3. Point Lemur\u0027s `LDAP_BIND_URI` at the proxy (or perform ARP spoofing/DNS hijacking)\n\n4. Observe that Lemur connects without any certificate verification error\n\n5. All credentials are visible in the proxy\u0027s TLS session\n\n### Remediation\n\nRemove the global TLS verification bypass and default to strict verification:\n\n```python\nif self.ldap_use_tls:\n    # Use instance-level option, not global\n    self.ldap_client.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_DEMAND)\n    self.ldap_client.set_option(ldap.OPT_PROTOCOL_VERSION, 3)\n    if self.ldap_cacert_file:\n        self.ldap_client.set_option(ldap.OPT_X_TLS_CACERTFILE, self.ldap_cacert_file)\n```\n\nIf backward compatibility is needed, make it configurable with a secure default:\n\n```python\ntls_require_cert = current_app.config.get(\"LDAP_TLS_REQUIRE_CERT\", ldap.OPT_X_TLS_DEMAND)\nself.ldap_client.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, tls_require_cert)\n```\n\n### Resources\n\n- CWE-295: https://cwe.mitre.org/data/definitions/295.html\n- python-ldap TLS documentation: https://www.python-ldap.org/en/python-ldap-3.4.0/reference/ldap.html#tls-options",
  "id": "GHSA-vr7c-r5gj-j3w5",
  "modified": "2026-05-13T16:41:37Z",
  "published": "2026-05-06T18:48:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-vr7c-r5gj-j3w5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44305"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Netflix/lemur"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/releases/tag/v1.9.0"
    },
    {
      "type": "WEB",
      "url": "https://www.python-ldap.org/en/python-ldap-3.4.0/reference/ldap.html#tls-options"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lemur: LDAP Authentication Globally Disables TLS Certificate Verification When LDAP_USE_TLS Is Enabled"
}

GHSA-VRHJ-MRVH-X542

Vulnerability from github – Published: 2022-05-13 01:10 – Updated: 2022-05-13 01:10
VLAI
Details

MaLion for Mac 4.3.0 to 5.2.1 does not properly validate certificates, which may allow an attacker to eavesdrop on an encrypted communication.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-10819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-08-04T16:29:00Z",
    "severity": "MODERATE"
  },
  "details": "MaLion for Mac 4.3.0 to 5.2.1 does not properly validate certificates, which may allow an attacker to eavesdrop on an encrypted communication.",
  "id": "GHSA-vrhj-mrvh-x542",
  "modified": "2022-05-13T01:10:04Z",
  "published": "2022-05-13T01:10:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10819"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU91587298/index.html"
    },
    {
      "type": "WEB",
      "url": "http://www.intercom.co.jp/information/2017/0801.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VRP5-7HMM-J77F

Vulnerability from github – Published: 2022-05-14 02:02 – Updated: 2022-05-14 02:02
VLAI
Details

Adobe Creative Cloud Desktop Application before 4.6.1 has an improper certificate validation vulnerability. Successful exploitation could lead to privilege escalation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-12829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-29T13:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Adobe Creative Cloud Desktop Application before 4.6.1 has an improper certificate validation vulnerability. Successful exploitation could lead to privilege escalation.",
  "id": "GHSA-vrp5-7hmm-j77f",
  "modified": "2022-05-14T02:02:08Z",
  "published": "2022-05-14T02:02:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12829"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/creative-cloud/apsb18-32.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105158"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041600"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VRP7-VCFX-J447

Vulnerability from github – Published: 2026-09-27 12:30 – Updated: 2026-10-02 21:31
VLAI
Details

wolfSSL versions 5.9.2 and earlier contain a flaw in the X.509 certificate validation logic where it fails to properly enforce NameConstraints extensions when there is an unconstrained CA tier between a name-constrained intermediate CA and the leaf certificate. wolfSSL incorrectly accepted certificates for hostnames they shouldn't be allowed to cover, due to a chain-walking state-machine bug that resets the validation state when encountering an intermediate without NameConstraints, thereby bypassing cryptographic delegation controls. This defect exists in the default build configuration that makes use of certificates where name constraint extensions are used. Thanks to Jack Lloyd, PathDiff, and Ben Smyth for reporting the issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-89133"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-27T10:16:58Z",
    "severity": "MODERATE"
  },
  "details": "wolfSSL versions 5.9.2 and earlier contain a flaw in the X.509 certificate validation logic where it fails to properly enforce NameConstraints extensions when there is an unconstrained CA tier between a name-constrained intermediate CA and the leaf certificate. wolfSSL incorrectly accepted certificates for hostnames they shouldn\u0027t be allowed to cover, due to a chain-walking state-machine bug that resets the validation state when encountering an intermediate without NameConstraints, thereby bypassing cryptographic delegation controls. This defect exists in the default build configuration that makes use of certificates where name constraint extensions are used. Thanks to Jack Lloyd, PathDiff, and Ben Smyth for reporting the issue.",
  "id": "GHSA-vrp7-vcfx-j447",
  "modified": "2026-10-02T21:31:57Z",
  "published": "2026-09-27T12:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89133"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wolfSSL/wolfssl/pull/10687"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/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"
    }
  ]
}

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.