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.

1128 vulnerabilities reference this CWE, most recent first.

GHSA-2W3G-R4C9-2JP8

Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30
VLAI
Details

Improper privilege management in the installer for Zoom Desktop Client for macOS before version 5.17.10 may allow a privileged user to conduct an escalation of privilege via local access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-27247"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-09T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Improper privilege management in the installer for Zoom Desktop Client for macOS before version 5.17.10 may allow a privileged user to conduct an escalation of privilege via local access.",
  "id": "GHSA-2w3g-r4c9-2jp8",
  "modified": "2024-04-09T18:30:28Z",
  "published": "2024-04-09T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27247"
    },
    {
      "type": "WEB",
      "url": "https://www.zoom.com/en/trust/security-bulletin/zsb-24012"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2W8X-224X-785M

Vulnerability from github – Published: 2026-03-17 06:31 – Updated: 2026-03-25 14:36
VLAI
Summary
sjcl is missing point-on-curve validation in sjcl.ecc.basicKey.publicKey
Details

All versions of the package sjcl are vulnerable to Improper Verification of Cryptographic Signature due to missing point-on-curve validation in sjcl.ecc.basicKey.publicKey(). An attacker can recover a victim's ECDH private key by sending crafted off-curve public keys and observing ECDH outputs. The dhJavaEc() function directly returns the raw x-coordinate of the scalar multiplication result (no hashing), providing a plaintext oracle without requiring any decryption feedback.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.8"
      },
      "package": {
        "ecosystem": "npm",
        "name": "sjcl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-4258"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T16:10:06Z",
    "nvd_published_at": "2026-03-17T06:16:18Z",
    "severity": "HIGH"
  },
  "details": "All versions of the package sjcl are vulnerable to Improper Verification of Cryptographic Signature due to missing point-on-curve validation in sjcl.ecc.basicKey.publicKey(). An attacker can recover a victim\u0027s ECDH private key by sending crafted off-curve public keys and observing ECDH outputs. The dhJavaEc() function directly returns the raw x-coordinate of the scalar multiplication result (no hashing), providing a plaintext oracle without requiring any decryption feedback.",
  "id": "GHSA-2w8x-224x-785m",
  "modified": "2026-03-25T14:36:28Z",
  "published": "2026-03-17T06:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4258"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bitwiseshiftleft/sjcl/commit/ee307459972442a17beebc29dc331fffd8aff796"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/Kr0emer/2560f98edb10b0b34f2438cd63913c47"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bitwiseshiftleft/sjcl"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bitwiseshiftleft/sjcl/blob/master/core/ecc.js#L454-L461"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-SJCL-15369617"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "sjcl is missing point-on-curve validation in sjcl.ecc.basicKey.publicKey"
}

GHSA-2WRX-Q5XX-WFFM

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

A CWE-347: Improper Verification of Cryptographic Signature vulnerability exists in EVlink City (EVC1S22P4 / EVC1S7P4 all versions prior to R8 V3.4.0.1), EVlink Parking (EVW2 / EVF2 / EV.2 all versions prior to R8 V3.4.0.1), and EVlink Smart Wallbox (EVB1A all versions prior to R8 V3.4.0.1 ) that could allow an attacker to craft a malicious firmware package and bypass the signature verification mechanism.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-22708"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-21T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A CWE-347: Improper Verification of Cryptographic Signature vulnerability exists in EVlink City (EVC1S22P4 / EVC1S7P4 all versions prior to R8 V3.4.0.1), EVlink Parking (EVW2 / EVF2 / EV.2 all versions prior to R8 V3.4.0.1), and EVlink Smart Wallbox (EVB1A all versions prior to R8 V3.4.0.1 ) that could allow an attacker to craft a malicious firmware package and bypass the signature verification mechanism.",
  "id": "GHSA-2wrx-q5xx-wffm",
  "modified": "2022-05-24T19:08:48Z",
  "published": "2022-05-24T19:08:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22708"
    },
    {
      "type": "WEB",
      "url": "http://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-194-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2X3R-HWV5-P32X

Vulnerability from github – Published: 2025-06-04 20:48 – Updated: 2025-06-04 22:56
VLAI
Summary
Deno's AES GCM authentication tags are not verified
Details

Summary

This affects AES-256-GCM and AES-128-GCM in Deno, introduced by commit 0d1beed. Specifically, the authentication tag is not being validated. This means tampered ciphertexts or incorrect keys might not be detected, which breaks the guarantees expected from AES-GCM. Older versions of Deno correctly threw errors in such cases, as does Node.js.

Without authentication tag verification, AES-GCM degrades to essentially CTR mode, removing integrity protection. Authenticated data set with set_aad is also affected, as it is incorporated into the GCM hash (ghash) but this too is not validated, rendering AAD checks ineffective.

PoC

import { Buffer } from "node:buffer";
import {
  createCipheriv,
  createDecipheriv,
  randomBytes,
  scrypt,
} from "node:crypto";

type Encrypted = {
  salt: string;
  iv: string;
  enc: string;
  authTag: string;
};

const deriveKey = (key: string, salt: Buffer) =>
  new Promise<Buffer>((res, rej) =>
    scrypt(key, salt, 32, (err, k) => {
      if (err) rej(err);
      else res(k);
    })
  );

async function encrypt(text: string, key: string): Promise<Encrypted> {
  const salt = randomBytes(32);
  const k = await deriveKey(key, salt);

  const iv = randomBytes(16);
  const enc = createCipheriv("aes-256-gcm", k, iv);
  const ciphertext = enc.update(text, "binary", "binary") + enc.final("binary");

  return {
    salt: salt.toString("binary"),
    iv: iv.toString("binary"),
    enc: ciphertext,
    authTag: enc.getAuthTag().toString("binary"),
  };
}

async function decrypt(enc: Encrypted, key: string) {
  const k = await deriveKey(key, Buffer.from(enc.salt, "binary"));
  const dec = createDecipheriv("aes-256-gcm", k, Buffer.from(enc.iv, "binary"));

  const out = dec.update(enc.enc, "binary", "binary");
  dec.setAuthTag(Buffer.from(enc.authTag, "binary"));
  return out + dec.final("binary");
}

const test = await encrypt("abcdefghi", "key");
test.enc = "";
console.log(await decrypt(test, "")); // no error

Impact

While discovered through experimentation, authentication failures that should raise errors may be silently ignored.

Severity
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "deno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.46.0"
            },
            {
              "fixed": "2.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "deno_node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.102.0"
            },
            {
              "fixed": "0.125.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24015"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-04T20:48:56Z",
    "nvd_published_at": "2025-06-03T23:15:20Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThis affects AES-256-GCM and AES-128-GCM in Deno, introduced by commit [0d1beed](https://github.com/denoland/deno/commit/0d1beed). Specifically, the authentication tag is not being validated. This means tampered ciphertexts or incorrect keys might not be detected, which breaks the guarantees expected from AES-GCM. Older versions of Deno correctly threw errors in such cases, as does Node.js.\n\nWithout authentication tag verification, AES-GCM degrades to essentially CTR mode, removing integrity protection. Authenticated data set with set_aad is also affected, as it is incorporated into the GCM hash (ghash) but this too is not validated, rendering AAD checks ineffective.\n\n### PoC\n\n```ts\nimport { Buffer } from \"node:buffer\";\nimport {\n  createCipheriv,\n  createDecipheriv,\n  randomBytes,\n  scrypt,\n} from \"node:crypto\";\n\ntype Encrypted = {\n  salt: string;\n  iv: string;\n  enc: string;\n  authTag: string;\n};\n\nconst deriveKey = (key: string, salt: Buffer) =\u003e\n  new Promise\u003cBuffer\u003e((res, rej) =\u003e\n    scrypt(key, salt, 32, (err, k) =\u003e {\n      if (err) rej(err);\n      else res(k);\n    })\n  );\n\nasync function encrypt(text: string, key: string): Promise\u003cEncrypted\u003e {\n  const salt = randomBytes(32);\n  const k = await deriveKey(key, salt);\n\n  const iv = randomBytes(16);\n  const enc = createCipheriv(\"aes-256-gcm\", k, iv);\n  const ciphertext = enc.update(text, \"binary\", \"binary\") + enc.final(\"binary\");\n\n  return {\n    salt: salt.toString(\"binary\"),\n    iv: iv.toString(\"binary\"),\n    enc: ciphertext,\n    authTag: enc.getAuthTag().toString(\"binary\"),\n  };\n}\n\nasync function decrypt(enc: Encrypted, key: string) {\n  const k = await deriveKey(key, Buffer.from(enc.salt, \"binary\"));\n  const dec = createDecipheriv(\"aes-256-gcm\", k, Buffer.from(enc.iv, \"binary\"));\n\n  const out = dec.update(enc.enc, \"binary\", \"binary\");\n  dec.setAuthTag(Buffer.from(enc.authTag, \"binary\"));\n  return out + dec.final(\"binary\");\n}\n\nconst test = await encrypt(\"abcdefghi\", \"key\");\ntest.enc = \"\";\nconsole.log(await decrypt(test, \"\")); // no error\n```\n\n### Impact\n\nWhile discovered through experimentation, authentication failures that should raise errors may be silently ignored.",
  "id": "GHSA-2x3r-hwv5-p32x",
  "modified": "2025-06-04T22:56:13Z",
  "published": "2025-06-04T20:48:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/security/advisories/GHSA-2x3r-hwv5-p32x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24015"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/commit/0d1beed"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/commit/0d1beed2e3633d71d5e288e0382b85be361ec13d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/commit/4f27d7cdc02e3edfb9d36275341fb8185d6e99ed"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/commit/a4003a5292bd0affefad3ecb24a8732886900f67"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/denoland/deno"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Deno\u0027s AES GCM authentication tags are not verified"
}

GHSA-2X5J-VHC8-9CWM

Vulnerability from github – Published: 2025-06-10 21:18 – Updated: 2025-10-23 17:36
VLAI
Summary
CIRCL-Fourq: Missing and wrong validation can lead to incorrect results
Details

Impact

The CIRCL implementation of FourQ fails to validate user-supplied low-order points during Diffie-Hellman key exchange, potentially allowing attackers to force the identity point and compromise session security.

Moreover, there is an incorrect point validation in ScalarMult can lead to incorrect results in the isEqual function and if a point is on the curve.

Patches

Version 1.6.1 (https://github.com/cloudflare/circl/tree/v1.6.1) mitigates the identified issues.

We acknowledge Alon Livne (Botanica Software Labs) for the reported findings.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cloudflare/circl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-8556"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-10T21:18:33Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\nThe CIRCL implementation of FourQ fails to validate user-supplied low-order points during Diffie-Hellman key exchange, potentially allowing attackers to force the identity point and compromise session security.\n\nMoreover, there is an incorrect point validation in ScalarMult can lead to incorrect results in the isEqual function and if a point is on the curve.\n\n\n### Patches\nVersion 1.6.1 (https://github.com/cloudflare/circl/tree/v1.6.1) mitigates the identified issues.\n\nWe acknowledge Alon Livne (Botanica Software Labs) for the reported findings.",
  "id": "GHSA-2x5j-vhc8-9cwm",
  "modified": "2025-10-23T17:36:51Z",
  "published": "2025-06-10T21:18:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/circl/security/advisories/GHSA-2x5j-vhc8-9cwm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8556"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-8556"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2371624"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cloudflare/circl"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/circl/tree/v1.6.1"
    },
    {
      "type": "WEB",
      "url": "https://news.ycombinator.com/item?id=45669593"
    },
    {
      "type": "WEB",
      "url": "https://www.botanica.software/blog/cryptographic-issues-in-cloudflares-circl-fourq-implementation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CIRCL-Fourq: Missing and wrong validation can lead to incorrect results"
}

GHSA-2XP3-57P7-QF4V

Vulnerability from github – Published: 2024-05-01 17:05 – Updated: 2024-07-05 18:34
VLAI
Summary
xml-crypto vulnerable to XML signature verification bypass due improper verification of signature/signature spoofing
Details

Summary

Default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-CoreValidation. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a <KeyInfo /> element, and pass xml-crypto default validation checks.

Details

Affected xml-crypto versions between versions >= 4.0.0 and < 6.0.0.

xml-crypto trusts by default any certificate provided via digitally signed XML document's <KeyInfo />.

xml-crypto prefers to use any certificate provided via digitally signed XML document's <KeyInfo /> even if library was configured to use specific certificate (publicCert) for signature verification purposes.

Attacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious private key (created by attacker) and by attaching that private key's certificate to <KeyInfo /> element.

Vulnerability is combination of changes introduced to 4.0.0 at * https://github.com/node-saml/xml-crypto/pull/301 * https://github.com/node-saml/xml-crypto/commit/c2b83f984049edb68ad1d7c6ad0739ec92af11ca

Changes at PR provided default method to extract certificate from signed XML document. * https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L405-L414 * https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L334

and changes at PR prefer output of that method to be used as certificate for signature verification even in the case when library is configured to use specific/pre-configured signingCert * https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L507

Name of the signingCert was changed later (but prior to 4.0.0 release) to publicCert: * https://github.com/node-saml/xml-crypto/commit/78329fbae34c9b25ba25882604e960f506d7c0e7 * https://github.com/node-saml/xml-crypto/blob/78329fbae34c9b25ba25882604e960f506d7c0e7/lib/signed-xml.js#L507

Issue was fixed to 6.0.0 by disabling implicit usage of default getCertFromKeyInfo implementation: * https://github.com/node-saml/xml-crypto/pull/445 * https://github.com/node-saml/xml-crypto/commit/21201723d2ca9bc11288f62cf72552b7d659b000

Possible workarounds for versions 4.x and 5.x: - Check the certificate extracted via getCertFromKeyInfo against trusted certificates before accepting the results of the validation. - Set xml-crypto's getCertFromKeyInfo to () => undefined forcing xml-crypto to use an explicitly configured publicCert or privateKey for signature verification.

PoC

https://github.com/node-saml/xml-crypto/discussions/399

Impact

An untrusted certificate can be used to pass a malicious XML payload through an improperly configured installation of xml-crypto.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "xml-crypto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "6.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-32962"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-01T17:05:53Z",
    "nvd_published_at": "2024-05-02T07:15:21Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nDefault configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-CoreValidation. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a `\u003cKeyInfo /\u003e` element, and pass `xml-crypto` default validation checks.\n\n### Details\n\nAffected `xml-crypto` versions between versions `\u003e= 4.0.0` and `\u003c 6.0.0`. \n\n`xml-crypto` trusts by default any certificate provided via digitally signed XML document\u0027s `\u003cKeyInfo /\u003e`.\n\n`xml-crypto` prefers to use any certificate provided via digitally signed XML document\u0027s `\u003cKeyInfo /\u003e` even if library was configured to use specific certificate (`publicCert`) for signature verification purposes.\n\nAttacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious private key (created by attacker) and by attaching that private key\u0027s certificate to `\u003cKeyInfo /\u003e` element.\n\nVulnerability is combination of changes introduced to `4.0.0` at\n* https://github.com/node-saml/xml-crypto/pull/301\n* https://github.com/node-saml/xml-crypto/commit/c2b83f984049edb68ad1d7c6ad0739ec92af11ca\n\nChanges at PR provided default method to extract certificate from signed XML document.\n* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L405-L414\n* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L334\n\nand changes at PR prefer output of that method to be used as certificate for signature verification even in the case when library is configured to use specific/pre-configured `signingCert`\n* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L507\n\nName of the `signingCert` was changed later (but prior to `4.0.0` release) to `publicCert`:\n* https://github.com/node-saml/xml-crypto/commit/78329fbae34c9b25ba25882604e960f506d7c0e7\n* https://github.com/node-saml/xml-crypto/blob/78329fbae34c9b25ba25882604e960f506d7c0e7/lib/signed-xml.js#L507\n\nIssue was fixed to `6.0.0` by disabling implicit usage of default `getCertFromKeyInfo` implementation:\n* https://github.com/node-saml/xml-crypto/pull/445\n* https://github.com/node-saml/xml-crypto/commit/21201723d2ca9bc11288f62cf72552b7d659b000\n\nPossible workarounds for versions 4.x and 5.x:\n- Check the certificate extracted via `getCertFromKeyInfo` against trusted certificates before accepting the results of the validation.\n- Set `xml-crypto`\u0027s `getCertFromKeyInfo` to `() =\u003e undefined` forcing `xml-crypto` to use an explicitly configured `publicCert` or `privateKey` for signature verification.\n\n### PoC\n\nhttps://github.com/node-saml/xml-crypto/discussions/399\n\n### Impact\n\nAn untrusted certificate can be used to pass a malicious XML payload through an improperly configured installation of `xml-crypto`.\n",
  "id": "GHSA-2xp3-57p7-qf4v",
  "modified": "2024-07-05T18:34:13Z",
  "published": "2024-05-01T17:05:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/security/advisories/GHSA-2xp3-57p7-qf4v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32962"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/pull/301"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/pull/445"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/commit/21201723d2ca9bc11288f62cf72552b7d659b000"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/commit/c2b83f984049edb68ad1d7c6ad0739ec92af11ca"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/node-saml/xml-crypto"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/discussions/399"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240705-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-CoreValidation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "xml-crypto vulnerable to XML signature verification bypass due improper verification of signature/signature spoofing"
}

GHSA-32XP-F3PH-FPPF

Vulnerability from github – Published: 2023-09-14 18:32 – Updated: 2024-04-04 07:40
VLAI
Details

A vulnerability has been identified in QMS Automotive (All versions < V12.39). The QMS.Mobile module of the affected application uses weak outdated application signing mechanism. This could allow an attacker to tamper the application code.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-40727"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-12T10:15:29Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in QMS Automotive (All versions \u003c V12.39). The QMS.Mobile module of the affected application uses weak outdated application signing mechanism. This could allow an attacker to tamper the application code.",
  "id": "GHSA-32xp-f3ph-fppf",
  "modified": "2024-04-04T07:40:31Z",
  "published": "2023-09-14T18:32:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40727"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-147266.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-338F-47MV-53CH

Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2024-05-21 18:31
VLAI
Details

Improper Verification of Cryptographic Signature vulnerability in HYPR Passwordless on Windows allows Malicious Software Update.This issue affects HYPR Passwordless: before 9.1.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-1721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T16:15:24Z",
    "severity": null
  },
  "details": "Improper Verification of Cryptographic Signature vulnerability in HYPR Passwordless on Windows allows Malicious Software Update.This issue affects HYPR Passwordless: before 9.1.",
  "id": "GHSA-338f-47mv-53ch",
  "modified": "2024-05-21T18:31:23Z",
  "published": "2024-05-21T18:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1721"
    },
    {
      "type": "WEB",
      "url": "https://www.hypr.com/trust-center/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-33J7-6P7H-F87G

Vulnerability from github – Published: 2025-05-23 15:31 – Updated: 2025-12-09 18:30
VLAI
Details

A vulnerability has been identified in SiPass integrated AC5102 (ACC-G2) (All versions), SiPass integrated ACC-AP (All versions). Affected devices do not properly check the integrity of firmware updates. This could allow a local attacker to upload a maliciously modified firmware onto the device. In a second scenario, a remote attacker who is able to intercept the transfer of a valid firmware from the server to the device could modify the firmware "on the fly".

Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
8.2 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-31807"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-23T15:15:21Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SiPass integrated AC5102 (ACC-G2) (All versions), SiPass integrated ACC-AP (All versions). Affected devices do not properly check the integrity of firmware updates. This could allow a local attacker to upload a maliciously modified firmware onto the device. In a second scenario, a remote attacker who is able to intercept the transfer of a valid firmware from the server to the device could modify the firmware \"on the fly\".",
  "id": "GHSA-33j7-6p7h-f87g",
  "modified": "2025-12-09T18:30:28Z",
  "published": "2025-05-23T15:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31807"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-367714.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-420375.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/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-33J8-J763-4FV5

Vulnerability from github – Published: 2026-06-12 12:31 – Updated: 2026-06-12 18:31
VLAI
Details

A vulnerability in Apache CXF's JwsJsonContainerRequestFilter can be exploited to cause CXF to process metadata that was not authenticated by the accepted signature. This can bypass the application's assumption

that accepted Content-Type or protected HTTP-header metadata came from a verified signature entry, and may steer downstream JAX-RS entity parsing or signed-header consistency checks. Users are recommended to upgrade to versions 4.2.2 or 4.1.7, which fix this issue.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-50634"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-12T10:16:23Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in Apache CXF\u0027s\u00a0JwsJsonContainerRequestFilter can be exploited to cause\u00a0CXF to process metadata that was not authenticated by the accepted signature.\u00a0This can bypass the application\u0027s assumption\n\nthat accepted `Content-Type` or protected HTTP-header metadata came from a verified signature entry, and may steer downstream JAX-RS entity parsing or signed-header consistency checks. Users are recommended to upgrade to versions 4.2.2 or 4.1.7, which fix this issue.",
  "id": "GHSA-33j8-j763-4fv5",
  "modified": "2026-06-12T18:31:53Z",
  "published": "2026-06-12T12:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50634"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/9nfwh9d3m4kznxrk1mz98hl0jml18k0p"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/11/11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A: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