CWE-1272 Base Stable

Sensitive Information Uncleared Before Debug/Power State Transition

This vulnerability occurs when a device changes its power mode or enters a debug state but fails to wipe sensitive data that should become inaccessible after the transition.

Definition

What is CWE-1272?

This vulnerability occurs when a device changes its power mode or enters a debug state but fails to wipe sensitive data that should become inaccessible after the transition.
Devices cycle through various operational states—like active power, low-power, sleep, hibernate, or debug modes—as part of normal function. Each state has different security boundaries controlling what data is accessible. A security flaw arises when the system moves from a more permissive state (where sensitive data is present) to a more restricted one, but neglects to purge that data first. This leaves confidential information, such as encryption keys or user data, lingering in memory or registers where it shouldn't be reachable. For developers, this means sensitive data can leak across state boundaries if not explicitly cleared before a transition. Think of it as forgetting to shred confidential documents before locking them in a safe—the safe is secure, but the contents inside still pose a risk. To prevent this, you must implement explicit cleanup routines that wipe all sensitive information from temporary storage, caches, and buffers immediately before any power-state or debug-state change is finalized.
Real-world impact

Real-world CVEs caused by CWE-1272

  • Product software does not set a flag as per TPM specifications, thereby preventing a failed authorization attempt from being recorded after a loss of power.

How attackers exploit it

Step-by-step attacker path

  1. 1

    This example shows how an attacker can take advantage of an incorrect state transition.

  2. 2

    Suppose a device is transitioning from state A to state B. During state A, it can read certain private keys from the hidden fuses that are only accessible in state A but not in state B. The device reads the keys, performs operations using those keys, then transitions to state B, where those private keys should no longer be accessible.

  3. 3

    After the transition to state B, even though the private keys are no longer accessible directly from the fuses in state B, they can be accessed indirectly by reading the memory that contains the private keys.

Vulnerable code example

Vulnerable Other

Suppose a device is transitioning from state A to state B. During state A, it can read certain private keys from the hidden fuses that are only accessible in state A but not in state B. The device reads the keys, performs operations using those keys, then transitions to state B, where those private keys should no longer be accessible.

Vulnerable Other
During the transition from A to B, the device does not scrub the memory.
Secure code example

Secure Other

After the transition to state B, even though the private keys are no longer accessible directly from the fuses in state B, they can be accessed indirectly by reading the memory that contains the private keys.

Secure Other
For transition from state A to state B, remove information which should not be available once the transition is complete.
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-1272

  • Architecture and Design / Implementation During state transitions, information not needed in the next state should be removed before the transition to the next state.
Detection signals

How to detect CWE-1272

Manual Analysis High

Write a known pattern into each sensitive location. Enter the power/debug state in question. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the pattern that was originally written, the test fails and the device needs to be fixed. Note that this test can likely be automated.

CWE-1272

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

Frequently asked questions

What is CWE-1272?

This vulnerability occurs when a device changes its power mode or enters a debug state but fails to wipe sensitive data that should become inaccessible after the transition.

How serious is CWE-1272?

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-1272?

MITRE lists the following affected platforms: VHDL, Verilog, Hardware Description Language, Not OS-Specific, Not Architecture-Specific, Not Technology-Specific.

How can I prevent CWE-1272?

During state transitions, information not needed in the next state should be removed before the transition to the next state.

How does Plexicus detect and fix CWE-1272?

Plexicus's SAST engine matches the data-flow signature for CWE-1272 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-1272?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/1272.html. You can also reference OWASP and NIST documentation for adjacent guidance.

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.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)