Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

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

2208 vulnerabilities reference this CWE, most recent first.

GHSA-HVX2-XH3R-XCR6

Vulnerability from github – Published: 2026-09-08 12:31 – Updated: 2026-09-08 12:31
VLAI
Details

A flaw was found in hawtio-operator. The operator reads the OpenShift Service CA private signing key from the openshift-service-ca namespace and uses it to mint client certificates with a Subject Common Name (CN) supplied by the author of a namespaced Hawtio custom resource. Because the operator ships a ClusterRole that aggregates Hawtio CR permissions into the edit and admin roles, any user with edit access in any namespace can obtain a Service-CA-signed certificate with an arbitrary subject. This certificate can be used to impersonate any in-cluster service identity to peers that trust the Service CA for client authentication, including Jolokia agents and other Service-CA-trusting components.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-78234"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T12:16:59Z",
    "severity": "CRITICAL"
  },
  "details": "A flaw was found in hawtio-operator. The operator reads the OpenShift Service CA private signing key from the openshift-service-ca namespace and uses it to mint client certificates with a Subject Common Name (CN) supplied by the author of a namespaced Hawtio custom resource. Because the operator ships a ClusterRole that aggregates Hawtio CR permissions into the edit and admin roles, any user with edit access in any namespace can obtain a Service-CA-signed certificate with an arbitrary subject. This certificate can be used to impersonate any in-cluster service identity to peers that trust the Service CA for client authentication, including Jolokia agents and other Service-CA-trusting components.",
  "id": "GHSA-hvx2-xh3r-xcr6",
  "modified": "2026-09-08T12:31:30Z",
  "published": "2026-09-08T12:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78234"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-78234"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2524894"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HW2C-8PMG-PX6W

Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42
VLAI
Details

core/imap/MCIMAPSession.cpp in Canary Mail before 3.22 has Missing SSL Certificate Validation for IMAP in STARTTLS mode.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-26911"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-17T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "core/imap/MCIMAPSession.cpp in Canary Mail before 3.22 has Missing SSL Certificate Validation for IMAP in STARTTLS mode.",
  "id": "GHSA-hw2c-8pmg-px6w",
  "modified": "2022-05-24T17:42:34Z",
  "published": "2022-05-24T17:42:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26911"
    },
    {
      "type": "WEB",
      "url": "https://github.com/canarymail/mailcore2/commit/45acb4efbcaa57a20ac5127dc976538671fce018"
    },
    {
      "type": "WEB",
      "url": "https://apps.apple.com/us/app/canary-mail/id1236045954"
    },
    {
      "type": "WEB",
      "url": "https://census-labs.com/news/2021/02/17/canary-mail-app-missing-certificate-validation-check-on-imap-starttls"
    },
    {
      "type": "WEB",
      "url": "https://census-labs.com/news/category/advisories"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2021/02/17/3"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/02/17/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-HWCC-4CV8-CF3H

Vulnerability from github – Published: 2023-12-22 19:51 – Updated: 2023-12-22 19:51
VLAI
Summary
Snowflake Connector .NET does not properly check the Certificate Revocation List (CRL)
Details

Issue

Snowflake recently received a report about a vulnerability in the Snowflake Connector .NET where the checks against the Certificate Revocation List (CRL) were not performed where the insecureMode flag was set to false, which is the default setting. The vulnerability affects versions between 2.0.25 and 2.1.4 (inclusive). Snowflake fixed the issue in version 2.1.5.

Attack Scenario

Snowflake uses CRL to check if a TLS certificate has been revoked before its expiration date. The lack of correct validation of revoked certificates could, in theory, allow an attacker who has both access to the private key of a correctly issued Snowflake certificate and the ability to intercept network traffic to perform a Man-in-the-Middle (MitM) attack in order to compromise Snowflake credentials used by the driver.

The vulnerability is difficult to exploit given both conditions required and, at the time of this advisory's publication, Snowflake is not aware of any compromise of its certificates, nor unauthorized issuance of such by any publicly trusted Certificate Authority (CA). However, an upgrade to the newest version is recommended to ensure the highest level of security and protection against future unforeseen threats.

Solution

On December 18, 2023, Snowflake released version 2.1.5 of the Snowflake Connector .NET, which fixes the issue, and we recommend users upgrade to version 2.1.5. Customers continuing to use the impacted versions of the connector should update their insecureMode flag to true.

Acknowledgement

Snowflake would like to thank Timo Vink for reporting this vulnerability.

Additional Information

If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.4"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Snowflake.Data"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.25"
            },
            {
              "fixed": "2.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-51662"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-22T19:51:09Z",
    "nvd_published_at": "2023-12-22T17:15:10Z",
    "severity": "MODERATE"
  },
  "details": "### Issue\nSnowflake recently received a report about a vulnerability in the Snowflake Connector .NET where the checks against the Certificate Revocation List (CRL) were not performed where the insecureMode flag was set to false, which is the default setting. The vulnerability affects versions between 2.0.25 and 2.1.4 (inclusive). Snowflake fixed the issue in [version 2.1.5](https://docs.snowflake.com/release-notes/clients-drivers/dotnet-2023#version-2-1-5-december-18-2023).\n\n### Attack Scenario\nSnowflake uses CRL to check if a TLS certificate has been revoked before its expiration date. The lack of correct validation of revoked certificates could, in theory, allow an attacker who has both access to the private key of a correctly issued Snowflake certificate and the ability to intercept network traffic to perform a Man-in-the-Middle (MitM) attack in order to compromise Snowflake credentials used by the driver.\n\nThe vulnerability is difficult to exploit given both conditions required and, at the time of this advisory\u0027s publication, Snowflake is not aware of any compromise of its certificates, nor unauthorized issuance of such by any publicly trusted Certificate Authority (CA). However, an upgrade to the newest version is recommended to ensure the highest level of security and protection against future unforeseen threats.\n\n### Solution\nOn December 18, 2023, Snowflake released [version 2.1.5](https://docs.snowflake.com/release-notes/clients-drivers/dotnet-2023#version-2-1-5-december-18-2023) of the Snowflake Connector .NET, which fixes the issue, and we recommend users upgrade to [version 2.1.5](https://docs.snowflake.com/release-notes/clients-drivers/dotnet-2023#version-2-1-5-december-18-2023).  Customers continuing to use the impacted versions of the connector should update their insecureMode flag to true. \n\n### Acknowledgement\nSnowflake would like to thank [Timo Vink](https://github.com/TimoVink) for reporting this vulnerability.\n\n### Additional Information\nIf you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our [Vulnerability Disclosure Policy](https://hackerone.com/snowflake?type=team).",
  "id": "GHSA-hwcc-4cv8-cf3h",
  "modified": "2023-12-22T19:51:09Z",
  "published": "2023-12-22T19:51:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/snowflakedb/snowflake-connector-net/security/advisories/GHSA-hwcc-4cv8-cf3h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51662"
    },
    {
      "type": "WEB",
      "url": "https://github.com/snowflakedb/snowflake-connector-net/commit/49cb77ddd6e18c110eca35aa580e89d73c46cc33"
    },
    {
      "type": "WEB",
      "url": "https://docs.snowflake.com/release-notes/clients-drivers/dotnet-2023#version-2-1-5-december-18-2023"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/snowflakedb/snowflake-connector-net"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Snowflake Connector .NET does not properly check the Certificate Revocation List (CRL)"
}

GHSA-HX2W-HJ9R-4GWR

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

The mAadhaar application 1.2.7 for Android lacks SSL Certificate Validation, leading to man-in-the-middle attacks against requests for FAQs or Help.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-14516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-13T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "The mAadhaar application 1.2.7 for Android lacks SSL Certificate Validation, leading to man-in-the-middle attacks against requests for FAQs or Help.",
  "id": "GHSA-hx2w-hj9r-4gwr",
  "modified": "2024-04-04T01:37:27Z",
  "published": "2022-05-24T16:53:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14516"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fs0c131y/ConPresentations/blob/master/AppSecVillageDefcon27.mAadhaar.pdf"
    },
    {
      "type": "WEB",
      "url": "https://play.google.com/store/apps/details?id=in.gov.uidai.mAadhaarPlus\u0026hl=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HX3X-MQ59-GR7F

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

The First Citizens Community Bank fccb/id809930960 app 3.0.1 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-9563"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-16T12:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The First Citizens Community Bank fccb/id809930960 app 3.0.1 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-hx3x-mq59-gr7f",
  "modified": "2025-04-20T03:39:12Z",
  "published": "2022-05-17T02:39:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9563"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/%40chronic_9612/advisory-44-credit-union-apps-for-ios-may-allow-login-credential-exposure-4d2f380b85c5"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@chronic_9612/advisory-44-credit-union-apps-for-ios-may-allow-login-credential-exposure-4d2f380b85c5"
    }
  ],
  "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-HXC4-7759-8JQ5

Vulnerability from github – Published: 2026-09-24 21:32 – Updated: 2026-09-24 21:32
VLAI
Details

Dell ThinOS 10, versions prior to SecurityAddon_2605.10.2766_T10, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Protection mechanism bypass and Unauthorized access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-82157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-24T19:17:17Z",
    "severity": "HIGH"
  },
  "details": "Dell ThinOS 10, versions prior to SecurityAddon_2605.10.2766_T10, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Protection mechanism bypass and Unauthorized access.",
  "id": "GHSA-hxc4-7759-8jq5",
  "modified": "2026-09-24T21:32:48Z",
  "published": "2026-09-24T21:32:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82157"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000506503/dsa-2026-404-security-update-for-dell-thinos-10-for-multiple-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HXCJ-GVXH-8944

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

In GNOME libgfbgraph through 0.2.4, gfbgraph-photo.c does not enable TLS certificate verification on the SoupSessionSync objects it creates, leaving users vulnerable to network MITM attacks. NOTE: this is similar to CVE-2016-20011.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-39358"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-22T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In GNOME libgfbgraph through 0.2.4, gfbgraph-photo.c does not enable TLS certificate verification on the SoupSessionSync objects it creates, leaving users vulnerable to network MITM attacks. NOTE: this is similar to CVE-2016-20011.",
  "id": "GHSA-hxcj-gvxh-8944",
  "modified": "2022-05-24T19:11:52Z",
  "published": "2022-05-24T19:11:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39358"
    },
    {
      "type": "WEB",
      "url": "https://blogs.gnome.org/mcatanzaro/2021/05/25/reminder-soupsessionsync-and-soupsessionasync-default-to-no-tls-certificate-verification"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/libgfbgraph/-/issues/17"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GRCVZUNPTNFQQQCEZVP7RYY6OKHPDBC5"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UYI47UX6S5PAOWVWQ2KID64MCTXTH7SE"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WXXAF56BYLSES4UCLXKFCODZXTNAZ2G6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-HXP5-8PGQ-MGV9

Vulnerability from github – Published: 2021-04-22 16:14 – Updated: 2021-04-21 20:27
VLAI
Summary
Missing Authentication for Critical Function in Apache Calcite
Details

"HttpUtils#getURLConnection method disables explicitly hostname verification for HTTPS connections making clients vulnerable to man-in-the-middle attacks. Calcite uses this method internally to connect with Druid and Splunk so information leakage may happen when using the respective Calcite adapters. The method itself is in a utility class so people may use it to create vulnerable HTTPS connections for other applications. From Apache Calcite 1.26 onwards, the hostname verification will be performed using the default JVM truststore."

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.calcite:calcite-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.calcite:calcite-druid"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.calcite:calcite-splunk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-13955"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-21T20:27:19Z",
    "nvd_published_at": "2020-10-09T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "\"HttpUtils#getURLConnection method disables explicitly hostname verification for HTTPS connections making clients vulnerable to man-in-the-middle attacks. Calcite uses this method internally to connect with Druid and Splunk so information leakage may happen when using the respective Calcite adapters. The method itself is in a utility class so people may use it to create vulnerable HTTPS connections for other applications. From Apache Calcite 1.26 onwards, the hostname verification will be performed using the default JVM truststore.\"",
  "id": "GHSA-hxp5-8pgq-mgv9",
  "modified": "2021-04-21T20:27:19Z",
  "published": "2021-04-22T16:14:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13955"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/calcite/commit/43eeafcbac29d02c72bd520c003cdfc571de2d15"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/CALCITE-4298"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0b0fbe2038388175951ce1028182d980f9e9a7328be13d52dab70bb3%40%3Cdev.calcite.apache.org%3E"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing Authentication for Critical Function in Apache Calcite"
}

GHSA-HXQ8-HCGP-QP7J

Vulnerability from github – Published: 2026-09-03 18:31 – Updated: 2026-09-03 18:31
VLAI
Details

In the current development version of Eclipse aeriOS, for which no official release has yet been published, the Federator component disables TLS certificate validation for outbound HTTPS connections by default. When the TLS_CERTIFICATE_VALIDATION environment variable is unset or set to false, the component configures its HTTP transport to skip TLS certificate verification.

As a result, an attacker able to intercept network communications between the Federator and external services could impersonate those services and intercept sensitive information transmitted over HTTPS, including OAuth client credentials and bearer tokens.

The issue has been addressed by enabling TLS certificate validation by default. The TLS_CERTIFICATE_VALIDATION environment variable is now set to true in the default configuration provided by the Helm chart and Docker Compose deployment.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-84736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-03T17:17:25Z",
    "severity": "HIGH"
  },
  "details": "In the current development version of Eclipse aeriOS, for which no official release has yet been published, the Federator component disables TLS certificate validation for outbound HTTPS connections by default. When the TLS_CERTIFICATE_VALIDATION environment variable is unset or set to false, the component configures its HTTP transport to skip TLS certificate verification.\n\n\n\n\nAs a result, an attacker able to intercept network communications between the Federator and external services could impersonate those services and intercept sensitive information transmitted over HTTPS, including OAuth client credentials and bearer tokens.\n\n\n\n\nThe issue has been addressed by enabling TLS certificate validation by default. The TLS_CERTIFICATE_VALIDATION environment variable is now set to true in the default configuration provided by the Helm chart and Docker Compose deployment.",
  "id": "GHSA-hxq8-hcgp-qp7j",
  "modified": "2026-09-03T18:31:49Z",
  "published": "2026-09-03T18:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84736"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-aerios/federator/commit/9c63b60becc9873b0195ff9cd6582b69cb12d4f2"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/755"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-J262-JH5J-P4FW

Vulnerability from github – Published: 2026-07-20 21:31 – Updated: 2026-07-21 00:30
VLAI
Details

Improper certificate validation in Apache MINA SSHD (server-side). Apache MINA SSHD is a Java library for client-side and server-side SSH.

Server-side OpenSSH user certificate validation during user authentication in an Apache MINA SSHD server did not check for the unsupported force-command or verify-required options that could be embedded in the certificate, nor did it validate these options. As a result it was possible that a user could authenticate with such a certificate that included a force-command option but still was able to execute other commands. What other command exactly would be available to the user depends on the implementation of the server.

This issue is fixed in Apache MINA SSHD 2.19.0 and 3.0.0-M5. Applications are advised to upgrade to these versions.

The fix rejects OpenSSH user certificates that include these options, since Apache MINA SSHD implements neither force-command nor sk-*-cert-v01@openssh.com user certificates (which are the only ones for which verify-required would make sense).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-56624"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-20T21:16:49Z",
    "severity": "HIGH"
  },
  "details": "Improper certificate validation in Apache MINA SSHD (server-side).\u00a0Apache MINA SSHD is a Java library for client-side and server-side SSH.\n\n\n\n\nServer-side OpenSSH user certificate validation during user authentication in an Apache MINA SSHD server did not check for the unsupported force-command or verify-required options that could be embedded in the certificate, nor did it validate these options. As a result it was possible that a user could authenticate with such a certificate that included a force-command option but still was able to execute other commands. What other command exactly would be available to the user depends on the implementation of the server.\n\n\n\n\nThis issue is fixed in Apache MINA SSHD 2.19.0 and 3.0.0-M5. Applications are advised to upgrade to these versions.\n\n\n\n\nThe fix rejects OpenSSH user certificates that include these options, since Apache MINA SSHD implements neither force-command nor sk-*-cert-v01@openssh.com user certificates (which are the only ones for which verify-required would make sense).",
  "id": "GHSA-j262-jh5j-p4fw",
  "modified": "2026-07-21T00:30:28Z",
  "published": "2026-07-20T21:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56624"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/o4c2jml522j3z80gbryqzc2f1253ltp6"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/07/20/17"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/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.