Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.
CWE-1314 Base Draft
Missing Write Protection for Parametric Data Values
This vulnerability occurs when a hardware device fails to protect the scaling parameters used to convert raw sensor readings. Untrusted software can alter these conversion factors, making dangerous…
Definition
What is CWE-1314?
This vulnerability occurs when a hardware device fails to protect the scaling parameters used to convert raw sensor readings. Untrusted software can alter these conversion factors, making dangerous conditions appear safe and potentially leading to hardware damage or system failure.
Hardware systems use sensors to monitor critical limits for temperature, power, voltage, and other operational parameters. Trusted firmware like the BIOS typically sets and protects these safety thresholds. However, the raw data from sensors often needs to be scaled using conversion parameters to produce meaningful values (like degrees Celsius or volts). The core issue is that while the final safety limits are often locked down, these underlying scaling factors are left exposed and writable.
By manipulating these unprotected scaling parameters, an attacker can distort the sensor's reported values. For example, they could make a dangerously high temperature appear within a normal range. This bypasses the intended safety checks, allowing the system to operate outside its safe design limits, which can cause physical damage to components or lead to a complete operational failure.
Real-world impact
Real-world CVEs caused by CWE-1314
-
Kernel can inject faults in computations during the execution of TrustZone leading to information disclosure in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon IoT, Snapdragon Mobile, Snapdragon Voice and Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking.
How attackers exploit it
Step-by-step attacker path
- 1
Identify a code path that handles untrusted input without validation.
- 2
Craft a payload that exercises the unsafe behavior — injection, traversal, overflow, or logic abuse.
- 3
Deliver the payload through a normal request and observe the application's reaction.
- 4
Iterate until the response leaks data, executes attacker code, or escalates privileges.
Vulnerable code example
Vulnerable Other
Malicious software executes instructions to increase power consumption to the highest possible level while causing the clock frequency to increase to its maximum value. Such a program executing for an extended period of time would likely overheat the device, possibly resulting in permanent damage to the device. A ring, oscillator-based temperature sensor will generally report the sensed value as oscillator frequency rather than degrees centigrade. The temperature sensor will have calibration values that are used to convert the detected frequency into the corresponding temperature in degrees centigrade. Consider a SoC design where the critical maximum temperature limit is set in fuse values to 100C and is not modifiable by software. If the scaled thermal sensor output equals or exceeds this limit, the system is commanded to shut itself down. The thermal sensor calibration values are programmable through registers that are exposed to system software. These registers allow software to affect the converted temperature output such that the output will never exceed the maximum temperature limit.
The sensor frequency value is scaled by applying the function:
```
Sensed Temp = a + b * Sensor Freq
```
where a and b are the programmable calibration data coefficients. Software sets a and b to zero ensuring the sensed temperature is always zero. Secure code example
Secure Other
This weakness may be addressed by preventing access to a and b.
The sensor frequency value is scaled by applying the function:
```
Sensed Temp = a + b * Sensor Freq
```
where a and b are the programmable calibration data coefficients. Untrusted software is prevented from changing the values of either a or b, preventing this method of manipulating the temperature. What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-1314
- Architecture and Design Access controls for sensor blocks should ensure that only trusted software is allowed to change threshold limits and sensor parametric data.
Detection signals
How to detect CWE-1314
Run dynamic application security testing against the live endpoint.
Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.
Code review: flag any new code that handles input from this surface without using the validated framework helpers.
CWE-1314
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Frequently asked questions What is CWE-1314?
How serious is CWE-1314?
What languages or platforms are affected by CWE-1314?
How can I prevent CWE-1314?
How does Plexicus detect and fix CWE-1314?
Where can I learn more about CWE-1314?
Frequently asked questions
What is CWE-1314?
This vulnerability occurs when a hardware device fails to protect the scaling parameters used to convert raw sensor readings. Untrusted software can alter these conversion factors, making dangerous conditions appear safe and potentially leading to hardware damage or system failure.
How serious is CWE-1314?
MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.
What languages or platforms are affected by CWE-1314?
MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Sensor Hardware.
How can I prevent CWE-1314?
Access controls for sensor blocks should ensure that only trusted software is allowed to change threshold limits and sensor parametric data.
How does Plexicus detect and fix CWE-1314?
Plexicus's SAST engine matches the data-flow signature for CWE-1314 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-1314?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/1314.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-1314
CWE-862 Parent
Missing Authorization
This vulnerability occurs when an application fails to verify whether a user has permission to access specific data or execute certain…
CWE-425 Sibling
Direct Request ('Forced Browsing')
This vulnerability occurs when a web application fails to verify user permissions for every protected page, file, or API endpoint,…
CWE-638 Sibling
Not Using Complete Mediation
This vulnerability occurs when software fails to verify access permissions every single time a user or process tries to use a resource.…
CWE-939 Sibling
Improper Authorization in Handler for Custom URL Scheme
This vulnerability occurs when an app implements a custom URL scheme handler but fails to properly verify which other apps or sources are…
CWE-1299 Peer
Missing Protection Mechanism for Alternate Hardware Interface
This vulnerability occurs when a hardware component's security controls only protect the primary access path, leaving alternate interfaces…
Ready to validate what matters?
Ready to validate what matters?
Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.