Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

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

1911 vulnerabilities reference this CWE, most recent first.

GHSA-4JJ9-CGQC-X9H5

Vulnerability from github – Published: 2025-12-12 19:22 – Updated: 2026-01-08 20:51
VLAI
Summary
NeuVector OpenID Connect is vulnerable to man-in-the-middle (MITM)
Details

Impact

NeuVector supports login authentication through OpenID Connect. However, the TLS verification (which verifies the remote server's authenticity and integrity) for OpenID Connect is not enforced by default. As a result this may expose the system to man-in-the-middle (MITM) attacks. Starting from version 5.4.0, NeuVector supports TLS verification for following connection types:

  • Registry Connections
  • Auth Server Connections (SAML, LDAP and OIDC)
  • Webhook Connections

By default, TLS verification remains disabled, and its configuration is located under Settings > Configuration in the NeuVector UI.

In the patched version, the new NeuVector deployment enables TLS verification by default. For rolling upgrades, NeuVector does not automatically change this setting to prevent disruptions.

Note: When "TLS verification" is enabled, it affects all connections to:

  • Registry servers
  • Auth servers (SAML, LDAP and OIDC)
  • Webhook servers

Patches

Patched versions include release v5.4.8 and above.

Workarounds

To manually enable TLS verification:

  1. Open the NeuVector UI.
  2. Navigate to Settings > Configuration.
  3. In the TLS Self-Signed Certificate Configuration section, select Enable TLS verification.
  4. (Optional) Upload or paste the TLS self-signed certificate.

References

If you have any questions or comments about this advisory:

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/neuvector/neuvector"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.3.0"
            },
            {
              "fixed": "5.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66001"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-12T19:22:04Z",
    "nvd_published_at": "2026-01-08T11:15:43Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nNeuVector supports login authentication through OpenID Connect. However, the TLS verification (which verifies the remote server\u0027s authenticity and integrity) for OpenID Connect is not enforced by default. As a result this may expose the system to man-in-the-middle (MITM) attacks.\nStarting from version 5.4.0, NeuVector supports TLS verification for following connection types:\n\n- Registry Connections\n- Auth Server Connections (SAML, LDAP and OIDC)\n- Webhook Connections\n\nBy default, TLS verification remains disabled, and its configuration is located under **Settings \u003e Configuration in the NeuVector UI**.\n\nIn the patched version, the new NeuVector deployment enables TLS verification by default. \nFor rolling upgrades, NeuVector does not automatically change this setting to prevent disruptions.\n\n**Note:** When \"TLS verification\" is enabled, it affects all connections to:\n\n- Registry servers\n- Auth servers (SAML, LDAP and OIDC)\n- Webhook servers\n\n### Patches\n\nPatched versions include release v5.4.8 and above.\n\n### Workarounds\n\nTo manually enable TLS verification:\n\n1. Open the NeuVector UI.\n2. Navigate to **Settings \u003e Configuration**.\n3. In the **TLS Self-Signed Certificate Configuration** section, select **Enable TLS verification**.\n4. (Optional) Upload or paste the **TLS self-signed certificate**.\n\n### References\n\nIf you have any questions or comments about this advisory:\n\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 [NeuVector](https://github.com/neuvector/neuvector/issues/new/choose) repository.\n- Verify with our [support matrix](https://www.suse.com/suse-neuvector/support-matrix/all-supported-versions/neuvector-v-all-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/#suse-security).",
  "id": "GHSA-4jj9-cgqc-x9h5",
  "modified": "2026-01-08T20:51:32Z",
  "published": "2025-12-12T19:22:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/neuvector/neuvector/security/advisories/GHSA-4jj9-cgqc-x9h5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66001"
    },
    {
      "type": "WEB",
      "url": "https://github.com/neuvector/neuvector/commit/955904b5762f296d209bf395a5fcc7a40a53c424"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2025-66001"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/neuvector/neuvector"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NeuVector OpenID Connect is vulnerable to man-in-the-middle (MITM)"
}

GHSA-4JMM-C6JW-G796

Vulnerability from github – Published: 2024-07-31 21:32 – Updated: 2024-09-06 21:37
VLAI
Summary
Filestash configured to skip TLS certificate verification when using the FTPS protocol
Details

filestash v0.4 is configured to skip TLS certificate verification when using the FTPS protocol, possibly allowing attackers to execute a man-in-the-middle attack via the Init function of index.go.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mickael-kerjean/filestash"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-41255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-453"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-02T16:27:35Z",
    "nvd_published_at": "2024-07-31T21:15:18Z",
    "severity": "HIGH"
  },
  "details": "filestash v0.4 is configured to skip TLS certificate verification when using the FTPS protocol, possibly allowing attackers to execute a man-in-the-middle attack via the Init function of index.go.",
  "id": "GHSA-4jmm-c6jw-g796",
  "modified": "2024-09-06T21:37:51Z",
  "published": "2024-07-31T21:32:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41255"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mickael-kerjean/filestash/issues/710"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/nyxfqq/c367f2ca9448810924dcf0f1af30b441"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-4jmm-c6jw-g796"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mickael-kerjean/filestash"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mickael-kerjean/filestash/blob/master/server/plugin/plg_backend_ftp/index.go#L108"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-3033"
    }
  ],
  "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:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Filestash configured to skip TLS certificate verification when using the FTPS protocol"
}

GHSA-4JQP-9QJV-57M2

Vulnerability from github – Published: 2026-02-06 22:34 – Updated: 2026-06-06 00:37
VLAI
Summary
Keylime Missing Authentication for Critical Function and Improper Authentication
Details

Impact

The Keylime registrar does not enforce mutual TLS (mTLS) client certificate authentication since version 7.12.0. The registrar's TLS context is configured with ssl.CERT_OPTIONAL instead of ssl.CERT_REQUIRED, allowing any client to connect to protected API endpoints without presenting a valid client certificate.

Who is impacted: - All Keylime deployments running versions 7.12.0 through 7.13.0 - Environments where the registrar HTTPS port (default 8891) is network-accessible to untrusted clients

What an attacker can do: - List all registered agents (GET /v2/agents/) - enumerate the entire agent inventory - Retrieve agent details (GET /v2/agents/{uuid}) - obtain public TPM keys, certificates, and network locations (IP/port) of any agent - Delete any agent (DELETE /v2/agents/{uuid}) - remove agents from the registry, disrupting attestation services

Note: The exposed TPM data (EK, AK, certificates) consists of public keys and certificates. Private keys remain protected within TPM hardware. The HMAC secret used for challenge-response validation is stored in the database but is not exposed via the API.

Affected versions: >= 7.12.0, <= 7.13.0

Fixed versions: 7.12.2, >= 7.13.1

Patches

A patch for the affected released versions is available. It removes the line that override the configuration of ssl.verify_mode, leaving the CERT_REQUIRED value set by web_util.init_mtls():

diff --git a/keylime/web/base/server.py b/keylime/web/base/server.py
index 1d9a9c2..859b23a 100644
--- a/keylime/web/base/server.py
+++ b/keylime/web/base/server.py
@@ -2,7 +2,6 @@ import asyncio
 import multiprocessing
 from abc import ABC, abstractmethod
 from functools import wraps
-from ssl import CERT_OPTIONAL
 from typing import TYPE_CHECKING, Any, Callable, Optional

 import tornado
@@ -252,7 +251,6 @@ class Server(ABC):
         self._https_port = config.getint(component, "tls_port", fallback=0)
         self._max_upload_size = config.getint(component, "max_upload_size", fallback=104857600)
         self._ssl_ctx = web_util.init_mtls(component)
-        self._ssl_ctx.verify_mode = CERT_OPTIONAL

     def _get(self, pattern: str, controller: type["Controller"], action: str, allow_insecure: bool = False) -> None:
         """Creates a new route to handle incoming GET requests issued for paths which match the given

Users should upgrade to the patched version once it is released.

Workarounds

If upgrading is not immediately possible, apply one of the following mitigations:

1. Network isolation (Recommended)

Restrict access to the registrar HTTPS port (default 8891) using firewall rules to allow only trusted hosts (verifier, tenant):

Example using iptables
iptables -A INPUT -p tcp --dport 8891 -s <verifier_ip> -j ACCEPT
iptables -A INPUT -p tcp --dport 8891 -s <tenant_ip> -j ACCEPT
iptables -A INPUT -p tcp --dport 8891 -j DROP

2. Reverse proxy with mTLS enforcement

Deploy a reverse proxy (nginx, HAProxy) in front of the registrar that enforces client certificate authentication:

Example nginx configuration
server {
    listen 8891 ssl;
    ssl_certificate /path/to/server.crt;
    ssl_certificate_key /path/to/server.key;
    ssl_client_certificate /path/to/ca.crt;
    ssl_verify_client on;  # Enforce client certificates

    location / {
        proxy_pass https://localhost:8892;  # Internal registrar port
    }
}
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keylime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.12.0"
            },
            {
              "fixed": "7.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keylime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.13.0"
            },
            {
              "fixed": "7.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "7.13.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-1709"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-06T22:34:44Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nThe Keylime registrar does not enforce mutual TLS (mTLS) client certificate authentication since version 7.12.0. The registrar\u0027s TLS context is configured with `ssl.CERT_OPTIONAL` instead of `ssl.CERT_REQUIRED`, allowing any client to connect to protected API endpoints without presenting a valid client certificate.\n\n**Who is impacted:**\n  - All Keylime deployments running versions 7.12.0 through 7.13.0\n  - Environments where the registrar HTTPS port (default 8891) is network-accessible to untrusted clients\n\n**What an attacker can do:**\n  - **List all registered agents** (`GET /v2/agents/`) - enumerate the entire agent inventory\n  - **Retrieve agent details** (`GET /v2/agents/{uuid}`) - obtain public TPM keys, certificates, and network locations (IP/port) of any agent\n  - **Delete any agent** (`DELETE /v2/agents/{uuid}`) - remove agents from the registry, disrupting attestation services\n\nNote: The exposed TPM data (EK, AK, certificates) consists of public keys and certificates. Private keys remain protected within TPM hardware. The HMAC secret used for challenge-response validation is stored in the database but is not exposed via the API.\n\n**Affected versions:** \u003e= 7.12.0, \u003c= 7.13.0\n\n**Fixed versions:** 7.12.2, \u003e= 7.13.1\n\n### Patches\n\nA patch for the affected released versions is available. It removes the line that override the configuration of `ssl.verify_mode`, leaving the `CERT_REQUIRED` value set by `web_util.init_mtls()`:\n\n```diff\ndiff --git a/keylime/web/base/server.py b/keylime/web/base/server.py\nindex 1d9a9c2..859b23a 100644\n--- a/keylime/web/base/server.py\n+++ b/keylime/web/base/server.py\n@@ -2,7 +2,6 @@ import asyncio\n import multiprocessing\n from abc import ABC, abstractmethod\n from functools import wraps\n-from ssl import CERT_OPTIONAL\n from typing import TYPE_CHECKING, Any, Callable, Optional\n\n import tornado\n@@ -252,7 +251,6 @@ class Server(ABC):\n         self._https_port = config.getint(component, \"tls_port\", fallback=0)\n         self._max_upload_size = config.getint(component, \"max_upload_size\", fallback=104857600)\n         self._ssl_ctx = web_util.init_mtls(component)\n-        self._ssl_ctx.verify_mode = CERT_OPTIONAL\n\n     def _get(self, pattern: str, controller: type[\"Controller\"], action: str, allow_insecure: bool = False) -\u003e None:\n         \"\"\"Creates a new route to handle incoming GET requests issued for paths which match the given\n```\n\nUsers should upgrade to the patched version once it is released.\n\n### Workarounds\n\nIf upgrading is not immediately possible, apply one of the following mitigations:\n\n#### 1. Network isolation (Recommended)\n\nRestrict access to the registrar HTTPS port (default 8891) using firewall rules\nto allow only trusted hosts (verifier, tenant):\n\n##### Example using iptables\n```\niptables -A INPUT -p tcp --dport 8891 -s \u003cverifier_ip\u003e -j ACCEPT\niptables -A INPUT -p tcp --dport 8891 -s \u003ctenant_ip\u003e -j ACCEPT\niptables -A INPUT -p tcp --dport 8891 -j DROP\n```\n\n#### 2. Reverse proxy with mTLS enforcement\n\nDeploy a reverse proxy (nginx, HAProxy) in front of the registrar that enforces client certificate authentication:\n\n##### Example nginx configuration\n```\nserver {\n    listen 8891 ssl;\n    ssl_certificate /path/to/server.crt;\n    ssl_certificate_key /path/to/server.key;\n    ssl_client_certificate /path/to/ca.crt;\n    ssl_verify_client on;  # Enforce client certificates\n\n    location / {\n        proxy_pass https://localhost:8892;  # Internal registrar port\n    }\n}\n```",
  "id": "GHSA-4jqp-9qjv-57m2",
  "modified": "2026-06-06T00:37:09Z",
  "published": "2026-02-06T22:34:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/security/advisories/GHSA-4jqp-9qjv-57m2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1709"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2224"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2225"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2298"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-1709"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2435514"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keylime/keylime"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/keylime/PYSEC-2026-74.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Keylime Missing Authentication for Critical Function and Improper Authentication"
}

GHSA-4JWR-Q2V5-WG73

Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2022-02-12 00:00
VLAI
Details

In Preloader XFLASH, there is a possible escalation of privilege due to an improper certificate validation. This could lead to local escalation of privilege for an attacker who has physical access to the device with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS06160806; Issue ID: ALPS06160806.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-20034"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-09T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Preloader XFLASH, there is a possible escalation of privilege due to an improper certificate validation. This could lead to local escalation of privilege for an attacker who has physical access to the device with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS06160806; Issue ID: ALPS06160806.",
  "id": "GHSA-4jwr-q2v5-wg73",
  "modified": "2022-02-12T00:00:52Z",
  "published": "2022-02-11T00:00:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20034"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/February-2022"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4M6F-X2GC-6FGQ

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

An improper certificate validation vulnerability has been reported to affect File Station 5. If exploited, the vulnerability could allow remote attackers who have gained user access to compromise the security of the system.

We have already fixed the vulnerability in the following versions: File Station 5 5.5.6.4791 and later and later

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-22486"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-06T16:15:24Z",
    "severity": "HIGH"
  },
  "details": "An improper certificate validation vulnerability has been reported to affect File Station 5. If exploited, the vulnerability could allow remote attackers who have gained user access to compromise the security of the system.\n\nWe have already fixed the vulnerability in the following versions:\nFile Station 5 5.5.6.4791 and later\n  and later",
  "id": "GHSA-4m6f-x2gc-6fgq",
  "modified": "2025-06-18T18:30:30Z",
  "published": "2025-06-06T18:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22486"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/en/security-advisory/qsa-25-09"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/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:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-4M7M-7666-WR24

Vulnerability from github – Published: 2022-05-14 03:30 – Updated: 2022-05-14 03:30
VLAI
Details

On F5 BIG-IP versions 13.0.0 - 13.1.0.3, attackers may be able to disrupt services on the BIG-IP system with maliciously crafted client certificate. This vulnerability affects virtual servers associated with Client SSL profile which enables the use of client certificate authentication. Client certificate authentication is not enabled by default in Client SSL profile. There is no control plane exposure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-5502"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-03-22T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "On F5 BIG-IP versions 13.0.0 - 13.1.0.3, attackers may be able to disrupt services on the BIG-IP system with maliciously crafted client certificate. This vulnerability affects virtual servers associated with Client SSL profile which enables the use of client certificate authentication. Client certificate authentication is not enabled by default in Client SSL profile. There is no control plane exposure.",
  "id": "GHSA-4m7m-7666-wr24",
  "modified": "2022-05-14T03:30:14Z",
  "published": "2022-05-14T03:30:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5502"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K43121447"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1040561"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4MCW-V943-57XW

Vulnerability from github – Published: 2023-06-13 09:30 – Updated: 2024-04-04 04:45
VLAI
Details

An improper certificate validation vulnerability [CWE-295] in FortiOS 6.2 all versions, 6.4 all versions, 7.0.0 through 7.0.10, 7.2.0 and FortiProxy 1.2 all versions, 2.0 all versions, 7.0.0 through 7.0.9, 7.2.0 through 7.2.3 may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the vulnerable device and the remote FortiGuard's map server.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-29175"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-13T09:15:17Z",
    "severity": "MODERATE"
  },
  "details": "An improper certificate validation vulnerability [CWE-295] in FortiOS 6.2 all versions, 6.4 all versions, 7.0.0 through 7.0.10, 7.2.0 and FortiProxy 1.2 all versions, 2.0 all versions, 7.0.0 through 7.0.9, 7.2.0 through 7.2.3 may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the vulnerable device and the remote\u00a0FortiGuard\u0027s map server.",
  "id": "GHSA-4mcw-v943-57xw",
  "modified": "2024-04-04T04:45:51Z",
  "published": "2023-06-13T09:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29175"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/psirt/FG-IR-22-468"
    }
  ],
  "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"
    }
  ]
}

GHSA-4MF2-C3H2-MQ3P

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

Potentially, SAP Cloud Connector, version - 2.0 communication with the backend is accepted without sufficient validation of the certificate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-33695"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-15T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Potentially, SAP Cloud Connector, version - 2.0 communication with the backend is accepted without sufficient validation of the certificate.",
  "id": "GHSA-4mf2-c3h2-mq3p",
  "modified": "2022-05-24T19:14:35Z",
  "published": "2022-05-24T19:14:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33695"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3058553"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=582222806"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4MF5-3RXX-7P8F

Vulnerability from github – Published: 2024-07-01 06:31 – Updated: 2024-08-01 15:31
VLAI
Details

In gnss service, there is a possible escalation of privilege due to improper certificate validation. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08720039; Issue ID: MSV-1424.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-20080"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-01T05:15:04Z",
    "severity": "CRITICAL"
  },
  "details": "In gnss service, there is a possible escalation of privilege due to improper certificate validation. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08720039; Issue ID: MSV-1424.",
  "id": "GHSA-4mf5-3rxx-7p8f",
  "modified": "2024-08-01T15:31:51Z",
  "published": "2024-07-01T06:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20080"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/July-2024"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4MV8-3862-HGHV

Vulnerability from github – Published: 2022-06-16 00:00 – Updated: 2022-06-25 00:01
VLAI
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.

Show details on source website

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

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.