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.

1127 vulnerabilities reference this CWE, most recent first.

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

GHSA-C6RR-7PMC-73WC

Vulnerability from github – Published: 2026-02-25 18:26 – Updated: 2026-02-27 20:55
VLAI
Summary
ENS DNSSEC Oracle Vulnerable to RSA Signature Forgery via Missing PKCS#1 v1.5 Padding Validation
Details

Impact

The RSASHA256Algorithm and RSASHA1Algorithm contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check if the last 32 (or 20) bytes of the decrypted signature match the expected hash. This enables Bleichenbacher's 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs (.cc and .name) use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership.

Affected contracts

Contract Address Status
RSASHA256Algorithm 0x9D1B5a639597f558bC37Cf81813724076c5C1e96 Vulnerable
RSASHA1Algorithm 0x6ca8624Bc207F043D140125486De0f7E624e37A1 Vulnerable
DNSSECImpl 0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5 Uses vulnerable algorithms
DNSRegistrar 0xB32cB5677a7C971689228EC835800432B339bA2B Attack entry point

Patches

The bug was reported via Immunefi with possible solutions. The patch was merged at https://github.com/ensdomains/ens-contracts/commit/c76c5ad0dc9de1c966443bd946fafc6351f87587

Workarounds

  • Deploy the patched contracts
  • Point DNSSECImpl.setAlgorithm to the deployed contract

Resources

https://github.com/ensdomains/ens-contracts-bug-62248-pr-509

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@ensdomains/ens-contracts"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22866"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-25T18:26:58Z",
    "nvd_published_at": "2026-02-25T16:23:25Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nThe `RSASHA256Algorithm` and `RSASHA1Algorithm` contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check if the last 32 (or 20) bytes of the decrypted signature match the expected hash. This enables Bleichenbacher\u0027s 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs (.cc and .name) use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership.\n\nAffected contracts\n\nContract | Address | Status\n-- | -- | --\nRSASHA256Algorithm | 0x9D1B5a639597f558bC37Cf81813724076c5C1e96 | Vulnerable\nRSASHA1Algorithm | 0x6ca8624Bc207F043D140125486De0f7E624e37A1 | Vulnerable\nDNSSECImpl | 0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5 | Uses vulnerable algorithms\nDNSRegistrar | 0xB32cB5677a7C971689228EC835800432B339bA2B | Attack entry point\n\n\n\n\n### Patches\n\nThe bug was reported via Immunefi with possible solutions. The patch was merged at https://github.com/ensdomains/ens-contracts/commit/c76c5ad0dc9de1c966443bd946fafc6351f87587\n\n\n### Workarounds\n\n- Deploy the patched contracts\n- Point DNSSECImpl.setAlgorithm to the deployed contract\n\n### Resources\n\nhttps://github.com/ensdomains/ens-contracts-bug-62248-pr-509",
  "id": "GHSA-c6rr-7pmc-73wc",
  "modified": "2026-02-27T20:55:13Z",
  "published": "2026-02-25T18:26:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ensdomains/ens-contracts/security/advisories/GHSA-c6rr-7pmc-73wc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22866"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ensdomains/ens-contracts/commit/c76c5ad0dc9de1c966443bd946fafc6351f87587"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ensdomains/ens-contracts"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ensdomains/ens-contracts-bug-62248-pr-509"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ENS DNSSEC Oracle Vulnerable to RSA Signature Forgery via Missing PKCS#1 v1.5 Padding Validation"
}

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.