{"@ID": "1421", "@Name": "Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution", "@Abstraction": "Base", "@Structure": "Simple", "@Status": "Incomplete", "Description": "A processor event may allow transient operations to access\n\t\t\tarchitecturally restricted data (for example, in another address\n\t\t\tspace) in a shared microarchitectural structure (for example, a CPU\n\t\t\tcache), potentially exposing the data over a covert channel.", "Extended_Description": {"xhtml:p": ["Many commodity processors have Instruction Set Architecture (ISA)\n\t\t\tfeatures that protect software components from one another. These\n\t\t\tfeatures can include memory segmentation, virtual memory, privilege\n\t\t\trings, trusted execution environments, and virtual machines, among\n\t\t\tothers. For example, virtual memory provides each process with its own\n\t\t\taddress space, which prevents processes from accessing each other's\n\t\t\tprivate data. Many of these features can be used to form\n\t\t\thardware-enforced security boundaries between software components.", "Many commodity processors also share microarchitectural resources that\n\t\t\tcache (temporarily store) data, which may be confidential. These\n\t\t\tresources may be shared across processor contexts, including across\n\t\t\tSMT threads, privilege rings, or others.", "When transient operations allow access to ISA-protected data in a\n\t\t\tshared microarchitectural resource, this might violate users'\n\t\t\texpectations of the ISA feature that is bypassed. For example, if\n\t\t\ttransient operations can access a victim's private data in a shared\n\t\t\tmicroarchitectural resource, then the operations' microarchitectural\n\t\t\tside effects may correspond to the accessed data. If an attacker can\n\t\t\ttrigger these transient operations and observe their side effects\n\t\t\tthrough a covert channel [REF-1400], then the attacker may be able to infer the\n\t\t\tvictim's private data. Private data could include sensitive program\n\t\t\tdata, OS/VMM data, page table data (such as memory addresses), system\n\t\t\tconfiguration data (see Demonstrative Example 3), or any other data\n\t\t\tthat the attacker does not have the required privileges to access."]}, "Related_Weaknesses": {"Related_Weakness": [{"@Nature": "ChildOf", "@CWE_ID": "1420", "@View_ID": "1000", "@Ordinal": "Primary"}, {"@Nature": "ChildOf", "@CWE_ID": "1420", "@View_ID": "1194", "@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": {"xhtml:p": "This weakness can be introduced during hardware architecture and\n\t\t\t\tdesign if a data path allows architecturally restricted data to\n\t\t\t\tpropagate to operations that execute before an older mis-prediction or\n\t\t\t\tprocessor event (such as an exception) is caught."}}, {"Phase": "Implementation", "Note": {"xhtml:p": "This weakness can be introduced during system software\n\t\t\t\timplementation if state-sanitizing operations are not invoked when\n\t\t\t\tswitching from one context to another, according to the hardware\n\t\t\t\tvendor's recommendations for mitigating the weakness."}}, {"Phase": "System Configuration", "Note": {"xhtml:p": "This weakness can be introduced if the system has not been\n\t\t\t\tconfigured according to the hardware vendor's recommendations for\n\t\t\t\tmitigating the weakness."}}, {"Phase": "Architecture and Design", "Note": {"xhtml:p": "This weakness can be introduced when an access control check\n\t\t\t\t(for example, checking page permissions) can proceed in parallel with\n\t\t\t\tthe access operation (for example, a load) that is being checked. If\n\t\t\t\tthe processor can allow the access operation to execute before the\n\t\t\t\tcheck completes, this race condition may allow subsequent transient\n\t\t\t\toperations to expose sensitive information."}}]}, "Common_Consequences": {"Consequence": {"Scope": "Confidentiality", "Impact": "Read Memory", "Likelihood": "Medium", "Note": {"xhtml:p": "<<put the information here>>"}}}, "Detection_Methods": {"Detection_Method": [{"Method": "Manual Analysis", "Description": {"xhtml:p": "This weakness can be detected in hardware by\n\t\t\t\tmanually inspecting processor specifications. Features that exhibit\n\t\t\t\tthis weakness may include microarchitectural predictors, access\n\t\t\t\tcontrol checks that occur out-of-order, or any other features that can\n\t\t\t\tallow operations to execute without committing to architectural\n\t\t\t\tstate. Academic researchers have demonstrated that new hardware\n\t\t\t\tweaknesses can be discovered by examining publicly available patent\n\t\t\t\tfilings, for example [REF-1405] and [REF-1406]. Hardware designers can also scrutinize aspects of the instruction set\n\t\t\t\tarchitecture that have undefined behavior; these can become a focal point when applying other\n\t\t\t\tdetection methods."}, "Effectiveness": "Moderate", "Effectiveness_Notes": "Manual analysis may not reveal all\n\t\t\t\tweaknesses in a processor specification\n\t\t\t\tand should be combined with other detection methods\n\t\t\t\tto improve coverage."}, {"Method": "Automated Analysis", "Description": {"xhtml:p": "This weakness can be detected (pre-discovery) in hardware by\n\t\t\t\temploying static or dynamic taint analysis methods [REF-1401]. These\n\t\t\t\tmethods can label data in one context (for example, kernel data) and\n\t\t\t\tperform information flow analysis (or a simulation, etc.) to determine\n\t\t\t\twhether tainted data can appear in another context (for example, user\n\t\t\t\tmode). Alternatively, stale or invalid data in shared\n\t\t\t\tmicroarchitectural resources can be marked as tainted, and the taint\n\t\t\t\tanalysis framework can identify when transient operations encounter\n\t\t\t\ttainted data."}, "Effectiveness": "Moderate", "Effectiveness_Notes": "Automated static or dynamic taint\n\t\t\t\tanalysis may not reveal all weaknesses in a processor\n\t\t\t\tspecification and should be combined with other detection\n\t\t\t\tmethods to improve coverage."}, {"Method": "Automated Analysis", "Description": {"xhtml:p": ["Software vendors can release tools that detect\n\t\t\t\tpresence of known weaknesses (post-discovery) on a processor. For example, some of\n\t\t\t\tthese tools can attempt to transiently execute a vulnerable code\n\t\t\t\tsequence and detect whether code successfully leaks data in a manner\n\t\t\t\tconsistent with the weakness under test. Alternatively, some hardware\n\t\t\t\tvendors provide enumeration for the presence of a weakness (or lack of\n\t\t\t\ta weakness). These enumeration bits can be checked and reported by\n\t\t\t\tsystem software. For example, Linux supports these checks for many\n\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": "This method can be useful for detecting\n\t\t\t\twhether a processor if affected by known weaknesses, but it\n\t\t\t\tmay not be useful for detecting unknown weaknesses."}, {"Method": "Fuzzing", "Description": "Academic researchers have demonstrated that this\n\t\t\t\tweakness can be detected in hardware using software fuzzing\n\t\t\t\ttools that treat the underlying hardware as a black box\n\t\t\t\t([REF-1406], [REF-1430])", "Effectiveness": "Opportunistic", "Effectiveness_Notes": "Fuzzing may not reveal all weaknesses\n\t\t\t\tin a processor specification and should be combined with\n\t\t\t\tother detection methods to improve coverage."}]}, "Potential_Mitigations": {"Mitigation": [{"Phase": "Architecture and Design", "Description": {"xhtml:p": "Hardware designers may choose to engineer the processor's\n\t\t\t\tpipeline to prevent architecturally restricted data from being used by\n\t\t\t\toperations that can execute transiently."}, "Effectiveness": "High"}, {"Phase": "Architecture and Design", "Description": {"xhtml:p": "Hardware designers may choose not to share\n\t\t\t\tmicroarchitectural resources that can contain sensitive data, such as\n\t\t\t\tfill buffers and store buffers."}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "This can be highly effective at preventing this\n\t\t\t\tweakness from being exposed across different SMT threads or different\n\t\t\t\tprocessor cores. It is generally less practical to isolate these\n\t\t\t\tresources between different contexts (for example, user and kernel)\n\t\t\t\tthat may execute on the same SMT thread or processor core."}}, {"Phase": "Architecture and Design", "Description": {"xhtml:p": "Hardware designers may choose to sanitize specific\n\t\t\t\tmicroarchitectural state (for example, store buffers) when the\n\t\t\t\tprocessor transitions to a different context, such as whenever a\n\t\t\t\tsystem call is invoked. Alternatively, the hardware may expose\n\t\t\t\tinstruction(s) that allow software to sanitize microarchitectural\n\t\t\t\tstate according to the user or system administrator's threat\n\t\t\t\tmodel. These mitigation approaches are similar to those that address\n\t\t\t\tCWE-226; however, sanitizing microarchitectural state may not be the\n\t\t\t\toptimal or best way to mitigate this weakness on every processor\n\t\t\t\tdesign."}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "Sanitizing shared state on context transitions\n\t\t\t\tmay not be practical for all processors, especially when the amount of\n\t\t\t\tshared state affected by the weakness is relatively\n\t\t\t\tlarge. Additionally, this technique may not be practical unless there\n\t\t\t\tis a synchronous transition between two processor contexts that would\n\t\t\t\tallow the affected resource to be sanitized. For example, this\n\t\t\t\ttechnique alone may not suffice to mitigate asynchronous access to a\n\t\t\t\tresource that is shared by two SMT threads."}}, {"Phase": "Architecture and Design", "Description": {"xhtml:p": "The hardware designer can attempt to prevent transient\n\t\t\t\texecution from causing observable discrepancies in specific covert\n\t\t\t\tchannels."}, "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": "Architecture and Design", "Description": {"xhtml:p": "Software architects may design software to enforce strong\n\t\t\t\tisolation between different contexts. For example, kernel page table\n\t\t\t\tisolation (KPTI) mitigates the Meltdown vulnerability [REF-1401] by\n\t\t\t\tseparating user-mode page tables from kernel-mode page tables, which\n\t\t\t\tprevents user-mode processes from using Meltdown to transiently access\n\t\t\t\tkernel memory [REF-1404]."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "Isolating different contexts across a process\n\t\t\t\tboundary (or another kind of architectural boundary) may only be\n\t\t\t\teffective for some weaknesses."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "If the weakness is exposed by a single instruction (or a\n\t\t\t\tsmall set of instructions), then the compiler (or JIT, etc.) can be\n\t\t\t\tconfigured to prevent the affected instruction(s) from being\n\t\t\t\tgenerated, and instead generate an alternate sequence of instructions\n\t\t\t\tthat is not affected by the weakness."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "This technique may only be fully effective if it\n\t\t\t\tis applied to all software that runs on the system. Also, relatively\n\t\t\t\tfew observed examples of this weakness have exposed data through only\n\t\t\t\ta single instruction."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "Use software techniques (including the use of\n\t\t\t\tserialization instructions) that are intended to reduce the number of\n\t\t\t\tinstructions that can be executed transiently after a processor event\n\t\t\t\tor misprediction."}, "Effectiveness": "Incidental", "Effectiveness_Notes": {"xhtml:p": "Some transient execution weaknesses can be\n\t\t\t\texploited even if a single instruction is executed transiently after a\n\t\t\t\tprocessor event or mis-prediction. This mitigation strategy has many\n\t\t\t\tother pitfalls that prevent it from eliminating this weakness\n\t\t\t\tentirely. For example, see [REF-1389]."}}, {"Phase": "Implementation", "Description": {"xhtml:p": "System software can mitigate this weakness by invoking\n\t\t\t\tstate-sanitizing operations when switching from one context to\n\t\t\t\tanother, according to the hardware vendor's recommendations."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "This technique may not be able to mitigate\n\t\t\t\tweaknesses that arise from resource sharing across SMT threads."}}, {"Phase": "System Configuration", "Description": {"xhtml:p": "Some systems may allow the user to disable (for example,\n\t\t\t\tin the BIOS) sharing of the affected resource."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "Disabling resource sharing (for example, by\n\t\t\t\tdisabling SMT) may result in significant performance overhead."}}, {"Phase": "System Configuration", "Description": {"xhtml:p": "Some systems may allow the user to disable (for example,\n\t\t\t\tin the BIOS) microarchitectural features that allow transient access\n\t\t\t\tto architecturally restricted data."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "Disabling microarchitectural features such as\n\t\t\t\tpredictors may result in significant performance overhead."}}, {"Phase": "Patching and Maintenance", "Description": {"xhtml:p": "The hardware vendor may provide a patch to sanitize the\n\t\t\t\taffected shared microarchitectural state when the processor\n\t\t\t\ttransitions to a different context."}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "This technique may not be able to mitigate\n\t\t\t\tweaknesses that arise from resource sharing across SMT threads."}}, {"Phase": "Patching and Maintenance", "Description": {"xhtml:p": "This kind of patch may not be feasible or\n\t\t\t\timplementable for all processors or all weaknesses."}, "Effectiveness": "Limited"}, {"Phase": "Requirements", "Description": {"xhtml:p": "Processor designers, system software vendors, or other\n\t\t\t\tagents may choose to restrict the ability of unprivileged software to\n\t\t\t\taccess to high-resolution timers that are commonly used to monitor\n\t\t\t\tcovert 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]."}}]}, "Demonstrative_Examples": {"Demonstrative_Example": [{"Intro_Text": {"xhtml:p": "Some processors may perform access control checks in parallel with\n\t\t\t\tmemory read/write operations. For example, when a user-mode program\n\t\t\t\tattempts to read data from memory, the processor may also need to\n\t\t\t\tcheck whether the memory address is mapped into user space or kernel\n\t\t\t\tspace. If the processor performs the access concurrently with the\n\t\t\t\tcheck, then the access may be able to transiently read kernel data\n\t\t\t\tbefore the check completes. This race condition is demonstrated in the\n\t\t\t\tfollowing code snippet from [REF-1408], with additional annotations:"}, "Example_Code": {"@Nature": "Bad", "@Language": "x86 Assembly", "xhtml:br": [null, null, null, null, null, null, null], "#text": "1 ; rcx = kernel address, rbx = probe array\n\t\t\t\t  2 xor rax, rax                # set rax to 0\n\t\t\t\t  3 retry:\n\t\t\t\t  4 mov al, byte [rcx]          # attempt to read kernel memory\n\t\t\t\t  5 shl rax, 0xc                # multiply result by page size (4KB)\n\t\t\t\t  6 jz retry                    # if the result is zero, try again\n\t\t\t\t  7 mov rbx, qword [rbx + rax]  # transmit result over a cache covert channel"}, "Body_Text": {"xhtml:p": "Vulnerable processors may return kernel data from a shared\n\t\t\t\tmicroarchitectural resource in line 4, for example, from the\n\t\t\t\tprocessor's L1 data cache. Since this vulnerability involves a race\n\t\t\t\tcondition, the mov in line 4 may not always return kernel data (that\n\t\t\t\tis, whenever the check \"wins\" the race), in which case this\n\t\t\t\tdemonstration code re-attempts the access in line 6. The accessed data\n\t\t\t\tis multiplied by 4KB, a common page size, to make it easier to observe\n\t\t\t\tvia a cache covert channel after the transmission in line 7. The use\n\t\t\t\tof cache covert channels to observe the side effects of transient\n\t\t\t\texecution has been described in [REF-1408]."}}, {"Intro_Text": {"xhtml:p": ["Many commodity processors share microarchitectural fill buffers\n\t\t\t\tbetween sibling hardware threads on simultaneous multithreaded (SMT)\n\t\t\t\tprocessors. Fill buffers can serve as temporary storage for data that\n\t\t\t\tpasses to and from the processor's caches. Microarchitectural Fill\n\t\t\t\tBuffer Data Sampling (MFBDS) is a vulnerability that can allow a\n\t\t\t\thardware thread to access its sibling's private data in a shared fill\n\t\t\t\tbuffer. The access may be prohibited by the processor's ISA, but MFBDS\n\t\t\t\tcan allow the access to occur during transient execution, in\n\t\t\t\tparticular during a faulting operation or an operation that triggers a\n\t\t\t\tmicrocode assist.", "More information on MFBDS can be found in [REF-1405] and [REF-1409]."]}}, {"Intro_Text": {"xhtml:p": ["Some processors may allow access to system registers (for example,\n\t\t\t\tsystem coprocessor registers or model-specific registers) during\n\t\t\t\ttransient execution. This scenario is depicted in the code snippet\n\t\t\t\tbelow. Under ordinary operating circumstances, code in exception level\n\t\t\t\t0 (EL0) is not permitted to access registers that are restricted to\n\t\t\t\tEL1, such as TTBR0_EL1. However, on some processors an earlier\n\t\t\t\tmis-prediction can cause the MRS instruction to transiently read the\n\t\t\t\tvalue in an EL1 register. In this example, a conditional branch (line\n\t\t\t\t2) can be mis-predicted as \"not taken\" while waiting for a slow load\n\t\t\t\t(line 1). This allows MRS (line 3) to transiently read the value in\n\t\t\t\tthe TTBR0_EL1 register. The subsequent memory access (line 6) can\n\t\t\t\tallow the restricted register's value to become observable, for\n\t\t\t\texample, over a cache covert channel.", "Code snippet is from [REF-1410]. See also [REF-1411]."]}, "Example_Code": {"@Nature": "Bad", "@Language": "x86 Assembly", "xhtml:br": [null, null, null, null, null, null, null, null], "#text": "1 LDR X1, [X2] ; arranged to miss in the cache\n\t\t\t\t  2 CBZ X1, over ; This will be taken \n\t\t\t\t  3 MRS X3, TTBR0_EL1; \n\t\t\t\t  4 LSL X3, X3, #imm \n\t\t\t\t  5 AND X3, X3, #0xFC0\n\t\t\t\t  6 LDR X5, [X6,X3] ; X6 is an EL0 base address\n\t\t\t\t  7 over"}}]}, "Observed_Examples": {"Observed_Example": [{"Reference": "CVE-2017-5715", "Description": "A fault may allow transient user-mode operations to\n\t\t\t\taccess kernel data cached in the L1D, potentially exposing the data\n\t\t\t\tover a covert channel.", "Link": "https://www.cve.org/CVERecord?id=CVE-2017-5715"}, {"Reference": "CVE-2018-3615", "Description": "A fault may allow transient non-enclave operations to\n\t\t\t\taccess SGX enclave data cached in the L1D, potentially exposing the\n\t\t\t\tdata over a covert channel.", "Link": "https://www.cve.org/CVERecord?id=CVE-2018-3615"}, {"Reference": "CVE-2019-1135", "Description": "A TSX Asynchronous Abort may allow transient operations\n\t\t\t\tto access architecturally restricted data, potentially exposing the\n\t\t\t\tdata over a covert channel.", "Link": "https://www.cve.org/CVERecord?id=CVE-2019-1135"}]}, "References": {"Reference": [{"@External_Reference_ID": "REF-1404"}, {"@External_Reference_ID": "REF-1405"}, {"@External_Reference_ID": "REF-1406"}, {"@External_Reference_ID": "REF-1401"}, {"@External_Reference_ID": "REF-1408"}, {"@External_Reference_ID": "REF-1409"}, {"@External_Reference_ID": "REF-1410"}, {"@External_Reference_ID": "REF-1411"}, {"@External_Reference_ID": "REF-1400"}, {"@External_Reference_ID": "REF-1389"}, {"@External_Reference_ID": "REF-1430"}, {"@External_Reference_ID": "REF-1417"}, {"@External_Reference_ID": "REF-1418"}, {"@External_Reference_ID": "REF-1419"}, {"@External_Reference_ID": "REF-1420"}]}, "Mapping_Notes": {"Usage": "Allowed", "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": "If a weakness can potentially be exploited to\n\t\t\t  infer data that is accessible inside or outside the current\n\t\t\t  processor context, then the weakness could map to CWE-1421 and\n\t\t\t  to another CWE such as CWE-1420.", "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": "2025-09-09", "Modification_Version": "4.18", "Modification_ReleaseDate": "2025-09-09", "Modification_Comment": "updated References, Relationships"}, {"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"}]}}