{"@ID": "1420", "@Name": "Exposure of Sensitive Information during Transient Execution", "@Abstraction": "Base", "@Structure": "Simple", "@Status": "Incomplete", "Description": "A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.", "Extended_Description": {"xhtml:p": ["When operations execute but do not commit to the processor's\n\t\t\t\t\tarchitectural state, this is commonly referred to as transient\n\t\t\t\t\texecution. This behavior can occur when the processor mis-predicts an\n\t\t\t\t\toutcome (such as a branch target), or when a processor event (such as\n\t\t\t\t\tan exception or microcode assist, etc.) is handled after younger\n\t\t\t\t\toperations have already executed. Operations that execute transiently\n\t\t\t\t\tmay exhibit observable discrepancies (CWE-203) in covert channels\n\t\t\t\t\t[REF-1400] such as data caches. Observable discrepancies of this kind\n\t\t\t\t\tcan be detected and analyzed using timing or power analysis\n\t\t\t\t\ttechniques, which may allow an attacker to infer information about the\n\t\t\t\t\toperations that executed transiently. For example, the attacker may be\n\t\t\t\t\table to infer confidential data that was accessed or used by those\n\t\t\t\t\toperations.", "Transient execution weaknesses may be exploited using one of two\n\t\t\t\t\tmethods. In the first method, the attacker generates a code sequence\n\t\t\t\t\tthat exposes data through a covert channel when it is executed\n\t\t\t\t\ttransiently (the attacker must also be able to trigger transient\n\t\t\t\t\texecution). Some transient execution weaknesses can only expose data\n\t\t\t\t\tthat is accessible within the attacker's processor context. For\n\t\t\t\t\texample, an attacker executing code in a software sandbox may be able\n\t\t\t\t\tto use a transient execution weakness to expose data within the same\n\t\t\t\t\taddress space, but outside of the attacker's sandbox. Other transient\n\t\t\t\t\texecution weaknesses can expose data that is architecturally\n\t\t\t\t\tinaccessible, that is, data protected by hardware-enforced boundaries\n\t\t\t\t\tsuch as page tables or privilege rings. These weaknesses are the\n\t\t\t\t\tsubject of CWE-1421.", "In the second exploitation method, the attacker first identifies a\n\t\t\t\t\tcode sequence in a victim program that, when executed transiently, can\n\t\t\t\t\texpose data that is architecturally accessible within the victim's\n\t\t\t\t\tprocessor context. For instance, the attacker may search the victim\n\t\t\t\t\tprogram for code sequences that resemble a bounds-check bypass\n\t\t\t\t\tsequence (see Demonstrative Example 1). If the attacker can trigger a\n\t\t\t\t\tmis-prediction of the conditional branch and influence the index of\n\t\t\t\t\tthe out-of-bounds array access, then the attacker may be able to infer\n\t\t\t\t\tthe value of out-of-bounds data by monitoring observable discrepancies\n\t\t\t\t\tin a covert channel."]}, "Related_Weaknesses": {"Related_Weakness": {"@Nature": "ChildOf", "@CWE_ID": "669", "@View_ID": "1000", "@Ordinal": "Primary"}}, "Weakness_Ordinalities": {"Weakness_Ordinality": {"Ordinality": "Primary"}}, "Applicable_Platforms": {"Language": {"@Class": "Not Language-Specific", "@Prevalence": "Undetermined"}, "Operating_System": {"@Class": "Not OS-Specific", "@Prevalence": "Undetermined"}, "Architecture": {"@Class": "Not Architecture-Specific", "@Prevalence": "Undetermined"}, "Technology": {"@Class": "Not Technology-Specific", "@Prevalence": "Undetermined"}}, "Modes_Of_Introduction": {"Introduction": [{"Phase": "Architecture and Design", "Note": "This weakness can be introduced when a computing unit (such as a CPU, GPU, accelerator, or any other processor) uses out-of-order execution, speculation, or any other microarchitectural feature that can allow microarchitectural operations to execute without committing to architectural state."}, {"Phase": "Implementation", "Note": "This weakness can be introduced when sandboxes or managed runtimes are not properly isolated by using hardware-enforced boundaries. Developers of sandbox or managed runtime software should exercise caution when relying on software techniques (such as bounds checking) to prevent code in one sandbox from accessing confidential data in another sandbox. For example, an attacker sandbox may be able to trigger a processor event or mis-prediction in a manner that allows it to transiently read a victim sandbox's private data."}]}, "Common_Consequences": {"Consequence": {"Scope": "Confidentiality", "Impact": "Read Memory", "Likelihood": "Medium"}}, "Detection_Methods": {"Detection_Method": [{"Method": "Manual Analysis", "Description": {"xhtml:p": "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])."}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": ["Hardware designers can also scrutinize aspects of the instruction set architecture \n\t\t\t\t\t\t\t\tthat have undefined behavior; these can become a focal point when applying other\n\t\t\t\t\t\t\t\tdetection methods.", "Manual analysis may not reveal all weaknesses in a processor specification\n\t\t\t\t\t\t\t\tand should be combined with other detection methods to improve coverage."]}}, {"Method": "Fuzzing", "Description": {"xhtml:p": "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])."}, "Effectiveness": "Opportunistic", "Effectiveness_Notes": {"xhtml:p": "Fuzzing may not reveal all weaknesses in a processor specification and should\n\t\t\t\t\t\t\tbe combined with other detection methods to improve coverage."}}, {"Method": "Fuzzing", "Description": {"xhtml:p": "Academic researchers have demonstrated that this weakness can be detected in software using software fuzzing tools ([REF-1429])."}, "Effectiveness": "Opportunistic", "Effectiveness_Notes": {"xhtml:p": "At the time of this writing, publicly available software fuzzing tools can only\n\t\t\t\t\t\t\t\tdetect a subset of transient execution weaknesses in software (for example, [REF-1429] can only\n\t\t\t\t\t\t\t\tdetect instances of Spectre v1) and may produce false positives."}}, {"Method": "Automated Static Analysis", "Description": {"xhtml:p": "A variety of automated static analysis tools can identify\n\t\t\t\t\t\t\tpotentially exploitable code sequences in software. These tools may\n\t\t\t\t\t\t\tperform the analysis on source code, on binary code, or on an\n\t\t\t\t\t\t\tintermediate code representation (for example, during compilation)."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "At the time of this writing, publicly available software static analysis tools can\n\t\t\t\t\t\t\tonly detect a subset of transient execution weaknesses in software and may produce false\n\t\t\t\t\t\t\tpositives."}}, {"Method": "Automated Analysis", "Description": {"xhtml:p": ["Software vendors can release tools that detect presence of\n\t\t\t\t\t\t\tknown weaknesses on a processor. For example, some of these tools can\n\t\t\t\t\t\t\tattempt to transiently execute a vulnerable code sequence and detect\n\t\t\t\t\t\t\twhether code successfully leaks data in a manner consistent with the\n\t\t\t\t\t\t\tweakness under test. Alternatively, some hardware vendors provide\n\t\t\t\t\t\t\tenumeration for the presence of a weakness (or lack of a\n\t\t\t\t\t\t\tweakness). These enumeration bits can be checked and reported by\n\t\t\t\t\t\t\tsystem software. For example, Linux supports these checks for many\n\t\t\t\t\t\t\tcommodity 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"]}, "Effectiveness": "High", "Effectiveness_Notes": {"xhtml:p": "This method can be useful for detecting whether a processor is affected by\n\t\t\t\t\t\t\t\tknown weaknesses, but it may not be useful for detecting unknown weaknesses."}}]}, "Potential_Mitigations": {"Mitigation": [{"Phase": "Architecture and Design", "Description": "The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.", "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "This technique has many pitfalls. For example,\n\t\t\t\t\t\t\tInvisiSpec was an early attempt to mitigate this weakness by blocking\n\t\t\t\t\t\t\t\"micro-architectural covert and side channels through the\n\t\t\t\t\t\t\tmultiprocessor data cache hierarchy due to speculative loads\" [REF-1417].\n\t\t\t\t\t\t\tCommodity processors and SoCs have many covert and side channels that\n\t\t\t\t\t\t\texist outside of the data cache hierarchy. Even when some of these\n\t\t\t\t\t\t\tchannels are blocked, others (such as execution ports [REF-1418]) may\n\t\t\t\t\t\t\tallow an attacker to infer confidential data. Mitigation strategies\n\t\t\t\t\t\t\tthat attempt to prevent transient execution from causing observable\n\t\t\t\t\t\t\tdiscrepancies also have other pitfalls, for example, see [REF-1419]."}}, {"Phase": "Requirements", "Description": {"xhtml:p": "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."}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "Instructions or features that constrain transient execution or suppress its side effects may impact performance."}}, {"Phase": "Requirements", "Description": {"xhtml:p": "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."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "Disabling specific predictors or other hardware features may result in significant performance overhead."}}, {"Phase": "Requirements", "Description": {"xhtml:p": "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."}, "Effectiveness": "Defense in Depth", "Effectiveness_Notes": {"xhtml:p": "Specific software algorithms can be used by an attacker to compensate for a lack of a high-resolution time source [REF-1420]."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "Isolate sandboxes or managed runtimes in separate address spaces (separate processes). For examples, see [REF-1421]."}, "Effectiveness": "High"}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "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)."}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "When used to comprehensively mitigate a transient execution weakness (for example, by inserting an LFENCE after every instruction in a program), serialization instructions can introduce significant performance overhead. On the other hand, when used to mitigate only a relatively small number of high-risk code sequences, serialization instructions may have a low or negligible impact on performance."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions."}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "Some CFI techniques may not be able to constrain transient execution, even though they are effective at constraining architectural execution. Or they may be able to provide some additional protection against a transient execution weakness, but without comprehensively mitigating the weakness. For example, Clang-CFI provides strong architectural CFI properties and can make some transient execution weaknesses more difficult to exploit [REF-1398]."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "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])."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "This technique may only be effective for software that is compiled with this mitigation. For some transient execution weaknesses, this technique may not be sufficient to protect software that is compiled without the affected instruction(s). For example, see CWE-1421."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "Use software techniques that can mitigate the consequences of transient execution. For example, address masking can be used in some circumstances to prevent out-of-bounds transient reads."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "Address masking and related software mitigation techniques have been used to harden specific code sequences that could potentially be exploited via transient execution. For example, the Linux kernel makes limited use of manually inserted address masks to mitigate bounds-check bypass [REF-1390]. Compiler-based techniques have also been used to automatically harden software [REF-1425]."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "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."}, "Effectiveness": "Incidental", "Effectiveness_Notes": {"xhtml:p": "Some transient execution weaknesses can be exploited even if a single instruction is executed transiently after a processor event or mis-prediction. This mitigation strategy has many other pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389]."}}, {"Phase": "Documentation", "Description": {"xhtml:p": "If a hardware feature can allow incorrect operations (or correct operations with incorrect data) to execute transiently, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations."}, "Effectiveness": "High"}]}, "Demonstrative_Examples": {"Demonstrative_Example": [{"Intro_Text": "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]:", "Example_Code": {"@Nature": "Bad", "@Language": "C", "xhtml:div": {"xhtml:br": null, "xhtml:div": {"@style": "margin-left:1em;", "#text": "y = array2[array1[x] * 4096];"}, "#text": "if (x < array1_size)"}}, "Body_Text": {"xhtml:p": ["However, if this code executes on a processor that performs\n\t\t\t\t\t\t\tconditional branch prediction the outcome of the if statement could be\n\t\t\t\t\t\t\tmis-predicted and the access on the next line will occur with a value\n\t\t\t\t\t\t\tof x that can point to an out-of-bounds location (within the program's\n\t\t\t\t\t\t\tmemory).", "Even though the processor does not commit the architectural effects of\n\t\t\t\t\t\t\tthe mis-predicted branch, the memory accesses alter data cache state,\n\t\t\t\t\t\t\twhich is not rolled back after the branch is resolved. The cache state\n\t\t\t\t\t\t\tcan reveal array1[x] thereby providing a mechanism to recover the data\n\t\t\t\t\t\t\tvalue located at address array1 + x."]}}, {"Intro_Text": "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]."}]}, "Observed_Examples": {"Observed_Example": [{"Reference": "CVE-2017-5753", "Description": "Microarchitectural conditional branch predictors may allow operations to execute transiently after a misprediction, potentially exposing data over a covert channel.", "Link": "https://www.cve.org/CVERecord?id=CVE-2017-5753"}, {"Reference": "CVE-2021-0089", "Description": "A machine clear triggered by self-modifying code may allow incorrect operations to execute transiently, potentially exposing data over a covert channel.", "Link": "https://www.cve.org/CVERecord?id=CVE-2021-0089"}, {"Reference": "CVE-2022-0002", "Description": "Microarchitectural indirect branch predictors may allow incorrect operations to execute transiently after a misprediction, potentially exposing data over a covert channel.", "Link": "https://www.cve.org/CVERecord?id=CVE-2022-0002"}]}, "References": {"Reference": [{"@External_Reference_ID": "REF-1389"}, {"@External_Reference_ID": "REF-1417"}, {"@External_Reference_ID": "REF-1418"}, {"@External_Reference_ID": "REF-1419"}, {"@External_Reference_ID": "REF-1420"}, {"@External_Reference_ID": "REF-1421"}, {"@External_Reference_ID": "REF-1398"}, {"@External_Reference_ID": "REF-1414"}, {"@External_Reference_ID": "REF-1390"}, {"@External_Reference_ID": "REF-1425"}, {"@External_Reference_ID": "REF-1427"}, {"@External_Reference_ID": "REF-1428"}, {"@External_Reference_ID": "REF-1429"}, {"@External_Reference_ID": "REF-1415"}, {"@External_Reference_ID": "REF-1400"}]}, "Mapping_Notes": {"Usage": "Allowed-with-Review", "Rationale": "This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.", "Comments": {"xhtml:p": "A vulnerability should only map to CWE-1420 if it cannot map to any of CWE-1420's child weaknesses. Follow this diagram:", "xhtml:img": {"@src": "/data/images/CWE-1420-MicroArch-DecisionTree.png", "@alt": "CWE-1420 mapping decision diagram"}}, "Reasons": {"Reason": {"@Type": "Acceptable-Use"}}}, "Content_History": {"Submission": {"Submission_Name": "Scott D. Constable", "Submission_Organization": "Intel Corporation", "Submission_Date": "2023-09-19", "Submission_Version": "4.14", "Submission_ReleaseDate": "2024-02-29"}, "Modification": [{"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2024-07-16", "Modification_Version": "4.15", "Modification_ReleaseDate": "2024-07-16", "Modification_Comment": "updated Mapping_Notes"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2025-09-09", "Modification_Version": "4.18", "Modification_ReleaseDate": "2025-09-09", "Modification_Comment": "updated References"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2025-12-11", "Modification_Version": "4.19", "Modification_ReleaseDate": "2025-12-11", "Modification_Comment": "updated References, Weakness_Ordinalities"}], "Contribution": [{"@Type": "Content", "Contribution_Name": "David Kaplan", "Contribution_Organization": "AMD", "Contribution_Date": "2024-01-22", "Contribution_Version": "4.14", "Contribution_ReleaseDate": "2024-02-29", "Contribution_Comment": "Member of Microarchitectural Weaknesses Working Group"}, {"@Type": "Content", "Contribution_Name": "Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett", "Contribution_Organization": "Arm", "Contribution_Date": "2024-01-22", "Contribution_Version": "4.14", "Contribution_ReleaseDate": "2024-02-29", "Contribution_Comment": "Members of Microarchitectural Weaknesses Working Group"}, {"@Type": "Content", "Contribution_Name": "Jason Oberg", "Contribution_Organization": "Cycuity", "Contribution_Date": "2024-01-22", "Contribution_Version": "4.14", "Contribution_ReleaseDate": "2024-02-29", "Contribution_Comment": "Member of Microarchitectural Weaknesses Working Group"}, {"@Type": "Content", "Contribution_Name": "Priya B. Iyer", "Contribution_Organization": "Intel Corporation", "Contribution_Date": "2024-01-22", "Contribution_Version": "4.14", "Contribution_ReleaseDate": "2024-02-29", "Contribution_Comment": "Member of Microarchitectural Weaknesses Working Group"}, {"@Type": "Content", "Contribution_Name": "Nicole Fern", "Contribution_Organization": "Riscure", "Contribution_Date": "2024-01-22", "Contribution_Version": "4.14", "Contribution_ReleaseDate": "2024-02-29", "Contribution_Comment": "Member of Microarchitectural Weaknesses Working Group"}]}}