The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.

Hardware products are typically only guaranteed to behave correctly within certain physical limits or environmental conditions. Such products cannot necessarily control the physical or external conditions to which they are subjected. However, the inability to handle such conditions can undermine a product's security. For example, an unexpected physical or environmental condition may cause the flipping of a bit that is used for an authentication decision. This unexpected condition could occur naturally or be induced artificially by an adversary.
Physical or environmental conditions of concern are:

Atmospheric characteristics: extreme temperature ranges, etc.

Interference: electromagnetic interference (EMI), radio frequency interference (RFI), etc.

Assorted light sources: white light, ultra-violet light (UV), lasers, infrared (IR), etc.

Power variances: under-voltages, over-voltages, under-current, over-current, etc.

Clock variances: glitching, overclocking, clock stretching, etc.

Component aging and degradation

Materials manipulation: focused ion beams (FIB), etc.

Exposure to radiation: x-rays, cosmic radiation, etc.

Primary

Architecture and Design
The product's design might not consider checking and handling extreme conditions.

Manufacturing
For hardware manufacturing, sub-par components might be chosen that are not able to handle the expected environmental conditions.

Confidentiality
Integrity
Availability
Varies by Context
Unexpected State
Consequences of this weakness are highly dependent on the role of affected components within the larger product.

Requirements
In requirements, be specific about expectations for how the product will perform when it exceeds physical and environmental boundary conditions, e.g., by shutting down.

Architecture and Design
Implementation
Where possible, include independent components that can detect excess environmental conditions and have the capability to shut down the product.

Architecture and Design
Implementation
Where possible, use shielding or other materials that can increase the adversary's workload and reduce the likelihood of being able to successfully trigger a security-related failure.

Below is a representative snippet of C code that is part of the secure-boot flow. A signature of the runtime-firmware image is calculated and compared against a golden value. If the signatures match, the bootloader loads runtime firmware. If there is no match, an error halt occurs. If the underlying hardware executing this code does not contain any circuitry or sensors to detect voltage or clock glitches, an attacker might launch a fault-injection attack right when the signature check is happening (at the location marked with the comment), causing a bypass of the signature-checking process.

...
if (signature_matches) // <-Glitch Here
{

load_runtime_firmware();

}
else
{

do_not_load_runtime_firmware();

}

...

After bypassing secure boot, an attacker can gain access to system assets to which the attacker should not have access.

If the underlying hardware detects a voltage or clock glitch, the information can be used to prevent the glitch from being successful.

In 2016, a security researcher, who was also a patient using a pacemaker, was on an airplane when a bit flip occurred in the pacemaker, likely due to the higher prevalence of cosmic radiation at such heights. The pacemaker was designed to account for bit flips and went into a default safe mode, which still forced the patient to go to a hospital to get it reset. The bit flip also inadvertently enabled the researcher to access the crash file, perform reverse engineering, and detect a hard-coded key. [REF-1101]

CVE-2019-17391
Lack of anti-glitch protections allows an attacker to launch a physical attack to bypass the secure boot and read protected eFuses.
https://www.cve.org/CVERecord?id=CVE-2019-17391

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

CWE Content Team
MITRE
2022-04-21
4.7
2022-04-28

CWE Content Team
MITRE
2022-06-28
updated Description, Name, Potential_Mitigations, Relationships, Type

CWE Content Team
MITRE
2022-10-13
updated References

CWE Content Team
MITRE
2023-01-31
updated Applicable_Platforms, Relationships

CWE Content Team
MITRE
2023-04-27
updated 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-09-09
4.18
2025-09-09
updated References

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

Members of the Hardware CWE Special Interest Group
2022-05-13
Provided feedback on descriptions

Improper Handling of Extreme Physical Environment Conditions