Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

1128 vulnerabilities reference this CWE, most recent first.

GHSA-9WX7-JRVC-28MM

Vulnerability from github – Published: 2021-11-08 21:51 – Updated: 2021-11-08 21:34
VLAI
Summary
Signature verification vulnerability in Stark Bank ecdsa libraries
Details

An attacker can forge signatures on arbitrary messages that will verify for any public key. This may allow attackers to authenticate as any user within the Stark Bank platform, and bypass signature verification needed to perform operations on the platform, such as send payments and transfer funds. Additionally, the ability for attackers to forge signatures may impact other users and projects using these libraries in different and unforeseen ways.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "starkbank-ecdsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.starkbank:ecdsa-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.0.0"
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "starkbank-ecdsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.1"
            },
            {
              "fixed": "1.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.3.1"
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "starkbank-ecdsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.2"
            },
            {
              "fixed": "1.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.1.2"
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-11-08T21:34:42Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "An attacker can forge signatures on arbitrary messages that will verify for any public key. This may allow attackers to authenticate as any user within the Stark Bank platform, and bypass signature verification needed to perform operations on the platform, such as send payments and transfer funds. Additionally, the ability for attackers to forge signatures may impact other users and projects using these libraries in different and unforeseen ways.",
  "id": "GHSA-9wx7-jrvc-28mm",
  "modified": "2021-11-08T21:34:42Z",
  "published": "2021-11-08T21:51:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-python/commit/d136170666e9510eb63c2572551805807bd4c17f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-dotnet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-java"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-node"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/starkbank/ecdsa-python"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-python/compare/v2.0.0...v2.0.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-python/releases/tag/v2.0.1"
    },
    {
      "type": "WEB",
      "url": "https://research.nccgroup.com/2021/11/08/technical-advisory-arbitrary-signature-forgery-in-stark-bank-ecdsa-libraries"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Signature verification vulnerability in Stark Bank ecdsa libraries"
}

GHSA-9X5Q-PWR2-HWVP

Vulnerability from github – Published: 2024-06-15 00:31 – Updated: 2024-06-15 00:31
VLAI
Details

StorageGRID (formerly StorageGRID Webscale) versions prior to 11.7.0.9 and 11.8.0.5 are susceptible to disclosure of sensitive information via complex MiTM attacks due to a vulnerability in the SSH cryptographic implementation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-14T22:15:10Z",
    "severity": "MODERATE"
  },
  "details": "StorageGRID (formerly StorageGRID Webscale) versions prior to \n11.7.0.9 and 11.8.0.5 are susceptible to disclosure of sensitive \ninformation via complex MiTM attacks due to a vulnerability in the SSH \ncryptographic implementation.",
  "id": "GHSA-9x5q-pwr2-hwvp",
  "modified": "2024-06-15T00:31:14Z",
  "published": "2024-06-15T00:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21988"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240614-0010"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9XJR-M6F3-V5WM

Vulnerability from github – Published: 2021-08-25 20:43 – Updated: 2023-06-13 17:38
VLAI
Summary
HTTPS MitM vulnerability due to lack of hostname verification
Details

When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not perform hostname verification when making HTTPS requests.

This allows an attacker to perform MitM attacks by preventing any valid CA-issued certificate, even if there's a hostname mismatch.

The problem was addressed by leveraging rust-openssl's built-in support for hostname verification.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "hyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-10932"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-19T21:25:12Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not perform hostname verification when making HTTPS requests.\n\nThis allows an attacker to perform MitM attacks by preventing any valid CA-issued certificate, even if there\u0027s a hostname mismatch.\n\nThe problem was addressed by leveraging rust-openssl\u0027s built-in support for hostname verification.",
  "id": "GHSA-9xjr-m6f3-v5wm",
  "modified": "2023-06-13T17:38:19Z",
  "published": "2021-08-25T20:43:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10932"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperium/hyper/issues/472"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperium/hyper/commit/01160abd92956e5f995cc45790df7a2b86c8989f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperium/hyper/blob/master/CHANGELOG.md#v094-2016-05-09"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2016-0002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "HTTPS MitM vulnerability due to lack of hostname verification"
}

GHSA-C2PQ-PFGC-Q2G7

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

In HP LaserJet Enterprise, HP PageWide Enterprise, HP LaserJet Managed, and HP OfficeJet Enterprise Printers, solution application signature checking may allow potential execution of arbitrary code.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-5923"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-27T16:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "In HP LaserJet Enterprise, HP PageWide Enterprise, HP LaserJet Managed, and HP OfficeJet Enterprise Printers, solution application signature checking may allow potential execution of arbitrary code.",
  "id": "GHSA-c2pq-pfgc-q2g7",
  "modified": "2022-05-14T01:09:26Z",
  "published": "2022-05-14T01:09:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5923"
    },
    {
      "type": "WEB",
      "url": "https://support.hp.com/us-en/document/c06169434"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2V4-JG9M-JGRR

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

SAP NetWeaver Application Server ABAP and ABAP Platform allows an authenticated attacker with normal privileges to obtain a valid signed message and send modified signed XML documents to the verifier. This may result in acceptance of tampered identity information leading to unauthorized access to sensitive user data and potential disruption of normal system usage. This causes a high impact on confidentiality, integrity and availability of the application.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-44748"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T01:16:46Z",
    "severity": "CRITICAL"
  },
  "details": "SAP NetWeaver Application Server ABAP and ABAP Platform allows an authenticated attacker with normal privileges to obtain a valid signed message and send modified signed XML documents to the verifier. This may result in acceptance of tampered identity information leading to unauthorized access to sensitive user data and potential disruption of normal system usage. This causes a high impact on confidentiality, integrity and availability of the application.",
  "id": "GHSA-c2v4-jg9m-jgrr",
  "modified": "2026-06-09T03:31:40Z",
  "published": "2026-06-09T03:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44748"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3746332"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "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-C39G-93PM-R85M

Vulnerability from github – Published: 2024-03-18 06:30 – Updated: 2024-08-28 18:31
VLAI
Details

In the CryptX module before 0.062 for Perl, gcm_decrypt_verify() and chacha20poly1305_decrypt_verify() do not verify the tag.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-25099"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-18T05:15:06Z",
    "severity": "CRITICAL"
  },
  "details": "In the CryptX module before 0.062 for Perl, gcm_decrypt_verify() and chacha20poly1305_decrypt_verify() do not verify the tag.",
  "id": "GHSA-c39g-93pm-r85m",
  "modified": "2024-08-28T18:31:53Z",
  "published": "2024-03-18T06:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25099"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DCIT/perl-CryptX/issues/47"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libtom/libtomcrypt/pull/451"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/dist/CryptX/changes"
    }
  ],
  "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-C3M2-JQMQ-PVP3

Vulnerability from github – Published: 2026-05-29 20:25 – Updated: 2026-06-09 11:00
VLAI
Summary
authentik's XML Signature Wrapping in SAML Source ACS allows authentication as arbitrary federated user
Details

Summary

authentik's SAML Source ACS endpoint is vulnerable to XML Signature Wrapping when validating upstream SAML responses. An attacker with any account at the upstream IdP can reuse a valid signed assertion to authenticate as another federated user.

### Patches

authentik 2026.5.1, 2026.2.4 and 2025.12.6 fix this issue.

### Impact

Affected: authentik deployments using a SAML Source for upstream SAML federation with signed assertions, or signed responses without signed assertions. Not affected: deployments that do not use SAML Source for upstream SAML federation.

The SAML Source trusts that the verified XML signature belongs to the assertion or response that authentik later consumes. A crafted SAML response can make signature verification succeed against the attacker's original signed assertion while authentik reads identity data from a different forged assertion.

An attacker first completes a legitimate login to the upstream IdP and captures the signed SAML response sent through their browser. They then submit a modified response to the ACS endpoint where the valid signature still verifies, but the consumed assertion contains a victim identifier or attacker-chosen attributes.

The attacker can authenticate as a victim who has previously used the SAML Source, or as a local user matched by forged email or username when those matching modes are enabled.

### Workarounds

Disable affected SAML Sources, or block access to their ACS endpoints.

### For more information

If there are any questions or comments about this advisory:

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "goauthentik.io"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260528144335-a370d76d23c7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-287",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T20:25:48Z",
    "nvd_published_at": "2026-06-02T21:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n \n authentik\u0027s SAML Source ACS endpoint is vulnerable to XML Signature Wrapping when validating upstream SAML responses. An attacker with any account at the upstream IdP can reuse a valid signed assertion to authenticate as another federated user.\n \n ### Patches\n \n authentik 2026.5.1, 2026.2.4 and 2025.12.6 fix this issue.\n \n ### Impact\n \n Affected: authentik deployments using a SAML Source for upstream SAML federation with signed assertions, or signed responses without signed assertions. Not affected: deployments that do not use SAML Source for upstream SAML federation.\n \n The SAML Source trusts that the verified XML signature belongs to the assertion or response that authentik later consumes. A crafted SAML response can make signature verification succeed against the attacker\u0027s original signed assertion while authentik reads identity data from a different forged assertion.\n \n An attacker first completes a legitimate login to the upstream IdP and captures the signed SAML response sent through their browser. They then submit a modified response to the ACS endpoint where the valid signature still verifies, but the consumed assertion contains a victim identifier or attacker-chosen attributes.\n \n The attacker can authenticate as a victim who has previously used the SAML Source, or as a local user matched by forged email or username when those matching modes are enabled.\n \n ### Workarounds\n \n Disable affected SAML Sources, or block access to their ACS endpoints.\n \n ### For more information\n \nIf there are any questions or comments about this advisory:\n \n - Send an email to [security@goauthentik.io](mailto:security@goauthentik.io)",
  "id": "GHSA-c3m2-jqmq-pvp3",
  "modified": "2026-06-09T11:00:16Z",
  "published": "2026-05-29T20:25:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/goauthentik/authentik/security/advisories/GHSA-c3m2-jqmq-pvp3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47201"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goauthentik/authentik/commit/a370d76d23c7de0fceed064ca322e33e6ebf0119"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/goauthentik/authentik"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "authentik\u0027s XML Signature Wrapping in SAML Source ACS allows authentication as arbitrary federated user"
}

GHSA-C53X-X7FC-9VRP

Vulnerability from github – Published: 2022-05-14 03:46 – Updated: 2025-04-20 03:50
VLAI
Details

An issue was discovered in Enigmail before 1.9.9. Signature spoofing is possible because the UI does not properly distinguish between an attachment signature, and a signature that applies to the entire containing message, aka TBE-01-021. This is demonstrated by an e-mail message with an attachment that is a signed e-mail message in message/rfc822 format.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-17847"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-27T17:08:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Enigmail before 1.9.9. Signature spoofing is possible because the UI does not properly distinguish between an attachment signature, and a signature that applies to the entire containing message, aka TBE-01-021. This is demonstrated by an e-mail message with an attachment that is a signed e-mail message in message/rfc822 format.",
  "id": "GHSA-c53x-x7fc-9vrp",
  "modified": "2025-04-20T03:50:29Z",
  "published": "2022-05-14T03:46:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-17847"
    },
    {
      "type": "WEB",
      "url": "https://enigmail.net/download/other/Enigmail%20Pentest%20Report%20by%20Cure53%20-%20Excerpt.pdf"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2017/12/msg00021.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-security-announce/2017/msg00333.html"
    },
    {
      "type": "WEB",
      "url": "https://sourceforge.net/p/enigmail/bugs/709"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2017/dsa-4070"
    },
    {
      "type": "WEB",
      "url": "https://www.mail-archive.com/enigmail-users%40enigmail.net/msg04280.html"
    },
    {
      "type": "WEB",
      "url": "https://www.mail-archive.com/enigmail-users@enigmail.net/msg04280.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C5CV-Q9QQ-59Q9

Vulnerability from github – Published: 2026-01-20 18:31 – Updated: 2026-01-20 18:31
VLAI
Details

IBM ApplinX 11.1 is vulnerable due to a privilege escalation vulnerability due to improper verification of JWT tokens. An attacker may be able to craft or modify a JSON web token in order to impersonate another user or to elevate their privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-36418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-20T16:16:04Z",
    "severity": "HIGH"
  },
  "details": "IBM ApplinX 11.1 is vulnerable due to a privilege escalation vulnerability due to improper verification of JWT tokens. An attacker may be able to craft or modify a JSON web token in order to impersonate another user or to elevate their privileges.",
  "id": "GHSA-c5cv-q9qq-59q9",
  "modified": "2026-01-20T18:31:57Z",
  "published": "2026-01-20T18:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36418"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7257446"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C653-97M9-RCG9

Vulnerability from github – Published: 2026-06-15 20:45 – Updated: 2026-06-15 20:45
VLAI
Summary
Netty: Wrapping plain trust manager silently disables hostname verification
Details

SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) performs no hostname verification at all.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.15.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.134.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.135.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50010"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T20:45:45Z",
    "nvd_published_at": "2026-06-12T16:16:31Z",
    "severity": "HIGH"
  },
  "details": "SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE\u0027s internal AbstractTrustManagerWrapper nor Netty\u0027s own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm=\"HTTPS\" by default, a client built with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` performs no hostname verification at all.",
  "id": "GHSA-c653-97m9-rcg9",
  "modified": "2026-06-15T20:45:45Z",
  "published": "2026-06-15T20:45:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-c653-97m9-rcg9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50010"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
    }
  ],
  "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": "Netty: Wrapping plain trust manager silently disables hostname verification"
}

No mitigation information available for this CWE.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

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.