Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

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

2019 vulnerabilities reference this CWE, most recent first.

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.

Show details on source website

{
  "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.

Show details on source website

{
  "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)

Show details on source website

{
  "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.

Show details on source website

{
  "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"
    }
  ]
}

GHSA-XM9F-FPH8-8369

Vulnerability from github – Published: 2023-03-24 21:30 – Updated: 2025-10-22 00:32
VLAI
Details

In WorkSource, there is a possible parcel mismatch. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11 Android-12 Android-12L Android-13Android ID: A-220302519

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-20963"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-24T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "In WorkSource, there is a possible parcel mismatch. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11 Android-12 Android-12L Android-13Android ID: A-220302519",
  "id": "GHSA-xm9f-fph8-8369",
  "modified": "2025-10-22T00:32:43Z",
  "published": "2023-03-24T21:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20963"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2023-03-01"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-20963"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XMCJ-8JMG-P5PR

Vulnerability from github – Published: 2026-08-25 18:31 – Updated: 2026-08-25 18:31
VLAI
Details

X-AnyLabeling's model downloader disabled TLS certificate verification. download_with_retry in anylabeling/services/auto_labeling/model.py built a context with ssl._create_unverified_context() and passed it to urllib.request.urlopen, so neither the certificate chain nor the hostname was checked on any model download, and models are fetched over HTTPS from the project's release host. Any party positioned to intercept that connection could therefore answer it with content of their own choosing. The response is written to a .part file and moved into place with os.replace, and the only post-download check, safe_check_model, validates the file's format rather than its provenance: no hash or signature is compared against an expected value. For an ONNX target the substituted file passes onnx.checker.check_model and is then used for inference, so the attacker chooses the model that produces the application's annotations. For a .pth or .pt target, which the shipped SAM2 video, YOLOE, UPN and open_vision configurations use, the check worker calls torch.load without weights_only, so a substituted file is unpickled and executes code of the attacker's choosing on PyTorch releases predating the weights_only default.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-79785"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T16:17:30Z",
    "severity": "HIGH"
  },
  "details": "X-AnyLabeling\u0027s model downloader disabled TLS certificate verification. download_with_retry in anylabeling/services/auto_labeling/model.py built a context with ssl._create_unverified_context() and passed it to urllib.request.urlopen, so neither the certificate chain nor the hostname was checked on any model download, and models are fetched over HTTPS from the project\u0027s release host. Any party positioned to intercept that connection could therefore answer it with content of their own choosing. The response is written to a .part file and moved into place with os.replace, and the only post-download check, safe_check_model, validates the file\u0027s format rather than its provenance: no hash or signature is compared against an expected value. For an ONNX target the substituted file passes onnx.checker.check_model and is then used for inference, so the attacker chooses the model that produces the application\u0027s annotations. For a .pth or .pt target, which the shipped SAM2 video, YOLOE, UPN and open_vision configurations use, the check worker calls torch.load without weights_only, so a substituted file is unpickled and executes code of the attacker\u0027s choosing on PyTorch releases predating the weights_only default.",
  "id": "GHSA-xmcj-8jmg-p5pr",
  "modified": "2026-08-25T18:31:54Z",
  "published": "2026-08-25T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79785"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CVHub520/X-AnyLabeling/commit/52f7c30333f3f99711f09334d740212aa30b9958"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CVHub520/X-AnyLabeling"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CVHub520/X-AnyLabeling/blob/v4.0.0-beta.8/anylabeling/services/auto_labeling/model.py"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CVHub520/X-AnyLabeling/releases/tag/v4.0.0-beta.9"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/x-anylabeling-cvhub"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/x-anylabeling-before-4.0.0-beta.9-improper-certificate-validation-in-model-downloads"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/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-XMM7-85WH-J3JF

Vulnerability from github – Published: 2022-08-26 00:03 – Updated: 2022-09-01 00:00
VLAI
Details

Odyssey passes to client unencrypted bytes from man-in-the-middle When Odyssey storage is configured to use the PostgreSQL server using 'trust' authentication with a 'clientcert' requirement or to use 'cert' authentication, a man-in-the-middle attacker can inject false responses to the client's first few queries. Despite the use of SSL certificate verification and encryption, Odyssey will pass these results to client as if they originated from valid server. This is similar to CVE-2021-23222 for PostgreSQL.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-43767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-25T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Odyssey passes to client unencrypted bytes from man-in-the-middle When Odyssey storage is configured to use the PostgreSQL server using \u0027trust\u0027 authentication with a \u0027clientcert\u0027 requirement or to use \u0027cert\u0027 authentication, a man-in-the-middle attacker can inject false responses to the client\u0027s first few queries. Despite the use of SSL certificate verification and encryption, Odyssey will pass these results to client as if they originated from valid server. This is similar to CVE-2021-23222 for PostgreSQL.",
  "id": "GHSA-xmm7-85wh-j3jf",
  "modified": "2022-09-01T00:00:22Z",
  "published": "2022-08-26T00:03:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43767"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yandex/odyssey/issues/377,"
    },
    {
      "type": "WEB",
      "url": "https://www.postgresql.org/support/security/CVE-2021-23222"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XMQV-PFW7-QMJ7

Vulnerability from github – Published: 2022-05-24 16:47 – Updated: 2023-10-26 22:18
VLAI
Summary
Jenkins ElectricFlow Plugin globally and unconditionally disabled SSL/TLS certificate validation
Details

CloudBees CD Plugin unconditionally disabled SSL/TLS certificate validation for the entire Jenkins controller JVM during the deployment/publication of an application.

CloudBees CD Plugin no longer does that. Instead, the existing opt-in option to ignore SSL/TLS errors is used during deployment for the specific connection.

This issue was caused by an incomplete fix for SECURITY-937.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.6"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:electricflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10334"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-26T22:18:30Z",
    "nvd_published_at": "2019-06-11T14:29:00Z",
    "severity": "MODERATE"
  },
  "details": "CloudBees CD Plugin unconditionally disabled SSL/TLS certificate validation for the entire Jenkins controller JVM during the deployment/publication of an application.\n\nCloudBees CD Plugin no longer does that. Instead, the existing opt-in option to ignore SSL/TLS errors is used during deployment for the specific connection.\n\nThis issue was caused by an incomplete fix for [SECURITY-937](https://www.jenkins.io/security/advisory/2019-02-19/#SECURITY-937).",
  "id": "GHSA-xmqv-pfw7-qmj7",
  "modified": "2023-10-26T22:18:30Z",
  "published": "2022-05-24T16:47:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10334"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/electricflow-plugin/commit/d0b807d5e2de07a90d902401bae033c2907b850a"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-06-11/#SECURITY-1411"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200227033720/http://www.securityfocus.com/bid/108747"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/06/11/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins ElectricFlow Plugin globally and unconditionally disabled SSL/TLS certificate validation"
}

GHSA-XP29-43PM-7R9G

Vulnerability from github – Published: 2026-02-12 12:31 – Updated: 2026-02-12 15:32
VLAI
Details

The affected devices do not validate the server certificate when connecting to the SolaX Cloud MQTTS server hosted in the Alibaba Cloud (mqtt001.solaxcloud.com, TCP 8883). This allows attackers in a man-in-the-middle position to act as the legitimate MQTT server and issue arbitrary commands to devices.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-15573"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-12T11:15:47Z",
    "severity": "CRITICAL"
  },
  "details": "The affected devices do not validate the server certificate when connecting to the SolaX Cloud MQTTS server hosted in the Alibaba Cloud (mqtt001.solaxcloud.com, TCP 8883). This allows attackers in a man-in-the-middle position to act as the legitimate MQTT server and issue arbitrary commands to devices.",
  "id": "GHSA-xp29-43pm-7r9g",
  "modified": "2026-02-12T15:32:47Z",
  "published": "2026-02-12T12:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15573"
    },
    {
      "type": "WEB",
      "url": "https://r.sec-consult.com/solax"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XP43-GQWV-MMJP

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

Heimdal Thor Agent 2.5.17x before 2.5.173 does not verify X.509 certificates from TLS servers, which allows remote attackers to spoof servers and obtain sensitive information via a crafted certificate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-8351"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-21T21:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Heimdal Thor Agent 2.5.17x before 2.5.173 does not verify X.509 certificates from TLS servers, which allows remote attackers to spoof servers and obtain sensitive information via a crafted certificate.",
  "id": "GHSA-xp43-gqwv-mmjp",
  "modified": "2022-05-14T01:15:47Z",
  "published": "2022-05-14T01:15:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8351"
    },
    {
      "type": "WEB",
      "url": "https://support.heimdalsecurity.com/hc/en-us/articles/360001084158-Release-2-5-172-PROD-Update"
    }
  ],
  "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: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.