CWE-354
AllowedImproper Validation of Integrity Check Value
Abstraction: Base · Status: Draft
The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.
251 vulnerabilities reference this CWE, most recent first.
GHSA-PVMV-CWG8-V6C8
Vulnerability from github – Published: 2026-05-08 18:27 – Updated: 2026-05-08 18:27Consensus Divergence in V5 Transparent SIGHASH_SINGLE With No Corresponding Output
Summary
Zebra failed to enforce a ZIP-244 consensus rule for V5 transparent transactions: when an input is signed with SIGHASH_SINGLE and there is no transparent output at the same index as that input, validation must fail. Zebra instead asked the underlying sighash library to compute a digest, and that library produced a digest over an empty output set rather than failing. An attacker could craft a V5 transaction with more transparent inputs than outputs that Zebra accepts but zcashd rejects, creating a consensus split between Zebra and zcashd nodes.
A previous fix (GHSA-cwfq-rfcr-8hmp) addressed a closely related case in the same area of the code, but did not cover this specific one.
Severity
Critical - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.
Note that the impact is currently alleviated by the fact that currently most miners run zcashd.
Affected Versions
Zebra 4.4.0.
Description
Verification of transparent transactions inherits the Bitcoin Script verification code in C++. Since it is consensus-critical, this code is called from Zebra through a foreign function interface (FFI), with a Rust callback that computes the sighash for each input being verified.
ZIP-244 §S.2a marks two situations as consensus failure for V5 transparent signatures:
- The signed hash type is not one of the six canonical values; and
- The hash type is
SIGHASH_SINGLE(alone or combined withANYONECANPAY) and the input has no transparent output at the same index.
zcashd enforces both rules: its SignatureHash raises an exception, and CheckSig catches it and fails the script. A previous fix (GHSA-cwfq-rfcr-8hmp) added the first rule to Zebra's V5 sighash callback. The second rule, however, was not added — Zebra's callback forwarded the request to librustzcash's ZIP-244 implementation, which handles an out-of-range SIGHASH_SINGLE output index by hashing an empty output set rather than refusing to produce a digest. As a result, Zebra would compute a well-defined sighash for the missing-output case and accept any signature that verified against it.
An attacker could exploit this by:
- Constructing a V5 transaction with two or more transparent inputs and fewer transparent outputs;
- Signing an input whose index has no matching
voutentry withSIGHASH_SINGLE(0x03) orSIGHASH_SINGLE|ANYONECANPAY(0x83), using the digest Zebra computes; - Broadcasting the transaction, or a block containing it, to the network.
Zebra would verify the transaction's transparent script and accept the transaction (and any block containing it), while zcashd would reject both, splitting Zebra nodes from the rest of the network.
Impact
Consensus Failure
- Attack Vector: Network.
- Effect: Network partition/consensus split.
- Scope: Any affected Zebra node.
Fixed Versions
This issue is fixed in Zebra 4.4.1.
Mitigation
Users should upgrade to Zebra 4.4.1 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.
Credits
Zebra thanks @sangsoo-osec, @zmanian, and @fivelittleducks for finding and reporting the issue.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "zebrad"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.4.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "zebra-script"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-354",
"CWE-573"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T18:27:26Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "# Consensus Divergence in V5 Transparent SIGHASH_SINGLE With No Corresponding Output\n\n## Summary\n\nZebra failed to enforce a ZIP-244 consensus rule for V5 transparent transactions: when an input is signed with `SIGHASH_SINGLE` and there is no transparent output at the same index as that input, validation must fail. Zebra instead asked the underlying sighash library to compute a digest, and that library produced a digest over an empty output set rather than failing. An attacker could craft a V5 transaction with more transparent inputs than outputs that Zebra accepts but `zcashd` rejects, creating a consensus split between Zebra and `zcashd` nodes.\n\nA previous fix ([`GHSA-cwfq-rfcr-8hmp`](https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-cwfq-rfcr-8hmp)) addressed a closely related case in the same area of the code, but did not cover this specific one. \n\n## Severity\n\n**Critical** - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.\n\nNote that the impact is currently alleviated by the fact that currently most miners run `zcashd`.\n\n## Affected Versions\n\nZebra 4.4.0.\n\n## Description\n\nVerification of transparent transactions inherits the Bitcoin Script verification code in C++. Since it is consensus-critical, this code is called from Zebra through a foreign function interface (FFI), with a Rust callback that computes the sighash for each input being verified.\n\nZIP-244 \u00a7S.2a marks two situations as consensus failure for V5 transparent signatures:\n\n1. The signed hash type is not one of the six canonical values; and\n2. The hash type is `SIGHASH_SINGLE` (alone or combined with `ANYONECANPAY`) and the input has no transparent output at the same index.\n\n`zcashd` enforces both rules: its `SignatureHash` raises an exception, and `CheckSig` catches it and fails the script. A previous fix (`GHSA-cwfq-rfcr-8hmp`) added the first rule to Zebra\u0027s V5 sighash callback. The second rule, however, was not added \u2014 Zebra\u0027s callback forwarded the request to `librustzcash`\u0027s ZIP-244 implementation, which handles an out-of-range `SIGHASH_SINGLE` output index by hashing an empty output set rather than refusing to produce a digest. As a result, Zebra would compute a well-defined sighash for the missing-output case and accept any signature that verified against it.\n\nAn attacker could exploit this by:\n\n- Constructing a V5 transaction with two or more transparent inputs and fewer transparent outputs;\n- Signing an input whose index has no matching `vout` entry with `SIGHASH_SINGLE` (`0x03`) or `SIGHASH_SINGLE|ANYONECANPAY` (`0x83`), using the digest Zebra computes;\n- Broadcasting the transaction, or a block containing it, to the network.\n\nZebra would verify the transaction\u0027s transparent script and accept the transaction (and any block containing it), while `zcashd` would reject both, splitting Zebra nodes from the rest of the network.\n\n## Impact\n\n**Consensus Failure**\n\n- **Attack Vector:** Network.\n- **Effect:** Network partition/consensus split.\n- **Scope:** Any affected Zebra node.\n\n## Fixed Versions\n\nThis issue is fixed in Zebra 4.4.1.\n\n## Mitigation\n\nUsers should upgrade to Zebra 4.4.1 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## Credits\n\nZebra thanks @sangsoo-osec, @zmanian, and @fivelittleducks for finding and reporting the issue.",
"id": "GHSA-pvmv-cwg8-v6c8",
"modified": "2026-05-08T18:27:26Z",
"published": "2026-05-08T18:27:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-pvmv-cwg8-v6c8"
},
{
"type": "PACKAGE",
"url": "https://github.com/ZcashFoundation/zebra"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Zebra v4.4.0 still accepts V5 SIGHASH_SINGLE without a corresponding output"
}
GHSA-PXM9-CF3X-RRC5
Vulnerability from github – Published: 2023-12-12 03:31 – Updated: 2023-12-14 00:30A missing integrity check in the update system in ProLion CryptoSpike 3.0.15P2 allows attackers to execute OS commands as the root Linux user on the host system via forged update packages.
{
"affected": [],
"aliases": [
"CVE-2023-36650"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-12T01:15:10Z",
"severity": "HIGH"
},
"details": "A missing integrity check in the update system in ProLion CryptoSpike 3.0.15P2 allows attackers to execute OS commands as the root Linux user on the host system via forged update packages.",
"id": "GHSA-pxm9-cf3x-rrc5",
"modified": "2023-12-14T00:30:25Z",
"published": "2023-12-12T03:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36650"
},
{
"type": "WEB",
"url": "https://www.cvcn.gov.it/cvcn/cve/CVE-2023-36650"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q36W-WXGM-W8F4
Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-05-24 19:09There is an Improper Validation of Integrity Check Value Vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may cause the system to reset.
{
"affected": [],
"aliases": [
"CVE-2021-22442"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-02T17:15:00Z",
"severity": "HIGH"
},
"details": "There is an Improper Validation of Integrity Check Value Vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may cause the system to reset.",
"id": "GHSA-q36w-wxgm-w8f4",
"modified": "2022-05-24T19:09:32Z",
"published": "2022-05-24T19:09:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22442"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2021/6"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-Q6J5-FJX5-2MC3
Vulnerability from github – Published: 2026-06-26 22:53 – Updated: 2026-06-26 22:53Summary
pnpm's tarball extraction worker skips integrity verification when the integrity field is absent from the lockfile resolution. If an attacker can both modify pnpm-lock.yaml to remove the integrity: field and cause the referenced registry URL to serve altered package content, pnpm install --frozen-lockfile can install the altered package without an integrity error. npm's npm ci enforces integrity by default; pnpm's behavior of silently skipping verification is a pnpm-specific fail-open gap.
Vulnerability Details
The addTarballToStore function in worker/src/start.ts (lines 189-204) checks if (integrity) before verifying the tarball hash. The TarballResolution type declares integrity as optional (integrity?: string). When the lockfile omits the integrity field, the guard evaluates to false, skipping hash verification entirely. The worker then computes a new hash from the unverified content and stores it as legitimate.
// worker/src/start.ts:189-204
function addTarballToStore ({ buffer, storeDir, integrity, ... }: TarballExtractMessage) {
if (integrity) { // false when integrity is undefined
const { algorithm, hexDigest } = parseIntegrity(integrity)
const calculatedHash = crypto.hash(algorithm, buffer, 'hex')
if (calculatedHash !== hexDigest) {
return { status: 'error', error: { type: 'integrity_validation_failed', ... } }
}
}
return {
status: 'success',
value: { integrity: integrity ?? calcIntegrity(buffer) },
}
}
Proof of Concept
bash autofyn_audit/exploits/vuln1_integrity_bypass/exploit.sh
# Publishes a package, generates lockfile, republishes tampered version,
# strips integrity field, re-runs install --frozen-lockfile.
# Result: PASS -- tampered package installed without integrity error.
Impact
Supply chain compromise in environments where an attacker can both alter the lockfile and cause the referenced registry URL to serve altered package content. The --frozen-lockfile flag does not fail closed when the integrity field is missing.
Suggested Remediation
Require an integrity field for remote tarball resolutions. Change the if (integrity) guard to fail when integrity is absent for non-local packages. When --frozen-lockfile is active, reject lockfile entries that lack integrity for remote packages.
Discovered by AutoFyn Full audit report: audit_report.md Exploit script: exploit.sh
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.34.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50021"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T22:53:01Z",
"nvd_published_at": "2026-06-25T18:16:39Z",
"severity": "MODERATE"
},
"details": "## Summary\n\npnpm\u0027s tarball extraction worker skips integrity verification when the `integrity` field is absent from the lockfile resolution. If an attacker can both modify `pnpm-lock.yaml` to remove the `integrity:` field and cause the referenced registry URL to serve altered package content, `pnpm install --frozen-lockfile` can install the altered package without an integrity error. npm\u0027s `npm ci` enforces integrity by default; pnpm\u0027s behavior of silently skipping verification is a pnpm-specific fail-open gap.\n\n## Vulnerability Details\n\nThe `addTarballToStore` function in `worker/src/start.ts` (lines 189-204) checks `if (integrity)` before verifying the tarball hash. The `TarballResolution` type declares `integrity` as optional (`integrity?: string`). When the lockfile omits the `integrity` field, the guard evaluates to `false`, skipping hash verification entirely. The worker then computes a new hash from the unverified content and stores it as legitimate.\n\n```typescript\n// worker/src/start.ts:189-204\nfunction addTarballToStore ({ buffer, storeDir, integrity, ... }: TarballExtractMessage) {\n if (integrity) { // false when integrity is undefined\n const { algorithm, hexDigest } = parseIntegrity(integrity)\n const calculatedHash = crypto.hash(algorithm, buffer, \u0027hex\u0027)\n if (calculatedHash !== hexDigest) {\n return { status: \u0027error\u0027, error: { type: \u0027integrity_validation_failed\u0027, ... } }\n }\n }\n return {\n status: \u0027success\u0027,\n value: { integrity: integrity ?? calcIntegrity(buffer) },\n }\n}\n```\n\n## Proof of Concept\n\n```bash\nbash autofyn_audit/exploits/vuln1_integrity_bypass/exploit.sh\n# Publishes a package, generates lockfile, republishes tampered version,\n# strips integrity field, re-runs install --frozen-lockfile.\n# Result: PASS -- tampered package installed without integrity error.\n```\n\n## Impact\n\nSupply chain compromise in environments where an attacker can both alter the lockfile and cause the referenced registry URL to serve altered package content. The `--frozen-lockfile` flag does not fail closed when the integrity field is missing.\n\n## Suggested Remediation\n\nRequire an `integrity` field for remote tarball resolutions. Change the `if (integrity)` guard to fail when integrity is absent for non-local packages. When `--frozen-lockfile` is active, reject lockfile entries that lack integrity for remote packages.\n\n---\n\n\u003e Discovered by [AutoFyn](https://github.com/SignalPilot-Labs/AutoFyn)\n\u003e Full audit report: [audit_report.md](https://github.com/tempcollab/pnpm/blob/main/autofyn_audit/audit_report.md)\n\u003e Exploit script: [exploit.sh](https://github.com/tempcollab/pnpm/blob/main/autofyn_audit/exploits/vuln1_integrity_bypass/exploit.sh)",
"id": "GHSA-q6j5-fjx5-2mc3",
"modified": "2026-06-26T22:53:01Z",
"published": "2026-06-26T22:53:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-q6j5-fjx5-2mc3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50021"
},
{
"type": "PACKAGE",
"url": "https://github.com/pnpm/pnpm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "pnpm Has an Integrity Check Bypass via Missing Lockfile Integrity Field"
}
GHSA-Q8JC-HPCV-JMXW
Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-04-04 02:37One Identity Cloud Access Manager before 8.1.4 Hotfix 1 allows OTP bypass via vectors involving a man in the middle, the One Identity Defender product, and replacing a failed SAML response with a successful SAML response.
{
"affected": [],
"aliases": [
"CVE-2019-13496"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-04T17:15:00Z",
"severity": "HIGH"
},
"details": "One Identity Cloud Access Manager before 8.1.4 Hotfix 1 allows OTP bypass via vectors involving a man in the middle, the One Identity Defender product, and replacing a failed SAML response with a successful SAML response.",
"id": "GHSA-q8jc-hpcv-jmxw",
"modified": "2024-04-04T02:37:58Z",
"published": "2022-05-24T17:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13496"
},
{
"type": "WEB",
"url": "https://github.com/FurqanKhan1/CVE-2019-13496"
},
{
"type": "WEB",
"url": "https://support.oneidentity.com/cloud-access-manager/kb/311391/cloud-access-manager-8-1-4-hotfix-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QM3C-X5C3-G2G4
Vulnerability from github – Published: 2022-05-24 17:12 – Updated: 2023-02-03 21:30There is an improper integrity checking vulnerability on some huawei products. The software of the affected product has an improper integrity check which may allow an attacker with high privilege to make malicious modifications.Affected product versions include:HEGE-560 versions 1.0.1.21(SP3);HEGE-570 versions 1.0.1.22(SP3);OSCA-550 versions 1.0.1.21(SP3);OSCA-550A versions 1.0.1.21(SP3);OSCA-550AX versions 1.0.1.21(SP3);OSCA-550X versions 1.0.1.21(SP3).
{
"affected": [],
"aliases": [
"CVE-2020-1879"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-03-20T16:15:00Z",
"severity": "LOW"
},
"details": "There is an improper integrity checking vulnerability on some huawei products. The software of the affected product has an improper integrity check which may allow an attacker with high privilege to make malicious modifications.Affected product versions include:HEGE-560 versions 1.0.1.21(SP3);HEGE-570 versions 1.0.1.22(SP3);OSCA-550 versions 1.0.1.21(SP3);OSCA-550A versions 1.0.1.21(SP3);OSCA-550AX versions 1.0.1.21(SP3);OSCA-550X versions 1.0.1.21(SP3).",
"id": "GHSA-qm3c-x5c3-g2g4",
"modified": "2023-02-03T21:30:30Z",
"published": "2022-05-24T17:12:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1879"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200311-01-integrity-en"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200415-02-dos-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QRM9-295F-XG65
Vulnerability from github – Published: 2022-09-21 00:00 – Updated: 2025-05-28 18:32An exploitable firmware downgrade vulnerability was discovered on the Netgear WPN824EXT WiFi Range Extender. An attacker can conduct a MITM attack to replace the user-uploaded firmware image with an original old firmware image. This affects Firmware 1.1.1_1.1.9 and earlier.
{
"affected": [],
"aliases": [
"CVE-2022-38956"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-20T18:15:00Z",
"severity": "MODERATE"
},
"details": "An exploitable firmware downgrade vulnerability was discovered on the Netgear WPN824EXT WiFi Range Extender. An attacker can conduct a MITM attack to replace the user-uploaded firmware image with an original old firmware image. This affects Firmware 1.1.1_1.1.9 and earlier.",
"id": "GHSA-qrm9-295f-xg65",
"modified": "2025-05-28T18:32:59Z",
"published": "2022-09-21T00:00:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38956"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40eupX2KdkT6iNpqJUWk9p4A/SyAnOSd1s"
},
{
"type": "WEB",
"url": "https://hackmd.io/@eupX2KdkT6iNpqJUWk9p4A/SyAnOSd1s"
},
{
"type": "WEB",
"url": "https://www.netgear.com/about/security"
}
],
"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-QVJW-73XM-JW34
Vulnerability from github – Published: 2026-04-10 00:30 – Updated: 2026-04-29 15:30A padding oracle exists in wolfSSL's PKCS7 CBC decryption that could allow an attacker to recover plaintext through repeated decryption queries with modified ciphertext. In previous versions of wolfSSL the interior padding bytes are not validated.
{
"affected": [],
"aliases": [
"CVE-2026-5504"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-09T23:17:01Z",
"severity": "MODERATE"
},
"details": "A padding oracle exists in wolfSSL\u0027s PKCS7 CBC decryption that could allow an attacker to recover plaintext through repeated decryption queries with modified ciphertext. In previous versions of wolfSSL the interior padding bytes are not validated.",
"id": "GHSA-qvjw-73xm-jw34",
"modified": "2026-04-29T15:30:35Z",
"published": "2026-04-10T00:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5504"
},
{
"type": "WEB",
"url": "https://github.com/wolfSSL/wolfssl/pull/10088"
}
],
"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:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-R353-4845-PR5P
Vulnerability from github – Published: 2026-03-13 20:44 – Updated: 2026-03-16 22:01Summary
XML nodes encrypted with either aes-128-gcm, aes-192-gcm, or aes-256-gcm lack validation of the authentication tag length. An attacker can use this to brute-force an authentication tag, recover the GHASH key, and decrypt the encrypted nodes. It also allows to forge arbitrary ciphertexts without knowing the encryption key.
Details
When decrypting with either aes-128-gcm, aes-192-gcm, or aes-256-gcm here, the $authTag is set from a substr(), but never has its length validated (it should be validated with something like strlen($authTag) == self::AUTHTAG_LENGTH). For that reason, a shorter than expected data blob will allow for the $authTag to have as short a tag as only one byte (see PHP's documentation).
See this example:
function test($data) {
$ivSize = 12;
$tagSize = 16;
$iv = substr($data, 0, $ivSize);
$data = substr($data, $ivSize);
$offset = 0 - $tagSize;
$tag = substr($data, $offset);
$ct = substr($data, 0, $offset);
echo 'IV: "' . $iv . '"' . PHP_EOL;
echo 'Tag: "' . $tag . '"' . PHP_EOL;
echo 'CT: "' . $ct . '"' . PHP_EOL;
}
/* Outputs:
php > test('myNonceNoncet');
IV: "myNonceNonce"
Tag: "t"
CT: ""
php > test('myNonceNonceta');
IV: "myNonceNonce"
Tag: "ta"
CT: ""
php > test('myNonceNoncetag');
IV: "myNonceNonce"
Tag: "tag"
CT: ""
*/
With a legit ciphertext in hand, this is enough to recover the GHASH key. With that key, any authenticated tags can be computed offline which allows for decryption of the ciphertext and forgery of arbitrary ciphertexts. PoC
- Setup a server expecting XML with an encrypted assertion
-
Run this php script poc.php with php -S 127.0.0.1:8888 (taken from this saml test case)
-
The script expects this private key: sp-private-key.pem.
-
Create an XML document with an encrypted assertion (encrypted with aes-256-gcm)
Here is the SAMLResponse used in the video below: saml_response.txt
Note: The steps from 3 to 6 are implemented in this exploit script: nonce_reuse_with_fmt_val_oracle.py. You can run the script with sage -python nonce_reuse_with_fmt_val_oracle.py -s 'url-encoded_and_base64-encoded_samlresponse'
-
Take the content of the node and apply the following modifications
-
Base64-decode the content
-
Take the first 12 bytes and save them as the nonce
-
Take the last 16 bytes and save them as the tag
-
Now brute-force the tag of an empty ciphertext
-
Loop through all 256 possible byte values (let's call that byte_tag_attempt)
-
Concatenate together the nonce and the byte_tag_attempt
-
Base64-encode the result
-
Replace the content of the node with this result
-
On http errors 500, we learn that the tag is valid
-
Do the same for the next byte of the tag until all 16 bytes have been brute-forced
-
With this new tag and the empty ciphertext, compute the GHASH key (the way to do this has been described in this blog post)
-
Use this GHASH key to compute authentication tags offline for arbitrary ciphertexts
-
Decryption is done by observing XML parsing errors that occur after modifying the ciphertext, those can be seen as http errors 500
https://private-user-images.githubusercontent.com/20672053/531768743-2f6e4a7e-4384-4350-b423-7ddd77aa9152.webm?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzMzMTQ3MjEsIm5iZiI6MTc3MzMxNDQyMSwicGF0aCI6Ii8yMDY3MjA1My81MzE3Njg3NDMtMmY2ZTRhN2UtNDM4NC00MzUwLWI0MjMtN2RkZDc3YWE5MTUyLndlYm0_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMxMlQxMTIwMjFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zNDRhZThlYTY5OWNmNGZmMmNmOGJhYTNkNzAwMjNiMTVhMDMxOTIzMGRkN2Y3OGU3NTI3NmFkMWE2OTgwMDFhJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.X9UVe9qpwX1YQYo34WmUI84KA0a28FKd4SGy15GEVMU
Impact
The general impact is:
XML nodes encrypted with AES-GCM can be decrypted by observing parsing differences XML nodes encrypted with AES-GCM can be modified to decrypt to an arbitrary value The GCM internal GHASH key can be recovered
In cases where the encryption key is embedded in the XML and is encrypted with the Service Provider's public key (like often done with SAML), the last two items don't have a big impact. This is because:
With the Service Provider's public key, an arbitrary ciphertext can be created with a known symmetric key The symmetric keys are generated on the fly every time the IdP creates a new SAMLResponse
In any case, secrets that are embedded in the XML, whether coming from an IdP, or from another scheme, can be decrypted.
Important: If static symmetric keys are used, as the GHASH key could have leaked, you must rotate those keys.
References
For additional information on the issue, you can refer to this blog post about the OpenSSL issue and how it can be exploited.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "simplesamlphp/xml-security"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.3.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "simplesamlphp/xml-security"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32600"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-13T20:44:21Z",
"nvd_published_at": "2026-03-16T14:19:38Z",
"severity": "HIGH"
},
"details": "### Summary\n\nXML nodes encrypted with either aes-128-gcm, aes-192-gcm, or aes-256-gcm lack validation of the authentication tag length.\nAn attacker can use this to brute-force an authentication tag, recover the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of), and decrypt the encrypted nodes.\nIt also allows to forge arbitrary ciphertexts without knowing the encryption key.\n\n### Details\n\nWhen decrypting with either aes-128-gcm, aes-192-gcm, or aes-256-gcm [here](https://github.com/robrichards/xmlseclibs/blob/2bdfd742624d739dfadbd415f00181b4a77aaf07/src/XMLSecurityKey.php#L467-L479), the $authTag is set from a substr(), but never has its length validated (it should be validated with something like strlen($authTag) == self::AUTHTAG_LENGTH).\nFor that reason, a shorter than expected data blob will allow for the $authTag to have as short a tag as only one byte (see [PHP\u0027s documentation](https://www.php.net/manual/en/function.openssl-decrypt.php#:~:text=The%20length%20of%20the%20tag%20is%20not%20checked%20by%20the%20function.%20It%20is%20the%20caller%27s%20responsibility%20to%20ensure%20that%20the%20length%20of%20the%20tag%20matches%20the%20length%20of%20the%20tag%20retrieved%20when%20openssl_encrypt()%20has%20been%20called.%20Otherwise%20the%20decryption%20may%20succeed%20if%20the%20given%20tag%20only%20matches%20the%20start%20of%20the%20proper%20tag.)).\n\nSee this example:\n\n```php\nfunction test($data) {\n $ivSize = 12;\n $tagSize = 16;\n\n $iv = substr($data, 0, $ivSize);\n $data = substr($data, $ivSize);\n $offset = 0 - $tagSize;\n $tag = substr($data, $offset);\n $ct = substr($data, 0, $offset);\n\n echo \u0027IV: \"\u0027 . $iv . \u0027\"\u0027 . PHP_EOL;\n echo \u0027Tag: \"\u0027 . $tag . \u0027\"\u0027 . PHP_EOL;\n echo \u0027CT: \"\u0027 . $ct . \u0027\"\u0027 . PHP_EOL;\n}\n\n/* Outputs:\nphp \u003e test(\u0027myNonceNoncet\u0027);\nIV: \"myNonceNonce\"\nTag: \"t\"\nCT: \"\"\nphp \u003e test(\u0027myNonceNonceta\u0027);\nIV: \"myNonceNonce\"\nTag: \"ta\"\nCT: \"\"\nphp \u003e test(\u0027myNonceNoncetag\u0027);\nIV: \"myNonceNonce\"\nTag: \"tag\"\nCT: \"\"\n*/\n```\n\nWith a legit ciphertext in hand, this is enough to recover the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of).\nWith that key, any authenticated tags can be computed offline which allows for decryption of the ciphertext and forgery of arbitrary ciphertexts.\nPoC\n\n1. Setup a server expecting XML with an encrypted assertion\n - Run this php script [poc.php](https://github.com/user-attachments/files/24426600/poc.php.txt) with php -S 127.0.0.1:8888 (taken from [this saml test case](https://github.com/robrichards/xmlseclibs/blob/69fd63080bc47a8d51bc101c30b7cb756862d1d6/tests/saml/saml-decrypt.phpt#L62))\n\n - The script expects this private key: [sp-private-key.pem.](https://github.com/user-attachments/files/24426620/sp-private-key.pem.txt)\n\n2. Create an XML document with an encrypted assertion (encrypted with aes-256-gcm)\n\nHere is the SAMLResponse used in the video below: [saml_response.txt](https://github.com/user-attachments/files/24426638/saml_response.txt)\n\nNote: The steps from 3 to 6 are implemented in this exploit script: [nonce_reuse_with_fmt_val_oracle.py](https://github.com/user-attachments/files/24426645/nonce_reuse_with_fmt_val_oracle.py).\nYou can run the script with sage -python nonce_reuse_with_fmt_val_oracle.py -s \u0027url-encoded_and_base64-encoded_samlresponse\u0027\n\n3. Take the content of the \u003cxenc:CipherValue\u003e node and apply the following modifications\n\n- Base64-decode the content\n\n- Take the first 12 bytes and save them as the nonce\n\n- Take the last 16 bytes and save them as the tag\n\n- Now brute-force the tag of an empty ciphertext\n\n - Loop through all 256 possible byte values (let\u0027s call that byte_tag_attempt)\n\n - Concatenate together the nonce and the byte_tag_attempt\n\n - Base64-encode the result\n\n - Replace the content of the \u003cxenc:CipherValue\u003e node with this result\n\n - On http errors 500, we learn that the tag is valid\n\n - Do the same for the next byte of the tag until all 16 bytes have been brute-forced\n\n4. With this new tag and the empty ciphertext, compute the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of) (the way to do this has been described in this [blog post](https://frereit.de/aes_gcm/))\n\n5. Use this [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of) to compute authentication tags offline for arbitrary ciphertexts\n\n6. Decryption is done by observing XML parsing errors that occur after modifying the ciphertext, those can be seen as http errors 500\n\nhttps://private-user-images.githubusercontent.com/20672053/531768743-2f6e4a7e-4384-4350-b423-7ddd77aa9152.webm?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzMzMTQ3MjEsIm5iZiI6MTc3MzMxNDQyMSwicGF0aCI6Ii8yMDY3MjA1My81MzE3Njg3NDMtMmY2ZTRhN2UtNDM4NC00MzUwLWI0MjMtN2RkZDc3YWE5MTUyLndlYm0_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMxMlQxMTIwMjFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zNDRhZThlYTY5OWNmNGZmMmNmOGJhYTNkNzAwMjNiMTVhMDMxOTIzMGRkN2Y3OGU3NTI3NmFkMWE2OTgwMDFhJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.X9UVe9qpwX1YQYo34WmUI84KA0a28FKd4SGy15GEVMU\n\n### Impact\n\nThe general impact is:\n\nXML nodes encrypted with AES-GCM can be decrypted by observing parsing differences\nXML nodes encrypted with AES-GCM can be modified to decrypt to an arbitrary value\nThe GCM internal [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of) can be recovered\n\nIn cases where the encryption key is embedded in the XML and is encrypted with the Service Provider\u0027s public key (like often done with SAML), the last two items don\u0027t have a big impact.\nThis is because:\n\nWith the Service Provider\u0027s public key, an arbitrary ciphertext can be created with a known symmetric key\nThe symmetric keys are generated on the fly every time the IdP creates a new SAMLResponse\n\nIn any case, secrets that are embedded in the XML, whether coming from an IdP, or from another scheme, can be decrypted.\n\nImportant: If static symmetric keys are used, as the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of) could have leaked, you must rotate those keys.\n\n### References\nFor additional information on the issue, you can refer to this [blog post](https://sideni.xyz/posts/exploiting_openssl_api/) about the OpenSSL issue and how it can be exploited.",
"id": "GHSA-r353-4845-pr5p",
"modified": "2026-03-16T22:01:35Z",
"published": "2026-03-13T20:44:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/simplesamlphp/xml-security/security/advisories/GHSA-r353-4845-pr5p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32600"
},
{
"type": "WEB",
"url": "https://github.com/simplesamlphp/xml-security/commit/cad6d57cf0a5a0b7e0cc4e4a5b18752e56eb1520"
},
{
"type": "WEB",
"url": "https://github.com/simplesamlphp/xml-security/commit/fdc12449e959c610943f9fd428e95e3832d74c25"
},
{
"type": "PACKAGE",
"url": "https://github.com/simplesamlphp/xml-security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "simplesamlphp/xml-security: Missing AES-GCM Authentication Tag Validation on Encrypted Nodes Allows for Unauthorized Decryption"
}
GHSA-R59W-M3RQ-R7X9
Vulnerability from github – Published: 2025-11-25 18:32 – Updated: 2025-11-25 18:32NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause improper validation of integrity. A successful exploit of this vulnerability might lead to information disclosure.
{
"affected": [],
"aliases": [
"CVE-2025-33193"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-25T18:15:50Z",
"severity": "MODERATE"
},
"details": "NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause improper validation of integrity. A successful exploit of this vulnerability might lead to information disclosure.",
"id": "GHSA-r59w-m3rq-r7x9",
"modified": "2025-11-25T18:32:22Z",
"published": "2025-11-25T18:32:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-33193"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5720"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-33193"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation
Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.
CAPEC-145: Checksum Spoofing
An adversary spoofs a checksum message for the purpose of making a payload appear to have a valid corresponding checksum. Checksums are used to verify message integrity. They consist of some value based on the value of the message they are protecting. Hash codes are a common checksum mechanism. Both the sender and recipient are able to compute the checksum based on the contents of the message. If the message contents change between the sender and recipient, the sender and recipient will compute different checksum values. Since the sender's checksum value is transmitted with the message, the recipient would know that a modification occurred. In checksum spoofing an adversary modifies the message body and then modifies the corresponding checksum so that the recipient's checksum calculation will match the checksum (created by the adversary) in the message. This would prevent the recipient from realizing that a change occurred.
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-75: Manipulating Writeable Configuration Files
Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.