CWE-1420: Exposure of Sensitive Information during Transient Execution

Définition

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.

Impact réel

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.

Comment les attaquants l'exploitent

Parcours de l'attaquant étape par étape

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
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
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].

Exemple de code vulnérable

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]:

Vulnérable C

if (x < array1_size)
  	y = array2[array1[x] * 4096];

Exemple de code sécurisé

Secure pseudo

Sécurisé 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.

Liste de contrôle de prévention

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]).

Signaux de détection

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

CWE-1420

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.

Request AI Swarm Pentest

Questions fréquentes

Frequently asked questions

Qu'est-ce que 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.

Quelle est la gravité de CWE-1420 ?

MITRE n'a pas publié de note de probabilité d'exploitation pour cette faiblesse. Traitez-la comme un impact moyen jusqu'à ce que votre modèle de menace prouve le contraire.

Quels langages ou plateformes sont affectés par CWE-1420 ?

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

Comment puis-je prévenir 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.

Comment Plexicus détecte et corrige CWE-1420 ?

Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-1420 à chaque commit. Lorsqu'une correspondance est trouvée, notre agent Codex Remedium ouvre une PR de correction avec le code corrigé, les tests et un résumé d'une ligne pour le relecteur.

Où puis-je en savoir plus sur CWE-1420 ?

MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/1420.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.

Faiblesses associées

Weaknesses related to CWE-1420

CWE-669 Parent

Prêt à valider ce qui compte.

Plexicus est Proof-Driven AppSec : findings validés, compréhension contextuelle et remédiation relue — ancrée dans la preuve, scopée avec vous.

Réserver un Pentest

Exposure of Sensitive Information during Transient Execution

What is CWE-1420?

Real-world CVEs caused by CWE-1420

Parcours de l'attaquant étape par étape

Vulnerable C

Secure pseudo

How to prevent CWE-1420

How to detect CWE-1420

Don't catalog this weakness. Prove it's reachable.

Frequently asked questions

Weaknesses related to CWE-1420

Incorrect Resource Transfer Between Spheres

Improper Removal of Sensitive Information Before Storage or Transfer

Creation of chroot Jail Without Changing Working Directory

Unrestricted Upload of File with Dangerous Type

Download of Code Without Integrity Check

Reliance on Cookies without Validation and Integrity Checking

Inclusion of Functionality from Untrusted Control Sphere

Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution

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

Further reading

Prêt à valider ce qui compte.

Vérifiez si l'AI Swarm Pentest convient à votre environnement.

Demande reçue. Réservez la prochaine étape.

Sample evidence handover

Server-Side Request Forgery in `webhooks/receiver`