CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1128 vulnerabilities reference this CWE, most recent first.
GHSA-3VHC-576X-3QV4
Vulnerability from github – Published: 2026-01-13 21:52 – Updated: 2026-01-13 21:52Summary
A flaw in Hono’s JWK/JWKS JWT verification middleware allowed the algorithm specified in the JWT header to influence signature verification when the selected JWK did not explicitly define 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. If the JWK did not specify an algorithm, the middleware fell back to using the alg value provided in the unverified JWT header.
Because the alg field in a JWK is optional and commonly omitted in real-world JWKS configurations, this behavior could allow an attacker to influence which algorithm is used for verification. In some environments, this may result in authentication or authorization bypass through crafted JWTs.
The practical impact depends on application configuration, including which algorithms are accepted and how JWTs are used to make authorization decisions.
Impact
In affected configurations, an attacker may be able to forge JWTs with attacker-controlled claims, potentially leading to 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:
The JWK/JWKS JWT verification middleware has been updated to require an explicit allowlist of asymmetric algorithms when verifying tokens. The middleware no longer derives the verification algorithm from untrusted JWT header values.
Instead, callers must explicitly specify which asymmetric algorithms are permitted, and only tokens signed with those algorithms will be accepted. This prevents JWT algorithm confusion by ensuring that algorithm selection is fully controlled by application configuration.
As part of this fix, the alg option is now required when using the JWK/JWKS middleware, and symmetric (HS*) algorithms are no longer accepted in this context.
Before (vulnerable configuration)
import { jwk } from 'hono/jwk'
app.use(
'/auth/*',
jwk({
jwks_uri: 'https://example.com/.well-known/jwks.json',
// alg was optional
})
)
After (patched configuration)
import { jwk } from 'hono/jwk'
app.use(
'/auth/*',
jwk({
jwks_uri: 'https://example.com/.well-known/jwks.json',
alg: ['RS256'], // required: explicit asymmetric algorithm allowlist
})
)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "hono"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.11.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22818"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T21:52:03Z",
"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 algorithm specified in the JWT header to influence signature verification when the selected JWK did not explicitly define 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. If the JWK did not specify an algorithm, the middleware fell back to using the `alg` value provided in the unverified JWT header.\n\nBecause the `alg` field in a JWK is optional and commonly omitted in real-world JWKS configurations, this behavior could allow an attacker to influence which algorithm is used for verification. In some environments, this may result in authentication or authorization bypass through crafted JWTs.\n\nThe practical impact depends on application configuration, including which algorithms are accepted and how JWTs are used to make authorization decisions.\n\n## Impact\n\nIn affected configurations, an attacker may be able to forge JWTs with attacker-controlled claims, potentially leading to 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\nThe JWK/JWKS JWT verification middleware has been updated to require an explicit allowlist of asymmetric algorithms when verifying tokens. The middleware no longer derives the verification algorithm from untrusted JWT header values.\n\nInstead, callers must explicitly specify which asymmetric algorithms are permitted, and only tokens signed with those algorithms will be accepted. This prevents JWT algorithm confusion by ensuring that algorithm selection is fully controlled by application\nconfiguration.\n\nAs part of this fix, the `alg` option is now required when using the JWK/JWKS middleware, and symmetric (HS*) algorithms are no longer accepted in this context.\n\n### Before (vulnerable configuration)\n\n```ts\nimport { jwk } from \u0027hono/jwk\u0027\n\napp.use(\n \u0027/auth/*\u0027,\n jwk({\n jwks_uri: \u0027https://example.com/.well-known/jwks.json\u0027,\n // alg was optional\n })\n)\n```\n\n### After (patched configuration)\n\n```ts\nimport { jwk } from \u0027hono/jwk\u0027\n\napp.use(\n \u0027/auth/*\u0027,\n jwk({\n jwks_uri: \u0027https://example.com/.well-known/jwks.json\u0027,\n alg: [\u0027RS256\u0027], // required: explicit asymmetric algorithm allowlist\n })\n)\n```",
"id": "GHSA-3vhc-576x-3qv4",
"modified": "2026-01-13T21:52:03Z",
"published": "2026-01-13T21:52:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/hono/security/advisories/GHSA-3vhc-576x-3qv4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22818"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/commit/190f6e28e2ca85ce3d1f2f54db1310f5f3eab134"
},
{
"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 JWK Auth Middleware has JWT algorithm confusion when JWK lacks \"alg\" (untrusted header.alg fallback)"
}
GHSA-3VMH-33XR-9CQH
Vulnerability from github – Published: 2026-03-30 19:13 – Updated: 2026-03-31 18:52CVE-2026-34377: Consensus Failure via Crafted V5 Authorization Data
Summary
A logic error in Zebra's transaction verification cache could allow a malicious miner to induce a consensus split. By matching a valid transaction's txid while providing invalid authorization data, a miner could cause vulnerable Zebra nodes to accept an invalid block, leading to a consensus split from the rest of the Zcash network. To be clear, this would not allow invalid transactions to be accepted but could result in a consensus split between vulnerable Zebra nodes and invulnerable Zebra and Zcashd nodes.
Severity
High - This is a Consensus Vulnerability that could allow a malicious miner to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.
Affected Versions
All Zebra versions supporting V5 transactions (Network Upgrade 5 and later) prior to version 4.3.0.
Description
The vulnerability exists in the find_verified_unmined_tx function within transaction.rs. This function was designed to optimize block verification by checking if a transaction was already verified in the mempool.
The lookup mechanism used the ZIP-244 txid as the unique key. However, for V5 transactions, the txid specifically excludes the Authorization Data Root (signatures and proofs). Because Zebra returned a "verified" status based solely on the txid, it skipped the essential check_v5_auth() call for the transaction version provided in the block.
An attacker (specifically a malicious miner) could exploit this by:
1. Observing a valid V5 transaction broadcast to the network and entering a Zebra node's mempool.
2. Creating a block containing a modified version of that transaction. The modified version has the same txid but contains invalid signatures or proofs.
3. The affected Zebra node identifies the txid in its mempool and incorrectly assumes the block's version of the transaction is already verified.
4. The node commits the block with the invalid transaction data.
5. Other nodes (like zcashd or zebra nodes without that transaction in their mempool) reject the block, resulting in a chain fork where the poisoned Zebra node is isolated.
Impact
Consensus Failure * Attack Vector: Network (specifically via a malicious miner). * Effect: Network partition/consensus split. * Scope: Any Zebra node utilizing the transaction verification cache optimization for V5 transactions.
Fixed Versions
This issue is fixed in Zebra 4.3.0.
The fix ensures that verification is only skipped if the transaction's full integrity—including authorization data—is validated against the mempool entry.
Mitigation
Users should upgrade to Zebra 4.3.0 or later immediately.
There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.
Resources
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "zebrad"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.3.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "zebra-consensus"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34377"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-30T19:13:41Z",
"nvd_published_at": "2026-03-31T15:16:19Z",
"severity": "HIGH"
},
"details": "---\n\n# CVE-2026-34377: Consensus Failure via Crafted V5 Authorization Data\n\n## Summary\nA logic error in Zebra\u0027s transaction verification cache could allow a malicious miner to induce a consensus split. By matching a valid transaction\u0027s `txid` while providing invalid authorization data, a miner could cause vulnerable Zebra nodes to accept an invalid block, leading to a consensus split from the rest of the Zcash network. To be clear, **this would not allow invalid transactions to be accepted** but could result in a consensus split between vulnerable Zebra nodes and invulnerable Zebra and Zcashd nodes.\n\n## Severity\n**High** - This is a Consensus Vulnerability that could allow a malicious miner to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.\n\n## Affected Versions\nAll Zebra versions supporting V5 transactions (Network Upgrade 5 and later) prior to **version 4.3.0**.\n\n## Description\nThe vulnerability exists in the `find_verified_unmined_tx` function within `transaction.rs`. This function was designed to optimize block verification by checking if a transaction was already verified in the mempool.\n\nThe lookup mechanism used the **ZIP-244 `txid`** as the unique key. However, for V5 transactions, the `txid` specifically excludes the **Authorization Data Root** (signatures and proofs). Because Zebra returned a \"verified\" status based solely on the `txid`, it skipped the essential `check_v5_auth()` call for the transaction version provided in the block.\n\nAn attacker (specifically a malicious miner) could exploit this by:\n1. Observing a valid V5 transaction broadcast to the network and entering a Zebra node\u0027s mempool.\n2. Creating a block containing a modified version of that transaction. The modified version has the same `txid` but contains invalid signatures or proofs.\n3. The affected Zebra node identifies the `txid` in its mempool and incorrectly assumes the block\u0027s version of the transaction is already verified.\n4. The node commits the block with the invalid transaction data.\n5. Other nodes (like `zcashd` or `zebra` nodes without that transaction in their mempool) reject the block, resulting in a chain fork where the poisoned Zebra node is isolated.\n\n## Impact\n**Consensus Failure**\n* **Attack Vector:** Network (specifically via a malicious miner).\n* **Effect:** Network partition/consensus split.\n* **Scope:** Any Zebra node utilizing the transaction verification cache optimization for V5 transactions.\n\n## Fixed Versions\nThis issue is fixed in **Zebra 4.3.0**. \n\nThe fix ensures that verification is only skipped if the transaction\u0027s full integrity\u2014including authorization data\u2014is validated against the mempool entry.\n\n## Mitigation\nUsers should upgrade to **Zebra 4.3.0** or later immediately. \n\nThere are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.\n\n## Resources\n* [Zebra 4.3.0 Release Announcement](https://zfnd.org/zebra-4-3-0-critical-security-fixes-zip-235-support-and-performance-improvements/)\n* [ZIP-244: Transaction Identifier](https://zips.z.cash/zip-0244)\n\n---",
"id": "GHSA-3vmh-33xr-9cqh",
"modified": "2026-03-31T18:52:14Z",
"published": "2026-03-30T19:13:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-3vmh-33xr-9cqh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34377"
},
{
"type": "PACKAGE",
"url": "https://github.com/ZcashFoundation/zebra"
},
{
"type": "WEB",
"url": "https://github.com/ZcashFoundation/zebra/releases/tag/v4.3.0"
},
{
"type": "WEB",
"url": "https://zfnd.org/zebra-4-3-0-critical-security-fixes-zip-235-support-and-performance-improvements"
},
{
"type": "WEB",
"url": "https://zips.z.cash/zip-0244"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Zebra has a Consensus Failure due to Improper Verification of V5 Transactions"
}
GHSA-3VQ2-5G7P-FGF2
Vulnerability from github – Published: 2024-11-12 21:30 – Updated: 2024-11-14 21:32An improper verification of cryptographic signature vulnerability [CWE-347] in FortiClient MacOS version 7.4.0, version 7.2.4 and below, version 7.0.10 and below, version 6.4.10 and below may allow a local authenticated attacker to swap the installer with a malicious package via a race condition during the installation process.
{
"affected": [],
"aliases": [
"CVE-2024-40592"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-12T19:15:11Z",
"severity": "HIGH"
},
"details": "An improper verification of cryptographic signature vulnerability [CWE-347] in FortiClient MacOS version 7.4.0, version 7.2.4 and below, version 7.0.10 and below, version 6.4.10 and below may allow a local authenticated attacker to\u00a0swap the installer with a malicious package via a race condition during the installation process.",
"id": "GHSA-3vq2-5g7p-fgf2",
"modified": "2024-11-14T21:32:01Z",
"published": "2024-11-12T21:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40592"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-022"
}
],
"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-3VVW-G7QX-FFJJ
Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-07-13 00:01A firmware validation issue was discovered in HMI3 Control Panel in Swisslog Healthcare Nexus Panel operated by released versions of software before Nexus Software 7.2.5.7. There is no firmware validation (e.g., cryptographic signature validation) during a File Upload for a firmware update.
{
"affected": [],
"aliases": [
"CVE-2021-37160"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-02T13:15:00Z",
"severity": "CRITICAL"
},
"details": "A firmware validation issue was discovered in HMI3 Control Panel in Swisslog Healthcare Nexus Panel operated by released versions of software before Nexus Software 7.2.5.7. There is no firmware validation (e.g., cryptographic signature validation) during a File Upload for a firmware update.",
"id": "GHSA-3vvw-g7qx-ffjj",
"modified": "2022-07-13T00:01:33Z",
"published": "2022-05-24T19:09:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37160"
},
{
"type": "WEB",
"url": "https://www.armis.com/PwnedPiper"
},
{
"type": "WEB",
"url": "https://www.swisslog-healthcare.com"
},
{
"type": "WEB",
"url": "https://www.swisslog-healthcare.com/-/media/swisslog-healthcare/documents/customer-service/armis-documents/cve-2021-37160-bulletin---no-firmware-update-validation.pdf?rev=c7f94647037c4007992e2e626d445561\u0026hash=E89531490070A809FB74994018BA1248"
},
{
"type": "WEB",
"url": "https://www.swisslog-healthcare.com/en-us/customer-care/security-information/cve-disclosures#:~:text=CVE%20Disclosures%20%20%20%20Vulnerability%20Name%20,%20%20CVE-2021-37164%20%204%20more%20rows%20"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3XMC-3R4G-3QF4
Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2024-04-04 01:47Multiple padding oracle vulnerabilities (Zombie POODLE, GOLDENDOODLE, OpenSSL 0-length) in the CBC padding implementation of FortiOS IPS engine version 5.000 to 5.006, 4.000 to 4.036, 4.200 to 4.219, 3.547 and below, when configured with SSL Deep Inspection policies and with the IPS sensor enabled, may allow an attacker to decipher TLS connections going through the FortiGate via monitoring the traffic in a Man-in-the-middle position.
{
"affected": [],
"aliases": [
"CVE-2019-5592"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-23T20:15:00Z",
"severity": "MODERATE"
},
"details": "Multiple padding oracle vulnerabilities (Zombie POODLE, GOLDENDOODLE, OpenSSL 0-length) in the CBC padding implementation of FortiOS IPS engine version 5.000 to 5.006, 4.000 to 4.036, 4.200 to 4.219, 3.547 and below, when configured with SSL Deep Inspection policies and with the IPS sensor enabled, may allow an attacker to decipher TLS connections going through the FortiGate via monitoring the traffic in a Man-in-the-middle position.",
"id": "GHSA-3xmc-3r4g-3qf4",
"modified": "2024-04-04T01:47:09Z",
"published": "2022-05-24T16:54:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5592"
},
{
"type": "WEB",
"url": "https://fortiguard.com/advisory/FG-IR-19-145"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3XQ6-CH8V-2GHJ
Vulnerability from github – Published: 2025-03-05 06:31 – Updated: 2025-03-05 21:32Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.843 Application 20.0.1923 allows Insufficient Signature Validation OVE-20230524-0014.
{
"affected": [],
"aliases": [
"CVE-2025-27670"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-05T06:15:39Z",
"severity": "CRITICAL"
},
"details": "Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.843 Application 20.0.1923 allows Insufficient Signature Validation OVE-20230524-0014.",
"id": "GHSA-3xq6-ch8v-2ghj",
"modified": "2025-03-05T21:32:10Z",
"published": "2025-03-05T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27670"
},
{
"type": "WEB",
"url": "https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-423W-P2W9-R7VQ
Vulnerability from github – Published: 2023-09-22 16:11 – Updated: 2025-12-31 22:00Summary
In the AES GCM implementation of decrypt_in_place_detached, the decrypted ciphertext (i.e. the correct plaintext) is exposed even if tag verification fails.
Impact
If a program using the aes-gcm crate's decrypt_in_place* APIs accesses the buffer after decryption failure, it will contain a decryption of an unauthenticated input. Depending on the specific nature of the program this may enable Chosen Ciphertext Attacks (CCAs) which can cause a catastrophic breakage of the cipher including full plaintext recovery.
Details
As seen in the implementation of decrypt_in_place_detached for AES GCM, if the tag verification fails, an error is returned. Because the decryption of the ciphertext is done in place, the plaintext contents are now exposed via buffer.
This should ideally not be the case - as noted in page 17 of NIST's publication Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC: In Step 8, the result of Step 7 is compared with the authentication tag that was received as an input: if they are identical, then the plaintext is returned; otherwise,FAIL is returned.
This is seems correctly addressed in the AES GCM SIV implementation, where the decrypted buffer is encrypted again before the error is returned - this fix is straightforward to implement in AES GCM. To ensure that these types of cases are covered during testing, it would be valuable to add test cases like 23, 24 etc from project wycheproof to ensure that when a bad tag is used, there is an error on decryption and that the plaintext value is not exposed.
PoC
To reproduce this issue, I'm using test case 23 from project wycheproof.
let key = GenericArray::from_slice(&hex!("000102030405060708090a0b0c0d0e0f"));
let nonce = GenericArray::from_slice(&hex!("505152535455565758595a5b"));
let tag = GenericArray::from_slice(&hex!("d9847dbc326a06e988c77ad3863e6083")); // bad tag
let mut ct = hex!("eb156d081ed6b6b55f4612f021d87b39");
let msg = hex!("202122232425262728292a2b2c2d2e2f");
let aad = hex!("");
let cipher = Aes128Gcm::new(&key);
let _plaintext = cipher.decrypt_in_place_detached(&nonce, &aad, &mut ct, &tag);
assert_eq!(ct, msg);
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.10.2"
},
"package": {
"ecosystem": "crates.io",
"name": "aes-gcm"
},
"ranges": [
{
"events": [
{
"introduced": "0.10.0"
},
{
"fixed": "0.10.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-42811"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-22T16:11:47Z",
"nvd_published_at": "2023-09-22T16:15:10Z",
"severity": "MODERATE"
},
"details": "### Summary\nIn the AES GCM implementation of decrypt_in_place_detached, the decrypted ciphertext (i.e. the correct plaintext) is exposed even if tag verification fails. \n\n### Impact\nIf a program using the `aes-gcm` crate\u0027s `decrypt_in_place*` APIs accesses the buffer after decryption failure, it will contain a decryption of an unauthenticated input. Depending on the specific nature of the program this may enable Chosen Ciphertext Attacks (CCAs) which can cause a catastrophic breakage of the cipher including full plaintext recovery.\n\n### Details\nAs seen in the implementation of [decrypt_in_place_detached](https://docs.rs/aes-gcm/latest/src/aes_gcm/lib.rs.html#309) for AES GCM, if the tag verification fails, an error is returned. Because the decryption of the ciphertext is done in place, the plaintext contents are now exposed via `buffer`. \n\nThis should ideally not be the case - as noted in page 17 of[ NIST\u0027s publication _Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC_](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf): \n_In Step 8, the result of Step 7 is compared with the authentication tag that was received as an input: if they are identical, then the plaintext is returned; otherwise,FAIL is returned._\n\nThis is seems correctly addressed in the [AES GCM SIV implementation](https://docs.rs/aes-gcm-siv/latest/src/aes_gcm_siv/lib.rs.html#307), where the decrypted buffer is encrypted again before the error is returned - this fix is straightforward to implement in AES GCM. To ensure that these types of cases are covered during testing, it would be valuable to add test cases like [23, 24 ](https://github.com/google/wycheproof/blob/master/testvectors/aes_gcm_test.json#L288)etc from [project wycheproof ](https://github.com/google/wycheproof)to ensure that when a bad tag is used, there is an error on decryption _**and**_ that the plaintext value is not exposed. \n\n### PoC\nTo reproduce this issue, I\u0027m using [test case 23](https://github.com/google/wycheproof/blob/master/testvectors/aes_gcm_test.json#L288) from project wycheproof. \n```rust\n let key = GenericArray::from_slice(\u0026hex!(\"000102030405060708090a0b0c0d0e0f\"));\n let nonce = GenericArray::from_slice(\u0026hex!(\"505152535455565758595a5b\"));\n let tag = GenericArray::from_slice(\u0026hex!(\"d9847dbc326a06e988c77ad3863e6083\")); // bad tag\n let mut ct = hex!(\"eb156d081ed6b6b55f4612f021d87b39\");\n let msg = hex!(\"202122232425262728292a2b2c2d2e2f\");\n let aad = hex!(\"\");\n let cipher = Aes128Gcm::new(\u0026key);\n let _plaintext = cipher.decrypt_in_place_detached(\u0026nonce, \u0026aad, \u0026mut ct, \u0026tag);\n assert_eq!(ct, msg);\n```",
"id": "GHSA-423w-p2w9-r7vq",
"modified": "2025-12-31T22:00:24Z",
"published": "2023-09-22T16:11:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/RustCrypto/AEADs/security/advisories/GHSA-423w-p2w9-r7vq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42811"
},
{
"type": "WEB",
"url": "https://docs.rs/aes-gcm/latest/src/aes_gcm/lib.rs.html#309"
},
{
"type": "PACKAGE",
"url": "https://github.com/RustCrypto/AEADs"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ROBB6TBDAGEQ2WIINR34F3DPSN3FND6K"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RYQCICN6BVC6I75O3F6W4VK4J3MOYDJU"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U67ZSMNX5V3WTBYPUYF45PSFG4SF5SGF"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2023-0096.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "AEADs/aes-gcm: Plaintext exposed in decrypt_in_place_detached even on tag verification failure"
}
GHSA-42RQ-CWG9-M583
Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2024-04-04 02:01A crafted S/MIME message consisting of an inner encryption layer and an outer SignedData layer was shown as having a valid digital signature, although the signer might have had no access to the contents of the encrypted message, and might have stripped a different signature from the encrypted message. Previous versions had only suppressed showing a digital signature for messages with an outer multipart/signed layer. This vulnerability affects Thunderbird < 68.1.1.
{
"affected": [],
"aliases": [
"CVE-2019-11755"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-27T18:15:00Z",
"severity": "HIGH"
},
"details": "A crafted S/MIME message consisting of an inner encryption layer and an outer SignedData layer was shown as having a valid digital signature, although the signer might have had no access to the contents of the encrypted message, and might have stripped a different signature from the encrypted message. Previous versions had only suppressed showing a digital signature for messages with an outer multipart/signed layer. This vulnerability affects Thunderbird \u003c 68.1.1.",
"id": "GHSA-42rq-cwg9-m583",
"modified": "2024-04-04T02:01:51Z",
"published": "2022-05-24T16:57:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11755"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1240290"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/11/msg00017.html"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Nov/24"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4202-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4335-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4571"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2019-32"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00009.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00010.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-434G-2637-QMQR
Vulnerability from github – Published: 2024-10-10 03:30 – Updated: 2025-11-27 08:42The Elliptic package 6.5.5 for Node.js for EDDSA implementation does not perform the required check if the signature proof(s) is within the bounds of the order n of the base point of the elliptic curve, leading to signature malleability. Namely, the verify function in lib/elliptic/eddsa/index.js omits sig.S().gte(sig.eddsa.curve.n) || sig.S().isNeg() validation.
This vulnerability could have a security-relevant impact if an application relies on the uniqueness of a signature.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "elliptic"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.5.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-48949"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-10T21:00:04Z",
"nvd_published_at": "2024-10-10T01:15:11Z",
"severity": "LOW"
},
"details": "The Elliptic package 6.5.5 for Node.js for EDDSA implementation does not perform the required check if the signature proof(s) is within the bounds of the order n of the base point of the elliptic curve, leading to signature malleability. Namely, the `verify` function in `lib/elliptic/eddsa/index.js` omits `sig.S().gte(sig.eddsa.curve.n) || sig.S().isNeg()` validation.\n\nThis vulnerability could have a security-relevant impact if an application relies on the uniqueness of a signature.",
"id": "GHSA-434g-2637-qmqr",
"modified": "2025-11-27T08:42:58Z",
"published": "2024-10-10T03:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48949"
},
{
"type": "WEB",
"url": "https://github.com/indutny/elliptic/commit/7ac5360118f74eb02da73bdf9f24fd0c72ff5281"
},
{
"type": "WEB",
"url": "https://blog.trailofbits.com/2025/11/18/we-found-cryptography-bugs-in-the-elliptic-library-using-wycheproof"
},
{
"type": "PACKAGE",
"url": "https://github.com/indutny/elliptic"
},
{
"type": "WEB",
"url": "https://github.com/indutny/elliptic/compare/v6.5.5...v6.5.6"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241227-0003"
}
],
"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/E:U",
"type": "CVSS_V4"
}
],
"summary": "Elliptic\u0027s verify function omits uniqueness validation"
}
GHSA-4433-4CXQ-VV73
Vulnerability from github – Published: 2022-05-17 03:46 – Updated: 2024-10-07 21:00The Server.verify_request function in SimpleGeo python-oauth2 does not check the nonce, which allows remote attackers to perform replay attacks via a signed URL. The vulnerability does not appear to be patched according to the following discussion.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "oauth2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.9rc1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2013-4346"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-23T21:12:22Z",
"nvd_published_at": "2014-05-20T14:55:00Z",
"severity": "HIGH"
},
"details": "The Server.verify_request function in SimpleGeo python-oauth2 does not check the nonce, which allows remote attackers to perform replay attacks via a signed URL.\nThe vulnerability does not appear to be patched according to the following [discussion](https://github.com/joestump/python-oauth2/issues/129#issuecomment-895911502).",
"id": "GHSA-4433-4cxq-vv73",
"modified": "2024-10-07T21:00:48Z",
"published": "2022-05-17T03:46:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4346"
},
{
"type": "WEB",
"url": "https://github.com/simplegeo/python-oauth2/issues/129"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2015:1591"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2015:1592"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2013-4346"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1007746"
},
{
"type": "PACKAGE",
"url": "https://github.com/joestump/python-oauth2"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/oauth2/PYSEC-2014-85.yaml"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200228063302/http://www.securityfocus.com/bid/62386"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2013/09/12/7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"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",
"type": "CVSS_V4"
}
],
"summary": "SimpleGeo python-oauth2 does not check the nonce allowing replay attacks"
}
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.