CWE-1420 Base Incomplete

Exposure of Sensitive Information during Transient Execution

Transient execution vulnerabilities occur when a processor speculatively runs operations that don't officially commit, potentially leaking sensitive data through covert side channels like cache…

Definition

What is CWE-1420?

Transient execution vulnerabilities occur when a processor speculatively runs operations that don't officially commit, potentially leaking sensitive data through covert side channels like cache timing.
Transient execution happens when a CPU runs instructions based on predictions (like branch outcomes) or before handling events (like exceptions), then discards the results without saving them to its official state. However, these temporary operations still leave traces in the processor's microarchitectural components, such as the cache. An attacker can detect these traces using precise timing or power analysis, creating a covert channel to infer confidential data that was accessed during that speculative window. Attackers exploit this in two main ways. First, they can craft their own code to trigger transient execution and leak data within their own processor context, sometimes bypassing software sandboxes. More severe variants can cross hardware-enforced boundaries like privilege rings. Second, attackers can search for vulnerable code patterns in victim software—like a bounds-check bypass—and manipulate branch predictions to cause transient out-of-bounds accesses. By then analyzing side-channel leaks, they can infer sensitive information from the victim's memory space.
Real-world impact

Real-world CVEs caused by CWE-1420

  • CVE-2017-5753

    Microarchitectural conditional branch predictors may allow operations to execute transiently after a misprediction, potentially exposing data over a covert channel.

  • CVE-2021-0089

    A machine clear triggered by self-modifying code may allow incorrect operations to execute transiently, potentially exposing data over a covert channel.

  • CVE-2022-0002

    Microarchitectural indirect branch predictors may allow incorrect operations to execute transiently after a misprediction, potentially exposing data over a covert channel.

How attackers exploit it

Step-by-step attacker path

  1. 1

    Secure programs perform bounds checking before accessing an array if the source of the array index is provided by an untrusted source such as user input. In the code below, data from array1 will not be accessed if x is out of bounds. The following code snippet is from [REF-1415]:

  2. 2

    However, if this code executes on a processor that performs conditional branch prediction the outcome of the if statement could be mis-predicted and the access on the next line will occur with a value of x that can point to an out-of-bounds location (within the program's memory). Even though the processor does not commit the architectural effects of the mis-predicted branch, the memory accesses alter data cache state, which is not rolled back after the branch is resolved. The cache state can reveal array1[x] thereby providing a mechanism to recover the data value located at address array1 + x.

  3. 3

    Some managed runtimes or just-in-time (JIT) compilers may overwrite recently executed code with new code. When the instruction pointer enters the new code, the processor may inadvertently execute the stale code that had been overwritten. This can happen, for instance, when the processor issues a store that overwrites a sequence of code, but the processor fetches and executes the (stale) code before the store updates memory. Similar to the first example, the processor does not commit the stale code's architectural effects, though microarchitectural side effects can persist. Hence, confidential information accessed or used by the stale code may be inferred via an observable discrepancy in a covert channel. This vulnerability is described in more detail in [REF-1427].

Vulnerable code example

Vulnerable C

Secure programs perform bounds checking before accessing an array if the source of the array index is provided by an untrusted source such as user input. In the code below, data from array1 will not be accessed if x is out of bounds. The following code snippet is from [REF-1415]:

Vulnerable C 
if (x < array1_size)
  	y = array2[array1[x] * 4096];
Secure code example

Secure pseudo

Secure pseudo 
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}
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-1420

  • Architecture and Design The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
  • Requirements Processor designers may expose instructions or other architectural features that allow software to mitigate the effects of transient execution, but without disabling predictors. These features may also help to limit opportunities for data exposure.
  • Requirements Processor designers may expose registers (for example, control registers or model-specific registers) that allow privileged and/or user software to disable specific predictors or other hardware features that can cause confidential data to be exposed during transient execution.
  • Requirements Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.
  • Build and Compilation Isolate sandboxes or managed runtimes in separate address spaces (separate processes). For examples, see [REF-1421].
  • Build and Compilation Include serialization instructions (for example, LFENCE) that prevent processor events or mis-predictions prior to the serialization instruction from causing transient execution after the serialization instruction. For some weaknesses, a serialization instruction can also prevent a processor event or a mis-prediction from occurring after the serialization instruction (for example, CVE-2018-3639 can allow a processor to predict that a load will not depend on an older store; a serialization instruction between the store and the load may allow the store to update memory and prevent the prediction from happening at all).
  • Build and Compilation Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions.
  • Build and Compilation If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated, and instead generate an alternate sequence of instructions that is not affected by the weakness. One prominent example of this mitigation is retpoline ([REF-1414]).
Detection signals

How to detect CWE-1420

Manual Analysis Moderate

This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state. Academic researchers have demonstrated that new hardware weaknesses can be discovered by exhaustively analyzing a processor's machine clear (or nuke) conditions ([REF-1427]).

Fuzzing Opportunistic

Academic researchers have demonstrated that this weakness can be detected in hardware using software fuzzing tools that treat the underlying hardware as a black box ([REF-1428]).

Fuzzing Opportunistic

Academic researchers have demonstrated that this weakness can be detected in software using software fuzzing tools ([REF-1429]).

Automated Static Analysis Limited

A variety of automated static analysis tools can identify potentially exploitable code sequences in software. These tools may perform the analysis on source code, on binary code, or on an intermediate code representation (for example, during compilation).

Automated Analysis High

Software vendors can release tools that detect presence of known weaknesses on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors: $ cat /proc/cpuinfo | grep bugs | head -n 1 bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed

Plexicus auto-fix

Plexicus auto-detects CWE-1420 and opens a fix PR in under 60 seconds.

Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.

Get a demo Try Plexicus free
Frequently asked questions

Frequently asked questions

What is CWE-1420?

Transient execution vulnerabilities occur when a processor speculatively runs operations that don't officially commit, potentially leaking sensitive data through covert side channels like cache timing.

How serious is CWE-1420?

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

MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Not Technology-Specific.

How can I prevent CWE-1420?

The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels. Processor designers may expose instructions or other architectural features that allow software to mitigate the effects of transient execution, but without disabling predictors. These features may also help to limit opportunities for data exposure.

How does Plexicus detect and fix CWE-1420?

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

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

Related weaknesses

Weaknesses related to CWE-1420

CWE-669 Parent

Incorrect Resource Transfer Between Spheres

This vulnerability occurs when an application incorrectly moves or shares a resource (like data, permissions, or functionality) between…

CWE-212 Sibling

Improper Removal of Sensitive Information Before Storage or Transfer

This vulnerability occurs when an application stores or transmits a resource containing sensitive data without properly cleaning it first,…

CWE-243 Sibling

Creation of chroot Jail Without Changing Working Directory

This vulnerability occurs when a program creates a chroot jail but fails to change its current working directory afterward. Because the…

CWE-434 Sibling

Unrestricted Upload of File with Dangerous Type

This vulnerability occurs when an application accepts file uploads without properly restricting the file types, allowing attackers to…

CWE-494 Sibling

Download of Code Without Integrity Check

This vulnerability occurs when an application fetches and runs code from an external source—like a remote server or CDN—without properly…

CWE-565 Sibling

Reliance on Cookies without Validation and Integrity Checking

This vulnerability occurs when an application uses cookies to make security decisions—like granting access or changing settings—but fails…

CWE-829 Sibling

Inclusion of Functionality from Untrusted Control Sphere

This weakness occurs when an application integrates executable code, like a library or plugin, from a source it does not fully control or…

CWE-1421 Child

Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution

This vulnerability occurs when a processor's speculative execution (transient operations) can temporarily access restricted data from…

CWE-1422 Child

Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution

This vulnerability occurs when a CPU incorrectly forwards outdated or incorrect data during speculative execution. This allows sensitive…

Resources

Further reading

Ready when you are

Don't Let Security
Weigh You Down.

Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.