auren-research/cyber-sec huggingface dataset:
Immutable data, such as a first-stage bootloader, device identifiers, and "write-once" configuration settings are stored in writable memory that can be re-programmed or updated in the field.

Security services such as secure boot, authentication of code and data, and device attestation all require assets such as the first stage bootloader, public keys, golden hash digests, etc. which are implicitly trusted. Storing these assets in read-only memory (ROM), fuses, or one-time programmable (OTP) memory provides strong integrity guarantees and provides a root of trust for securing the rest of the system. Security is lost if assets assumed to be immutable can be modified.

Primary

Implementation
Keys, code, configuration settings, and other data should be programmed in write-once or read-only memory instead of writable memory.

Integrity
Varies by Context

Implementation
All immutable code or data should be programmed into ROM or write-once memory.

Cryptographic hash functions are commonly used to create unique fixed-length digests used to ensure the integrity of code and keys. A golden digest is stored on the device and compared to the digest computed from the data to be verified. If the digests match, the data has not been maliciously modified. If an attacker can modify the golden digest they then have the ability to store arbitrary data that passes the verification check. Hash digests used to verify public keys and early stage boot code should be immutable, with the strongest protection offered by hardware immutability.

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.

This entry is still under development and will continue to
see updates and content improvements.

As of CWE 4.3, CWE-1282 and CWE-1233 are being investigated
for potential duplication or overlap.

Nicole Fern
Cycuity (originally submitted as Tortuga Logic)
2020-05-15
4.1
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Demonstrative_Examples, Description, Modes_of_Introduction, Name

CWE Content Team
MITRE
2021-03-15
updated Maintenance_Notes

CWE Content Team
MITRE
2021-07-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2022-04-28
updated Related_Attack_Patterns

CWE Content Team
MITRE
2023-01-31
updated Related_Attack_Patterns

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

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

Assumed-Immutable Data Stored in Writable Memory
The register contents used for attestation or measurement reporting data to verify boot flow are modifiable by an adversary.

A System-on-Chip (SoC) implements secure boot or verified boot. During this boot flow, the SoC often measures the code that it authenticates. The measurement is usually done by calculating the one-way hash of the code binary and extending it to the previous hash. The hashing algorithm should be a Secure One-Way hash function. The final hash, i.e., the value obtained after the completion of the boot flow, serves as the measurement data used in reporting or in attestation. The calculated hash is often stored in registers that can later be read by the party of interest to determine tampering of the boot flow. A common weakness is that the contents in these registers are modifiable by an adversary, thus spoofing the measurement.

Primary

Architecture and Design
Such issues can be introduced during hardware architecture or design and can be identified later during Testing or System Configuration phases.

Implementation
If the access-controls which protecting the reporting registers are misconfigured during implementation, this weakness can arise.

Confidentiality
Read Memory
Read Application Data

Architecture and Design

Measurement data should be stored in registers that are read-only or otherwise have access controls that prevent modification by an untrusted agent.

The SoC extends the hash and stores the results in registers. Without protection, an adversary can write their chosen hash values to these registers. Thus, the attacker controls the reported results.

To prevent the above scenario, the registers should have one or more of the following properties:

Should be Read-Only with respect to an adversary
Cannot be extended or modifiable either directly or indirectly (using a trusted agent as proxy) by an adversary
Should have appropriate access controls or protections

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.

This entry is still in development and will continue to see updates and content improvements.

Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi
Intel Corporation
2020-04-25
4.1
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated References, Related_Attack_Patterns

CWE Content Team
MITRE
2022-04-28
updated Related_Attack_Patterns

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities
The product receives input that is expected to be of a certain type, but it does not validate or incorrectly validates that the input is actually of the expected type.

When input does not comply with the expected type, attackers could trigger unexpected errors, cause incorrect actions to take place, or exploit latent vulnerabilities that would not be possible if the input conformed with the expected type.
This weakness can appear in type-unsafe programming languages, or in programming languages that support casting or conversion of an input to another type.

Primary

Implementation

Other
Varies by Context

Implementation
Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

High

CVE-2024-37032
Large language model (LLM) management tool does not
validate the format of a digest value (CWE-1287) from a
private, untrusted model registry, enabling relative
path traversal (CWE-23), a.k.a. Probllama
https://www.cve.org/CVERecord?id=CVE-2024-37032

CVE-2008-2223
SQL injection through an ID that was supposed to be numeric.
https://www.cve.org/CVERecord?id=CVE-2008-2223

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.

This entry is still under development and will continue to see updates and content improvements.

CWE Content Team
MITRE
2020-06-24
4.1
2020-02-24

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2024-07-16
4.15
2024-07-16
updated Observed_Examples

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities
The product receives a complex input with multiple elements or fields that must be consistent with each other, but it does not validate or incorrectly validates that the input is actually consistent.

Some input data can be structured with multiple elements or fields that must be consistent with each other, e.g. a number-of-items field that is followed by the expected number of elements. When such complex inputs are inconsistent, attackers could trigger unexpected errors, cause incorrect actions to take place, or exploit latent vulnerabilities.

Primary

Implementation

Other
Varies by Context

Implementation
Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

High

CVE-2018-16733
product does not validate that the start block appears before the end block
https://www.cve.org/CVERecord?id=CVE-2018-16733

CVE-2006-3790
size field that is inconsistent with packet size leads to buffer over-read
https://www.cve.org/CVERecord?id=CVE-2006-3790

CVE-2008-4114
system crash with offset value that is inconsistent with packet size
https://www.cve.org/CVERecord?id=CVE-2008-4114

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.

This entry is still under development and will continue to see updates and content improvements.

CWE Content Team
MITRE
2020-06-24
4.1
2020-02-24

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities
The product relies on one source of data, preventing the ability to detect if an adversary has compromised a data source.

To operate successfully, a product sometimes has to implicitly trust the integrity of an information source. When information is implicitly signed, one can ensure that the data was not tampered in transit. This does not ensure that the information source was not compromised when responding to a request. By requesting information from multiple sources, one can check if all of the data is the same. If they are not, the system should report the information sources that respond with a different or minority value as potentially compromised. If there are not enough answers to provide a majority or plurality of responses, the system should report all of the sources as potentially compromised. As the seriousness of the impact of incorrect integrity increases, so should the number of independent information sources that would need to be queried.

Primary

Architecture and Design
This flaw could be introduced during the design of the application or misconfiguration at run time by only specifying a single point of validation.

Implementation
Such issues could be introduced during hardware implementation, then identified later during Testing or System Configuration phases.

Operation
This weakness could be introduced by intentionally failing all but one of the devices used to retrieve the data or by failing the devices that validate the data.

Confidentiality
Integrity
Read Application Data
Modify Application Data
Gain Privileges or Assume Identity
An attacker that may be able to execute a single Person-in-the-Middle attack can subvert a check of an external oracle (e.g. the ACME protocol check for a file on a website), and thus inject an arbitrary reply to the single perspective request to the external oracle.

Requirements
Design system to use a Practical Byzantine fault method, to request information from multiple sources to verify the data and report on potentially compromised information sources.

Implementation
Failure to use a Practical Byzantine fault method when requesting data. Lack of place to report potentially compromised information sources. Relying on non-independent information sources for integrity checking. Failure to report information sources that respond in the minority to incident response procedures.

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.

Kurt Seifried
Cloud Security Alliance
2020-04-03
4.2
2020-08-20

CWE Content Team
MITRE
2020-12-10
updated Description, 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
2025-09-09
4.18
2025-09-09
updated References

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities
The System-on-Chip (SoC) implements a Security Identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Identifiers are not correctly implemented.

Systems-On-Chip (Integrated circuits and hardware
engines) implement Security Identifiers to
differentiate/identify actions originated from various
agents. These actions could be 'read', 'write', 'program',
'reset', 'fetch', 'compute', etc. Security identifiers are
generated and assigned to every agent in the System (SoC)
that is either capable of generating an action or receiving
an action from another agent. Every agent could be assigned
a unique, Security Identifier based on its trust level or
privileges.
A broad class of flaws can exist in the Security
Identifier process, including but not limited to missing
security identifiers, improper conversion of security
identifiers, incorrect generation of security identifiers,
etc.

Primary

Architecture and Design
Such issues could be introduced during hardware architecture and design, then identified later during Testing or System Configuration phases.

Implementation
Such issues could be introduced during hardware implementation, then identified later during Testing or System Configuration phases.

Confidentiality
Integrity
Availability
Access Control
Modify Memory
Read Memory
DoS: Resource Consumption (Other)
Execute Unauthorized Code or Commands
Gain Privileges or Assume Identity
Quality Degradation
High

Architecture and Design
Security Identifier Decoders must be reviewed for design inconsistency and common weaknesses.

Implementation
Access and programming flows must be tested in pre-silicon and post-silicon testing.

Allowed-with-Review
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit

This entry is still under development and will continue to see updates and content improvements.

CWE Content Team
MITRE
2020-07-17
4.2
2020-08-20

CWE Content Team
MITRE
2021-07-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2022-04-28
updated Applicable_Platforms, Related_Attack_Patterns

CWE Content Team
MITRE
2022-06-28
updated Applicable_Platforms

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities
Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers.

Primary

Architecture and Design

Implementation

Access Control
Gain Privileges or Assume Identity

Implementation
Credentials stored in configuration files should be encrypted, Use standard APIs and industry accepted algorithms to encrypt the credentials stored in configuration files.

The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database, but the pair is stored in plaintext.

...<connectionStrings><add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" /></connectionStrings>...

Username and password information should not be included in a configuration file or a properties file in plaintext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information.

ASP.NET Misconfiguration: Password in Configuration File

Allowed
This CWE entry is at the Variant 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.

7 Pernicious Kingdoms
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated References, Demonstrative_Example, Potential_Mitigations, Time_of_Introduction

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

CWE Content Team
MITRE
2009-07-27
updated Demonstrative_Examples

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated Relationships

CWE Content Team
MITRE
2012-10-30
updated Demonstrative_Examples

CWE Content Team
MITRE
2013-02-21
updated Potential_Mitigations

CWE Content Team
MITRE
2014-07-30
updated Demonstrative_Examples, Relationships

CWE Content Team
MITRE
2017-11-08
updated Relationships

CWE Content Team
MITRE
2018-03-27
updated Demonstrative_Examples

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

CWE Content Team
MITRE
2021-03-15
updated Demonstrative_Examples

CWE Content Team
MITRE
2021-10-28
updated Relationships

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

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Relationships, Weakness_Ordinalities
The product's data removal process does not completely delete all data and potentially sensitive information within hardware components.

Physical properties of hardware devices, such as remanence of magnetic media, residual charge of ROMs/RAMs, or screen burn-in may still retain sensitive data after a data removal process has taken place and power is removed.
Recovering data after erasure or overwriting is possible due to a phenomenon called data remanence. For example, if the same value is written repeatedly to a memory location, the corresponding memory cells can become physically altered to a degree such that even after the original data is erased that data can still be recovered through physical characterization of the memory cells.

Primary

Resultant

Implementation

Confidentiality
Read Memory
Read Application Data

Architecture and Design
Apply blinding or masking techniques to implementations of cryptographic algorithms.

Implementation
Alter the method of erasure, add protection of media, or destroy the media to protect the data.

CVE-2019-8575
Firmware Data Deletion Vulnerability in which a base station factory reset might not delete all user information. The impact of this enables a new owner of a used device that has been "factory-default reset" with a vulnerable firmware version can still retrieve, at least, the previous owner's wireless network name, and the previous owner's wireless security (such as WPA2) key. This issue was addressed with improved, data deletion.
https://www.cve.org/CVERecord?id=CVE-2019-8575

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.

This entry is still under development and will continue to see updates and content improvements.

Nicole Fern
Cycuity (originally submitted as Tortuga Logic)
2020-05-29
4.2
2020-08-20

CWE Content Team
MITRE
2020-12-10
updated Relationships

CWE Content Team
MITRE
2021-07-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2021-10-28
updated Description

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

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2023-10-26
updated Observed_Examples

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities
This entry has been deprecated because it was a duplicate of CWE-170. All content has been transferred to CWE-170.

Prohibited
This CWE has been deprecated.
See description and name for possible suggestions of other CWEs to consider.

CWE Community
2006-07-19
Draft 3
2006-07-19
Submitted by members of the CWE community to extend early CWE versions

CWE Content Team
MITRE
2008-09-08
updated Applicable_Platforms, Causal_Nature, Common_Consequences, Description, Likelihood_of_Exploit, Name, Relationships, Type

CWE Content Team
MITRE
2009-10-29
updated Relationships

CWE Content Team
MITRE
2021-07-20
updated Name

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

Miscalculated Null Termination
DEPRECATED (Duplicate): Miscalculated Null Termination