CWE-295

{
  "affected": [],
  "aliases": [
    "CVE-2022-32151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-15T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The httplib and urllib Python libraries that Splunk shipped with Splunk Enterprise did not validate certificates using the certificate authority (CA) certificate stores by default in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203. Python 3 client libraries now verify server certificates by default and use the appropriate CA certificate stores for each library. Apps and add-ons that include their own HTTP libraries are not affected. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.",
  "id": "GHSA-4mv8-3862-hghv",
  "modified": "2022-06-25T00:01:03Z",
  "published": "2022-06-16T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32151"
    },
    {
      "type": "WEB",
      "url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation"
    },
    {
      "type": "WEB",
      "url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_simplerequest"
    },
    {
      "type": "WEB",
      "url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0601.html"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-5594"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-21T12:15:08Z",
    "severity": "HIGH"
  },
  "details": "Improper validation of the server\u2019s certificate chain in secure traffic scanning feature considered intermediate certificate signed using the MD5 or SHA1 algorithm as trusted.",
  "id": "GHSA-4mwg-64w4-5g5m",
  "modified": "2024-01-04T15:30:21Z",
  "published": "2023-12-21T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5594"
    },
    {
      "type": "WEB",
      "url": "https://support.eset.com/en/ca8562-eset-customer-advisory-improper-following-of-a-certificates-chain-of-trust-in-eset-security-products-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-0334"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-07T21:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the certificate management subsystem of Cisco AnyConnect Network Access Manager and of Cisco AnyConnect Secure Mobility Client for iOS, Mac OS X, Android, Windows, and Linux could allow an unauthenticated, remote attacker to bypass the TLS certificate check when downloading certain configuration files. The vulnerability is due to improper use of Simple Certificate Enrollment Protocol and improper server certificate validation. An attacker could exploit this vulnerability by preparing malicious profile and localization files for Cisco AnyConnect to use. A successful exploit could allow the attacker to remotely change the configuration profile, a certificate, or the localization data used by AnyConnect Secure Mobility Client. Cisco Bug IDs: CSCvh23141.",
  "id": "GHSA-4p6c-fxcr-rhm3",
  "modified": "2022-05-13T01:35:23Z",
  "published": "2022-05-13T01:35:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0334"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180606-AnyConnect-cert-bypass"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/104430"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041075"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2019-15604"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-02-07T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper Certificate Validation in Node.js 10, 12, and 13 causes the process to abort when sending a crafted X.509 certificate",
  "id": "GHSA-4p8g-wmmc-p9f7",
  "modified": "2024-03-07T21:30:19Z",
  "published": "2022-05-24T17:08:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15604"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/746733"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0573"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0579"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0597"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0598"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0602"
    },
    {
      "type": "WEB",
      "url": "https://nodejs.org/en/blog/release/v10.19.0"
    },
    {
      "type": "WEB",
      "url": "https://nodejs.org/en/blog/release/v12.15.0"
    },
    {
      "type": "WEB",
      "url": "https://nodejs.org/en/blog/release/v13.8.0"
    },
    {
      "type": "WEB",
      "url": "https://nodejs.org/en/blog/vulnerability/february-2020-security-releases"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202003-48"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20200221-0004"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4669"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-45170"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-12T02:16:42Z",
    "severity": "HIGH"
  },
  "details": "Idira Privilege Cloud Connector versions prior 1.1.100504 under specific conditions and configuration scenarios, TLS certificate validation may not be fully enforced. CyberArk Security Bulletin: CA26-17",
  "id": "GHSA-4pc6-w92r-32xw",
  "modified": "2026-06-23T15:32:30Z",
  "published": "2026-06-12T03:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45170"
    },
    {
      "type": "WEB",
      "url": "https://docs.cyberark.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/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:Amber",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "lettre"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.1"
            },
            {
              "fixed": "0.11.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46428"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T14:29:10Z",
    "nvd_published_at": "2026-07-20T16:17:01Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nAn inverted-boolean bug in lettre\u0027s `boring-tls` integration silently\ndisables TLS hostname verification for callers using the default (strict)\nconfiguration. An on-path attacker presenting any chain-valid certificate\nfor any domain can intercept SMTP submission, including PLAIN/LOGIN\ncredentials and message contents, against any lettre user built with the\n`boring-tls` feature. Other TLS backends (`native-tls`, `rustls`) are\nunaffected.\n\n### Details\nboring\u0027s `SslConnectorBuilder::set_verify_hostname(bool)` /\n`verify_hostname(bool)` API takes a *verify* flag \u2014 `true` means enforce\nhostname verification, `false` means skip it. (Boring docs:\nhttps://docs.rs/boring/latest/boring/ssl/struct.ConnectConfiguration.html#method.set_verify_hostname)\nlettre\u0027s `TlsParametersBuilder` exposes the opposite-named flag\n`accept_invalid_hostnames: bool` \u2014 `true` means *accept invalid* (skip\nverification), `false` means verify. lettre passes this flag directly to\nboring at both TLS-upgrade sites, inverting the semantics:\nsrc/transport/smtp/client/net.rs:202 (sync)\n    .verify_hostname(*accept_invalid_hostnames)\nsrc/transport/smtp/client/async_net.rs:377 (async)\n    config.set_verify_hostname(accept_invalid_hostnames);\nConcrete behaviour under `boring-tls`:\n  * accept_invalid_hostnames = false  (the strict default)\n      \u2192 set_verify_hostname(false)  \u2192 hostname verification SKIPPED\n        (wrong; the caller asked for strict verification)\n  * accept_invalid_hostnames = true   (explicit opt-in to \"dangerous\")\n      \u2192 set_verify_hostname(true)   \u2192 hostname verification ENFORCED\n        (wrong; the caller opted into accepting any name)\nBoring\u0027s own warning on `set_verify_hostname`:\n    \"If hostname verification is not used, *any* valid certificate for\n    *any* site will be trusted for use from any other. This introduces\n    a significant vulnerability to man-in-the-middle attacks.\"\n`native-tls` (src/transport/smtp/client/tls.rs:355) uses\n`danger_accept_invalid_hostnames(self.accept_invalid_hostnames)`, whose\nflag name and semantics match lettre\u0027s \u2014 unaffected. `rustls` uses a\nseparate verifier path \u2014 unaffected.\nThe bug was introduced in PR #797 (\"Add support for boring TLS\"), commit\n985fa7e, first released in v0.10.1, and persists unchanged through v0.11.21\n(latest). Zero existing tests cover `accept_invalid_hostnames` end-to-end\nwith any backend, which is why the inversion has gone undetected.\nFix: negate the flag at both call sites. Two-line patch:\n    -    .verify_hostname(*accept_invalid_hostnames)\n    +    .verify_hostname(!*accept_invalid_hostnames)\n    -    config.set_verify_hostname(accept_invalid_hostnames);\n    +    config.set_verify_hostname(!accept_invalid_hostnames);\nI have the patch ready locally and can push to a private fork if a\ncollaborative fix branch is preferred.\n\n### PoC\nSetup (any lettre version \u003e= v0.10.1, built with the `boring-tls`\nfeature, default-strict configuration):\n1. Generate a TLS cert for any hostname the attacker controls, e.g.\n   `attacker.example`, signed by any CA in the client\u0027s trust store\n   (e.g. a Let\u0027s Encrypt cert is sufficient).\n2. Stand up an attacker SMTP server on the network path between the\n   lettre client and the intended MX. Have it present the\n   `attacker.example` cert on STARTTLS or implicit TLS.\n3. Use lettre with default-strict TLS to send to the real MX hostname,\n   e.g. `mail.example.com`:\n       use lettre::transport::smtp::client::{Tls, TlsParameters};\n       use lettre::{AsyncSmtpTransport, Tokio1Executor, Message};\n       let tls = TlsParameters::builder(\"mail.example.com\".to_owned())\n           .build_boring()\n           .unwrap();\n       let mailer = AsyncSmtpTransport::\u003cTokio1Executor\u003e::relay(\n               \"mail.example.com\",\n           )?\n           .tls(Tls::Required(tls))\n           .build();\n       mailer.send(message).await?;     // succeeds against attacker\nExpected with hostname verification: handshake fails because the\npresented leaf cert\u0027s SAN does not match `mail.example.com`.\nActual on `boring-tls`: handshake succeeds. lettre proceeds with the\nSMTP transaction, sending MAIL FROM, RCPT TO, message body, and any\nconfigured SMTP AUTH credentials to the attacker.\nSymmetric inverse PoC (proves the inversion, not just a missing check):\nconfigure `.dangerous_accept_invalid_hostnames(true)` and try to connect\nto a server whose cert SAN matches the connect domain. With the bug,\nthe handshake *fails* because lettre passes `true` to `verify_hostname`\nand boring rejects... actually wait, it succeeds (SAN matches). Better\ninverse demonstration: connect to a server whose cert SAN matches the\nconnect domain with `accept_invalid_hostnames=true`, then connect to a\nmismatched-SAN server with the same flag \u2014 the latter is rejected,\nproving the flag is inverted (the user opted into accepting any name,\nyet lettre enforces strict verification).\nA reproducer cargo project can be produced on request.\n\n### Impact\nWho is impacted: any lettre user who\n  1. enables the `boring-tls` feature, AND\n  2. relies on default-strict hostname verification\n     (i.e. does NOT call `.dangerous_accept_invalid_hostnames(true)`).\nThis is the entire \"I want strict TLS\" population on `boring-tls`. They\nget the opposite of what they asked for: a TLS handshake that ignores\nhostname mismatch.\nExploitation: an attacker on the network path between the lettre client\nand the target SMTP server, holding any chain-valid TLS certificate\n(e.g. a free Let\u0027s Encrypt cert for a domain the attacker owns), can\npresent that certificate when the lettre client connects to the intended\nMX. boring accepts the handshake, lettre proceeds, and the attacker\ngains read/write access to:\n  * SMTP envelope (MAIL FROM, RCPT TO)\n  * Message bodies, attachments, headers\n  * Any SMTP AUTH credentials (PLAIN, LOGIN, CRAM-MD5, etc.)\n  * Any DKIM signatures and DMARC alignment downstream depends on\n    can be inspected and selectively dropped\nConfidentiality and integrity impact: High. Availability impact: None\ndirect (the attacker can choose to forward or drop, but the bug itself\ndoes not deny service).\nCloudflare\u0027s email-fwdr independently identified and mitigated this\ndownstream by promoting a previously-metric-only post-handshake SAN\ncheck to a hard error (fix landed 2026-05-12). Because we\u0027re mitigated\ndownstream, we are not on a publication clock; we are reporting so the\nupstream fix can ship and other lettre+boring-tls deployments can stop\nrelying on per-caller workarounds. Happy to coordinate on embargo\ntiming.\nAffected versions: every released lettre version with `boring-tls`\nsupport, from v0.10.1 (PR #797, commit 985fa7e) through v0.11.21\n(latest). No prior advisory or fix.\nSuggested fix: two-line negation of the flag at the boring call sites\n(see Details). Patch is ready locally and can be attached to a private\ncollaboration fork.",
  "id": "GHSA-4pj9-g833-qx53",
  "modified": "2026-07-28T14:29:10Z",
  "published": "2026-07-28T14:29:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lettre/lettre/security/advisories/GHSA-4pj9-g833-qx53"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46428"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lettre/lettre/commit/f5efffc88360dbdbfcef80f465e42d5bce68ca35"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lettre/lettre"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lettre/lettre/releases/tag/v0.11.22"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0141.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "lettre has TLS hostname verification disabled when using Boring TLS backend"
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-7043"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-02-27T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL before 1.0.2. tunnel.c mishandles certificate validation because hostname comparisons do not consider \u0026#39;\\0\u0026#39; characters, as demonstrated by a good.example.com\\x00evil.example.com attack.",
  "id": "GHSA-4pqj-5gg5-44jh",
  "modified": "2024-04-04T02:48:25Z",
  "published": "2022-05-24T17:09:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7043"
    },
    {
      "type": "WEB",
      "url": "https://github.com/adrienverge/openfortivpn/issues/536"
    },
    {
      "type": "WEB",
      "url": "https://github.com/adrienverge/openfortivpn/commit/6328a070ddaab16faaf008cb9a8a62439c30f2a8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/adrienverge/openfortivpn/commit/cd9368c6a1b4ef91d77bb3fdbe2e5bc34aa6f4c4"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/CKNKSGBVYGRRVRLFEFBEKUEJYJR5LWOF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FF6HYIBREQGATRM5COF57MRQWKOKCWZ3"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SRVVNXCNTNMPCIAZIVR4FAGYCSU53FNA"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CKNKSGBVYGRRVRLFEFBEKUEJYJR5LWOF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FF6HYIBREQGATRM5COF57MRQWKOKCWZ3"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SRVVNXCNTNMPCIAZIVR4FAGYCSU53FNA"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00009.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00011.html"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-22642"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-11T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "An improper certificate validation vulnerability [CWE-295] in FortiAnalyzer and FortiManager 7.2.0 through 7.2.1, 7.0.0 through 7.0.5, 6.4.8 through 6.4.10 may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the device and the remote FortiGuard server hosting outbreakalert ressources.",
  "id": "GHSA-4pv6-q257-8q33",
  "modified": "2024-04-04T03:24:40Z",
  "published": "2023-04-11T18:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22642"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/psirt/FG-IR-22-502"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-6900"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-06T11:16:31Z",
    "severity": "CRITICAL"
  },
  "details": "Improper certificate validation vulnerability in B\u0026R Industrial Automation GmbH APROL.\n\nThis issue affects APROL: before R 4.4-01P5.",
  "id": "GHSA-4q88-82vm-7283",
  "modified": "2026-07-06T12:31:31Z",
  "published": "2026-07-06T12:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6900"
    },
    {
      "type": "WEB",
      "url": "https://br-cws-assets.de-fra-1.linodeobjects.com/SA26P011-661853b7.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-38864"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-23T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "IBM Security Verify Bridge 1.0.5.0 could allow a user to obtain sensitive information due to improper certificate validation. IBM X-Force ID: 208155.",
  "id": "GHSA-4qmx-9m2v-r9qw",
  "modified": "2022-05-24T19:15:30Z",
  "published": "2022-05-24T19:15:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38864"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/208155"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6491651"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}