CWE-1423 Base Incomplete

Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution

This vulnerability occurs when separate software components, like different processes or virtual machines, share the processor's internal prediction mechanisms. An attacker can manipulate these…

Definition

What is CWE-1423?

This vulnerability occurs when separate software components, like different processes or virtual machines, share the processor's internal prediction mechanisms. An attacker can manipulate these shared predictors to trigger speculative execution in a victim component, potentially leaking sensitive data across a security boundary via covert side channels.
Modern processors use hardware-enforced boundaries like virtual memory or privilege rings to isolate software. However, underlying microarchitectural predictors—which guess future code paths for performance—can sometimes be shared across these boundaries. When an attacker's code influences these shared predictors, it can steer speculative execution in a victim (like the kernel or another process), creating observable side effects that reveal private information. Predictor sharing can happen during transitions like system calls or between hardware threads in simultaneous multithreading (SMT). While some processors include features to isolate predictor state, these protections may not be enabled by default or may require explicit software configuration. This leaves systems vulnerable if not properly hardened against these microarchitectural data leaks.
Real-world impact

Real-world CVEs caused by CWE-1423

  • CVE-2017-5754

    (Branch Target Injection, BTI, Spectre v2). Shared microarchitectural indirect branch predictor state may allow code to influence transient execution across a process, VM, or privilege boundary, potentially exposing data that is accessible beyond the boundary.

  • CVE-2022-0001

    (Branch History Injection, BHI, Spectre-BHB). Shared branch history state may allow user-mode code to influence transient execution in the kernel, potentially exposing kernel data over a covert channel.

  • CVE-2021-33149

    (RSB underflow, Retbleed). Shared return stack buffer state may allow code that executes before a prediction barrier to influence transient execution after the prediction barrier, potentially exposing data that is accessible beyond the barrier over a covert channel.

How attackers exploit it

Step-by-step attacker path

  1. 1

    Branch Target Injection (BTI) is a vulnerability that can allow an SMT hardware thread to maliciously train the indirect branch predictor state that is shared with its sibling hardware thread. A cross-thread BTI attack requires the attacker to find a vulnerable code sequence within the victim software. For example, the authors of [REF-1415] identified the following code sequence in the Windows library ntdll.dll:

  2. 2

    To successfully exploit this code sequence to disclose the victim's private data, the attacker must also be able to find an indirect branch site within the victim, where the attacker controls the values in edi and ebx, and the attacker knows the value in edx as shown above at the indirect branch site. A proof-of-concept cross-thread BTI attack might proceed as follows: 1. The attacker thread and victim thread must be co-scheduled on the same physical processor core. 1. The attacker thread must train the shared branch predictor so that when the victim thread reaches indirect_branch_site, the jmp instruction will be predicted to target example_code_sequence instead of the correct architectural target. The training procedure may vary by processor, and the attacker may need to reverse-engineer the branch predictor to identify a suitable training algorithm. 1. This step assumes that the attacker can control some values in the victim program, specifically the values in edi and ebx at indirect_branch_site. When the victim reaches indirect_branch_site the processor will (mis)predict example_code_sequence as the target and (transiently) execute the adc instructions. If the attacker chooses ebx so that `ebx = m - 0x13BE13BD - edx, then the first adc will load 32 bits from address m in the victim's address space and add *m (the data loaded from) to the attacker-controlled base address in edi. The second adc instruction accesses a location in memory whose address corresponds to *m`. 1. The adversary uses a covert channel analysis technique such as Flush+Reload ([REF-1416]) to infer the value of the victim's private data *m.

  3. 3

    BTI can also allow software in one execution context to maliciously train branch predictor entries that can be used in another context. For example, on some processors user-mode software may be able to train predictor entries that can also be used after transitioning into kernel mode, such as after invoking a system call. This vulnerability does not necessarily require SMT and may instead be performed in synchronous steps, though it does require the attacker to find an exploitable code sequence in the victim's code, for example, in the kernel.

Vulnerable code example

Vulnerable x86 Assembly

Branch Target Injection (BTI) is a vulnerability that can allow an SMT hardware thread to maliciously train the indirect branch predictor state that is shared with its sibling hardware thread. A cross-thread BTI attack requires the attacker to find a vulnerable code sequence within the victim software. For example, the authors of [REF-1415] identified the following code sequence in the Windows library ntdll.dll:

Vulnerable x86 Assembly 
adc edi,dword ptr [ebx+edx+13BE13BDh]
   adc dl,byte ptr [edi]
   ...
 indirect_branch_site:
   jmp dword ptr [rsi] # at this point attacker knows edx, controls edi and ebx
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-1423

  • Architecture and Design The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
  • Architecture and Design Hardware designers may choose to use microarchitectural bits to tag predictor entries. For example, each predictor entry may be tagged with a kernel-mode bit which, when set, indicates that the predictor entry was created in kernel mode. The processor can use this bit to enforce that predictions in the current mode must have been trained in the current mode. This can prevent malicious cross-mode training, such as when user-mode software attempts to create predictor entries that influence transient execution in the kernel. Predictor entry tags can also be used to associate each predictor entry with the SMT thread that created it, and thus the processor can enforce that each predictor entry can only be used by the SMT thread that created it. This can prevent an SMT thread from using predictor entries crafted by a malicious sibling SMT thread.
  • Architecture and Design Hardware designers may choose to sanitize microarchitectural predictor state (for example, branch prediction history) when the processor transitions to a different context, for example, whenever a system call is invoked. Alternatively, the hardware may expose instruction(s) that allow software to sanitize predictor state according to the user's threat model. For example, this can allow operating system software to sanitize predictor state when performing a context switch from one process to another.
  • Implementation System software can mitigate this weakness by invoking predictor-state-sanitizing operations (for example, the indirect branch prediction barrier on Intel x86) when switching from one context to another, according to the hardware vendor's recommendations.
  • 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. One prominent example of this mitigation is retpoline ([REF-1414]).
  • 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 Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction.
  • System Configuration Some systems may allow the user to disable predictor sharing. For example, this could be a BIOS configuration, or a model-specific register (MSR) that can be configured by the operating system or virtual machine monitor.
Detection signals

How to detect CWE-1423

Manual Analysis Moderate

This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may have microarchitectural predictor state that is shared between hardware threads, execution contexts (for example, user and kernel), or other components that may host mutually distrusting software (or firmware, etc.).

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

Automated Analysis Moderate

This weakness can be detected in hardware by employing static or dynamic taint analysis methods [REF-1401]. These methods can label each predictor entry (or prediction history, etc.) according to the processor context that created it. Taint analysis or information flow analysis can then be applied to detect when predictor state created in one context can influence predictions made in another context.

Plexicus auto-fix

Plexicus auto-detects CWE-1423 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-1423?

This vulnerability occurs when separate software components, like different processes or virtual machines, share the processor's internal prediction mechanisms. An attacker can manipulate these shared predictors to trigger speculative execution in a victim component, potentially leaking sensitive data across a security boundary via covert side channels.

How serious is CWE-1423?

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

MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Microcontroller Hardware, Processor Hardware, Memory Hardware, System on Chip.

How can I prevent CWE-1423?

The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels. Hardware designers may choose to use microarchitectural bits to tag predictor entries. For example, each predictor entry may be tagged with a kernel-mode bit which, when set, indicates that the predictor entry was created in kernel mode. The processor can use this bit to enforce that predictions in the current mode must have been trained in the current mode. This…

How does Plexicus detect and fix CWE-1423?

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

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

Related weaknesses

Weaknesses related to CWE-1423

CWE-1420 Parent

Exposure of Sensitive Information during Transient Execution

Transient execution vulnerabilities occur when a processor speculatively runs operations that don't officially commit, potentially leaking…

CWE-1421 Sibling

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 Sibling

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.