CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1436 vulnerabilities reference this CWE, most recent first.
GHSA-FXG4-QP5Q-79P3
Vulnerability from github – Published: 2025-06-28 00:31 – Updated: 2025-06-28 00:31Improper 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.
{
"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-G33H-RRJ9-75QV
Vulnerability from github – Published: 2026-09-16 18:32 – Updated: 2026-10-09 12:31A flaw was found in sequoia-openpgp. The library incorrectly infers key flags for older certificates when a key flags subpacket is missing, leading to a discrepancy in how key capabilities are viewed. This key flag confusion allows an attacker to bypass the back-signature check. Consequently, an attacker can illegitimately bind an arbitrary subkey to their own certificate and forge signatures, completely compromising cryptographic integrity.
{
"affected": [],
"aliases": [
"CVE-2026-42784"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-16T17:17:18Z",
"severity": "HIGH"
},
"details": "A flaw was found in sequoia-openpgp. The library incorrectly infers key flags for older certificates when a key flags subpacket is missing, leading to a discrepancy in how key capabilities are viewed. This key flag confusion allows an attacker to bypass the back-signature check. Consequently, an attacker can illegitimately bind an arbitrary subkey to their own certificate and forge signatures, completely compromising cryptographic integrity.",
"id": "GHSA-g33h-rrj9-75qv",
"modified": "2026-10-09T12:31:40Z",
"published": "2026-09-16T18:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42784"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34160"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42078"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42902"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:76733"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:76734"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:76735"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:76737"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:79357"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-42784"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2464122"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G353-MGV3-8PCJ
Vulnerability from github – Published: 2026-03-13 20:55 – Updated: 2026-04-06 22:32Summary
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.
{
"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-G3JJ-5CMM-3HXX
Vulnerability from github – Published: 2026-10-08 22:01 – Updated: 2026-10-08 22:01Summary
fast-jwt 6.2.4 silently classifies raw serialized public JWK JSON
as an HMAC secret.
If an application supplies public JWK JSON text as the verifier key and
HS256 is explicitly allowed or automatically inferred, an attacker who
knows the same public JSON text can use it as an HMAC key and create an
arbitrary HS256 token that fast-jwt accepts as valid.
This can result in authentication or authorization bypass through forged JWT claims.
The PoC demonstrates the issue with a serialized RSA public JWK. The same non-PEM classification also applies to raw JWKS JSON text, although the attached standalone PoC focuses on the smallest JWK case.
Details
The verifier accepts a string or Buffer as key material. In
src/crypto.js, performDetectPublicKeyAlgorithms() attempts to infer
the permitted algorithm family from the supplied string.
Strings matching supported PEM public-key formats are classified as asymmetric keys. Any other non-empty string is assumed to be an HMAC secret:
```js function performDetectPublicKeyAlgorithms(key) { const trimmedKey = key.trim() const publicKeyPemMatch = trimmedKey.match(publicKeyPemMatcher)
if (trimmedKey.match(privateKeyPemMatcher)) { throw new TokenError( TokenError.codes.invalidKey, 'Private keys are not supported for verifying.' ) } else if ( publicKeyPemMatch && publicKeyPemMatch[1] === 'RSA' ) { return rsaAlgorithms } else if ( !publicKeyPemMatch && !trimmedKey.includes(publicKeyX509CertMatcher) ) { // Not a PEM, assume a plain secret return hsAlgorithms }
// ... }
A serialized RSA, EC, or OKP public JWK is valid JSON, but it is not PEM and does not contain a certificate header. It therefore reaches:
return hsAlgorithms
The HS256 verification path then uses the complete public JSON string as the HMAC key.
Because JWK public-key material is public by design, an attacker can know the verifier's cryptographic key material. When that public material is reinterpreted as an HMAC secret, the attacker can calculate a valid HS256 signature over arbitrary claims.
The vulnerable transition is:
Public asymmetric JWK JSON | v Does not match PEM detection | v Classified as a plain secret | v HS256 permitted or inferred | v Attacker signs using public JSON bytes | v Forged token accepted
The attached PoC demonstrates both relevant configurations:
An explicit mixed-family allowlist: createVerifier({ key: rawJwk, algorithms: ['HS256', 'RS256'] }) No explicit algorithm allowlist: createVerifier({ key: rawJwk })
In the second configuration, fast-jwt detects the raw non-PEM string as symmetric key material and permits the HS algorithm family.
An RS256-only verifier rejects the same forged token, providing a negative control:
createVerifier({ key: rawJwk, algorithms: ['RS256'] })
The documentation describes asymmetric verifier keys as PEM-encoded public keys. The security issue is not that the raw JWK is successfully parsed as an asymmetric key. It is that ambiguous structured public-key text is silently reclassified as a symmetric secret rather than being rejected, and that this classification permits an attacker-controlled HS256 token.
PoC
Requirements:
Node.js 20 or newer npm The attached submission ZIP
Extract the attachment and run:
cd poc npm install node poc.js
The PoC performs the following steps:
Generates a fresh RSA key pair locally. Exports only the public key as a JWK. Adds ordinary public JWK metadata such as kid, use, and alg. Serializes the public JWK as JSON. Uses the serialized public JWK text as an HS256 HMAC key. Creates a token containing attacker-selected administrative claims. Supplies the same raw public JSON string to the real fast-jwt verifier. Confirms acceptance with a mixed HS256/RS256 allowlist. Confirms acceptance when algorithm detection is left enabled. Confirms rejection with an RS256-only verifier.
Expected output:
mixed algorithms: forged token accepted inferred algorithms: forged token accepted RS256-only control: forged token rejected VULNERABLE: fast-jwt@6.2.4 accepted attacker-signed HS256 claims
The accepted token contains:
{ "sub": "attacker", "role": "admin", "admin": true }
The PoC operates entirely locally using a newly generated key pair. It does not contact any production service, identity provider, or third-party application.
Impact
An affected application may accept attacker-generated JWT claims as authentic.
Depending on how verified claims are used, an attacker could potentially forge:
user or subject identifiers; administrator roles; authorization scopes; permissions; tenant or organization identifiers; and application-specific authorization flags.
This may result in authentication bypass, horizontal privilege escalation, vertical privilege escalation, or unauthorized access to protected application data.
Exploitation requires all of the following:
The application passes raw serialized public JWK or JWKS JSON text as the verifier key. HS256 is explicitly permitted or is inferred from the non-PEM string. The attacker knows the exact serialized bytes supplied to the verifier.
Public JWK/JWKS material is normally available to relying parties and often exposed through public discovery endpoints. However, property ordering, whitespace, or other serialization differences may affect an attacker's ability to reproduce the exact HMAC key bytes.
These integration and serialization requirements are represented by High attack complexity.
Applications that supply a supported PEM public key and restrict verification to the expected asymmetric algorithm family are not affected by this PoC.
Earlier package versions were not assessed as part of this report.
Suggested remediation
Structured public-key representations should be detected before an arbitrary non-PEM string is classified as symmetric key material.
At minimum, JSON strings containing asymmetric JWK or JWKS structures should be rejected for HS* verification. Relevant asymmetric kty values include:
RSA EC OKP
Potential approaches include:
Parse JSON-looking verifier strings before HMAC classification. Reject asymmetric JWK/JWKS structures for HS256, HS384, and HS512. Do not treat all non-PEM strings as symmetric secrets merely because PEM detection failed. Require explicit algorithm selection when the key format is ambiguous. Bind the permitted algorithm family to the semantic key type rather than the success or failure of PEM detection.
Regression tests should cover:
compact serialized JWK JSON; pretty-printed JWK JSON; raw JWKS JSON; RSA, EC, and OKP public keys; mixed symmetric/asymmetric algorithm allowlists; default algorithm detection; asymmetric-only algorithm controls; trailing whitespace and newline variants; and property-order and serialization variants. fast-jwt-raw-jwk-hs256-submit.zip
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fast-jwt"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.4"
},
{
"fixed": "6.3.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"6.2.4"
]
}
],
"aliases": [
"CVE-2026-107724"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T22:01:53Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n`fast-jwt` 6.2.4 silently classifies raw serialized public JWK JSON\nas an HMAC secret.\n\nIf an application supplies public JWK JSON text as the verifier key and\nHS256 is explicitly allowed or automatically inferred, an attacker who\nknows the same public JSON text can use it as an HMAC key and create an\narbitrary HS256 token that `fast-jwt` accepts as valid.\n\nThis can result in authentication or authorization bypass through forged\nJWT claims.\n\nThe PoC demonstrates the issue with a serialized RSA public JWK. The same\nnon-PEM classification also applies to raw JWKS JSON text, although the\nattached standalone PoC focuses on the smallest JWK case.\n\n### Details\n\nThe verifier accepts a string or Buffer as key material. In\n`src/crypto.js`, `performDetectPublicKeyAlgorithms()` attempts to infer\nthe permitted algorithm family from the supplied string.\n\nStrings matching supported PEM public-key formats are classified as\nasymmetric keys. Any other non-empty string is assumed to be an HMAC\nsecret:\n\n```js\nfunction performDetectPublicKeyAlgorithms(key) {\n const trimmedKey = key.trim()\n const publicKeyPemMatch = trimmedKey.match(publicKeyPemMatcher)\n\n if (trimmedKey.match(privateKeyPemMatcher)) {\n throw new TokenError(\n TokenError.codes.invalidKey,\n \u0027Private keys are not supported for verifying.\u0027\n )\n } else if (\n publicKeyPemMatch \u0026\u0026\n publicKeyPemMatch[1] === \u0027RSA\u0027\n ) {\n return rsaAlgorithms\n } else if (\n !publicKeyPemMatch \u0026\u0026\n !trimmedKey.includes(publicKeyX509CertMatcher)\n ) {\n // Not a PEM, assume a plain secret\n return hsAlgorithms\n }\n\n // ...\n}\n\nA serialized RSA, EC, or OKP public JWK is valid JSON, but it is not PEM\nand does not contain a certificate header. It therefore reaches:\n\nreturn hsAlgorithms\n\nThe HS256 verification path then uses the complete public JSON string as\nthe HMAC key.\n\nBecause JWK public-key material is public by design, an attacker can know\nthe verifier\u0027s cryptographic key material. When that public material is\nreinterpreted as an HMAC secret, the attacker can calculate a valid\nHS256 signature over arbitrary claims.\n\nThe vulnerable transition is:\n\nPublic asymmetric JWK JSON\n |\n v\nDoes not match PEM detection\n |\n v\nClassified as a plain secret\n |\n v\nHS256 permitted or inferred\n |\n v\nAttacker signs using public JSON bytes\n |\n v\nForged token accepted\n\nThe attached PoC demonstrates both relevant configurations:\n\nAn explicit mixed-family allowlist:\ncreateVerifier({\n key: rawJwk,\n algorithms: [\u0027HS256\u0027, \u0027RS256\u0027]\n})\nNo explicit algorithm allowlist:\ncreateVerifier({\n key: rawJwk\n})\n\nIn the second configuration, fast-jwt detects the raw non-PEM string as\nsymmetric key material and permits the HS algorithm family.\n\nAn RS256-only verifier rejects the same forged token, providing a\nnegative control:\n\ncreateVerifier({\n key: rawJwk,\n algorithms: [\u0027RS256\u0027]\n})\n\nThe documentation describes asymmetric verifier keys as PEM-encoded\npublic keys. The security issue is not that the raw JWK is successfully\nparsed as an asymmetric key. It is that ambiguous structured public-key\ntext is silently reclassified as a symmetric secret rather than being\nrejected, and that this classification permits an attacker-controlled\nHS256 token.\n\nPoC\n\nRequirements:\n\nNode.js 20 or newer\nnpm\nThe attached submission ZIP\n\nExtract the attachment and run:\n\ncd poc\nnpm install\nnode poc.js\n\nThe PoC performs the following steps:\n\nGenerates a fresh RSA key pair locally.\nExports only the public key as a JWK.\nAdds ordinary public JWK metadata such as kid, use, and alg.\nSerializes the public JWK as JSON.\nUses the serialized public JWK text as an HS256 HMAC key.\nCreates a token containing attacker-selected administrative claims.\nSupplies the same raw public JSON string to the real\nfast-jwt verifier.\nConfirms acceptance with a mixed HS256/RS256 allowlist.\nConfirms acceptance when algorithm detection is left enabled.\nConfirms rejection with an RS256-only verifier.\n\nExpected output:\n\nmixed algorithms: forged token accepted\ninferred algorithms: forged token accepted\nRS256-only control: forged token rejected\nVULNERABLE: fast-jwt@6.2.4 accepted attacker-signed HS256 claims\n\nThe accepted token contains:\n\n{\n \"sub\": \"attacker\",\n \"role\": \"admin\",\n \"admin\": true\n}\n\nThe PoC operates entirely locally using a newly generated key pair. It\ndoes not contact any production service, identity provider, or\nthird-party application.\n\nImpact\n\nAn affected application may accept attacker-generated JWT claims as\nauthentic.\n\nDepending on how verified claims are used, an attacker could potentially\nforge:\n\nuser or subject identifiers;\nadministrator roles;\nauthorization scopes;\npermissions;\ntenant or organization identifiers; and\napplication-specific authorization flags.\n\nThis may result in authentication bypass, horizontal privilege\nescalation, vertical privilege escalation, or unauthorized access to\nprotected application data.\n\nExploitation requires all of the following:\n\nThe application passes raw serialized public JWK or JWKS JSON text as\nthe verifier key.\nHS256 is explicitly permitted or is inferred from the non-PEM string.\nThe attacker knows the exact serialized bytes supplied to the\nverifier.\n\nPublic JWK/JWKS material is normally available to relying parties and\noften exposed through public discovery endpoints. However, property\nordering, whitespace, or other serialization differences may affect an\nattacker\u0027s ability to reproduce the exact HMAC key bytes.\n\nThese integration and serialization requirements are represented by\nHigh attack complexity.\n\nApplications that supply a supported PEM public key and restrict\nverification to the expected asymmetric algorithm family are not\naffected by this PoC.\n\nEarlier package versions were not assessed as part of this report.\n\nSuggested remediation\n\nStructured public-key representations should be detected before an\narbitrary non-PEM string is classified as symmetric key material.\n\nAt minimum, JSON strings containing asymmetric JWK or JWKS structures\nshould be rejected for HS* verification. Relevant asymmetric kty\nvalues include:\n\nRSA\nEC\nOKP\n\nPotential approaches include:\n\nParse JSON-looking verifier strings before HMAC classification.\nReject asymmetric JWK/JWKS structures for HS256, HS384, and HS512.\nDo not treat all non-PEM strings as symmetric secrets merely because\nPEM detection failed.\nRequire explicit algorithm selection when the key format is\nambiguous.\nBind the permitted algorithm family to the semantic key type rather\nthan the success or failure of PEM detection.\n\nRegression tests should cover:\n\ncompact serialized JWK JSON;\npretty-printed JWK JSON;\nraw JWKS JSON;\nRSA, EC, and OKP public keys;\nmixed symmetric/asymmetric algorithm allowlists;\ndefault algorithm detection;\nasymmetric-only algorithm controls;\ntrailing whitespace and newline variants; and\nproperty-order and serialization variants.\n[fast-jwt-raw-jwk-hs256-submit.zip](https://github.com/user-attachments/files/30396435/fast-jwt-raw-jwk-hs256-submit.zip)",
"id": "GHSA-g3jj-5cmm-3hxx",
"modified": "2026-10-08T22:01:53Z",
"published": "2026-10-08T22:01:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-g3jj-5cmm-3hxx"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/pull/636"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/commit/10f9591349199ed2ab9fa1748ce92cdca697f6cf"
},
{
"type": "PACKAGE",
"url": "https://github.com/nearform/fast-jwt"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/releases/tag/v6.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "fast-jwt treats raw public JWK JSON as an HMAC secret, enabling HS256 token forgery"
}
GHSA-G43P-7J43-JPJ7
Vulnerability from github – Published: 2022-05-14 01:48 – Updated: 2022-05-14 01:48In 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.
{
"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:31Net::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.
{
"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:20An 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.
{
"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:30The 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.
{
"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"
}
]
}
GHSA-G5RW-PW9W-C288
Vulnerability from github – Published: 2026-08-21 09:32 – Updated: 2026-08-24 18:31Certificate validation failures in SAML authentication in Apache CloudStack 4.20.3.0 and 4.22.1.0 on all platforms allow a malicious agent to forge a SAML response to the management server. The agent will have to spoof the ip address of the IdP or get an url of its own choosing registered in the management server, after which it can allow logging on with forged signatures.
Users are recommended to upgrade to versions 4.20.3.1 or 4.22.1.1 and above, which fix this issue.
{
"affected": [],
"aliases": [
"CVE-2026-68745"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-21T09:16:40Z",
"severity": "HIGH"
},
"details": "Certificate validation failures in SAML authentication in Apache CloudStack 4.20.3.0 and 4.22.1.0 on all platforms allow a malicious agent to forge a SAML response to the management server. The agent will have to spoof the ip address of the IdP or get an url of its own choosing registered in the management server, after which it can allow logging on with forged signatures.\n\nUsers are recommended to upgrade to versions 4.20.3.1 or 4.22.1.1 and above, which fix this issue.",
"id": "GHSA-g5rw-pw9w-c288",
"modified": "2026-08-24T18:31:45Z",
"published": "2026-08-21T09:32:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68745"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/g6cwddtjrwbh1d56wjz4cfp3fzfm4kbc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G5WV-CVF4-2R98
Vulnerability from github – Published: 2024-11-26 15:31 – Updated: 2025-11-04 00:32The application failed to account for exceptions thrown by the loadManifestFromFile method during add-on signature verification. This flaw, triggered by an invalid or unsupported extension manifest, could have caused runtime errors that disrupted the signature validation process. As a result, the enforcement of signature validation for unrelated add-ons may have been bypassed. Signature validation in this context is used to ensure that third-party applications on the user's computer have not tampered with the user's extensions, limiting the impact of this issue. This vulnerability affects Firefox < 133, Firefox ESR < 128.5, Thunderbird < 133, and Thunderbird < 128.5.
{
"affected": [],
"aliases": [
"CVE-2024-11696"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-26T14:15:19Z",
"severity": "MODERATE"
},
"details": "The application failed to account for exceptions thrown by the `loadManifestFromFile` method during add-on signature verification. This flaw, triggered by an invalid or unsupported extension manifest, could have caused runtime errors that disrupted the signature validation process. As a result, the enforcement of signature validation for unrelated add-ons may have been bypassed. Signature validation in this context is used to ensure that third-party applications on the user\u0027s computer have not tampered with the user\u0027s extensions, limiting the impact of this issue. This vulnerability affects Firefox \u003c 133, Firefox ESR \u003c 128.5, Thunderbird \u003c 133, and Thunderbird \u003c 128.5.",
"id": "GHSA-g5wv-cvf4-2r98",
"modified": "2025-11-04T00:32:08Z",
"published": "2024-11-26T15:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11696"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1929600"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/11/msg00029.html"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-63"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-64"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-67"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-68"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/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.