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.

1121 vulnerabilities reference this CWE, most recent first.

GHSA-HWW5-54C3-F2VG

Vulnerability from github – Published: 2026-05-15 06:30 – Updated: 2026-05-15 06:30
VLAI
Details

Improper verification of cryptographic signature in the Radeon RGB tool could allow a malicious file placed in the installation directory to be run with elevated privileges potentially leading to arbitrary code execution.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-36334"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-15T05:16:32Z",
    "severity": "HIGH"
  },
  "details": "Improper verification of cryptographic signature in the Radeon RGB tool could allow a malicious file placed in the installation directory to be run with elevated privileges potentially leading to arbitrary code execution.",
  "id": "GHSA-hww5-54c3-f2vg",
  "modified": "2026-05-15T06:30:29Z",
  "published": "2026-05-15T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36334"
    },
    {
      "type": "WEB",
      "url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-6027.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/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-HXJR-HWRW-HRV5

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

Improper Verification of Cryptographic Signature vulnerability exists in homeLYnk (Wiser For KNX) and spaceLYnk V2.60 and prior which could cause remote code execution when an attacker loads unauthorized code.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-22734"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-26T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper Verification of Cryptographic Signature vulnerability exists in homeLYnk (Wiser For KNX) and spaceLYnk V2.60 and prior which could cause remote code execution when an attacker loads unauthorized code.",
  "id": "GHSA-hxjr-hwrw-hrv5",
  "modified": "2022-05-24T19:03:17Z",
  "published": "2022-05-24T19:03:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22734"
    },
    {
      "type": "WEB",
      "url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-130-04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-J2HR-Q93X-GXVH

Vulnerability from github – Published: 2024-10-11 16:58 – Updated: 2024-10-11 16:58
VLAI
Summary
SSOReady has an XML Signature Bypass via differential XML parsing
Details

Affected versions are vulnerable to XML signature bypass attacks. An attacker can carry out signature bypass if you have access to certain IDP-signed messages. The underlying mechanism exploits differential behavior between XML parsers.

Users of https://ssoready.com, the public hosted instance of SSOReady, are unaffected. We advise folks who self-host SSOReady to upgrade to 7f92a06 or later. Do so by updating your SSOReady Docker images from sha-... to sha-7f92a06. The documentation for self-hosting SSOReady is available here.

Vulnerability was discovered by @ahacker1-securesaml. It's likely the precise mechanism of attack affects other SAML implementations, so the reporter and I (@ucarion) have agreed to not disclose it in detail publicly at this time.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ssoready/ssoready"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20241009153838-7f92a0630439"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47832"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-11T16:58:36Z",
    "nvd_published_at": "2024-10-09T19:15:14Z",
    "severity": "CRITICAL"
  },
  "details": "Affected versions are vulnerable to XML signature bypass attacks. An attacker can carry out signature bypass if you have access to certain IDP-signed messages. The underlying mechanism exploits differential behavior between XML parsers.\n\nUsers of https://ssoready.com, the public hosted instance of SSOReady, are unaffected. We advise folks who self-host SSOReady to upgrade to 7f92a06 or later. Do so by updating your SSOReady Docker images from `sha-...` to `sha-7f92a06`. The documentation for self-hosting SSOReady is available [here](https://ssoready.com/docs/self-hosting/self-hosting-sso-ready).\n\nVulnerability was discovered by @ahacker1-securesaml. It\u0027s likely the precise mechanism of attack affects other SAML implementations, so the reporter and I (@ucarion) have agreed to not disclose it in detail publicly at this time.",
  "id": "GHSA-j2hr-q93x-gxvh",
  "modified": "2024-10-11T16:58:37Z",
  "published": "2024-10-11T16:58:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ssoready/ssoready/security/advisories/GHSA-j2hr-q93x-gxvh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47832"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ssoready/ssoready/commit/7f92a0630439972fcbefa8c7eafe8c144bd89915"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ssoready/ssoready"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-3185"
    },
    {
      "type": "WEB",
      "url": "https://ssoready.com/docs/self-hosting/self-hosting-sso-ready"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SSOReady has an XML Signature Bypass via differential XML parsing"
}

GHSA-J2PQ-XRMC-F4R4

Vulnerability from github – Published: 2022-04-05 00:00 – Updated: 2022-04-10 00:01
VLAI
Details

On Schneider Electric ConneXium Tofino Firewall TCSEFEA23F3F22 before 03.23, TCSEFEA23F3F20/21, and Belden Tofino Xenon Security Appliance, an arbitrary firmware image can be loaded because firmware signature verification (for a USB stick) can be bypassed. NOTE: this issue exists because of an incomplete fix of CVE-2017-11400.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-30066"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-03T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "On Schneider Electric ConneXium Tofino Firewall TCSEFEA23F3F22 before 03.23, TCSEFEA23F3F20/21, and Belden Tofino Xenon Security Appliance, an arbitrary firmware image can be loaded because firmware signature verification (for a USB stick) can be bypassed. NOTE: this issue exists because of an incomplete fix of CVE-2017-11400.",
  "id": "GHSA-j2pq-xrmc-f4r4",
  "modified": "2022-04-10T00:01:01Z",
  "published": "2022-04-05T00:00:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30066"
    },
    {
      "type": "WEB",
      "url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2022-011-05"
    },
    {
      "type": "WEB",
      "url": "https://www.belden.com/support/security-assurance"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J2WP-F4R8-6834

Vulnerability from github – Published: 2023-09-13 18:31 – Updated: 2024-01-25 18:30
VLAI
Details

A vulnerability in the iPXE boot function of Cisco IOS XR software could allow an authenticated, local attacker to install an unverified software image on an affected device.

This vulnerability is due to insufficient image verification. An attacker could exploit this vulnerability by manipulating the boot parameters for image verification during the iPXE boot process on an affected device. A successful exploit could allow the attacker to boot an unverified software image on the affected device.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-20236"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-13T17:15:09Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the iPXE boot function of Cisco IOS XR software could allow an authenticated, local attacker to install an unverified software image on an affected device.\n\n This vulnerability is due to insufficient image verification. An attacker could exploit this vulnerability by manipulating the boot parameters for image verification during the iPXE boot process on an affected device. A successful exploit could allow the attacker to boot an unverified software image on the affected device.",
  "id": "GHSA-j2wp-f4r8-6834",
  "modified": "2024-01-25T18:30:44Z",
  "published": "2023-09-13T18:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20236"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-ipxe-sigbypass-pymfyqgB"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J3FF-XP6C-6GCC

Vulnerability from github – Published: 2022-03-18 18:57 – Updated: 2022-03-18 18:57
VLAI
Summary
Failure to validate signature during handshake
Details

Impact

@chainsafe/libp2p-noise before 4.1.2 and 5.0.3 was not correctly validating signatures during the handshake process. This may allow a man-in-the-middle to pose as other peers and get those peers banned.

Patches

Users should upgrade to 4.1.2 or 5.0.3

Workarounds

No workarounds, just patch upgrade

References

https://github.com/ChainSafe/js-libp2p-noise/pull/130

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@chainsafe/libp2p-noise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@chainsafe/libp2p-noise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-24759"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-03-18T18:57:53Z",
    "nvd_published_at": "2022-03-17T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n`@chainsafe/libp2p-noise` before 4.1.2 and 5.0.3 was not correctly validating signatures during the handshake process.\nThis may allow a man-in-the-middle to pose as other peers and get those peers banned.\n\n### Patches\nUsers should upgrade to 4.1.2 or 5.0.3\n\n### Workarounds\nNo workarounds, just patch upgrade\n\n### References\nhttps://github.com/ChainSafe/js-libp2p-noise/pull/130\n",
  "id": "GHSA-j3ff-xp6c-6gcc",
  "modified": "2022-03-18T18:57:53Z",
  "published": "2022-03-18T18:57:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ChainSafe/js-libp2p-noise/security/advisories/GHSA-j3ff-xp6c-6gcc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24759"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ChainSafe/js-libp2p-noise/pull/130"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ChainSafe"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ChainSafe/js-libp2p-noise/releases/tag/v5.0.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Failure to validate signature during handshake"
}

GHSA-J3JW-J2J8-2WV9

Vulnerability from github – Published: 2021-11-10 20:58 – Updated: 2021-11-15 14:43
VLAI
Summary
Improper Verification of Cryptographic Signature in starkbank-ecdsa
Details

The verify function in the Stark Bank .NET ECDSA library (ecdsa-dotnet) 1.3.1 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "starkbank-ecdsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-43569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-11-10T18:26:13Z",
    "nvd_published_at": "2021-11-09T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The verify function in the Stark Bank .NET ECDSA library (ecdsa-dotnet) 1.3.1 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages.",
  "id": "GHSA-j3jw-j2j8-2wv9",
  "modified": "2021-11-15T14:43:39Z",
  "published": "2021-11-10T20:58:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43569"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/starkbank/ecdsa-dotnet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-dotnet/releases/tag/v1.3.2"
    },
    {
      "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": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Verification of Cryptographic Signature in starkbank-ecdsa"
}

GHSA-J3VP-XQJF-C8PJ

Vulnerability from github – Published: 2022-05-13 01:02 – Updated: 2022-05-13 01:02
VLAI
Details

Little Snitch versions 4.0 to 4.0.6 use the SecStaticCodeCheckValidityWithErrors() function without the kSecCSCheckAllArchitectures flag and therefore do not validate all architectures stored in a fat binary. An attacker can maliciously craft a fat binary containing multiple architectures that may cause a situation where Little Snitch treats the running process as having no code signature at all while erroneously indicating that the binary on disk does have a valid code signature. This could lead to users being confused about whether or not the code signature is valid.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-10470"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-12T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Little Snitch versions 4.0 to 4.0.6 use the SecStaticCodeCheckValidityWithErrors() function without the kSecCSCheckAllArchitectures flag and therefore do not validate all architectures stored in a fat binary. An attacker can maliciously craft a fat binary containing multiple architectures that may cause a situation where Little Snitch treats the running process as having no code signature at all while erroneously indicating that the binary on disk does have a valid code signature. This could lead to users being confused about whether or not the code signature is valid.",
  "id": "GHSA-j3vp-xqjf-c8pj",
  "modified": "2022-05-13T01:02:17Z",
  "published": "2022-05-13T01:02:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10470"
    },
    {
      "type": "WEB",
      "url": "https://obdev.at/cve/2018-10470-8FRWkW4oH8.html"
    },
    {
      "type": "WEB",
      "url": "https://www.okta.com/security-blog/2018/06/issues-around-third-party-apple-code-signing-checks"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J477-6VPG-6C8X

Vulnerability from github – Published: 2026-01-29 15:21 – Updated: 2026-01-29 15:21
VLAI
Summary
Juju has broken CMR authorization
Details

Impact

Cross-model Relation authorization is broken and has a potential security vulnerability. If the controller does not have the root key to verify the macaroon (or if the macaroon has expired), an unvalidated and therefore untrusted macaroon is used to extract declared caveats. Facts from these caveats are then blindly used to mint a new macaroon that becomes valid.

Scenario

A user knows that user X has access to offer Y. The user mints a macaroon stating that user X has access to offer Y and sends it to the controller in a request. The controller fails to verify the macaroon because it lacks the root key and mints a new macaroon requiring proof that user X has access to offer Y. Since user X does have access and the discharge endpoint does not require authentication, the controller returns the new macaroon. The user can then use the returned macaroon to consume the offer as user X.

Patches

N/A

Workarounds

A previous proposal via this PR addresses the issue but would break model migrations since macaroon root keys are not included in model descriptions. Additionally, root keys are not model-scoped, making it unclear which keys to transfer during migration.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/juju/juju"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.0.0-20260127110037-9b1a0e53a4a4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-1237"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-29T15:21:27Z",
    "nvd_published_at": "2026-01-28T15:16:16Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nCross-model Relation authorization is broken and has a potential security vulnerability. If the controller does not have the root key to verify the macaroon (or if the macaroon has expired), an unvalidated and therefore untrusted macaroon is used to extract declared caveats. Facts from these caveats are then blindly used to mint a new macaroon that becomes valid.\n\n### Scenario\n\nA user knows that user X has access to offer Y. The user mints a macaroon stating that user X has access to offer Y and sends it to the controller in a request. The controller fails to verify the macaroon because it lacks the root key and mints a new macaroon requiring proof that user X has access to offer Y. Since user X does have access and the discharge endpoint does not require authentication, the controller returns the new macaroon. The user can then use the returned macaroon to consume the offer as user X.\n\n### Patches\n\nN/A\n\n### Workarounds\n\nA previous proposal via [this PR](https://github.com/juju/juju/pull/21062) addresses the issue but would break model migrations since macaroon root keys are not included in model descriptions. Additionally, root keys are not model-scoped, making it unclear which keys to transfer during migration.",
  "id": "GHSA-j477-6vpg-6c8x",
  "modified": "2026-01-29T15:21:27Z",
  "published": "2026-01-29T15:21:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/juju/juju/security/advisories/GHSA-j477-6vpg-6c8x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1237"
    },
    {
      "type": "WEB",
      "url": "https://github.com/juju/juju/pull/21062"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/juju/juju"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Juju has broken CMR authorization"
}

GHSA-J4H7-9CC4-7F3R

Vulnerability from github – Published: 2026-07-14 12:31 – Updated: 2026-07-14 12:31
VLAI
Details

A vulnerability has been identified in Opcenter X (All versions < V2604). Affected applications do not properly validate the algorithm specified in the JSON Web Token (JWT) header. This could allow an unauthenticated remote attacker to forge arbitrary JWT, bypass authentication mechanisms and impersonate any user including administrative accounts, potentially gaining full unauthorized access to the application.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-56451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T10:16:33Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability has been identified in Opcenter X (All versions \u003c V2604). Affected applications do not properly validate the algorithm specified in the JSON Web Token (JWT) header.\nThis could allow an unauthenticated remote attacker to forge arbitrary JWT, bypass authentication mechanisms and impersonate any user including administrative accounts, potentially gaining full unauthorized access to the application.",
  "id": "GHSA-j4h7-9cc4-7f3r",
  "modified": "2026-07-14T12:31:15Z",
  "published": "2026-07-14T12:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56451"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-096828.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:L/SI:H/SA:H/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"
    }
  ]
}

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.