CWE-1272 Base Estable

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.

Definición

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.
Impacto en el mundo real

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.

Cómo lo explotan los atacantes

Ruta del atacante paso a paso

  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.

Ejemplo de código vulnerable

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.
Ejemplo de código seguro

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.

Seguro 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.
Lista de prevención

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.
Señales de detección

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.

Auto-corrección de Plexicus

Plexicus detecta automáticamente CWE-1272 y abre un PR de corrección en menos de 60 segundos.

Codex Remedium escanea cada commit, identifica esta debilidad concreta y entrega un pull request listo para revisión con el parche. Sin tickets. Sin traspasos.

Preguntas frecuentes

Frequently asked questions

¿Qué es 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.

¿Qué gravedad tiene CWE-1272?

MITRE no ha publicado una calificación de probabilidad de explotación para esta debilidad. Trátala como de impacto medio hasta que tu modelo de amenazas demuestre lo contrario.

¿Qué lenguajes o plataformas se ven afectados por CWE-1272?

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

¿Cómo puedo prevenir CWE-1272?

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

¿Cómo detecta y corrige Plexicus CWE-1272?

El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-1272 en cada commit. Cuando hay coincidencia, nuestro agente Codex Remedium abre un PR de corrección con el código corregido, las pruebas y un resumen de una línea para el revisor.

¿Dónde puedo aprender más sobre CWE-1272?

MITRE publica la definición canónica en https://cwe.mitre.org/data/definitions/1272.html. También puedes consultar la documentación de OWASP y NIST para guías relacionadas.

Listo cuando tú lo estés

Deja de pagar por desarrollador.
Empieza a cerrar el bucle.

Plexicus es el ASPM nativo de IA que escanea, filtra, corrige, pentestea y explica — de forma autónoma. Desarrolladores ilimitados, repos ilimitados, acciones de IA de uso justo. Nivel gratuito real, €269/mo anual cuando estés listo.