Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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

1903 vulnerabilities reference this CWE, most recent first.

GHSA-XGF4-VH79-4G7J

Vulnerability from github – Published: 2023-10-17 03:32 – Updated: 2024-04-04 08:42
VLAI
Details

IBM Security Verify Privilege On-Premises 11.5 does not validate, or incorrectly validates, a certificate which could disclose sensitive information which could aid further attacks against the system. IBM X-Force ID: 240455.

Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-43892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-17T03:15:09Z",
    "severity": "MODERATE"
  },
  "details": "\nIBM Security Verify Privilege On-Premises 11.5 does not validate, or incorrectly validates, a certificate which could disclose sensitive information which could aid further attacks against the system.  IBM X-Force ID:  240455.\n\n",
  "id": "GHSA-xgf4-vh79-4g7j",
  "modified": "2024-04-04T08:42:29Z",
  "published": "2023-10-17T03:32:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43892"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/240455"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7047202"
    }
  ],
  "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"
    }
  ]
}

GHSA-XGP8-3HG3-C2MH

Vulnerability from github – Published: 2026-04-16 21:17 – Updated: 2026-04-16 21:17
VLAI
Summary
webpki: Name constraints were accepted for certificates asserting a wildcard name
Details

Permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.

This was incorrect because, given a name constraint of accept.example.com, *.example.com could feasibly allow a name of reject.example.com which is outside the constraint. This is very similar to CVE-2025-61727.

Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.

Severity
2.2 (Low)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rustls-webpki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.101.0"
            },
            {
              "fixed": "0.103.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rustls-webpki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.104.0-alpha.1"
            },
            {
              "fixed": "0.104.0-alpha.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:17:12Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "Permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.\n\nThis was incorrect because, given a name constraint of `accept.example.com`, `*.example.com` could feasibly allow a name of `reject.example.com` which is outside the constraint.\nThis is very similar to [CVE-2025-61727](https://go.dev/issue/76442).\n\nSince name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.",
  "id": "GHSA-xgp8-3hg3-c2mh",
  "modified": "2026-04-16T21:17:12Z",
  "published": "2026-04-16T21:17:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rustls/webpki/security/advisories/GHSA-xgp8-3hg3-c2mh"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rustls/webpki"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0099.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "webpki: Name constraints were accepted for certificates asserting a wildcard name"
}

GHSA-XGPC-Q899-67P8

Vulnerability from github – Published: 2025-04-25 15:11 – Updated: 2025-05-05 22:00
VLAI
Summary
Fleet doesn’t validate a server’s certificate when connecting through SSH
Details

Impact

A vulnerability has been identified within Fleet where, by default, Fleet will automatically trust a remote server’s certificate when connecting through SSH if the certificate isn’t set in the known_hosts file. This could allow the execution of a man-in-the-middle (MitM) attack against Fleet. In case the server that is being connected to has a trusted entry in the known_hosts file, then Fleet will correctly check the authenticity of the presented certificate.

Please consult the associated MITRE ATT&CK - Technique - Adversary-in-the-Middle for further information about this category of attack.

Patches

Patched versions include releases v0.10.12, v0.11.7 and v0.12.2.

The fix involves some key areas with the following changes:

  • Git latest commit fetcher sources known_hosts entries from the following locations, in decreasing order of priority:
  • Secret referenced in a GitRepo’s clientSecretName field;
  • If no secret is referenced, in a gitcredential secret located in the GitRepo’s namespace;

  • If that secret does not exist, in a (new) known-hosts config map installed by Fleet, populated statically with public entries shared by a few git providers: Github, Gitlab, Bitbucket, Azure DevOps;

  • Git cloner: same as above.

  • fleet apply command: same as above. The command reads entries from a FLEET_KNOWN_HOSTS environment variable. That command is typically run within a container inside a job pod created by Fleet to update bundles from a new commit. However, users may also decide to run it locally, perhaps even with multiple concurrent executions of the command on the same machine. To cater for this, fleet apply writes the contents of FLEET_KNOWN_HOSTS, if any, to a temporary file with a random name, and deletes that file once bundles have been created. This reduces the risk of conflicts between concurrent runs. This happens regardless of the git repository URL (SSH or not), since a repository may reference artifacts to be retrieved using SSH anyway.

Note about sourcing known_hosts entries: if entries are found in a supported source, whatever that source may be, then those entries will be used. For instance, if wrong entries, or an incomplete set of entries (e.g. only BitBucket entries for a GitRepo pointing to Github) are found in a secret referenced in a GitRepo’s clientSecretName field, they will still be used. This will lead to errors if strict host key checks are enabled, even if matching, correct entries are found in another source with lower priority, such as the known-hosts config map. Fleet will not use one source to complement the other.

Note: Fleet v0.9 release line does not have the fix for this CVE. The fix for v0.9 was considered too complex and with the risk of introducing instabilities right before this version goes into end-of-life (EOL), as documented in SUSE’s Product Support Lifecycle page. Please see the section below for workarounds or consider upgrading to a newer and patched version of Rancher.

Workarounds

There are no workarounds for this issue. Users are recommended to upgrade, as soon as possible, to a version of Fleet that contains the fixes.

References

If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/fleet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0-rc.1"
            },
            {
              "fixed": "0.10.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/fleet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.11.0"
            },
            {
              "fixed": "0.11.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/fleet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.0"
            },
            {
              "fixed": "0.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-23390"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-25T15:11:07Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nA vulnerability has been identified within Fleet where, by default, Fleet will automatically trust a remote server\u2019s certificate when connecting through SSH if the certificate isn\u2019t set in the `known_hosts` file. This could allow the execution of a man-in-the-middle (MitM) attack against Fleet. In case the server that is being connected to has a trusted entry in the known_hosts file, then Fleet will correctly check the authenticity of the presented certificate. \n\nPlease consult the associated  [MITRE ATT\u0026CK - Technique - Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/) for further information about this category of attack.\n\n### Patches\nPatched versions include releases `v0.10.12`, `v0.11.7` and `v0.12.2`.\n\nThe fix involves some key areas with the following changes:\n\n- Git latest commit fetcher sources `known_hosts` entries from the following locations, in decreasing order of priority:\n  1. Secret referenced in a `GitRepo`\u2019s `clientSecretName` field;\n  2. If no secret is referenced, in a `gitcredential` secret located in the `GitRepo`\u2019s namespace;\n  3. If that secret does not exist, in a (new) `known-hosts` config map installed by Fleet, populated statically with public entries shared by a few git providers: Github, Gitlab, Bitbucket, Azure DevOps;\n\n- Git cloner: same as above.\n\n- `fleet apply` command: same as above. The command reads entries from a `FLEET_KNOWN_HOSTS` environment variable. That command is typically run within a container inside a job pod created by Fleet to update bundles from a new commit. However, users may also decide to run it locally, perhaps even with multiple concurrent executions of the command on the same machine. To cater for this, `fleet apply` writes the contents of `FLEET_KNOWN_HOSTS`, if any, to a temporary file with a random name, and deletes that file once bundles have been created. This reduces the risk of conflicts between concurrent runs.\nThis happens regardless of the git repository URL (SSH or not), since a repository may reference artifacts to be retrieved using SSH anyway.\n\n**Note about sourcing `known_hosts` entries:** if entries are found in a supported source, whatever that source may be, then those entries will be used. For instance, if wrong entries, or an incomplete set of entries (e.g. only BitBucket entries for a `GitRepo` pointing to Github) are found in a secret referenced in a `GitRepo`\u2019s `clientSecretName` field, they will still be used. This will lead to errors if strict host key checks are enabled, even if matching, correct entries are found in another source with lower priority, such as the `known-hosts` config map. Fleet will not use one source to complement the other.\n\n**Note: Fleet v0.9 release line does not have the fix for this CVE. The fix for v0.9 was considered too complex and with the risk of introducing instabilities right before this version goes into end-of-life (EOL), as documented in [SUSE\u2019s Product Support Lifecycle](https://www.suse.com/lifecycle/#suse-rancher-prime) page. Please see the section below for workarounds or consider upgrading to a newer and patched version of Rancher.**\n\n### Workarounds\nThere are no workarounds for this issue. Users are recommended to upgrade, as soon as possible, to a version of Fleet that contains the fixes.\n\n### References\nIf you have any questions or comments about this advisory:\n- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.\n- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.\n- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).",
  "id": "GHSA-xgpc-q899-67p8",
  "modified": "2025-05-05T22:00:39Z",
  "published": "2025-04-25T15:11:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rancher/fleet/security/advisories/GHSA-xgpc-q899-67p8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rancher/fleet/pull/3571"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rancher/fleet/pull/3572"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rancher/fleet/pull/3573"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rancher/fleet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rancher/fleet/releases/tag/v0.10.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rancher/fleet/releases/tag/v0.11.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rancher/fleet/releases/tag/v0.12.2"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3649"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fleet doesn\u2019t validate a server\u2019s certificate when connecting through SSH"
}

GHSA-XGV7-PQQH-H2W9

Vulnerability from github – Published: 2023-01-19 17:51 – Updated: 2023-12-14 22:27
VLAI
Summary
jruby-openssl gem for JRuby fails to do proper certificate validation
Details

A security problem involving peer certificate verification was found where failed verification silently did nothing, making affected applications vulnerable to attackers. Attackers could lead a client application to believe that a secure connection to a rogue SSL server is legitimate. Attackers could also penetrate client-validated SSL server applications with a dummy certificate.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "jruby-openssl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2009-4123"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-19T17:51:27Z",
    "nvd_published_at": "2023-12-12T16:15:07Z",
    "severity": "HIGH"
  },
  "details": "A security problem involving peer certificate verification was found where failed verification silently did nothing, making affected applications vulnerable to attackers. Attackers could lead a client application to believe that a secure connection to a rogue SSL server is legitimate. Attackers could also penetrate client-validated SSL server applications with a dummy certificate.\n",
  "id": "GHSA-xgv7-pqqh-h2w9",
  "modified": "2023-12-14T22:27:18Z",
  "published": "2023-01-19T17:51:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-4123"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-xgv7-pqqh-h2w9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jruby/jruby-openssl"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/jruby-openssl/CVE-2009-4123.yml"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20101213091125/http://jruby.org/2009/12/07/vulnerability-in-jruby-openssl"
    },
    {
      "type": "WEB",
      "url": "http://jruby.org/2009/12/07/vulnerability-in-jruby-openssl"
    }
  ],
  "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"
    }
  ],
  "summary": "jruby-openssl gem for JRuby fails to do proper certificate validation"
}

GHSA-XH2H-F6RW-XFQX

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

Improper validation of the cloud certificate chain in Mobile Connect allows man-in-the-middle attack to impersonate the legitimate Command Centre Server. This issue affects: Gallagher Command Centre Mobile Connect for Android 15 versions prior to 15.04.040; version 14 and prior versions.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-23162"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-18T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper validation of the cloud certificate chain in Mobile Connect allows man-in-the-middle attack to impersonate the legitimate Command Centre Server. This issue affects: Gallagher Command Centre Mobile Connect for Android 15 versions prior to 15.04.040; version 14 and prior versions.",
  "id": "GHSA-xh2h-f6rw-xfqx",
  "modified": "2022-05-24T19:21:03Z",
  "published": "2022-05-24T19:21:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23162"
    },
    {
      "type": "WEB",
      "url": "https://security.gallagher.com/Security-Advisories/CVE-2021-23162"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XH5X-Q49R-R9W4

Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2024-03-27 18:32
VLAI
Details

curl 7.41.0 through 7.73.0 is vulnerable to an improper check for certificate revocation due to insufficient verification of the OCSP response.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-8286"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-14T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "curl 7.41.0 through 7.73.0 is vulnerable to an improper check for certificate revocation due to insufficient verification of the OCSP response.",
  "id": "GHSA-xh5x-q49r-r9w4",
  "modified": "2024-03-27T18:32:37Z",
  "published": "2022-05-24T17:36:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8286"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1048457"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4881"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212327"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212326"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212325"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210122-0007"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202012-14"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NZUVSQHN2ESHMJXNQ2Z7T2EELBB5HJXG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAEHE2S2QLO4AO4MEEYL75NB7SAH5PSL"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NZUVSQHN2ESHMJXNQ2Z7T2EELBB5HJXG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DAEHE2S2QLO4AO4MEEYL75NB7SAH5PSL"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/12/msg00029.html"
    },
    {
      "type": "WEB",
      "url": "https://curl.se/docs/CVE-2020-8286.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-200951.pdf"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2021/Apr/50"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2021/Apr/51"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2021/Apr/54"
    }
  ],
  "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-XH6R-VR44-6R8X

Vulnerability from github – Published: 2024-10-18 09:31 – Updated: 2024-10-22 18:32
VLAI
Details

A vulnerability has been identified in Bitdefender Total Security HTTPS scanning functionality where the software fails to properly validate website certificates. Specifically, if a site certificate lacks the "Server Authentication" specification in the Extended Key Usage extension, the product does not verify the certificate's compliance with the site, deeming such certificates as valid. This flaw could allow an attacker to perform a Man-in-the-Middle (MITM) attack, intercepting and potentially altering communications between the user and the website.

Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
8.6 (High)
CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-6055"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-18T08:15:03Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in Bitdefender Total Security HTTPS scanning functionality where the software fails to properly validate website certificates. Specifically, if a site certificate lacks the \"Server Authentication\" specification in the Extended Key Usage extension, the product does not verify the certificate\u0027s compliance with the site, deeming such certificates as valid. This flaw could allow an attacker to perform a Man-in-the-Middle (MITM) attack, intercepting and potentially altering communications between the user and the website.",
  "id": "GHSA-xh6r-vr44-6r8x",
  "modified": "2024-10-22T18:32:05Z",
  "published": "2024-10-18T09:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6055"
    },
    {
      "type": "WEB",
      "url": "https://bitdefender.com/support/security-advisories/improper-certificate-validation-in-bitdefender-total-security-https-scanning-va-11158"
    }
  ],
  "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:A/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:H/SI:H/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-XJ36-6XC6-8P9X

Vulnerability from github – Published: 2024-03-06 18:30 – Updated: 2024-11-14 22:43
VLAI
Summary
Jenkins Delphix Plugin has SSL/TLS certificate validation disabled by default
Details

In Jenkins Delphix Plugin 3.0.1, a global option for administrators to enable or disable SSL/TLS certificate validation for Data Control Tower (DCT) connections is disabled by default.

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:delphix"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.1"
            },
            {
              "fixed": "3.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.0.1"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-28161"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-06T20:14:33Z",
    "nvd_published_at": "2024-03-06T17:15:11Z",
    "severity": "MODERATE"
  },
  "details": "In Jenkins Delphix Plugin 3.0.1, a global option for administrators to enable or disable SSL/TLS certificate validation for Data Control Tower (DCT) connections is disabled by default.",
  "id": "GHSA-xj36-6xc6-8p9x",
  "modified": "2024-11-14T22:43:27Z",
  "published": "2024-03-06T18:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28161"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/delphix-plugin/commit/5a7c027098b7b4f2f7dabfe3912ccd70af52d0cd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/delphix-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2024-03-06/#SECURITY-3215"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/03/06/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Delphix Plugin has SSL/TLS certificate validation disabled by default"
}

GHSA-XM5M-WGH2-RRG3

Vulnerability from github – Published: 2026-04-14 01:01 – Updated: 2026-04-24 20:43
VLAI
Summary
Sigstore Timestamp Authority has Improper Certificate Validation in verifier
Details

Authorization bypass via certificate bag manipulation in sigstore/timestamp-authority verifier

An authorization bypass vulnerability exists in sigstore/timestamp-authority verifier (timestamp-authority/v2/pkg/verification): VerifyTimestampResponse function correctly verifies the certificate chain but when the TSA specific constraints are verified in VerifyLeafCert, the first non-CA certificate from the PKCS#7 certificate bag is used instead of the leaf certificate from the certificate chain. An attacker can exploit this by prepending a forged certificate to the certificate bag while the message is signed with an authorized key. The library validates the signature using the one certificate but performs authorization checks on the another, allowing an attacker to bypass some authorization controls.

This vulnerability does not apply to timestamp-authority service, only to users of timestamp-authority/v2/pkg/verification package.

This vulnerability does not apply to sigstore-go even though it is a user of timestamp-authority/v2/pkg/verification: Providing TSACertificate option to VerifyTimestampResponse fully mitigates the issue.

Patches

The issue will be fixed in timestamp-authority 2.0.6

Workarounds

Users of VerifyTimestampResponse can use the TSACertificate option to specify the exact certificate they expect to be used: this fully mitigates the issue.

References

This issue was found after reading CVE-2026-33753 / GHSA-3xxc-pwj6-jgrj (originally reported by @Jaynornj and @Pr00fOf3xpl0it)

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.5"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/timestamp-authority/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39984"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T01:01:59Z",
    "nvd_published_at": "2026-04-15T04:17:40Z",
    "severity": "MODERATE"
  },
  "details": "### Authorization bypass via certificate bag manipulation in sigstore/timestamp-authority verifier\n\nAn authorization bypass vulnerability exists in sigstore/timestamp-authority verifier (timestamp-authority/v2/pkg/verification): `VerifyTimestampResponse` function correctly verifies the certificate chain but when the TSA specific constraints are verified in `VerifyLeafCert`, the first non-CA certificate from the PKCS#7 certificate bag is used instead of the leaf certificate from the certificate chain. An attacker can exploit this by prepending a forged certificate to the certificate bag while the message is signed with an authorized key. The library validates the signature using the one certificate but performs authorization checks on the another, allowing an attacker to bypass some authorization controls. \n\nThis vulnerability does **not** apply to timestamp-authority service, only to users of `timestamp-authority/v2/pkg/verification` package.\n\nThis vulnerability does **not** apply to sigstore-go even though it is a user of `timestamp-authority/v2/pkg/verification`: Providing `TSACertificate` option to  `VerifyTimestampResponse` fully mitigates the issue.\n\n\n### Patches\n\nThe issue will be fixed in timestamp-authority 2.0.6\n\n### Workarounds\n\nUsers of `VerifyTimestampResponse` can use the `TSACertificate` option to specify the exact certificate they expect to be used: this fully mitigates the issue.\n\n### References\n\nThis issue was found after reading CVE-2026-33753 / GHSA-3xxc-pwj6-jgrj (originally reported by @Jaynornj and @Pr00fOf3xpl0it)",
  "id": "GHSA-xm5m-wgh2-rrg3",
  "modified": "2026-04-24T20:43:09Z",
  "published": "2026-04-14T01:01:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/timestamp-authority/security/advisories/GHSA-xm5m-wgh2-rrg3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39984"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/timestamp-authority"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/timestamp-authority/releases/tag/v2.0.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sigstore Timestamp Authority has Improper Certificate Validation in verifier"
}

GHSA-XM87-MJ3J-9PPW

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

The YottaMark ShopWell - Healthy Diet & Grocery Food Scanner app 5.3.7 through 5.4.2 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.

Severity
5.9 (Medium)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-8942"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-15T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The YottaMark ShopWell - Healthy Diet \u0026 Grocery Food Scanner app 5.3.7 through 5.4.2 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-xm87-mj3j-9ppw",
  "modified": "2025-04-20T03:37:44Z",
  "published": "2022-05-17T02:43:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8942"
    },
    {
      "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"
    }
  ]
}
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.

← Back to the CWE list