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-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-VV4W-99G8-93PP

Vulnerability from github – Published: 2026-04-14 09:30 – Updated: 2026-04-14 09:30
VLAI
Details

A vulnerability has been identified in Siemens Software Center (All versions < V3.5.8.2), Simcenter 3D (All versions < V2506.6000), Simcenter Femap (All versions < V2506.0002), Simcenter STAR-CCM+ (All versions < V2602), Solid Edge SE2025 (All versions < V225.0 Update 13), Solid Edge SE2026 (All versions < V226.0 Update 04), Tecnomatix Plant Simulation (All versions < V2504.0008). Affected applications do not properly validate client certificates to connect to Analytics Service endpoint. This could allow an unauthenticated remote attacker to perform man in the middle attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-40745"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-14T09:16:34Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in Siemens Software Center (All versions \u003c V3.5.8.2), Simcenter 3D (All versions \u003c V2506.6000), Simcenter Femap (All versions \u003c V2506.0002), Simcenter STAR-CCM+ (All versions \u003c V2602), Solid Edge SE2025 (All versions \u003c V225.0 Update 13), Solid Edge SE2026 (All versions \u003c V226.0 Update 04), Tecnomatix Plant Simulation (All versions \u003c V2504.0008). Affected applications do not properly validate client certificates to connect to Analytics Service endpoint. This could allow an unauthenticated remote attacker to perform man in the middle attacks.",
  "id": "GHSA-vv4w-99g8-93pp",
  "modified": "2026-04-14T09:30:44Z",
  "published": "2026-04-14T09:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40745"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-981622.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/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-VVP7-QF5P-R677

Vulnerability from github – Published: 2024-02-16 00:30 – Updated: 2024-08-01 15:31
VLAI
Details

In ca-certificates, there is a possible way to read encrypted TLS data due to untrusted cryptographic certificates. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-40104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-15T23:15:08Z",
    "severity": "HIGH"
  },
  "details": "In ca-certificates, there is a possible way to read encrypted TLS data due to untrusted cryptographic certificates. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-vvp7-qf5p-r677",
  "modified": "2024-08-01T15:31:26Z",
  "published": "2024-02-16T00:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40104"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/system/ca-certificates/+/91204b9fdbd77b3f27f94b73868607b2dccbfdad"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2023-11-01"
    }
  ],
  "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-VVR9-CXF3-4GVJ

Vulnerability from github – Published: 2022-04-23 00:40 – Updated: 2024-04-03 23:52
VLAI
Details

vdsm: certificate generation upon node creation allowing vdsm to start and serve requests from anyone who has a matching key (and certificate)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2012-5518"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-25T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "vdsm: certificate generation upon node creation allowing vdsm to start and serve requests from anyone who has a matching key (and certificate)",
  "id": "GHSA-vvr9-cxf3-4gvj",
  "modified": "2024-04-03T23:52:11Z",
  "published": "2022-04-23T00:40:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5518"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/cve-2012-5518"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-5518"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2012/11/11/3"
    }
  ],
  "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"
    }
  ]
}

GHSA-VW5V-4F2Q-W9XF

Vulnerability from github – Published: 2026-03-03 20:08 – Updated: 2026-03-25 18:29
VLAI
Summary
AWS-LC has PKCS7_verify Certificate Chain Validation Bypass
Details

Summary

AWS-LC is an open-source, general-purpose cryptographic library.

Impact

Improper certificate validation in PKCS7_verify() in AWS-LC allows an unauthenticated user to bypass certificate chain verification when processing PKCS7 objects with multiple signers, except the final signer.

Customers of AWS services do not need to take action. aws-lc-sys contains code from AWS-LC. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.

Impacted versions:

aws-lc-sys versions: >= 0.24.0, < 0.38.0

Patches

The patch is included in v0.38.0

Workarounds

There is no workaround. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.

Resources

If there are any questions or comments about this advisory, contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

AWS-LC would like to thank Joshua Rogers (https://joshua.hu/) for collaborating on this issue through the coordinated vulnerability disclosure process.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "aws-lc-sys"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.24.0"
            },
            {
              "fixed": "0.38.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T20:08:24Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nAWS-LC is an open-source, general-purpose cryptographic library.\n\n### Impact\nImproper certificate validation in PKCS7_verify() in AWS-LC allows an unauthenticated user to bypass certificate chain verification when processing PKCS7 objects with multiple signers, except the final signer.\n\nCustomers of AWS services do not need to take action. aws-lc-sys contains code from AWS-LC. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.\n\n#### Impacted versions: \naws-lc-sys versions: \u003e= 0.24.0, \u003c 0.38.0\n\n### Patches\nThe patch is included in v0.38.0\n\n### Workarounds\nThere is no workaround. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.\n\n### Resources\nIf there are any questions or comments about this advisory, contact [AWS/Amazon] Security via the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.\n\n### Acknowledgement\nAWS-LC would like to thank Joshua Rogers (https://joshua.hu/) for collaborating on this issue through the coordinated vulnerability disclosure process.",
  "id": "GHSA-vw5v-4f2q-w9xf",
  "modified": "2026-03-25T18:29:18Z",
  "published": "2026-03-03T20:08:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-lc-rs/security/advisories/GHSA-vw5v-4f2q-w9xf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-lc/security/advisories/GHSA-cfwj-9wp5-wqvp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3336"
    },
    {
      "type": "WEB",
      "url": "https://aws.amazon.com/security/security-bulletins/2026-005-AWS"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aws/aws-lc-rs"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0046.html"
    }
  ],
  "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:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AWS-LC has PKCS7_verify Certificate Chain Validation Bypass"
}

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.