GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

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

1336 vulnerabilities reference this CWE, most recent first.

GHSA-8H88-GXP3-J7PG

Vulnerability from github – Published: 2026-04-01 21:11 – Updated: 2026-04-01 21:11
VLAI
Summary
openssl-encrypt's unverified key bundle from_dict() + to_identity() path allows encryption to attacker keys
Details

Summary

The PublicKeyBundle.from_dict() method in openssl_encrypt/modules/key_bundle.py at lines 329-361 creates bundles from untrusted data without verifying the signature. The docstring warns to call verify_signature() after creation, but the to_identity() method (line 363-391) can convert an unverified bundle directly to an Identity object.

Affected Code

@classmethod
def from_dict(cls, data: Dict) -> "PublicKeyBundle":
    """
    SECURITY: Does NOT verify signature. Call verify_signature() after creation.
    """
    # Creates bundle without verification

Impact

If from_dict() followed by to_identity() is called without an intervening verify_signature() call, encryption could be performed against an attacker's public key, leaking secrets. While key_resolver.py (lines 146-147) does verify before use, the unguarded API path remains directly callable.

Recommended Fix

  • Add a verified flag to PublicKeyBundle that must be set before to_identity() can be called
  • Or have to_identity() automatically call verify_signature() and raise on failure
  • Or make from_dict() require verification as part of construction

Fix

Fixed in commit f4a1ba6 on branch releases/1.4.x — from_dict() now verifies self_signature by default (verify=True parameter); raises ValueError on verification failure.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "openssl-encrypt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T21:11:14Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `PublicKeyBundle.from_dict()` method in `openssl_encrypt/modules/key_bundle.py` at **lines 329-361** creates bundles from untrusted data without verifying the signature. The docstring warns to call `verify_signature()` after creation, but the `to_identity()` method (line 363-391) can convert an unverified bundle directly to an `Identity` object.\n\n### Affected Code\n\n```python\n@classmethod\ndef from_dict(cls, data: Dict) -\u003e \"PublicKeyBundle\":\n    \"\"\"\n    SECURITY: Does NOT verify signature. Call verify_signature() after creation.\n    \"\"\"\n    # Creates bundle without verification\n```\n\n### Impact\n\nIf `from_dict()` followed by `to_identity()` is called without an intervening `verify_signature()` call, encryption could be performed against an attacker\u0027s public key, leaking secrets. While `key_resolver.py` (lines 146-147) does verify before use, the unguarded API path remains directly callable.\n\n### Recommended Fix\n\n- Add a `verified` flag to `PublicKeyBundle` that must be set before `to_identity()` can be called\n- Or have `to_identity()` automatically call `verify_signature()` and raise on failure\n- Or make `from_dict()` require verification as part of construction\n\n### Fix\n\nFixed in commit `f4a1ba6` on branch `releases/1.4.x` \u2014 from_dict() now verifies self_signature by default (verify=True parameter); raises ValueError on verification failure.",
  "id": "GHSA-8h88-gxp3-j7pg",
  "modified": "2026-04-01T21:11:14Z",
  "published": "2026-04-01T21:11:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-8h88-gxp3-j7pg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jahlives/openssl_encrypt/commit/f4a1ba660063cd9e17883829e5272a248525a16b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jahlives/openssl_encrypt"
    }
  ],
  "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:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "openssl-encrypt\u0027s unverified key bundle from_dict() + to_identity() path allows encryption to attacker keys"
}

GHSA-8HXX-PMWX-5VVQ

Vulnerability from github – Published: 2022-05-17 00:15 – Updated: 2022-05-17 00:15
VLAI
Details

A vulnerability in Cisco NX-OS System Software could allow an authenticated, local attacker to bypass signature verification when loading a software patch. The vulnerability is due to insufficient NX-OS signature verification for software patches. An authenticated, local attacker could exploit this vulnerability to bypass signature verification and load a crafted, unsigned software patch on a targeted device. The attacker would need valid administrator credentials to perform this exploit. This vulnerability affects the following products running Cisco NX-OS System Software: Multilayer Director Switches, Nexus 7000 Series Switches, Nexus 7700 Series Switches, Unified Computing System Manager. Cisco Bug IDs: CSCvf16494, CSCvf23655.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-12331"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-30T09:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Cisco NX-OS System Software could allow an authenticated, local attacker to bypass signature verification when loading a software patch. The vulnerability is due to insufficient NX-OS signature verification for software patches. An authenticated, local attacker could exploit this vulnerability to bypass signature verification and load a crafted, unsigned software patch on a targeted device. The attacker would need valid administrator credentials to perform this exploit. This vulnerability affects the following products running Cisco NX-OS System Software: Multilayer Director Switches, Nexus 7000 Series Switches, Nexus 7700 Series Switches, Unified Computing System Manager. Cisco Bug IDs: CSCvf16494, CSCvf23655.",
  "id": "GHSA-8hxx-pmwx-5vvq",
  "modified": "2022-05-17T00:15:06Z",
  "published": "2022-05-17T00:15:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12331"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171129-nxos"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102159"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1039930"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8J44-5653-Q846

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

A TOTP two-factor authentication bypass vulnerability in Koollab LMS allowed an attacker to supply a client-controlled seed to generate a matching one-time password and bypass the second authentication factor, potentially enabling unauthorised access to administrator accounts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-63237"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-29T07:16:43Z",
    "severity": "MODERATE"
  },
  "details": "A TOTP two-factor authentication bypass vulnerability in\nKoollab LMS allowed an\nattacker to supply a client-controlled seed to generate a matching one-time\npassword and bypass the second authentication factor, potentially enabling\nunauthorised access to administrator accounts.",
  "id": "GHSA-8j44-5653-q846",
  "modified": "2026-07-29T09:31:27Z",
  "published": "2026-07-29T09:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63237"
    },
    {
      "type": "WEB",
      "url": "https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-094"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8JJF-W7J6-323C

Vulnerability from github – Published: 2018-01-04 21:03 – Updated: 2023-08-18 21:00
VLAI
Summary
Samlify vulnerable to Authentication Bypass by allowing tokens to be reused with different usernames
Details

Versions of samlify prior to 2.4.0-rc5 are vulnerable to Authentication Bypass. The package fails to prevent XML Signature Wrapping, allowing tokens to be reused with different usernames. A remote attacker can modify SAML content for a SAML service provider without invalidating the cryptographic signature, which may allow attackers to bypass primary authentication for the affected SAML service provider.

Recommendation

Upgrade to version 2.4.0-rc5 or later

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "samlify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.0-rc5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-1000452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-91"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:25:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Versions of `samlify` prior to 2.4.0-rc5 are vulnerable to Authentication Bypass. The package fails to prevent XML Signature Wrapping, allowing tokens to be reused with different usernames. A remote attacker can modify SAML content for a SAML service provider without invalidating the cryptographic signature, which may allow attackers to bypass primary authentication for the affected SAML service provider.\n\n\n## Recommendation\n\nUpgrade to version 2.4.0-rc5 or later",
  "id": "GHSA-8jjf-w7j6-323c",
  "modified": "2023-08-18T21:00:53Z",
  "published": "2018-01-04T21:03:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000452"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tngan/samlify/commit/d382bbc7c6b8ea889839ae1f178730c25b09eb42"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/356284"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tngan/samlify"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tngan/samlify/compare/v2.4.0-rc4...v2.4.0-rc5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tngan/samlify/releases/tag/v2.4.0-rc5"
    },
    {
      "type": "WEB",
      "url": "https://www.whitehats.nl/blog/xml-signature-wrapping-samlify"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Samlify vulnerable to Authentication Bypass by allowing tokens to be reused with different usernames"
}

GHSA-8JQH-95G6-7JPJ

Vulnerability from github – Published: 2026-08-28 16:01 – Updated: 2026-08-28 16:01
VLAI
Summary
Phalcon: Non-constant-time HMAC verification in `Encryption\Crypt::decrypt` (timing side-channel)
Details

Summary

Phalcon\Encryption\Crypt provides authenticated encryption: when useSigning is enabled (the default), encrypt() appends an HMAC tag and decrypt() verifies it before returning the plaintext. The verification compares the attacker-supplied tag against the freshly computed HMAC using PHP/Zephir identity comparison (!==), which the Zephir compiler lowers to !ZEPHIR_IS_IDENTICAL(...) — a byte-wise memcmp that returns early on the first differing byte. The comparison time therefore depends on how many leading bytes of the supplied tag are correct, a classic MAC-verification timing side-channel. Every other secret/MAC comparison in the framework uses the constant-time hash_equals() (zephir_hash_equals) — the CSRF token check (Security::checkToken) and the JWT signature check (Signer\Hmac::verify); Crypt::decrypt is the lone deviation.

Details

Vulnerable code

phalcon/Encryption/Crypt.zep:246 (Zephir source):

if true === this->useSigning {
    // Checks on the decrypted message digest using the HMAC method.
    if digest !== hash_hmac(hashAlgorithm, padded, decryptKey, true) {
        throw new Mismatch("Hash does not match.");
    }
}

Generated C --> ext/phalcon/encryption/crypt.zep.c:364-367:

ZEPHIR_CALL_FUNCTION(&_8$$7, "hash_hmac", NULL, 245, &hashAlgorithm, &padded, &decryptKey, &__$true);
...
if (!ZEPHIR_IS_IDENTICAL(&digest, &_8$$7)) {                 // <-- non-constant-time
    ZEPHIR_THROW_EXCEPTION_DEBUG_STR(..., "Hash does not match.", "phalcon/Encryption/Crypt.zep", 247);

ZEPHIR_IS_IDENTICAL --> zephir_is_identical() (ext/kernel/operators.c:472) --> Zend is_identical_function --> for equal-length strings a memcmp that exits on the first mismatching byte (data-dependent timing).

Impact

The HMAC is the integrity/authentication tag of Phalcon's authenticated-encryption scheme. A successful timing attack (Keyczar/CVE-2009-0654-style: fix the IV+ciphertext so the target tag is constant, then recover it byte-by-byte from response timing) yields a tag the attacker can attach to a chosen IV+ciphertext so that decrypt() accepts it as authentic, defeating the integrity guarantee. Combined with CFB malleability (flipping a ciphertext byte flips the corresponding plaintext byte), an attacker who recovers the forging capability can tamper with the decrypted contents the application trusts (e.g. encrypted cookies carrying authorization/identity state). There is no confidentiality break by itself.

Suggested fix

Replace the identity comparison with the constant-time helper already used elsewhere in the framework. In phalcon/Encryption/Crypt.zep:246:

// before
if digest !== hash_hmac(hashAlgorithm, padded, decryptKey, true) {
    throw new Mismatch("Hash does not match.");
}
// after
if true !== hash_equals(hash_hmac(hashAlgorithm, padded, decryptKey, true), digest) {
    throw new Mismatch("Hash does not match.");
}

hash_equals() returns false for unequal-length inputs, so it also covers the truncated-tag case. Optional further hardening: verify the MAC before unpadding (functionally moot here because cryptUnpadText never throws) and consider migrating the default toward an AEAD mode such as aes-256-gcm.

Addressed Issue:

  • https://github.com/phalcon/cphalcon/issues/17090

Patched Stream:

  • https://github.com/phalcon/cphalcon/issues/17090
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.14.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phalcon/cphalcon"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-208",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T16:01:05Z",
    "nvd_published_at": "2026-07-10T22:16:42Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`Phalcon\\Encryption\\Crypt` provides authenticated encryption: when `useSigning` is enabled (the default), `encrypt()` appends an HMAC tag and `decrypt()` verifies it before returning the plaintext. The verification compares the attacker-supplied tag against the freshly computed HMAC using PHP/Zephir identity comparison (`!==`), which the Zephir compiler lowers to `!ZEPHIR_IS_IDENTICAL(...)` \u2014 a byte-wise `memcmp` that returns early on the first differing byte. The comparison time therefore depends on how many leading bytes of the supplied tag are correct, a classic MAC-verification timing side-channel. Every other secret/MAC comparison in the framework uses the constant-time `hash_equals()` (`zephir_hash_equals`) \u2014 the CSRF token check (`Security::checkToken`) and the JWT signature check (`Signer\\Hmac::verify`); `Crypt::decrypt` is the lone deviation.\n\n## Details\n\n### Vulnerable code\n\n`phalcon/Encryption/Crypt.zep:246` (Zephir source):\n\n```zephir\nif true === this-\u003euseSigning {\n    // Checks on the decrypted message digest using the HMAC method.\n    if digest !== hash_hmac(hashAlgorithm, padded, decryptKey, true) {\n        throw new Mismatch(\"Hash does not match.\");\n    }\n}\n```\n\nGenerated C --\u003e `ext/phalcon/encryption/crypt.zep.c:364-367`:\n\n```c\nZEPHIR_CALL_FUNCTION(\u0026_8$$7, \"hash_hmac\", NULL, 245, \u0026hashAlgorithm, \u0026padded, \u0026decryptKey, \u0026__$true);\n...\nif (!ZEPHIR_IS_IDENTICAL(\u0026digest, \u0026_8$$7)) {                 // \u003c-- non-constant-time\n    ZEPHIR_THROW_EXCEPTION_DEBUG_STR(..., \"Hash does not match.\", \"phalcon/Encryption/Crypt.zep\", 247);\n```\n\n`ZEPHIR_IS_IDENTICAL` --\u003e `zephir_is_identical()` (`ext/kernel/operators.c:472`) --\u003e Zend `is_identical_function` --\u003e for equal-length strings a `memcmp` that exits on the first mismatching byte (data-dependent timing).\n\n\n\n### Impact\n\nThe HMAC is the integrity/authentication tag of Phalcon\u0027s authenticated-encryption scheme. A successful timing attack (Keyczar/CVE-2009-0654-style: fix the IV+ciphertext so the target tag is constant, then recover it byte-by-byte from response timing) yields a tag the attacker can attach to a chosen IV+ciphertext so that `decrypt()` accepts it as authentic, defeating the integrity guarantee. Combined with CFB malleability (flipping a ciphertext byte flips the corresponding plaintext byte), an attacker who recovers the forging capability can tamper with the decrypted contents the application trusts (e.g. encrypted cookies carrying authorization/identity state). There is no confidentiality break by itself.\n\n## Suggested fix\n\nReplace the identity comparison with the constant-time helper already used elsewhere in the framework. In `phalcon/Encryption/Crypt.zep:246`:\n\n```zephir\n// before\nif digest !== hash_hmac(hashAlgorithm, padded, decryptKey, true) {\n    throw new Mismatch(\"Hash does not match.\");\n}\n// after\nif true !== hash_equals(hash_hmac(hashAlgorithm, padded, decryptKey, true), digest) {\n    throw new Mismatch(\"Hash does not match.\");\n}\n```\n\n`hash_equals()` returns false for unequal-length inputs, so it also covers the truncated-tag case. Optional further hardening: verify the MAC before unpadding (functionally moot here because `cryptUnpadText` never throws) and consider migrating the default toward an AEAD mode such as `aes-256-gcm`.\n\nAddressed Issue: \n\n- https://github.com/phalcon/cphalcon/issues/17090\n\nPatched Stream: \n\n- https://github.com/phalcon/cphalcon/issues/17090",
  "id": "GHSA-8jqh-95g6-7jpj",
  "modified": "2026-08-28T16:01:05Z",
  "published": "2026-08-28T16:01:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/phalcon/cphalcon/security/advisories/GHSA-8jqh-95g6-7jpj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54736"
    },
    {
      "type": "WEB",
      "url": "https://github.com/phalcon/cphalcon/issues/17090"
    },
    {
      "type": "WEB",
      "url": "https://github.com/phalcon/cphalcon/pull/17091"
    },
    {
      "type": "WEB",
      "url": "https://github.com/phalcon/cphalcon/commit/ad53ab1b2e7ec59b3af92b0b37b8aaa099011137"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/phalcon/cphalcon"
    },
    {
      "type": "WEB",
      "url": "https://github.com/phalcon/cphalcon/releases/tag/v5.14.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Phalcon: Non-constant-time HMAC verification in `Encryption\\Crypt::decrypt` (timing side-channel)"
}

GHSA-8M6F-Q6PM-9PMM

Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2024-04-04 00:41
VLAI
Details

The signature verification routine in the Airmail GPG-PGP Plugin, versions 1.0 (9) and earlier, does not verify the status of the signature at all, which allows remote attackers to spoof arbitrary email signatures by crafting a signed email with an invalid signature. Also, it does not verify the validity of the signing key, which allows remote attackers to spoof arbitrary email signatures by crafting a key with a fake user ID (email address) and injecting it into the user's keyring.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-8338"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-16T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The signature verification routine in the Airmail GPG-PGP Plugin, versions 1.0 (9) and earlier, does not verify the status of the signature at all, which allows remote attackers to spoof arbitrary email signatures by crafting a signed email with an invalid signature. Also, it does not verify the validity of the signing key, which allows remote attackers to spoof arbitrary email signatures by crafting a key with a fake user ID (email address) and injecting it into the user\u0027s keyring.",
  "id": "GHSA-8m6f-q6pm-9pmm",
  "modified": "2024-04-04T00:41:29Z",
  "published": "2022-05-24T16:45:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8338"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Airmail/AirmailPlugIn-Framework/commits/master"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired/blob/master/paper/johnny-fired.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2019/04/30/4"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/152703/Johnny-You-Are-Fired.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2019/Apr/38"
    }
  ],
  "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-8M7C-8M39-RV4X

Vulnerability from github – Published: 2026-05-05 18:46 – Updated: 2026-05-05 18:46
VLAI
Summary
awslabs/tough Delegated Roles have a Signature Threshold Bypass
Details

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

  • CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tough"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tuftool"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-6966"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T18:46:09Z",
    "nvd_published_at": "2026-04-24T20:16:28Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nImproper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.\n\n### Impact\nThe tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.\n\n### Patches\nThis issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. \n\n### Workarounds\nNo workarounds to this issue are known.\n\n### References\n* CVE-2026-6966\n\nIf there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.\n\n### Acknowledgement\n\nAmazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process",
  "id": "GHSA-8m7c-8m39-rv4x",
  "modified": "2026-05-05T18:46:09Z",
  "published": "2026-05-05T18:46:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/awslabs/tough/security/advisories/GHSA-8m7c-8m39-rv4x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6966"
    },
    {
      "type": "WEB",
      "url": "https://aws.amazon.com/security/security-bulletins/2026-019-aws"
    },
    {
      "type": "WEB",
      "url": "https://crates.io/crates/tough/0.22.0"
    },
    {
      "type": "WEB",
      "url": "https://crates.io/crates/tuftool/0.15.0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/awslabs/tough"
    },
    {
      "type": "WEB",
      "url": "https://github.com/awslabs/tough/releases/tag/tough-v0.22.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/awslabs/tough/releases/tag/tuftool-v0.15.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "awslabs/tough Delegated Roles have a Signature Threshold Bypass"
}

GHSA-8M8C-G2FV-F6HJ

Vulnerability from github – Published: 2025-10-14 18:30 – Updated: 2025-10-14 18:30
VLAI
Details

An Improper Verification of Cryptographic Signature vulnerability [CWE-347] in FortiClient MacOS installer version 7.4.2 and below, version 7.2.9 and below, 7.0 all versions may allow a local user to escalate their privileges via FortiClient related executables.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-46774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-14T16:15:38Z",
    "severity": "HIGH"
  },
  "details": "An Improper Verification of Cryptographic Signature vulnerability [CWE-347] in FortiClient MacOS installer version 7.4.2 and below, version 7.2.9 and below, 7.0 all versions may allow a local user to escalate their privileges via FortiClient related executables.",
  "id": "GHSA-8m8c-g2fv-f6hj",
  "modified": "2025-10-14T18:30:27Z",
  "published": "2025-10-14T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46774"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-25-126"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8MV4-X3GG-MM93

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

GIGABYTE BRIX UEFI firmware does not cryptographically validate images prior to updating the system firmware. Additionally, the firmware updates are served over HTTP. An attacker can make arbitrary modifications to firmware images without being detected.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-3198"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-09T19:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "GIGABYTE BRIX UEFI firmware does not cryptographically validate images prior to updating the system firmware. Additionally, the firmware updates are served over HTTP. An attacker can make arbitrary modifications to firmware images without being detected.",
  "id": "GHSA-8mv4-x3gg-mm93",
  "modified": "2022-05-13T01:36:43Z",
  "published": "2022-05-13T01:36:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3198"
    },
    {
      "type": "WEB",
      "url": "https://www.cylance.com/en_us/blog/gigabyte-brix-systems-vulnerabilities.html"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/507496"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/97294"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8MXX-G9VW-R875

Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2024-04-04 00:40
VLAI
Details

The signature verification routine in install.sh in yarnpkg/website through 2018-06-05 only verifies that the yarn release is signed by any (arbitrary) key in the local keyring of the user, and does not pin the signature to the yarn release key, which allows remote attackers to sign tampered yarn release packages with their own key.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-12556"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-16T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The signature verification routine in install.sh in yarnpkg/website through 2018-06-05 only verifies that the yarn release is signed by any (arbitrary) key in the local keyring of the user, and does not pin the signature to the yarn release key, which allows remote attackers to sign tampered yarn release packages with their own key.",
  "id": "GHSA-8mxx-g9vw-r875",
  "modified": "2024-04-04T00:40:14Z",
  "published": "2022-05-24T16:45:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12556"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired/blob/master/paper/johnny-fired.pdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yarnpkg/website/commits/master"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2019/04/30/4"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/152703/Johnny-You-Are-Fired.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2019/Apr/38"
    }
  ],
  "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"
    }
  ]
}

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.