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.

Primary

Architecture and Design

Implementation
REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Medium

Integrity
Other
Modify Application Data
Other
Integrity checks usually use a secret key that helps authenticate the data origin. Skipping integrity checking generally opens up the possibility that new data from an invalid source can be injected.

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

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

Implementation
Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.

The following example demonstrates the weakness.

sd = socket(AF_INET, SOCK_DGRAM, 0); serv.sin_family = AF_INET;serv.sin_addr.s_addr = htonl(INADDR_ANY);servr.sin_port = htons(1008);bind(sd, (struct sockaddr *) & serv, sizeof(serv));while (1) {

memset(msg, 0x0, MAX_MSG);clilen = sizeof(cli);if (inet_ntoa(cli.sin_addr)==...) n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen);
}

while(true) {DatagramPacket packet = new DatagramPacket(data,data.length,IPAddress, port);socket.send(sendPacket);}

Part 3-3
Req SR 3.1

Failure to check integrity check value

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-03-10
updated Description, Name, Relationships

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

CWE Content Team
MITRE
2010-12-13
updated Description

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

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

CWE Content Team
MITRE
2014-07-30
updated Relationships

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

CWE Content Team
MITRE
2019-06-20
updated Related_Attack_Patterns, Relationships

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

CWE Content Team
MITRE
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Taxonomy_Mappings

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

participants in the CWE ICS/OT SIG 62443 Mapping Fall Workshop
2023-11-14
4.14
2024-02-29
Contributed or reviewed taxonomy mappings for ISA/IEC 62443

Failure to Check Integrity Check Value