The product uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.
If integrity check values or "checksums" are omitted from a protocol, there is no way of determining if data has been corrupted in transmission. The lack of checksum functionality in a protocol removes the first application-level check of data that can be used. The end-to-end philosophy of checks states that integrity checks should be performed at the lowest level that they can be completely implemented. Excluding further sanity checks and input validation performed by applications, the protocol's checksum is the most important level of checksum, since it can be performed more completely than at any previous level and takes into account entire messages, as opposed to single packets.

Primary

Architecture and Design
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.

Implementation

Medium

Integrity
Other
Other
Data that is parsed and used may be corrupted.

Non-Repudiation
Other
Hide Activities
Other
Without a checksum it is impossible to determine if any changes have been made to the data after it was sent.

Architecture and Design
Add an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used.

Implementation
Ensure that the checksums present in the protocol design are properly implemented and added to each message before it is sent.

In this example, a request packet is received, and privileged information is sent to the requester:

while(true) {DatagramPacket rp = new DatagramPacket(rData,rData.length);outSock.receive(rp);InetAddress IPAddress = rp.getAddress();int port = rp.getPort();out = secret.getBytes();DatagramPacket sp =new DatagramPacket(out, out.length, IPAddress, port);outSock.send(sp);}

The response containing secret data has no integrity check associated with it, allowing an attacker to alter the message without detection.

Failure to add integrity check value

Part 2-4
Req SP.03.03 RE(1)

Part 2-4
Req SP.04.02 RE(1)

Part 2-4
Req SP.11.06 RE(2)

Part 3-3
Req SR 3.1

Part 4-1
Req SD-1

Part 4-2
Req CR 3.1

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

CLASP
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings

CWE Content Team
MITRE
2009-10-29
updated Description, Other_Notes

CWE Content Team
MITRE
2010-12-13
updated Description, Name

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences, Demonstrative_Examples

CWE Content Team
MITRE
2012-05-11
updated References, Relationships

CWE Content Team
MITRE
2012-10-30
updated Demonstrative_Examples

CWE Content Team
MITRE
2014-07-30
updated Relationships

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms, Modes_of_Introduction, Relationships

CWE Content Team
MITRE
2019-06-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2020-02-24
updated References, Relationships

CWE Content Team
MITRE
2021-07-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2021-10-28
updated Relationships

CWE Content Team
MITRE
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Relationships, Weakness_Ordinalities

"Mapping CWE to 62443" Sub-Working Group
CWE-CAPEC ICS/OT SIG
2023-04-25
Suggested mappings to ISA/IEC 62443.

Failure to Add Integrity Check Value