Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

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

1912 vulnerabilities reference this CWE, most recent first.

GHSA-67MG-QMC3-GH6F

Vulnerability from github – Published: 2022-05-24 16:55 – Updated: 2024-04-04 01:54
VLAI
Details

Limesurvey before 3.17.14 does not enforce SSL/TLS usage in the default configuration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-16179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-09T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Limesurvey before 3.17.14 does not enforce SSL/TLS usage in the default configuration.",
  "id": "GHSA-67mg-qmc3-gh6f",
  "modified": "2024-04-04T01:54:20Z",
  "published": "2022-05-24T16:55:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16179"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LimeSurvey/LimeSurvey/commit/5870fd1037058bc4e43cccf893b576c72293371e#diff-d539f3f8185667ee48db78e1bf65a3b4R42"
    },
    {
      "type": "WEB",
      "url": "https://www.limesurvey.org/limesurvey-updates/2188-limesurvey-3-17-14-build-190902-released"
    }
  ],
  "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"
    }
  ]
}

GHSA-67MR-6F82-P9VQ

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

The com.softphone.common package in the Grandstream Wave app 1.0.1.26 and earlier for Android does not properly validate SSL certificates, which allows man-in-the-middle attackers to spoof the Grandstream provisioning server via a crafted certificate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-1519"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-04-21T20:59:00Z",
    "severity": "MODERATE"
  },
  "details": "The com.softphone.common package in the Grandstream Wave app 1.0.1.26 and earlier for Android does not properly validate SSL certificates, which allows man-in-the-middle attackers to spoof the Grandstream provisioning server via a crafted certificate.",
  "id": "GHSA-67mr-6f82-p9vq",
  "modified": "2022-05-14T02:47:00Z",
  "published": "2022-05-14T02:47:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-1519"
    },
    {
      "type": "WEB",
      "url": "https://rt-solutions.de/wp-content/uploads/2016/04/CVE-2016-1519-gswave-tls-mitm.pdf"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/136290/Grandstream-Wave-1.0.1.26-TLS-Man-In-The-Middle.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/537819/100/0/threaded"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-67WP-8RC4-MVRW

Vulnerability from github – Published: 2026-01-19 18:30 – Updated: 2026-01-19 18:30
VLAI
Details

An Improper Certificate Validation vulnerability in the OPC-UA client and ANSL over TLS client used in Automation Studio versions before 6.5 could allow an unauthenticated attacker on the network to position themselves to intercept and interfere with data exchanges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-11043"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-19T16:15:52Z",
    "severity": "CRITICAL"
  },
  "details": "An Improper Certificate Validation vulnerability in the OPC-UA client and ANSL over TLS client used in Automation Studio versions before 6.5 could allow an unauthenticated attacker on the network to position themselves to intercept and interfere with data exchanges.",
  "id": "GHSA-67wp-8rc4-mvrw",
  "modified": "2026-01-19T18:30:25Z",
  "published": "2026-01-19T18:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11043"
    },
    {
      "type": "WEB",
      "url": "https://www.br-automation.com/fileadmin/SA25P004-4f45197f.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"
    }
  ]
}

GHSA-684G-2532-25MP

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

An issue was discovered in certain Apple products. macOS before 10.12.5 is affected. The issue involves the "802.1X" component. It allows remote attackers to discover the network credentials of arbitrary users by operating a crafted network that requires 802.1X authentication, because EAP-TLS certificate validation mishandles certificate changes.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-6988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-22T05:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in certain Apple products. macOS before 10.12.5 is affected. The issue involves the \"802.1X\" component. It allows remote attackers to discover the network credentials of arbitrary users by operating a crafted network that requires 802.1X authentication, because EAP-TLS certificate validation mishandles certificate changes.",
  "id": "GHSA-684g-2532-25mp",
  "modified": "2022-05-17T02:34:18Z",
  "published": "2022-05-17T02:34:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6988"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT207797"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038484"
    }
  ],
  "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-686Q-7454-35QJ

Vulnerability from github – Published: 2025-01-31 00:30 – Updated: 2025-06-30 18:31
VLAI
Details

This vulnerability allows network-adjacent attackers to compromise the integrity of downloaded information on affected installations of Pioneer DMH-WT7600NEX devices. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the telematics functionality, which operates over HTTPS. The issue results from the lack of proper validation of the certificate presented by the server. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-23928"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-31T00:15:09Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows network-adjacent attackers to compromise the integrity of downloaded information on affected installations of Pioneer DMH-WT7600NEX devices. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the telematics functionality, which operates over HTTPS. The issue results from the lack of proper validation of the certificate presented by the server. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root.",
  "id": "GHSA-686q-7454-35qj",
  "modified": "2025-06-30T18:31:43Z",
  "published": "2025-01-31T00:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23928"
    },
    {
      "type": "WEB",
      "url": "https://jpn.pioneer/ja/car/dl/dmh-sz700_sf700"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1045"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-68G3-7FHP-7RG3

Vulnerability from github – Published: 2026-06-25 21:31 – Updated: 2026-06-26 21:32
VLAI
Details

Chain intermediate CA:TRUE without keyCertSign accepted as a signing CA. Intermediate CA certificates are required to have the keyCertSign key usage when a Key Usage extension is present, but chain-supplied temporary CAs (WOLFSSL_TEMP_CA) added while building a certificate path were previously exempted from this check, so an intermediate asserting CA:TRUE but lacking keyCertSign was accepted as a signing CA. The check now applies to chain-supplied temporary CAs as well; only operator-loaded root certificates (WOLFSSL_USER_CA) and self-signed roots remain exempt. Per RFC 5280 an absent Key Usage extension implies all usages, so the requirement is enforced only when the extension is actually present (extKeyUsageSet). Affects the OpenSSL-compatibility certificate-path-building path (X509_verify_cert / X509_STORE, OPENSSL_EXTRA/OPENSSL_ALL), where untrusted chain intermediates are added as temporary CAs; native (non-OpenSSL-compat) certificate verification does not create temporary CAs and is unaffected. Within those builds, the check applies unless ALLOW_INVALID_CERTSIGN is defined.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-55964"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T20:17:16Z",
    "severity": "MODERATE"
  },
  "details": "Chain intermediate CA:TRUE without keyCertSign accepted as a signing CA. Intermediate CA certificates are required to have the keyCertSign key usage when a Key Usage extension is present, but chain-supplied temporary CAs (WOLFSSL_TEMP_CA) added while building a certificate path were previously exempted from this check, so an intermediate asserting CA:TRUE but lacking keyCertSign was accepted as a signing CA. The check now applies to chain-supplied temporary CAs as well; only operator-loaded root certificates (WOLFSSL_USER_CA) and self-signed roots remain exempt. Per RFC 5280 an absent Key Usage extension implies all usages, so the requirement is enforced only when the extension is actually present (extKeyUsageSet). Affects the OpenSSL-compatibility certificate-path-building path (X509_verify_cert / X509_STORE, OPENSSL_EXTRA/OPENSSL_ALL), where untrusted chain intermediates are added as temporary CAs; native (non-OpenSSL-compat) certificate verification does not create temporary CAs and is unaffected. Within those builds, the check applies unless ALLOW_INVALID_CERTSIGN is defined.",
  "id": "GHSA-68g3-7fhp-7rg3",
  "modified": "2026-06-26T21:32:11Z",
  "published": "2026-06-25T21:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55964"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wolfSSL/wolfssl/pull/10702"
    },
    {
      "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: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-68P7-5FP8-CWWG

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

An Improper Certificate Validation in Ivanti EPMM before versions 12.6.1.1, 12.7.0.1, and 12.8.0.1 allows a remote unauthenticated attacker to impersonate registered Sentry hosts and obtain valid CA-signed client certificates.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-5787"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-07T16:16:22Z",
    "severity": "HIGH"
  },
  "details": "An Improper Certificate Validation in Ivanti EPMM before versions 12.6.1.1, 12.7.0.1, and 12.8.0.1 allows a remote unauthenticated attacker to impersonate registered Sentry hosts and obtain valid CA-signed client certificates.",
  "id": "GHSA-68p7-5fp8-cwwg",
  "modified": "2026-05-07T18:30:40Z",
  "published": "2026-05-07T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5787"
    },
    {
      "type": "WEB",
      "url": "https://hub.ivanti.com/s/article/May-2026-Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-Multiple-CVEs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-68PF-743M-HV2W

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

Logstash 1.4.x before 1.4.5 and 1.5.x before 1.5.4 with Lumberjack output or the Logstash forwarder does not validate SSL/TLS certificates from the Logstash server, which might allow attackers to obtain sensitive information via a man-in-the-middle attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2015-5619"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-08-09T16:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Logstash 1.4.x before 1.4.5 and 1.5.x before 1.5.4 with Lumberjack output or the Logstash forwarder does not validate SSL/TLS certificates from the Logstash server, which might allow attackers to obtain sensitive information via a man-in-the-middle attack.",
  "id": "GHSA-68pf-743m-hv2w",
  "modified": "2022-05-14T00:58:12Z",
  "published": "2022-05-14T00:58:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-5619"
    },
    {
      "type": "WEB",
      "url": "https://www.elastic.co/blog/logstash-1-5-4-and-1-4-5-released"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/133269/Logstash-1.5.3-Man-In-The-Middle.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/536294/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/536858/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/76455"
    }
  ],
  "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-6929-8P9F-26JX

Vulnerability from github – Published: 2026-07-02 20:25 – Updated: 2026-07-02 20:25
VLAI
Summary
SimpleSAMLphp HTTP-Artifact TLS validator confusion allows cross-IdP authentication bypass
Details

Summary

SimpleSAMLphp's HTTP-Artifact receive path can treat an unsigned embedded SAML Response as cryptographically valid for the wrong IdP.

In the HTTPArtifact::receive() flow, the SOAP ArtifactResponse receives a TLS-based validator from SOAPClient::addSSLValidator(). The embedded SAML Response then receives a validator that delegates signature validation to that outer ArtifactResponse. Later, the SP validates the embedded Response against metadata selected from the embedded response issuer, not necessarily the artifact issuer.

The critical issue is that SOAPClient::validateSSL() returns normally when the TLS public key does not match the key currently being validated. SAML2\Message::validate() treats any validator call that does not throw an exception as successful. As a result, an ArtifactResponse obtained from one IdP can validate an unsigned embedded SAML Response that claims to be issued by a different IdP.

In a multi-IdP/federation deployment where a malicious or lower-trust IdP can issue an HTTP-Artifact response to an SP, this can allow the attacker to authenticate to the SP as arbitrary users from a higher-trust victim IdP.

Impact

A malicious or lower-trust IdP in the same SP/federation trust set can authenticate to the SP as users from another IdP when HTTP-Artifact is used. The attacker can choose assertion attributes, NameID, and session data in the forged unsigned assertion.

This is an authentication bypass and identity-provider impersonation issue. In realistic federations, the security boundary between IdPs matters: a compromised or low-assurance IdP should not be able to mint identities for a high-assurance IdP.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/saml2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/saml2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/saml2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.20.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/saml2-legacy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.20.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49283"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T20:25:56Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nSimpleSAMLphp\u0027s HTTP-Artifact receive path can treat an unsigned embedded SAML `Response` as cryptographically valid for the wrong IdP.\n\nIn the `HTTPArtifact::receive()` flow, the SOAP `ArtifactResponse` receives a TLS-based validator from `SOAPClient::addSSLValidator()`. The embedded SAML `Response` then receives a validator that delegates signature validation to that outer `ArtifactResponse`. Later, the SP validates the embedded `Response` against metadata selected from the embedded response issuer, not necessarily the artifact issuer.\n\nThe critical issue is that `SOAPClient::validateSSL()` returns normally when the TLS public key does not match the key currently being validated. `SAML2\\Message::validate()` treats any validator call that does not throw an exception as successful. As a result, an `ArtifactResponse` obtained from one IdP can validate an unsigned embedded SAML `Response` that claims to be issued by a different IdP.\n\nIn a multi-IdP/federation deployment where a malicious or lower-trust IdP can issue an HTTP-Artifact response to an SP, this can allow the attacker to authenticate to the SP as arbitrary users from a higher-trust victim IdP.\n\n## Impact\n\nA malicious or lower-trust IdP in the same SP/federation trust set can authenticate to the SP as users from another IdP when HTTP-Artifact is used. The attacker can choose assertion attributes, `NameID`, and session data in the forged unsigned assertion.\n\nThis is an authentication bypass and identity-provider impersonation issue. In realistic federations, the security boundary between IdPs matters: a compromised or low-assurance IdP should not be able to mint identities for a high-assurance IdP.",
  "id": "GHSA-6929-8p9f-26jx",
  "modified": "2026-07-02T20:25:56Z",
  "published": "2026-07-02T20:25:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/simplesamlphp/saml2/security/advisories/GHSA-6929-8p9f-26jx"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/simplesamlphp/saml2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SimpleSAMLphp HTTP-Artifact TLS validator confusion allows cross-IdP authentication bypass"
}

GHSA-6939-J3MF-8M46

Vulnerability from github – Published: 2022-05-13 01:25 – Updated: 2025-04-20 03:37
VLAI
Details

The Space Coast Credit Union Mobile app 2.2 for iOS and 2.1.0.1104 for Android 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-3212"
  ],
  "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 Space Coast Credit Union Mobile app 2.2 for iOS and 2.1.0.1104 for Android 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-6939-j3mf-8m46",
  "modified": "2025-04-20T03:37:14Z",
  "published": "2022-05-13T01:25:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3212"
    },
    {
      "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"
    },
    {
      "type": "WEB",
      "url": "http://www.kb.cert.org/vuls/id/556600"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/98307"
    }
  ],
  "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"
    }
  ]
}

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.