CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1344 vulnerabilities reference this CWE, most recent first.
GHSA-3QPC-4533-P5RR
Vulnerability from github – Published: 2022-05-14 01:41 – Updated: 2022-05-14 01:41In verify_signed_hash() in lib/liboswkeys/signatures.c in Openswan before 2.6.50.1, the RSA implementation does not verify the value of padding string during PKCS#1 v1.5 signature verification. Consequently, a remote attacker can forge signatures when small public exponents are being used. IKEv2 signature verification is affected when RAW RSA keys are used.
{
"affected": [],
"aliases": [
"CVE-2018-15836"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-26T21:29:00Z",
"severity": "HIGH"
},
"details": "In verify_signed_hash() in lib/liboswkeys/signatures.c in Openswan before 2.6.50.1, the RSA implementation does not verify the value of padding string during PKCS#1 v1.5 signature verification. Consequently, a remote attacker can forge signatures when small public exponents are being used. IKEv2 signature verification is affected when RAW RSA keys are used.",
"id": "GHSA-3qpc-4533-p5rr",
"modified": "2022-05-14T01:41:56Z",
"published": "2022-05-14T01:41:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15836"
},
{
"type": "WEB",
"url": "https://github.com/xelerance/Openswan/commit/0b460be9e287fd335c8ce58129c67bf06065ef51"
},
{
"type": "WEB",
"url": "https://github.com/xelerance/Openswan/commit/9eaa6c2a823c1d2b58913506a15f9474bf857a3d"
},
{
"type": "WEB",
"url": "https://lists.openswan.org/pipermail/users/2018-August/023761.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3R3G-G73X-G593
Vulnerability from github – Published: 2021-10-12 16:06 – Updated: 2025-12-22 16:27Impact
coreos-installer fails to correctly verify GPG signatures when decompressing gzip-compressed artifacts. This allows bypass of signature verification in cases where coreos-installer decompresses a downloaded OS image, allowing an attacker who can modify the OS image to compromise a newly-installed system.
Default installations from ISO or PXE media in Fedora CoreOS, RHEL CoreOS, and RHEL for Edge are not affected, as coreos-installer installs from an OS image shipped as part of the install media.
These flows are affected:
-
Installing with
--image-file,--image-url, orcoreos.inst.image_url. For example, if a user has a local mirror of installation images, an attacker could replace an image with a gzip-compressed alternative (even if the file extension is.xz). The result:``` $ coreos-installer install --image-url http://localhost:8080/image.xz /dev/loop0 Downloading image from http://localhost:8080/image.xz Downloading signature from http://localhost:8080/image.xz.sig
Read disk 749.9 MiB/749.9 MiB (100%) gpg: Signature made Mon 20 Sep 2021 02:41:50 PM EDT gpg: using RSA key 8C5BA6990BDB26E19F2A1A801161AE6945719A39 gpg: BAD signature from "Fedora (34) fedora-34-primary@fedoraproject.org" [ultimate] Install complete. ```
Notice that GPG reports a bad signature, but coreos-installer continues anyway. Automation that relies on coreos-installer's exit status will not notice either.
-
coreos-installer download --decompress --image-url:``` $ coreos-installer download --decompress --image-url http://localhost:8080/image.xz
Read disk 749.9 MiB/749.9 MiB (100%) gpg: Signature made Mon 20 Sep 2021 02:41:50 PM EDT gpg: using RSA key 8C5BA6990BDB26E19F2A1A801161AE6945719A39 gpg: BAD signature from "Fedora (34) fedora-34-primary@fedoraproject.org" [ultimate] ./image ```
Again, coreos-installer reports success.
-
Installing with default parameters, when not installing from the image built into live ISO or PXE media, if the hosting service is compromised or if an active attacker gains control of the HTTPS response.
-
coreos-installer download --decompressif the hosting service is compromised or if an active attacker gains control of the HTTPS response.
Patches
The vulnerability is fixed in coreos-installer 0.10.1.
Workarounds
For coreos-installer download, do not use the -d or --decompress options.
For coreos-installer install, manually inspect the stderr output. If BAD signature appears, do not boot from the target disk. Note, however, that some OS services may have already accessed data on the compromised disk.
References
For more information, see PR 655.
For more information
If you have any questions or comments about this advisory, open an issue in coreos-installer or email the CoreOS development mailing list.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "coreos-installer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-20319"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-10-11T21:17:04Z",
"nvd_published_at": "2022-03-04T18:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\ncoreos-installer fails to correctly verify GPG signatures when decompressing gzip-compressed artifacts. This allows bypass of signature verification in cases where coreos-installer decompresses a downloaded OS image, allowing an attacker who can modify the OS image to compromise a newly-installed system.\n\nDefault installations from ISO or PXE media in Fedora CoreOS, RHEL CoreOS, and RHEL for Edge are **not** affected, as coreos-installer installs from an OS image shipped as part of the install media.\n\nThese flows are affected:\n\n1. Installing with `--image-file`, `--image-url`, or `coreos.inst.image_url`. For example, if a user has a local mirror of installation images, an attacker could replace an image with a gzip-compressed alternative (even if the file extension is `.xz`). The result:\n\n ```\n $ coreos-installer install --image-url http://localhost:8080/image.xz /dev/loop0\n Downloading image from http://localhost:8080/image.xz\n Downloading signature from http://localhost:8080/image.xz.sig\n \u003e Read disk 749.9 MiB/749.9 MiB (100%)\n gpg: Signature made Mon 20 Sep 2021 02:41:50 PM EDT\n gpg: using RSA key 8C5BA6990BDB26E19F2A1A801161AE6945719A39\n gpg: BAD signature from \"Fedora (34) \u003cfedora-34-primary@fedoraproject.org\u003e\" [ultimate]\n Install complete.\n ```\n\n Notice that GPG reports a bad signature, but coreos-installer continues anyway. Automation that relies on coreos-installer\u0027s exit status will not notice either.\n\n2. `coreos-installer download --decompress --image-url`:\n\n ```\n $ coreos-installer download --decompress --image-url http://localhost:8080/image.xz\n \u003e Read disk 749.9 MiB/749.9 MiB (100%)\n gpg: Signature made Mon 20 Sep 2021 02:41:50 PM EDT\n gpg: using RSA key 8C5BA6990BDB26E19F2A1A801161AE6945719A39\n gpg: BAD signature from \"Fedora (34) \u003cfedora-34-primary@fedoraproject.org\u003e\" [ultimate]\n ./image\n ```\n\n Again, coreos-installer reports success.\n\n3. Installing with default parameters, when **not** installing from the image built into live ISO or PXE media, if the hosting service is compromised or if an active attacker gains control of the HTTPS response.\n\n4. `coreos-installer download --decompress` if the hosting service is compromised or if an active attacker gains control of the HTTPS response.\n\n### Patches\n\nThe vulnerability is [fixed](https://github.com/coreos/coreos-installer/pull/659) in coreos-installer 0.10.1.\n\n### Workarounds\n\nFor `coreos-installer download`, do not use the `-d` or `--decompress` options.\n\nFor `coreos-installer install`, manually inspect the stderr output. If `BAD signature` appears, do not boot from the target disk. Note, however, that some OS services may have already accessed data on the compromised disk.\n\n### References\n\nFor more information, see [PR 655](https://github.com/coreos/coreos-installer/pull/655).\n\n### For more information\n\nIf you have any questions or comments about this advisory, [open an issue in coreos-installer](https://github.com/coreos/coreos-installer/issues/new/choose) or email the CoreOS [development mailing list](https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/).",
"id": "GHSA-3r3g-g73x-g593",
"modified": "2025-12-22T16:27:06Z",
"published": "2021-10-12T16:06:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/coreos/coreos-installer/security/advisories/GHSA-3r3g-g73x-g593"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20319"
},
{
"type": "WEB",
"url": "https://github.com/coreos/coreos-installer/pull/655"
},
{
"type": "WEB",
"url": "https://github.com/coreos/coreos-installer/pull/659/commits/ad243c6f0eff2835b2da56ca5f7f33af76253c89"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2011862"
},
{
"type": "PACKAGE",
"url": "https://github.com/coreos/coreos-installer"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2022-0103.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "coreos-installer improperly verifies GPG signature when decompressing gzipped artifact"
}
GHSA-3V6V-6VWQ-2H95
Vulnerability from github – Published: 2026-08-11 18:31 – Updated: 2026-08-11 18:31Improper verification of cryptographic signature in Windows Schannel allows an unauthorized attacker to bypass a security feature over a network.
{
"affected": [],
"aliases": [
"CVE-2026-62757"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T17:18:28Z",
"severity": "MODERATE"
},
"details": "Improper verification of cryptographic signature in Windows Schannel allows an unauthorized attacker to bypass a security feature over a network.",
"id": "GHSA-3v6v-6vwq-2h95",
"modified": "2026-08-11T18:31:19Z",
"published": "2026-08-11T18:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62757"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-62757"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
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"
}
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.