Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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

1266 vulnerabilities reference this CWE, most recent first.

GHSA-FR8M-434R-G3XP

Vulnerability from github – Published: 2025-10-15 18:57 – Updated: 2026-01-22 20:44
VLAI
Summary
gnark-crypto doesn't range check input values during ECDSA and EdDSA signature deserialization
Details

Impact

During deserialization of ECDSA and EdDSA signatures gnark-crypto did not check that the values are in the range [1, n-1] with n being the corresponding modulus (either base field modulus in case of R in EdDSA, and scalar field modulus in case of s,r in ECDSA and s in EdDSA). As this also allowed zero inputs, then it was possible to craft a signature which lead to null pointer dereference, leading to denial-of-service of an application. This also enabled weak signature malleability when the users assumed uniqueness of the serialized signatures (but not the underlying modulo reduced values).

We are not aware of any users impacted by the bug. The implemented signature schemes in gnark-crypto complement the in-circuit versions in gnark, allowing to have end-to-end tests.

Patches

The issue was patched in PR #449. The fix returns an error during deserialization if the values do not belong to the ranges [1, n-1].

The fix is included in release v0.12.0 and upwards.

Workarounds

Users can manually validate the inputs to be in corresponding ranges when using serialized signatures (or digests of them) as unique keys.

To address the denial-of-service, the users can install hook to recover panics and recover

Resources

Acknowledgement

Lack of range checks leading to signature malleability was reported by Verichains.

Severity
5.1 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/consensys/gnark-crypto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-44273"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-15T18:57:59Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nDuring deserialization of ECDSA and EdDSA signatures gnark-crypto did not check that the values are in the range `[1, n-1]` with `n` being the corresponding modulus (either base field modulus in case of `R` in EdDSA, and scalar field modulus in case of `s,r` in ECDSA and `s` in EdDSA). As this also allowed zero inputs, then it was possible to craft a signature which lead to null pointer dereference, leading to denial-of-service of an application. This also enabled weak signature malleability when the users assumed uniqueness of the serialized signatures (but not the underlying modulo reduced values).\n\nWe are not aware of any users impacted by the bug. The implemented signature schemes in gnark-crypto complement the in-circuit versions in gnark, allowing to have end-to-end tests.\n\n### Patches\n\nThe issue was patched in PR #449. The fix returns an error during deserialization if the values do not belong to the ranges `[1, n-1]`.\n\nThe fix is included in release v0.12.0 and upwards.\n\n### Workarounds\n\nUsers can manually validate the inputs to be in corresponding ranges when using serialized signatures (or digests of them) as unique keys.\n\nTo address the denial-of-service, the users can install hook to recover panics and recover \n\n### Resources\n\n* [Verichains advisory](https://github.com/advisories/GHSA-9xfq-8j3r-xp5g) for signature malleability.\n* Fix https://github.com/Consensys/gnark-crypto/pull/449\n* [Go blog post \"Defer, Panic, and Recover\"](https://go.dev/blog/defer-panic-and-recover)\n* [gnark v0.12.0](https://github.com/Consensys/gnark-crypto/releases/tag/v0.12.0)\n\n\n### Acknowledgement\n\nLack of range checks leading to signature malleability was reported by [Verichains](https://www.verichains.io/).",
  "id": "GHSA-fr8m-434r-g3xp",
  "modified": "2026-01-22T20:44:35Z",
  "published": "2025-10-15T18:57:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Consensys/gnark-crypto/security/advisories/GHSA-fr8m-434r-g3xp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44273"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Consensys/gnark-crypto/pull/449"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Consensys/gnark-crypto"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Consensys/gnark-crypto/releases/tag/v0.12.0"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/blog/defer-panic-and-recover"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gnark-crypto doesn\u0027t range check input values during ECDSA and EdDSA signature deserialization"
}

GHSA-FVF3-RPFR-XQW3

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

An issue in code signature validation was addressed with improved checks. This issue is fixed in macOS Big Sur 11.7, macOS Ventura 13, iOS 16, iOS 15.7 and iPadOS 15.7, macOS Monterey 12.6. An app may be able to bypass code signing checks.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-42793"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-01T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue in code signature validation was addressed with improved checks. This issue is fixed in macOS Big Sur 11.7, macOS Ventura 13, iOS 16, iOS 15.7 and iPadOS 15.7, macOS Monterey 12.6. An app may be able to bypass code signing checks.",
  "id": "GHSA-fvf3-rpfr-xqw3",
  "modified": "2022-11-03T12:00:27Z",
  "published": "2022-11-02T12:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42793"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213443"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213444"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213445"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213446"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213488"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FVFC-M52V-J2P2

Vulnerability from github – Published: 2026-07-30 09:31 – Updated: 2026-07-30 09:31
VLAI
Details

The firmware update process for the basemodule of the charging controller only validates the CRC32 checksum without cryptographic signature verification. This allows an unauthenticated remote attacker to install a modified firmware, resulting in full system compromise.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.3 (Critical)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-44104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T07:16:58Z",
    "severity": "CRITICAL"
  },
  "details": "The firmware update process for the basemodule of the charging controller only validates the\nCRC32 checksum without cryptographic signature verification. This allows an unauthenticated remote attacker to install a modified firmware, resulting in full system compromise.",
  "id": "GHSA-fvfc-m52v-j2p2",
  "modified": "2026-07-30T09:31:18Z",
  "published": "2026-07-30T09:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44104"
    },
    {
      "type": "WEB",
      "url": "https://www.certvde.com/en/advisories/VDE-2026-008"
    }
  ],
  "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/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-FW2J-WPP5-8VP5

Vulnerability from github – Published: 2022-07-27 00:00 – Updated: 2022-08-05 00:00
VLAI
Details

The Omron SYSMAC Nx product family PLCs (NJ series, NY series, NX series, and PMAC series) through 2022-005-18 lack cryptographic authentication. These PLCs are programmed using the SYMAC Studio engineering software (which compiles IEC 61131-3 conformant POU code to native machine code for execution by the PLC's runtime). The resulting machine code is executed by a runtime, typically controlled by a real-time operating system. The logic that is downloaded to the PLC does not seem to be cryptographically authenticated, allowing an attacker to manipulate transmitted object code to the PLC and execute arbitrary machine code on the processor of the PLC's CPU module in the context of the runtime. In the case of at least the NJ series, an RTOS and hardware combination is used that would potentially allow for memory protection and privilege separation and thus limit the impact of code execution. However, it was not confirmed whether these sufficiently segment the runtime from the rest of the RTOS.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-31206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-26T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The Omron SYSMAC Nx product family PLCs (NJ series, NY series, NX series, and PMAC series) through 2022-005-18 lack cryptographic authentication. These PLCs are programmed using the SYMAC Studio engineering software (which compiles IEC 61131-3 conformant POU code to native machine code for execution by the PLC\u0027s runtime). The resulting machine code is executed by a runtime, typically controlled by a real-time operating system. The logic that is downloaded to the PLC does not seem to be cryptographically authenticated, allowing an attacker to manipulate transmitted object code to the PLC and execute arbitrary machine code on the processor of the PLC\u0027s CPU module in the context of the runtime. In the case of at least the NJ series, an RTOS and hardware combination is used that would potentially allow for memory protection and privilege separation and thus limit the impact of code execution. However, it was not confirmed whether these sufficiently segment the runtime from the rest of the RTOS.",
  "id": "GHSA-fw2j-wpp5-8vp5",
  "modified": "2022-08-05T00:00:30Z",
  "published": "2022-07-27T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31206"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-179-02"
    },
    {
      "type": "WEB",
      "url": "https://www.forescout.com/blog"
    }
  ],
  "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-FXG4-QP5Q-79P3

Vulnerability from github – Published: 2025-06-28 00:31 – Updated: 2025-06-28 00:31
VLAI
Details

Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious microcode, potentially resulting in loss of integrity of x86 instruction execution, loss of confidentiality and integrity of data in x86 CPU privileged context and compromise of SMM execution environment.

Severity
6.4 (Medium)
CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-36347"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-27T23:15:26Z",
    "severity": "MODERATE"
  },
  "details": "Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious microcode, potentially resulting in loss of integrity of x86 instruction execution, loss of confidentiality and integrity of data in x86 CPU privileged context and compromise of SMM execution environment.",
  "id": "GHSA-fxg4-qp5q-79p3",
  "modified": "2025-06-28T00:31:11Z",
  "published": "2025-06-28T00:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36347"
    },
    {
      "type": "WEB",
      "url": "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G353-MGV3-8PCJ

Vulnerability from github – Published: 2026-03-13 20:55 – Updated: 2026-04-06 22:32
VLAI
Summary
OpenClaw: Feishu webhook mode accepted forged events when only `verificationToken` was configured
Details

Summary

Feishu webhook mode allowed deployments that configured only verificationToken without encryptKey. In that state, forged inbound events could be accepted because the weaker configuration did not provide the required cryptographic verification boundary.

Impact

An unauthenticated network attacker who could reach the webhook endpoint could inject forged Feishu events, impersonate senders, and potentially trigger downstream tool execution subject to the local agent policy.

Affected versions

openclaw <= 2026.3.11

Patch

Fixed in openclaw 2026.3.12. Feishu webhook mode now fails closed unless encryptKey is configured, and the webhook transport rejects missing or invalid signatures before dispatch. Update to 2026.3.12 or later and configure encryptKey for webhook deployments.

Severity
8.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.11"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T20:55:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFeishu webhook mode allowed deployments that configured only `verificationToken` without `encryptKey`. In that state, forged inbound events could be accepted because the weaker configuration did not provide the required cryptographic verification boundary.\n\n### Impact\n\nAn unauthenticated network attacker who could reach the webhook endpoint could inject forged Feishu events, impersonate senders, and potentially trigger downstream tool execution subject to the local agent policy.\n\n### Affected versions\n\n`openclaw` `\u003c= 2026.3.11`\n\n### Patch\n\nFixed in `openclaw` `2026.3.12`. Feishu webhook mode now fails closed unless `encryptKey` is configured, and the webhook transport rejects missing or invalid signatures before dispatch. Update to `2026.3.12` or later and configure `encryptKey` for webhook deployments.",
  "id": "GHSA-g353-mgv3-8pcj",
  "modified": "2026-04-06T22:32:29Z",
  "published": "2026-03-13T20:55:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-g353-mgv3-8pcj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32974"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/44087"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/7844bc89a1612800810617c823eb0c76ef945804"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.12"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-forged-event-injection-via-feishu-webhook-verification-token"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: Feishu webhook mode accepted forged events when only `verificationToken` was configured"
}

GHSA-G43P-7J43-JPJ7

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

In sig_verify() in x509.c in axTLS version 2.1.3 and before, the PKCS#1 v1.5 signature verification does not properly verify the ASN.1 metadata. Consequently, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation through fake X.509 certificates. This is an even more permissive variant of CVE-2006-4790 and CVE-2014-1568.

Severity
5.9 (Medium)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-16253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-11-07T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "In sig_verify() in x509.c in axTLS version 2.1.3 and before, the PKCS#1 v1.5 signature verification does not properly verify the ASN.1 metadata. Consequently, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation through fake X.509 certificates. This is an even more permissive variant of CVE-2006-4790 and CVE-2014-1568.",
  "id": "GHSA-g43p-7j43-jpj7",
  "modified": "2022-05-14T01:48:58Z",
  "published": "2022-05-14T01:48:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16253"
    },
    {
      "type": "WEB",
      "url": "https://github.com/igrr/axtls-8266/commit/5efe2947ab45e81d84b5f707c51d1c64be52f36c"
    },
    {
      "type": "WEB",
      "url": "https://sourceforge.net/p/axtls/mailman/message/36459928"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G48M-J5M7-625H

Vulnerability from github – Published: 2026-08-03 15:32 – Updated: 2026-08-03 21:31
VLAI
Details

Net::SAML2 versions before 0.86 for Perl allow authentication bypass because _verify_encrypted_assertion accepts an EncryptedAssertion whose decrypted content carries no signature.

_verify_encrypted_assertion decrypts the EncryptedAssertion and returns it as verified when it carries no signature, via "return $xml unless $xpath->exists('dsig:Signature', $assert);". The signature check and the trust anchor check that follow run only when a signature is present, so a decrypted assertion with no dsig:Signature element reaches new_from_xml unverified and its NameID and attributes are read into the assertion object. An SP's encryption certificate is published in its SAML metadata so the IdP can encrypt to it, so any party can encrypt an unsigned assertion to that certificate, wrap it in a samlp:Response, and post it to the assertion consumer service.

Any caller that configures a decryption key_file, and so accepts EncryptedAssertions, takes identity fields from an assertion that no trust anchor covers, and an unauthenticated party can authenticate as an arbitrary user. Callers with no key_file configured do not decrypt and are unaffected.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-18108"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-03T14:16:25Z",
    "severity": "CRITICAL"
  },
  "details": "Net::SAML2 versions before 0.86 for Perl allow authentication bypass because _verify_encrypted_assertion accepts an EncryptedAssertion whose decrypted content carries no signature.\n\n_verify_encrypted_assertion decrypts the EncryptedAssertion and returns it as verified when it carries no signature, via \"return $xml unless $xpath-\u003eexists(\u0027dsig:Signature\u0027, $assert);\". The signature check and the trust anchor check that follow run only when a signature is present, so a decrypted assertion with no dsig:Signature element reaches new_from_xml unverified and its NameID and attributes are read into the assertion object. An SP\u0027s encryption certificate is published in its SAML metadata so the IdP can encrypt to it, so any party can encrypt an unsigned assertion to that certificate, wrap it in a samlp:Response, and post it to the assertion consumer service.\n\nAny caller that configures a decryption key_file, and so accepts EncryptedAssertions, takes identity fields from an assertion that no trust anchor covers, and an unauthenticated party can authenticate as an arbitrary user. Callers with no key_file configured do not decrypt and are unaffected.",
  "id": "GHSA-g48m-j5m7-625h",
  "modified": "2026-08-03T21:31:35Z",
  "published": "2026-08-03T15:32:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18108"
    },
    {
      "type": "WEB",
      "url": "https://github.com/perl-net-saml2/perl-Net-SAML2/commit/d916468586404518b8cf3c78dbd001cc1f1046a7.patch"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/TIMLEGGE/Net-SAML2-0.85/source/lib/Net/SAML2/Protocol/Assertion.pm#L78"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/TIMLEGGE/Net-SAML2-0.86/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-G4VJ-X7V9-H82M

Vulnerability from github – Published: 2021-08-25 20:56 – Updated: 2021-08-18 21:20
VLAI
Summary
Overflow in libsecp256k1
Details

An issue was discovered in the libsecp256k1 crate before 0.5.0 for Rust. It can verify an invalid signature because it allows the R or S parameter to be larger than the curve order, aka an overflow.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "libsecp256k1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-38195"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-18T21:20:32Z",
    "nvd_published_at": "2021-08-08T06:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in the libsecp256k1 crate before 0.5.0 for Rust. It can verify an invalid signature because it allows the R or S parameter to be larger than the curve order, aka an overflow.",
  "id": "GHSA-g4vj-x7v9-h82m",
  "modified": "2021-08-18T21:20:32Z",
  "published": "2021-08-25T20:56:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38195"
    },
    {
      "type": "WEB",
      "url": "https://github.com/paritytech/libsecp256k1/pull/67"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/paritytech/libsecp256k1"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2021-0076.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Overflow in libsecp256k1"
}

GHSA-G5M6-F674-9758

Vulnerability from github – Published: 2026-07-09 12:30 – Updated: 2026-07-09 12:30
VLAI
Details

The CorvusPay WooCommerce Payment Gateway plugin for WordPress is vulnerable to Payment Bypass via Improper Verification of Cryptographic Signature in all versions up to, and including, 2.7.4. The corvuspay_success_handler function registers the REST endpoint POST /wp-json/corvuspay/success/ with 'permission_callback' => '__return_true', and while it calls $this->client->validate->signature() and stores the boolean result in $res, the result is never evaluated in a conditional — it is only written to the debug log — causing execution to unconditionally reach $order->payment_complete() regardless of whether the cryptographic signature is valid. This makes it possible for unauthenticated attackers to mark any pending WooCommerce order as fully paid by sending a POST request to the success endpoint containing an arbitrary or forged signature value, allowing them to obtain goods or services without payment. Because WooCommerce order IDs are sequential integers, target orders are trivially enumerable via the order_number POST parameter, requiring no prior knowledge of the victim order.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-9027"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-09T11:16:42Z",
    "severity": "MODERATE"
  },
  "details": "The CorvusPay WooCommerce Payment Gateway plugin for WordPress is vulnerable to Payment Bypass via Improper Verification of Cryptographic Signature in all versions up to, and including, 2.7.4. The `corvuspay_success_handler` function registers the REST endpoint `POST /wp-json/corvuspay/success/` with `\u0027permission_callback\u0027 =\u003e \u0027__return_true\u0027`, and while it calls `$this-\u003eclient-\u003evalidate-\u003esignature()` and stores the boolean result in `$res`, the result is never evaluated in a conditional \u2014 it is only written to the debug log \u2014 causing execution to unconditionally reach `$order-\u003epayment_complete()` regardless of whether the cryptographic signature is valid. This makes it possible for unauthenticated attackers to mark any pending WooCommerce order as fully paid by sending a POST request to the success endpoint containing an arbitrary or forged signature value, allowing them to obtain goods or services without payment. Because WooCommerce order IDs are sequential integers, target orders are trivially enumerable via the `order_number` POST parameter, requiring no prior knowledge of the victim order.",
  "id": "GHSA-g5m6-f674-9758",
  "modified": "2026-07-09T12:30:29Z",
  "published": "2026-07-09T12:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9027"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/corvuspay-woocommerce-integration/tags/2.7.2/includes/class-wc-gateway-corvuspay.php#L202"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/corvuspay-woocommerce-integration/tags/2.7.2/includes/class-wc-gateway-corvuspay.php#L656"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/corvuspay-woocommerce-integration/tags/2.7.2/includes/class-wc-order-corvuspay.php#L188"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/corvuspay-woocommerce-integration/tags/2.7.4/includes/class-wc-gateway-corvuspay.php#L202"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/corvuspay-woocommerce-integration/tags/2.7.4/includes/class-wc-gateway-corvuspay.php#L656"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/corvuspay-woocommerce-integration/tags/2.7.4/includes/class-wc-order-corvuspay.php#L188"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?reponame=\u0026old=3576949%40corvuspay-woocommerce-integration\u0026new=3576949%40corvuspay-woocommerce-integration"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/3bc9f344-b605-4257-8d77-e073f85fe344?source=cve"
    }
  ],
  "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"
    }
  ]
}

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.

← Back to the CWE list