CWE-353, Missing Support for Integrity Check, describes a transmission protocol that has no mechanism for verifying the integrity of data in transit, such as a checksum. It is a design level gap, and it matters most to people who define or extend protocols, file formats and message schemes.
How it happens
A protocol designer focuses on function. Messages carry fields, and the receiver parses them. No one adds a checksum because the transport seems reliable, or because a lower layer already has one.
MITRE explains why that is a mistake. Leaving out checksum values means there is no way to tell whether data was corrupted in transmission, and it removes the first application level check. MITRE cites the end to end principle: integrity checks should happen at the lowest level where they can be fully implemented. A protocol's own checksum sees entire messages, where earlier layers see single packets.
The observed example is CVE-2025-32890, a mesh device that uses a cryptographic algorithm without integrity checking, which allows modification of messages.
What an attacker gains
MITRE lists two effects. Data that is parsed and used may be corrupted. And without a checksum it is impossible to determine whether changes were made after the data was sent, which also affects non-repudiation and the ability to detect that something happened.
A point worth drawing out from the CVE example: encryption alone is not integrity. A cipher that hides content may still let an attacker flip bits or alter messages unless something authenticates them.
How to find it
The record lists no detection methods. Read the protocol specification.
- Does every message type carry an integrity value covering the whole message?
- Is there authentication, not only a plain checksum, where tampering by an attacker is in scope?
- If a lower layer provides checks, does the application still rely on them for anything security relevant?
How to fix it
MITRE's guidance is two steps.
- At design time, add an appropriately sized checksum to the protocol, so received data can be validated before it is parsed and used.
- At implementation time, make sure the checksums present in the protocol design are actually calculated and added to each message before it is sent.
A caution that follows from the definition: a plain checksum catches accidents but not adversaries. If an attacker could alter messages, pair integrity with a keyed construction so they cannot simply recompute the value.
If your product consumes firmware, packages or updates, the same idea applies at a larger scale. A free scan at gold.safeguard.sh/scan can check your dependency list for known issues in the browser, with no login, and your file stays on your machine.
Quick check
Why does MITRE put the checksum in the protocol itself?
Because the protocol level check covers entire messages and is the first application level check, so it can be done more completely than at lower layers.
Is encryption enough to protect integrity?
Not by itself. The CVE-2025-32890 example involved a cryptographic algorithm without integrity checking, which allowed message modification.
Sources
- MITRE CWE-353: https://cwe.mitre.org/data/definitions/353.html
