CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1124 vulnerabilities reference this CWE, most recent first.
GHSA-CVP8-5R8G-FHVQ
Vulnerability from github – Published: 2024-09-11 21:08 – Updated: 2024-09-19 18:25ruby-saml, the dependent SAML gem of omniauth-saml has a signature wrapping vulnerability in <= v1.12.0 and v1.13.0 to v1.16.0 , see https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-jw9c-mfg7-9rx2 As a result, omniauth-saml created a new release by upgrading ruby-saml to the patched versions v1.17.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "omniauth-saml"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "omniauth-saml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "omniauth-saml"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-11T21:08:26Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "ruby-saml, the dependent SAML gem of omniauth-saml has a signature wrapping vulnerability in \u003c= v1.12.0 and v1.13.0 to v1.16.0 , see https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-jw9c-mfg7-9rx2 \nAs a result, omniauth-saml created a [new release](https://github.com/omniauth/omniauth-saml/releases) by upgrading ruby-saml to the patched versions v1.17. \n",
"id": "GHSA-cvp8-5r8g-fhvq",
"modified": "2024-09-19T18:25:42Z",
"published": "2024-09-11T21:08:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-jw9c-mfg7-9rx2"
},
{
"type": "WEB",
"url": "https://github.com/omniauth/omniauth-saml/security/advisories/GHSA-cvp8-5r8g-fhvq"
},
{
"type": "WEB",
"url": "https://github.com/omniauth/omniauth-saml/commit/4274e9d57e65f2dcaae4aa3b2accf831494f2ddd"
},
{
"type": "WEB",
"url": "https://github.com/omniauth/omniauth-saml/commit/6c681fd082ab3daf271821897a40ab3417382e29"
},
{
"type": "PACKAGE",
"url": "https://github.com/omniauth/omniauth-saml"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/omniauth-saml/GHSA-cvp8-5r8g-fhvq.yml"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "omniauth-saml vulnerable to Improper Verification of Cryptographic Signature"
}
GHSA-CX5H-J8W3-WHPR
Vulnerability from github – Published: 2025-12-12 21:31 – Updated: 2025-12-17 21:30A downgrade issue affecting Intel-based Mac computers was addressed with additional code-signing restrictions. This issue is fixed in macOS Sequoia 15.7.3. An app may be able to access sensitive user data.
{
"affected": [],
"aliases": [
"CVE-2025-43521"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-12T21:15:56Z",
"severity": "MODERATE"
},
"details": "A downgrade issue affecting Intel-based Mac computers was addressed with additional code-signing restrictions. This issue is fixed in macOS Sequoia 15.7.3. An app may be able to access sensitive user data.",
"id": "GHSA-cx5h-j8w3-whpr",
"modified": "2025-12-17T21:30:43Z",
"published": "2025-12-12T21:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43521"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125886"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125887"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F3Q4-GGFP-JV34
Vulnerability from github – Published: 2024-08-30 18:51 – Updated: 2024-08-30 18:51Adyen has utility methods for validating notification HMAC signatures. The is_valid_hmac and is_valid_hmac_notification methods are vulnerable to a timing attack, you should compare the hash of the HMACs instead.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Adyen"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "7.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2024-08-30T18:51:58Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Adyen has utility methods for validating notification HMAC signatures. The `is_valid_hmac` and `is_valid_hmac_notification` methods are vulnerable to a timing attack, you should compare the hash of the HMACs instead.",
"id": "GHSA-f3q4-ggfp-jv34",
"modified": "2024-08-30T18:51:58Z",
"published": "2024-08-30T18:51:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Adyen/adyen-python-api-library/issues/168"
},
{
"type": "WEB",
"url": "https://github.com/Adyen/adyen-python-api-library/pull/170"
},
{
"type": "WEB",
"url": "https://github.com/Adyen/adyen-python-api-library/commit/3292133dbc00ffc4cccfb92de672a76eaa587ca5"
},
{
"type": "PACKAGE",
"url": "https://github.com/Adyen/adyen-python-api-library"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/adyen/PYSEC-2023-1.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Adyen APIs Library for Python timing attack vulnerability"
}
GHSA-F3W5-V9XX-RP8P
Vulnerability from github – Published: 2021-12-20 18:17 – Updated: 2021-05-20 20:10The root cause of this security vulnerability is in the Tendermint specification, and this advisory is a duplicate of https://github.com/tendermint/spec/security/advisories/GHSA-jqfc-687g-59pw.
Impact
Tendermint light clients running versions 0.34.0 to 0.34.8 are unable to detect and punish a new kind of attack. We’re calling this a “forward lunatic attack,” or FLA. The severity of this vulnerability is moderate.
Note that an FLA cannot be successfully executed unless there are already ⅓+ Byzantine validators, and therefore outside of Tendermint’s security model; however, it is important to be able to detect and punish these kinds of attacks in order to incentivize correct behavior.
In an FLA, an attacking validator (with ⅓+ voting power) signs commit messages for arbitrary application state associated with a block height that hasn’t been seen yet, hence the name “forward lunatic attacks.” A malicious validator effectively executes a lunatic attack, but signs messages for a target block that is higher than the current block. This can be dangerous: Typically, misbehavior evidence is only created when there are conflicting blocks at the same height, but by targeting a block height that is far “ahead” of the current chain height, it’s possible that the chain will not produce a (conflicting) block at the target height in time to create evidence.
Prior to Tendermint v0.34.9, the light client could accept a bad header from its primary witness, and would not be able to form evidence of this deception, even if all the secondary witnesses were correct. Because the light client is responsible for verifying cross-chain state for IBC, a successful FLA could result in loss of funds. However, it is important to note that FLAs are only possible outside the Tendermint security model.
All FLAs, attempted and successful, leave traces of provable misbehavior on-chain. A faulty header contains signatures from the faulty validator, and even in unpatched versions of Tendermint Core, networks could use social consensus (off-chain action) to recover the network. The patches introduced in Tendermint Core v0.34.9 handle all evidence automatically and on-chain.
Note that this fix also allows for successful automatic reporting of FLAs, even after a chain halt. By adding a time to FetchBlock, light clients effectively have a backup way to determine if a halted chain should have continued, and it will be able to submit evidence as soon as the chain resumes.
Patches
This problem has been patched in Tendermint Core v0.34.9.
Workarounds
There are no workarounds. All users are recommended to upgrade to Tendermint Core v0.34.9 at their earliest possible convenience.
Credits
Thank you to @MaximilianDiez for originally surfacing this issue, and to @cmwaters, @josef-widder, and @milosevic for creating fixes at both the implementation and specification level.
For more information
If you have any questions or comments about this advisory: * Open an issue in tendermint/tendermint * Email us at security@tendermint.com
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tendermint/tendermint"
},
"ranges": [
{
"events": [
{
"introduced": "0.34.0"
},
{
"fixed": "0.34.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-20T20:10:47Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "_The root cause of this security vulnerability is in the Tendermint specification, and this advisory is a duplicate of https://github.com/tendermint/spec/security/advisories/GHSA-jqfc-687g-59pw._\n\n\n### Impact\nTendermint light clients running versions 0.34.0 to 0.34.8 are unable to detect and punish a new kind of attack. We\u2019re calling this a \u201cforward lunatic attack,\u201d or FLA. The severity of this vulnerability is _moderate_. \n\nNote that an FLA cannot be successfully executed unless there are already \u2153+ Byzantine validators, and therefore outside of Tendermint\u2019s security model; however, it is important to be able to detect and punish these kinds of attacks in order to incentivize correct behavior.\n\nIn an FLA, an attacking validator (with \u2153+ voting power) signs commit messages for arbitrary application state associated with a block height that hasn\u2019t been seen yet, hence the name \u201cforward lunatic attacks.\u201d A malicious validator effectively executes a [lunatic attack](https://docs.tendermint.com/master/spec/light-client/accountability/#the-misbehavior-of-faulty-validators), but signs messages for a target block that is higher than the current block. This can be dangerous: Typically, misbehavior evidence is only created when there are conflicting blocks at the same height, but by targeting a block height that is far \u201cahead\u201d of the current chain height, it\u2019s possible that the chain will not produce a (conflicting) block at the target height in time to create evidence. \n\nPrior to Tendermint v0.34.9, the light client could accept a bad header from its primary witness, and would not be able to form evidence of this deception, even if all the secondary witnesses were correct. Because the light client is responsible for verifying cross-chain state for IBC, a successful FLA could result in loss of funds. However, it is important to note that FLAs are only possible outside the Tendermint security model. \n\nAll FLAs, attempted and successful, leave traces of provable misbehavior on-chain. A faulty header contains signatures from the faulty validator, and even in unpatched versions of Tendermint Core, networks could use social consensus (off-chain action) to recover the network. The patches introduced in Tendermint Core v0.34.9 handle all evidence automatically and on-chain. \n\nNote that this fix also allows for successful automatic reporting of FLAs, even after a chain halt. By adding a time to FetchBlock, light clients effectively have a backup way to determine if a halted chain should have continued, and it will be able to submit evidence as soon as the chain resumes. \n\n### Patches\nThis problem has been patched in Tendermint Core v0.34.9. \n\n### Workarounds\nThere are no workarounds. All users are recommended to upgrade to Tendermint Core v0.34.9 at their earliest possible convenience. \n\n### Credits\n\nThank you to @MaximilianDiez for originally surfacing this issue, and to @cmwaters, @josef-widder, and @milosevic for creating fixes at both the implementation and specification level.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [tendermint/tendermint](https://github.com/tendermint/tendermint)\n* Email us at [security@tendermint.com](mailto:security@tendermint.com)",
"id": "GHSA-f3w5-v9xx-rp8p",
"modified": "2021-05-20T20:10:47Z",
"published": "2021-12-20T18:17:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tendermint/tendermint/security/advisories/GHSA-f3w5-v9xx-rp8p"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Signature verification failure in Tendermint"
}
GHSA-F4G9-H89H-JGV9
Vulnerability from github – Published: 2021-01-21 14:12 – Updated: 2024-10-14 15:50Impact
All users of pysaml2 that use the default CryptoBackendXmlSec1 backend and need to verify signed SAML documents are impacted. pysaml2 <= 6.4.1 does not validate the SAML document against an XML schema. This allows invalid XML documents to trick the verification process, by presenting elements with a valid signature inside elements whose content has been malformed. The verification is offloaded to xmlsec1 and xmlsec1 will not validate every signature in the given document, but only the first it finds in the given scope.
Patches
Users should upgrade to pysaml2 v6.5.0.
Workarounds
No workaround provided at this point.
References
No references provided at this point.
Credits
- Victor Schönfelder Garcia (isits AG International School of IT Security)
- Juraj Somorovsky (Paderborn University)
- Vladislav Mladenov (Ruhr University Bochum)
For more information
If you have any questions or comments about this advisory: * Open an issue in pysaml2 * Email us at the incident-response address
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pysaml2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21238"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-01-21T14:11:38Z",
"nvd_published_at": "2021-01-21T15:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nAll users of pysaml2 that use the default `CryptoBackendXmlSec1` backend and need to verify signed SAML documents are impacted. `pysaml2 \u003c= 6.4.1` does not validate the SAML document against an XML schema. This allows invalid XML documents to trick the verification process, by presenting elements with a valid signature inside elements whose content has been malformed. The verification is offloaded to `xmlsec1` and `xmlsec1` will not validate every signature in the given document, but only the first it finds in the given scope.\n\n### Patches\n\nUsers should upgrade to pysaml2 `v6.5.0`.\n\n### Workarounds\n\nNo workaround provided at this point.\n\n### References\n\nNo references provided at this point.\n\n### Credits\n\n- Victor Scho\u0308nfelder Garcia (isits AG International School of IT Security)\n- Juraj Somorovsky (Paderborn University)\n- Vladislav Mladenov (Ruhr University Bochum)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [pysaml2](https://github.com/IdentityPython/pysaml2)\n* Email us at [the incident-response address](mailto:incident-response@idpy.org)",
"id": "GHSA-f4g9-h89h-jgv9",
"modified": "2024-10-14T15:50:30Z",
"published": "2021-01-21T14:12:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/IdentityPython/pysaml2/security/advisories/GHSA-f4g9-h89h-jgv9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21238"
},
{
"type": "WEB",
"url": "https://github.com/IdentityPython/pysaml2/commit/1d8fd268f5bf887480a403a7a5ef8f048157cc14"
},
{
"type": "PACKAGE",
"url": "https://github.com/IdentityPython/pysaml2"
},
{
"type": "WEB",
"url": "https://github.com/IdentityPython/pysaml2/releases/tag/v6.5.0"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pysaml2/PYSEC-2021-48.yaml"
},
{
"type": "WEB",
"url": "https://pypi.org/project/pysaml2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "SAML XML Signature wrapping in PySAML2"
}
GHSA-F4X5-257X-2739
Vulnerability from github – Published: 2023-10-19 12:30 – Updated: 2024-04-04 08:47The Texas Instruments OMAP L138 (secure variants) trusted execution environment (TEE) performs an RSA check implemented in mask ROM when loading a module through the SK_LOAD routine. However, only the module header authenticity is validated. An adversary can re-use any correctly signed header and append a forged payload, to be encrypted using the CEK (obtainable through CVE-2022-25332) in order to obtain arbitrary code execution in secure context. This constitutes a full break of the TEE security architecture.
{
"affected": [],
"aliases": [
"CVE-2022-25333"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-19T10:15:09Z",
"severity": "HIGH"
},
"details": "The Texas Instruments OMAP L138 (secure variants) trusted execution environment (TEE) performs an RSA check implemented in mask ROM when loading a module through the SK_LOAD routine. However, only the module header authenticity is validated. An adversary can re-use any correctly signed header and append a forged payload, to be encrypted using the CEK (obtainable through CVE-2022-25332) in order to obtain arbitrary code execution in secure context. This constitutes a full break of the TEE security architecture.",
"id": "GHSA-f4x5-257x-2739",
"modified": "2024-04-04T08:47:24Z",
"published": "2023-10-19T12:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25333"
},
{
"type": "WEB",
"url": "https://tetraburst.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F5P4-P5Q5-JV3H
Vulnerability from github – Published: 2025-10-28 17:49 – Updated: 2025-11-05 22:11Summary
A malicious host may provide a crafted LUKS2 volume to a Contrast pod VM that uses the secure persistent volume feature. The guest will open the volume and write secret data using a volume key known to the attacker.
LUKS2 volume metadata is (a) not authenticated and (b) supports null key-encryption algorithms, allowing an attacker to create a volume such that the volume:
- Opens (cryptsetup open) without error using any passphrase or token
- Records all writes in plaintext (or ciphertext with an attacker-known key)
Details
Contrast uses cryptsetup to setup secure persistent volumes, using the secret seed as key for the cryptsetup encryption. To do so the Contrast Initializer will invoke the cryptsetup CLI. If the device provided by Kubernetes is a identified as cryptsetup device, the Initializer assumes a pod restart happened and the device was previously encrypted with the secret seed. The Initializer will try to open the device, and assume it is protected if the operation succeeds. However, due to the unsafe handling of null keyslot algorithms in the cryptsetup 2.8.1, it is possible that the opened volume is not encrypted at all.
Cryptsetup prior to version 2.8.1 does not report an error when processing LUKS2-formatted disks that use the cipher_null-ecb algorithm in the keyslot encryption field.
Impact
Using a maliciously crafted cryptsetup device, an attacker can read confidential data that was written to the persistent volume that should have been protected by encryption.
Notice that Contrast's persistent volumes weren't integrity protected, so the integrity impact of this attack isn't considered.
Patches
A partial fix landed in cryptsetup version 2.8.1, disabling null ciphers in keyslots when the user passphrase is nonempty. Contrast shipped this cryptsetup version shortly after it has been released upstream, in Contrast version v1.12.1.
However, LUKS header parsing and interpretation remains a large attack surface. Attackers may still be able to modify LUKS headers in other ways, such as triggering automatic reencryption or downgrading to weak ciphers. As a long term hardening solution, LUKS disks is encrypted in detached header mode. The detached header resides in a tmpfs file inside guest RAM, and is checked before it is used to open the device. This has been implemented in #1731 and released as part of Contrast v1.13.0.
In addition, we added integrity protection for secure persistent storage as a new feature in #1734, which was also shipped as part of v1.13.0.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.12.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/edgelesssys/contrast"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347",
"CWE-552"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-28T17:49:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nA malicious host may provide a crafted LUKS2 volume to a Contrast pod VM that uses the [secure persistent volume](https://docs.edgeless.systems/contrast/howto/encrypted-storage) feature. The guest will open the volume and write secret data using a volume key known to the attacker. \n\nLUKS2 volume metadata is (a) not authenticated and (b) supports null key-encryption algorithms, allowing an attacker to create a volume such that the volume:\n\n- Opens (cryptsetup open) without error using any passphrase or token\n- Records all writes in plaintext (or ciphertext with an attacker-known key)\n\n### Details\n\nContrast uses cryptsetup to setup secure persistent volumes, using the secret seed as key for the cryptsetup encryption. To do so the Contrast Initializer will invoke the `cryptsetup` CLI. If the device provided by Kubernetes is a identified as cryptsetup device, the Initializer assumes a pod restart happened and the device was previously encrypted with the secret seed. The Initializer will try to open the device, and assume it is protected if the operation succeeds. However, due to the unsafe handling of null keyslot algorithms in the cryptsetup 2.8.1, it is possible that the opened volume is not encrypted at all.\n\nCryptsetup prior to version 2.8.1 does not report an error when processing LUKS2-formatted disks that use the `cipher_null-ecb` algorithm in the keyslot `encryption` field.\n\n### Impact\n\nUsing a maliciously crafted cryptsetup device, an attacker can read confidential data that was written to the persistent volume that should have been protected by encryption.\n\nNotice that Contrast\u0027s persistent volumes weren\u0027t integrity protected, so the integrity impact of this attack isn\u0027t considered.\n\n### Patches\n\nA partial fix landed in [cryptsetup version 2.8.1](https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/v2.8.1-ReleaseNotes#L14), disabling null ciphers in keyslots when the user passphrase is nonempty. Contrast shipped this cryptsetup version shortly after it has been released upstream, in [Contrast version v1.12.1](https://github.com/edgelesssys/contrast/releases/tag/v1.12.1).\n\nHowever, LUKS header parsing and interpretation remains a large attack surface. Attackers may still be able to modify LUKS headers in other ways, such as triggering automatic reencryption or downgrading to weak ciphers. As a long term hardening solution, LUKS disks is encrypted in detached header mode. The detached header resides in a tmpfs file inside guest RAM, and is checked before it is used to open the device. This has been implemented in [#1731](https://github.com/edgelesssys/contrast/pull/1731) and released as part of [Contrast v1.13.0](https://github.com/edgelesssys/contrast/releases/tag/v1.13.0).\n\nIn addition, we added integrity protection for secure persistent storage as a new feature in [#1734](https://github.com/edgelesssys/contrast/pull/1734), which was also shipped as part of [v1.13.0](https://github.com/edgelesssys/contrast/releases/tag/v1.13.0).",
"id": "GHSA-f5p4-p5q5-jv3h",
"modified": "2025-11-05T22:11:22Z",
"published": "2025-10-28T17:49:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/edgelesssys/contrast/security/advisories/GHSA-f5p4-p5q5-jv3h"
},
{
"type": "WEB",
"url": "https://github.com/edgelesssys/contrast/pull/1731"
},
{
"type": "WEB",
"url": "https://github.com/edgelesssys/contrast/commit/2252a231d570c2dce10a33660452b0bfc3c43958"
},
{
"type": "PACKAGE",
"url": "https://github.com/edgelesssys/contrast"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-4078"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Contrast has insecure LUKS2 persistent storage partitions may be opened and used"
}
GHSA-F67F-6CW9-8MQ4
Vulnerability from github – Published: 2026-01-13 21:51 – Updated: 2026-01-13 21:51Summary
A flaw in Hono’s JWK/JWKS JWT verification middleware allowed the JWT header’s alg value to influence signature verification when the selected JWK did not explicitly specify an algorithm. This could enable JWT algorithm confusion and, in certain configurations, allow forged tokens to be accepted.
Details
When verifying JWTs using JWKs or a JWKS endpoint, the middleware selected the verification algorithm based on the JWK’s alg field if present, but otherwise fell back to the alg value provided in the unverified JWT header.
Because the alg field in a JWK is optional and often omitted in real-world JWKS configurations, this behavior could allow an attacker to control the algorithm used for verification. In some environments, this may lead to authentication or authorization
bypass through crafted tokens.
The practical impact depends on application configuration, including which algorithms are accepted and how JWTs are used for authorization decisions.
Impact
In affected configurations, an attacker may be able to forge JWTs with attacker-controlled claims, potentially resulting in authentication or authorization bypass.
Applications that do not use the JWK/JWKS middleware, do not rely on JWT-based authentication, or explicitly restrict allowed algorithms are not affected.
Resolution
Update to the latest patched release.
Breaking change:
As part of this fix, the JWT middleware now requires the alg option to be explicitly specified. This prevents algorithm confusion by ensuring that the verification algorithm is not derived from untrusted JWT header values.
Applications upgrading must update their configuration accordingly.
Before (vulnerable configuration)
import { jwt } from 'hono/jwt'
app.use(
'/auth/*',
jwt({
secret: 'it-is-very-secret',
// alg was optional
})
)
After (patched configuration)
import { jwt } from 'hono/jwt'
app.use(
'/auth/*',
jwt({
secret: 'it-is-very-secret',
alg: 'HS256', // required
})
)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "hono"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.11.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22817"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T21:51:44Z",
"nvd_published_at": "2026-01-13T20:16:11Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA flaw in Hono\u2019s JWK/JWKS JWT verification middleware allowed the JWT header\u2019s `alg` value to influence signature verification when the selected JWK did not explicitly specify an algorithm. This could enable **JWT algorithm confusion** and, in certain configurations, allow forged tokens to be accepted.\n\n## Details\n\nWhen verifying JWTs using JWKs or a JWKS endpoint, the middleware selected the verification algorithm based on the JWK\u2019s `alg` field if present, but otherwise fell back to the `alg` value provided in the unverified JWT header.\n\nBecause the `alg` field in a JWK is optional and often omitted in real-world JWKS configurations, this behavior could allow an attacker to control the algorithm used for verification. In some environments, this may lead to authentication or authorization\nbypass through crafted tokens.\n\nThe practical impact depends on application configuration, including which algorithms are accepted and how JWTs are used for authorization decisions.\n\n## Impact\n\nIn affected configurations, an attacker may be able to forge JWTs with attacker-controlled claims, potentially resulting in authentication or authorization bypass.\n\nApplications that do not use the JWK/JWKS middleware, do not rely on JWT-based authentication, or explicitly restrict allowed algorithms are not affected.\n\n## Resolution\n\nUpdate to the latest patched release.\n\n**Breaking change:**\n\nAs part of this fix, the JWT middleware now requires the `alg` option to be explicitly specified. This prevents algorithm confusion by ensuring that the verification algorithm is not derived from untrusted JWT header values.\n\nApplications upgrading must update their configuration accordingly.\n\n### Before (vulnerable configuration)\n\n```ts\nimport { jwt } from \u0027hono/jwt\u0027\n\napp.use(\n \u0027/auth/*\u0027,\n jwt({\n secret: \u0027it-is-very-secret\u0027,\n // alg was optional\n })\n)\n```\n\n### After (patched configuration)\n\n```ts\nimport { jwt } from \u0027hono/jwt\u0027\n\napp.use(\n \u0027/auth/*\u0027,\n jwt({\n secret: \u0027it-is-very-secret\u0027,\n alg: \u0027HS256\u0027, // required\n })\n)\n```",
"id": "GHSA-f67f-6cw9-8mq4",
"modified": "2026-01-13T21:51:45Z",
"published": "2026-01-13T21:51:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/hono/security/advisories/GHSA-f67f-6cw9-8mq4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22817"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/commit/cc0aa7ae327ed84cc391d29086dec2a3e44e7a1f"
},
{
"type": "PACKAGE",
"url": "https://github.com/honojs/hono"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Hono JWT Middleware\u0027s JWT Algorithm Confusion via Unsafe Default (HS256) Allows Token Forgery and Auth Bypass"
}
GHSA-F6RC-73VX-29H5
Vulnerability from github – Published: 2024-07-31 21:32 – Updated: 2024-08-15 15:30An issue was discovered in filestash v0.4. The usage of the ssh.InsecureIgnoreHostKey() disables host key verification, possibly allowing attackers to obtain sensitive information via a man-in-the-middle attack.
{
"affected": [],
"aliases": [
"CVE-2024-41258"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-31T21:15:18Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in filestash v0.4. The usage of the ssh.InsecureIgnoreHostKey() disables host key verification, possibly allowing attackers to obtain sensitive information via a man-in-the-middle attack.",
"id": "GHSA-f6rc-73vx-29h5",
"modified": "2024-08-15T15:30:53Z",
"published": "2024-07-31T21:32:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41258"
},
{
"type": "WEB",
"url": "https://gist.github.com/nyxfqq/ed8c2ba3398c9e28cd8dbf0902bd8edf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F7Q4-PWC6-W24P
Vulnerability from github – Published: 2024-08-02 09:31 – Updated: 2025-11-04 16:51In the Elliptic package 6.5.6 for Node.js, EDDSA signature malleability occurs because there is a missing signature length check, and thus zero-valued bytes can be removed or appended.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.5.6"
},
"package": {
"ecosystem": "npm",
"name": "elliptic"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "6.5.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-42459"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2024-08-05T13:21:11Z",
"nvd_published_at": "2024-08-02T07:16:10Z",
"severity": "LOW"
},
"details": "In the Elliptic package 6.5.6 for Node.js, EDDSA signature malleability occurs because there is a missing signature length check, and thus zero-valued bytes can be removed or appended.",
"id": "GHSA-f7q4-pwc6-w24p",
"modified": "2025-11-04T16:51:32Z",
"published": "2024-08-02T09:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42459"
},
{
"type": "WEB",
"url": "https://github.com/indutny/elliptic/pull/317"
},
{
"type": "WEB",
"url": "https://github.com/indutny/elliptic/commit/accb61e9c1a005e5c8ff96a8b33893100bb42d11"
},
{
"type": "WEB",
"url": "https://github.com/indutny/elliptic/commit/c0690b36be043ee73c1780ae4b7df48632b11cf9"
},
{
"type": "PACKAGE",
"url": "https://github.com/indutny/elliptic"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241004-0005"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Elliptic\u0027s EDDSA missing signature length check"
}
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.