The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).

A hash function is defined as an algorithm that maps arbitrarily sized data into a fixed-sized digest (output) such that the following properties hold:

The algorithm is not invertible (also called "one-way" or "not reversible")
The algorithm is deterministic; the same input produces the same digest every time

Building on this definition, a cryptographic hash function must also ensure that a malicious actor cannot leverage the hash function to have a reasonable chance of success at determining any of the following:

the original input (preimage attack), given only the digest
another input that can produce the same digest (2nd preimage attack), given the original input
a set of two or more inputs that evaluate to the same digest (birthday attack), given the actor can arbitrarily choose the inputs to be hashed and can do so a reasonable amount of times

What is regarded as "reasonable" varies by context and threat model, but in general, "reasonable" could cover any attack that is more efficient than brute force (i.e., on average, attempting half of all possible combinations). Note that some attacks might be more efficient than brute force but are still not regarded as achievable in the real world.
Any algorithm that does not meet the above conditions will generally be considered weak for general use in hashing.
In addition to algorithmic weaknesses, a hash function can be made weak by using the hash in a security context that breaks its security guarantees. For example, using a hash function without a salt for storing passwords (that are sufficiently short) could enable an adversary to create a "rainbow table" [REF-637] to recover the password under certain conditions; this attack works against such hash functions as MD5, SHA-1, and SHA-2.

Primary

Architecture and Design
COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.

Access Control
Bypass Protection Mechanism

Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
High

Architecture and Design

Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.
Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.
Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.

High

In both of these examples, a user is logged in if their given password matches a stored password:

unsigned char *check_passwd(char *plaintext) {ctext = simple_digest("sha1",plaintext,strlen(plaintext), ... );
//Login if hash matches stored hash
if (equal(ctext, secret_password())) {login_user();}}

String plainText = new String(plainTextIn);MessageDigest encer = MessageDigest.getInstance("SHA");encer.update(plainTextIn);byte[] digest = password.digest();
//Login if hash matches stored hash
if (equal(digest,secret_password())) {login_user();}

This code relies exclusively on a password mechanism (CWE-309) using only one factor of authentication (CWE-308). If an attacker can steal or guess a user's password, they are given full access to their account. Note this code also uses SHA-1, which is a weak hash (CWE-328). It also does not use a salt (CWE-759).

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.
At least one OT product used weak hashes.

The example code below is taken from the JTAG access control mechanism of the Hack@DAC'21 buggy OpenPiton SoC [REF-1360]. Access to JTAG allows users to access sensitive information in the system. Hence, access to JTAG is controlled using cryptographic authentication of the users. In this example (see the vulnerable code source), the password checker uses HMAC-SHA256 for authentication. It takes a 512-bit secret message from the user, hashes it using HMAC, and compares its output with the expected output to determine the authenticity of the user.

...
logic [31:0] data_d, data_q
logic [512-1:0] pass_data;
...

Write: begin

...

if (pass_mode) begin

pass_data = { {60{8'h00}}, data_d};
state_d = PassChk;
pass_mode = 1'b0;

...

end

...

The vulnerable code shows an incorrect implementation of the HMAC authentication where it only uses the least significant 32 bits of the secret message for the authentication (the remaining 480 bits are hard coded as zeros). As a result, the system is susceptible to brute-force attacks where the attacker only needs to determine 32 bits of the secret message instead of 512 bits, weakening the cryptographic protocol.
To mitigate, remove the zero padding and use all 512 bits of the secret message for HMAC authentication [REF-1361].

...
logic [512-1:0] data_d, data_q
logic [512-1:0] pass_data;
...

Write: begin

...

if (pass_mode) begin

pass_data = data_d;
state_d = PassChk;
pass_mode = 1'b0;

...

end

...

CVE-2022-30320
Programmable Logic Controller (PLC) uses a protocol with a cryptographically insecure hashing algorithm for passwords.
https://www.cve.org/CVERecord?id=CVE-2022-30320

CVE-2005-4900
SHA-1 algorithm is not collision-resistant.
https://www.cve.org/CVERecord?id=CVE-2005-4900

CVE-2020-25685
DNS product uses a weak hash (CRC32 or SHA-1) of the query name, allowing attacker to forge responses by computing domain names with the same hash.
https://www.cve.org/CVERecord?id=CVE-2020-25685

CVE-2012-6707
blogging product uses MD5-based algorithm for passwords.
https://www.cve.org/CVERecord?id=CVE-2012-6707

CVE-2019-14855
forging of certificate signatures using SHA-1 collisions.
https://www.cve.org/CVERecord?id=CVE-2019-14855

CVE-2017-15999
mobile app for backup sends SHA-1 hash of password in cleartext.
https://www.cve.org/CVERecord?id=CVE-2017-15999

CVE-2006-4068
Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
https://www.cve.org/CVERecord?id=CVE-2006-4068

Reversible One-Way Hash

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.

Since CWE 4.4, various cryptography-related entries including CWE-328 have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.

PLOVER
2006-07-19
Draft 3
2006-07-19

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

CWE Content Team
MITRE
2008-10-14
updated Description

CWE Content Team
MITRE
2009-01-12
updated Description, References

CWE Content Team
MITRE
2009-10-29
updated Relationships

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

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

CWE Content Team
MITRE
2012-10-30
updated Demonstrative_Examples, Potential_Mitigations, References

CWE Content Team
MITRE
2014-02-18
updated Potential_Mitigations, References

CWE Content Team
MITRE
2014-06-23
updated Relationships

CWE Content Team
MITRE
2014-07-30
updated Relationships

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

CWE Content Team
MITRE
2018-03-27
updated Relationships

CWE Content Team
MITRE
2021-03-15
updated Demonstrative_Examples

CWE Content Team
MITRE
2021-10-28
updated Description, Maintenance_Notes, Name, Observed_Examples, References, Relationships

CWE Content Team
MITRE
2022-10-13
updated Demonstrative_Examples, Observed_Examples, References

CWE Content Team
MITRE
2023-01-31
updated Applicable_Platforms

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, References, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes, Relationships

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Demonstrative_Examples, Description, References

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated References

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

Reversible One-Way Hash