CWE-354
Improper Validation of Integrity Check Value
BaseDraftLikelihood: Medium
Description
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.
Improper validation of checksums before use results in an unnecessary risk that can easily be mitigated. The protocol specification describes the algorithm used for calculating the checksum. It is then a simple matter of implementing the calculation and verifying that the calculated checksum and the received checksum match. Improper verification of the calculated checksum and the received checksum can lead to far greater consequences.
Hierarchy (View 1000)
Related attack patterns (CAPEC)
CAPEC-145 · CAPEC-463 · CAPEC-75
CVEs mapped to this weakness (21)
page 1 of 2| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2026-33026 | Cri | 0.59 | 9.1 | 0.00 | Mar 30, 2026 | Nginx UI is a web user interface for the Nginx web server. Prior to version 2.3.4, the nginx-ui backup restore mechanism allows attackers to tamper with encrypted backup archives and inject malicious configuration during restoration. This issue has been patched in version 2.3.4. | |
| CVE-2026-26928 | Hig | 0.57 | — | 0.00 | Apr 2, 2026 | SzafirHost downloads necessary files in the context of the initiating web page. When called, SzafirHost updates its dynamic library. JAR files are correctly verified based on a list of trusted file hashes, and if a file was not on that list, it was checked to see if it had been digitally signed by the vendor. The application doesn't verify hash or vendor's digital signature of uploaded DLL, SO, JNILIB or DYLIB file. The attacker can provide malicious file which will be saved in users /temp folder and executed by the application. This issue was fixed in version 1.1.0. | |
| CVE-2026-5479 | Hig | 0.53 | 8.1 | 0.00 | Apr 10, 2026 | In wolfSSL's EVP layer, the ChaCha20-Poly1305 AEAD decryption path in wolfSSL_EVP_CipherFinal (and related EVP cipher finalization functions) fails to verify the authentication tag before returning plaintext to the caller. When an application uses the EVP API to perform ChaCha20-Poly1305 decryption, the implementation computes or accepts the tag but does not compare it against the expected value. | |
| CVE-2025-54887 | Cri | 0.52 | 9.1 | 0.00 | Aug 8, 2025 | jwe is a Ruby implementation of the RFC 7516 JSON Web Encryption (JWE) standard. In versions 1.1.0 and below, authentication tags of encrypted JWEs can be brute forced, which may result in loss of confidentiality for those JWEs and provide ways to craft arbitrary JWEs. This puts users at risk because JWEs can be modified to decrypt to an arbitrary value, decrypted by observing parsing differences and the GCM internal GHASH key can be recovered. Users are affected by this vulnerability even if they do not use an AES-GCM encryption algorithm for their JWEs. As the GHASH key may have been leaked, users must rotate the encryption keys after upgrading. This issue is fixed in version 1.1.1. | |
| CVE-2026-32105 | Hig | 0.50 | 7.7 | 0.00 | Apr 17, 2026 | xrdp is an open source RDP server. In versions through 0.10.5, xrdp does not implement verification for the Message Authentication Code (MAC) signature of encrypted RDP packets when using the "Classic RDP Security" layer. While the sender correctly generates signatures, the receiving logic lacks the necessary implementation to validate the 8-byte integrity signature, causing it to be silently ignored. An unauthenticated attacker with man-in-the-middle (MITM) capabilities can exploit this missing check to modify encrypted traffic in transit without detection. It does not affect connections where the TLS security layer is enforced. This issue has been fixed in version 0.10.6. If users are unable to immediately upgrade, they should configure xrdp.ini to enforce TLS security (security_layer=tls) to ensure end-to-end integrity. | |
| CVE-2024-48930 | Hig | 0.50 | — | 0.00 | Oct 21, 2024 | secp256k1-node is a Node.js binding for an Optimized C library for EC operations on curve secp256k1. In `elliptic`-based version, `loadUncompressedPublicKey` has a check that the public key is on the curve. Prior to versions 5.0.1, 4.0.4, and 3.8.1, however, `loadCompressedPublicKey` is missing that check. That allows the attacker to use public keys on low-cardinality curves to extract enough information to fully restore the private key from as little as 11 ECDH sessions, and very cheaply on compute power. Other operations on public keys are also affected, including e.g. `publicKeyVerify()` incorrectly returning `true` on those invalid keys, and e.g. `publicKeyTweakMul()` also returning predictable outcomes allowing to restore the tweak. Versions 5.0.1, 4.0.4, and 3.8.1 contain a fix for the issue. | |
| CVE-2024-32883 | Hig | 0.50 | 7.7 | 0.00 | Apr 26, 2024 | MCUboot is a secure bootloader for 32-bits microcontrollers. MCUboot uses a TLV (tag-length-value) structure to represent the meta data associated with an image. The TLVs themselves are divided into two sections, a protected and an unprotected section. The protected TLV entries are included as part of the image signature to avoid tampering. However, the code does not distinguish which TLV entries should be protected or not, so it is possible for an attacker to add unprotected TLV entries that should be protected. Currently, the primary protected TLV entries should be the dependency indication, and the boot record. An injected dependency value would primarily result in an otherwise acceptable image being rejected. A boot record injection could allow fields in a later attestation record to include data not intended, which could cause an image to appear to have properties that it should not have. As a workaround, disable the boot record functionality. | |
| CVE-2026-40323 | Hig | 0.49 | 7.5 | 0.00 | Apr 18, 2026 | SP1 is a zero‑knowledge virtual machine that proves the correct execution of programs compiled for the RISC-V architecture. In versions 6.0.0 through 6.0.2, a soundness vulnerability in the SP1 V6 recursive shard verifier allows a malicious prover to construct a recursive proof from a shard proof that the native verifier would reject. Version 6.1.0 fixes the issue. | |
| CVE-2024-3727 | Hig | 0.47 | 8.3 | 0.01 | May 14, 2024 | A flaw was found in the github.com/containers/image library. This flaw allows attackers to trigger unexpected authenticated registry accesses on behalf of a victim user, causing resource exhaustion, local path traversal, and other attacks. | |
| CVE-2026-28402 | Hig | 0.46 | 7.1 | 0.00 | Feb 27, 2026 | nimiq/core-rs-albatross is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.2.2, a malicious or compromised validator that is elected as proposer can publish a macro block proposal where `header.body_root` does not match the actual macro body hash. The proposal can pass proposal verification because the macro proposal verification path validates the header but does not validate the binding `body_root == hash(body)`; later code expects this binding and may panic on mismatch, crashing validators. Note that the impact is only for validator nodes. The patch for this vulnerability is formally released as part of v1.2.2. The patch adds the corresponding body root verification in the proposal checks. No known workarounds are available. | |
| CVE-2024-7402 | Hig | 0.46 | — | 0.00 | Aug 14, 2025 | Netskope has identified a potential gap in its agent (Netskope Client) in which a malicious insider can potentially tamper the Netskope Client configuration by performing MITM (Man-in-the-Middle) activity on the Netskope Client communication channel. A successful exploitation would require administrative privileges on the machine, and could result in temporarily altering the configuration of Netskope Client or permanently disabling or removing the agent from the machine. | |
| CVE-2024-46992 | Hig | 0.44 | 7.8 | 0.00 | Jul 1, 2025 | Electron is an open source framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. From versions 30.0.0-alpha.1 to before 30.0.5 and 31.0.0-alpha.1 to before 31.0.0-beta.1, Electron is vulnerable to an ASAR Integrity bypass. This only impacts apps that have the embeddedAsarIntegrityValidation and onlyLoadAppFromAsar fuses enabled. Apps without these fuses enabled are not impacted. This issue is specific to Windows, apps using these fuses on macOS are not impacted. Specifically this issue can only be exploited if the app is launched from a filesystem the attacker has write access too. i.e. the ability to edit files inside the .app bundle on macOS which these fuses are supposed to protect against. This issue has been patched in versions 30.0.5 and 31.0.0-beta.1. There are no workarounds for this issue. | |
| CVE-2024-47935 | Med | 0.44 | 6.7 | 0.00 | Feb 17, 2025 | Improper Validation of Integrity Check Value vulnerability in TXOne Networks StellarProtect (Legacy Mode), StellarEnforce, and Safe Lock allows an attacker to escalate their privileges in the victim’s device. The attacker needs to hijack the DLL file in advance. This issue affects StellarProtect (Legacy Mode): before 3.2; StellarEnforce: before 3.2; Safe Lock: from 3.0.0 before 3.1.1076. *Note: StellarProtect (Legacy Mode) is the new name for StellarEnforce, they are the same product. | |
| CVE-2024-34714 | Hig | 0.42 | 7.6 | 0.00 | May 14, 2024 | The Hoppscotch Browser Extension is a browser extension for Hoppscotch, a community-driven end-to-end open-source API development ecosystem. Due to an oversight during a change made to the extension in the commit d4e8e4830326f46ba17acd1307977ecd32a85b58, a critical check for the origin list was missed and allowed for messages to be sent to the extension which the extension gladly processed and responded back with the results of, while this wasn't supposed to happen and be blocked by the origin not being present in the origin list. This vulnerability exposes Hoppscotch Extension users to sites which call into Hoppscotch Extension APIs internally. This fundamentally allows any site running on the browser with the extension installed to bypass CORS restrictions if the user is running extensions with the given version. This security hole was patched in the commit 7e364b928ab722dc682d0fcad713a96cc38477d6 which was released along with the extension version `0.35`. As a workaround, Chrome users can use the Extensions Settings to disable the extension access to only the origins that you want. Firefox doesn't have an alternative to upgrading to a fixed version. | |
| CVE-2020-26141 | Med | 0.42 | 6.5 | 0.00 | May 11, 2021 | An issue was discovered in the ALFA Windows 10 driver 6.1316.1209 for AWUS036H. The Wi-Fi implementation does not verify the Message Integrity Check (authenticity) of fragmented TKIP frames. An adversary can abuse this to inject and possibly decrypt packets in WPA or WPA2 networks that support the TKIP data-confidentiality protocol. | |
| CVE-2025-24148 | Med | 0.36 | 5.5 | 0.00 | Mar 31, 2025 | This issue was addressed with improved handling of executable types. This issue is fixed in macOS Sequoia 15.4, macOS Sonoma 14.7.5, macOS Ventura 13.7.5. A malicious JAR file may bypass Gatekeeper checks. | |
| CVE-2026-5504 | Med | 0.34 | 5.3 | 0.00 | Apr 9, 2026 | A 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. | |
| CVE-2026-32148 | Med | 0.31 | 5.9 | 0.00 | Apr 30, 2026 | Insufficient Verification of Data Authenticity vulnerability in hexpm hex (Hex.RemoteConverger module) allows dependency integrity bypass via unverified lockfile checksums. Hex stores checksums for dependencies in the mix.lock file to ensure reproducible and integrity-checked builds. However, Hex.RemoteConverger.verify_resolved/2 never executes checksum verification because the lock data returned by Hex.Utils.lock/1 uses string-based dependency names, while the verification logic compares against atom-based names. This type mismatch causes the verification code path to be silently skipped. Checksums are still validated when packages are initially downloaded from the registry, but mismatches between the lockfile and resolved dependencies are not detected. An attacker who can influence cached packages (e.g., via local cache poisoning or a compromised registry) can provide modified dependency contents that will be accepted without detection. The mix.lock file is silently rewritten with the checksum values from the registry, erasing evidence of tampering. This issue affects hex: from 0.16.0 before 2.4.2. | |
| CVE-2025-4418 | Med | 0.29 | 4.4 | 0.00 | Jun 12, 2025 | An improper validation of integrity check value vulnerability exists in AVEVA PI Connector for CygNet Versions 1.6.14 and prior that, if exploited, could allow a miscreant with elevated privileges to modify PI Connector for CygNet local data files (cache and buffers) in a way that causes the connector service to become unresponsive. | |
| CVE-2023-50738 | Med | 0.28 | 4.3 | 0.00 | Jan 17, 2025 | A new feature to prevent Firmware downgrades was recently added to some Lexmark products. A method to override this downgrade protection has been identified. |