☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 7.5 CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

CVE-2020-5953

CVE-2020-5953 Code Execution in Insyde
📅 PUBLISHED: 2022-02-03 00:00 UTC 🔄 UPDATED: 2026-10-02 19:31 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.28%
👁️
0.28% probability
7.1× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1546
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS VECTOR BREAKDOWN 7.5
AV: L Attack Vector Local
AC: H Attack Complexity High
PR: H Privileges Required High
UI: N User Interaction None
S: C Scope Changed
C: H Confidentiality High
I: H Integrity High
A: H Availability High
7.5
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2020-5953 is a privilege escalation vulnerability in the System Management Interrupt (SWSMI) handler of InsydeH2O UEFI firmware. The flaw allows a caller with ring 0 (kernel) privileges to escalate to ring -2 (System Management Mode, SMM), the most privileged execution environment in the x86 platform. The vulnerability stems from improper dereferencing of the EFI_RUNTIME_SERVICES (gRT) pointer to call a GetVariable service located outside of SMRAM, enabling arbitrary code execution within SMM. Systems running InsydeH2O firmware on affected versions are at risk of complete platform compromise, including bypass of firmware-level security mechanisms such as Secure Boot, Intel Boot Guard, and SMM-based security monitors.

The impact is severe but requires high prerequisites: local access, high privileges (kernel-mode code execution), and a successful exploitation attempt against a hard-to-reach attack surface. The CVSS v3.1 score is 7.5 (High), with a scope change indicating that compromise of SMM affects resources beyond the original privilege domain. No public exploit has been observed in the wild, and the EPSS score (0.00284) suggests low current exploitation activity.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

The vulnerability resides in the SWSMI handler of InsydeH2O UEFI firmware. SMM (System Management Mode) is a privileged x86 execution mode triggered by System Management Interrupts (SMI). SMM code executes in a dedicated memory region called SMRAM (System Management RAM), which is inaccessible to the operating system. Code running in SMM operates at privilege ring -2, above the hypervisor (ring -1) and kernel (ring 0). Compromise of SMM grants the attacker read/write access to all system memory, including firmware code, hypervisor memory, and OS kernel memory.

The specific flaw involves the SWSMI handler dereferencing the gRT pointer (EFI_RUNTIME_SERVICES) to invoke a GetVariable service. The UEFI runtime services table (gRT) is a structure containing function pointers to runtime services, including GetVariable. In this vulnerable implementation, the handler calls GetVariable via gRT without verifying that the gRT pointer resides within SMRAM. When the SWSMI handler executes this call, it dereferences a pointer that points outside of SMRAM — into non-SMM memory (i.e., regular system memory or ACPI/MMIO regions).

This creates a classic SMM call-out vulnerability. The SMM handler, while executing in SMM, redirects execution to a function pointer (GetVariable) located outside the protected SMRAM region. An attacker who controls the content of that memory region (e.g., through OS-level primitives) can substitute their own code at the location that gRT points to. When the SMM handler invokes the GetVariable service, it instead executes attacker-controlled code with SMM privileges.

Per the CVSS vector (AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H), the attack is local, requires significant skill (high attack complexity), and requires high privileges (kernel-mode code execution as a prerequisite). The scope change (S:C) indicates that exploitation at ring -2 grants access to resources beyond the original ring 0 domain, including firmware, hypervisor state, and other platform secrets.

The mechanism can be summarized as: a lack of validation that runtime service pointers (gRT) used by the SWSMI handler reside within SMRAM, allowing an attacker to redirect SMM execution to attacker-controlled code via a call-out to the GetVariable function.


Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and NVD description. No specific function names, file paths, or API parameters beyond those in the NVD description (gRT, GetVariable, SWSMI handler) are used.

Step 1 — Reconnaissance / Target Identification: An attacker first identifies target systems running InsydeH2O UEFI firmware. This can be achieved via firmware version enumeration during an operating system audit, UEFI firmware update tooling, or by querying system management BIOS (SMBIOS) tables that often include firmware vendor and version information. The attacker must also confirm that the target SWSMI handler exhibits the vulnerable gRT dereference behavior. Since exploitation requires local access and kernel privileges, the target is a specific machine or fleet of machines running affected firmware versions.

Step 2 — Triggering the Flaw: The attacker, already possessing ring 0 (kernel) code execution, must achieve two things: (a) control the memory location that gRT points to, and (b) trigger the vulnerable SWSMI handler. To control the gRT pointer destination, the attacker maps or allocates memory outside of SMRAM, places shellcode at that address, and either tricks the SMM handler into dereferencing a gRT pointer that has been altered, or leverages an existing gRT pointer that was already relocated to non-SMRAM memory. The SWSMI handler is triggered by generating a System Management Interrupt via an I/O port write (typically port 0xB2 on x86 platforms) from kernel mode. The attacker crafts the SMI command/data to invoke the specific SWSMI handler function that performs the vulnerable GetVariable call.

Step 3 — Payload / Execution Method: When the SWSMI handler executes, it dereferences gRT to call GetVariable. Because the gRT pointer points to attacker-controlled memory outside SMRAM, execution transfers to attacker-supplied code while the CPU is in SMM. The payload can be any SMM code — for example, shellcode that disables SMM write-protection by clearing the SMM_BLOCK and SMM_OVER_4GB bits in the MSRs (e.g., IA32_SMM_MONITOR_CTL) or SMRR protections, then copies malicious code into SMRAM to achieve persistence. Alternatively, the payload can patch SMM handlers or the SMI dispatch table to maintain persistent code execution in SMM.

Step 4 — Post-Exploitation Impact: With SMM code execution, the attacker achieves the highest privilege level on the platform (ring -2). They can:

  • Read/write all system memory, including the hypervisor (VMM) and OS kernel.
  • Bypass or disable security features: Secure Boot, Measured Boot (TPM-based attestation), Intel Boot Guard, and SMM-based security monitors (e.g., Hypervisor-enforced Memory Integrity).
  • Install persistent firmware rootkits (SMM backdoors) that survive OS reinstalls and even full disk wipe attempts, since they reside in SMRAM and the SPI flash.
  • Subvert the Trusted Platform Module (TPM) or BitLocker disk encryption by intercepting secrets during runtime.
  • Silently exfiltrate cryptographic keys, passwords, and other sensitive data stored in memory.

Impact Assessment

Business Impact: Successful exploitation represents a catastrophic firmware-level compromise. For enterprise environments, an attacker who reaches SMM can neutralize the very security foundations upon which the platform relies: UEFI Secure Boot, measured boot attestation, and virtualization-based security (VBS). Once an SMM rootkit is installed, it is effectively invisible to the OS, antivirus, EDR, and even the hypervisor. The result is a persistent, stealthy backdoor that survives OS reinstallation and disk reformatting. For organizations subject to compliance requirements (PCI-DSS, HIPAA, FedRAMP), a firmware compromise undermines the integrity guarantees these frameworks rely upon. For cloud providers and virtualized environments, SMM code execution can cross tenant boundaries if a hypervisor is running on the compromised host, enabling a guest VM to compromise the host and adjacent tenants.

Affected Systems: All devices using InsydeH2O UEFI firmware — this includes a broad range of laptops, desktops, servers, embedded systems, and IoT devices from numerous OEMs. The exact affected versions are not documented in the available data, meaning the blast radius is potentially large but unquantified. Enterprises cannot easily enumerate fleet exposure without OEM-specific firmware version checking tools.

CVSS Analysis:

  • Attack Vector: Local — physical or remote user with local access required.
  • Attack Complexity: High — requires significant skill and multiple primitives (kernel execution + memory control) to chain.
  • Privileges Required: High — attacker must already have ring 0 code execution.
  • User Interaction: None — no victim interaction needed.
  • Scope: Changed — compromise extends beyond the original privilege domain (ring 0) into SMM (ring -2), impacting the entire platform.
  • CIA Impact: High/High/High — complete confidentiality, integrity, and availability loss.

Blast Radius: Low-to-moderate real-world likelihood (EPSS 0.00284, no known exploits) but the impact of a single successful compromise is total. For high-security environments (e.g., government, finance, critical infrastructure), this type of flaw must be prioritized for firmware patching regardless of low exploit probability.


Detection Guidance

Sigma Rule

title: InsydeH2O SMM Call-Out via SWSMI Handler (CVE-2020-5953)
id: 9132c7c2-28a4-48c5-9d8a-9955e51f1c9c
status: experimental
description: Detects unusual System Management Interrupt activity or calls to SWSMI handler that may indicate exploitation of CVE-2020-5953.
author: valtersit.com Threat Intelligence
date: 2024/07/15
logsource:
    category: smi_events
    product: uefi_firmware
detection:
    selection:
        EventID: ['SWSMI_HANDLER_DISPATCH', 'SMI_TRIGGER_SWSMI_HANDLER']
        SWSMI_Handler_Address|endswith: ['0x00000000', '0xFFFFFFFF']
        RuntimeServiceCall:
            - GetVariableCalled: 'true'
            - gRT_Dereferenced: 'true'
            - MemoryRegion: 'Non-SMRAM'
    condition: selection
falsepositives:
    - Legitimate SWSMI handler activity for platform management functions
level: high
tags:
    - attack.privilege_escalation
    - attack.t1546
    - cve.2020.5953

YARA Rule

rule insydeh2o_smm_callout_cve_2020_5953
{
    meta:
        author = "valtersit.com Threat Intelligence"
        description = "Detects SWSMI handler code patterns that dereference gRT outside SMRAM for GetVariable calls"
        cve = "CVE-2020-5953"
        date = "2024/07/15"
    strings:
        $grt_getvariable = { 48 8B 05 ?? ?? ?? ??  48 8B 40 48  FF 15 ?? ?? ?? ?? }  // mov rax, [rip+disp32]; mov rax, [rax+offset]; call [rip+disp32] — pattern approximating gRT deref
        $smi_handler_entry = { B2 B0  EC E6  B2 B1  EC }                       // SMI trigger via I/O ports 0xB0/0xB1 (SWSMI command/data ports)
        $smm_trigger_port = { B2 B2 }                                          // OUT DX, AL pattern to port 0xB2
    condition:
        $smi_handler_entry or $smm_trigger_port
        and $grt_getvariable
        and uint16(0) >= 0x8000   // heuristic: memory image starts in UEFI DXE range
}

Suricata IDS Rule

alert tcp any any -> any any (msg:"CVE-2020-5953 InsydeH2O SMM Call-Out — Potential Firmware Exploitation Indicator"; flow:established; content:"InsydeH2O"; nocase; content:"GetVariable"; nocase; content:"SWSMI"; nocase; threshold:type limit, track by_src, count 5, seconds 60; classtype:attempted-admin; sid:20205953; rev:1; reference:cve,2020-5953; reference:url,nvd.nist.gov/vuln/detail/CVE-2020-5953;)

Note: This vulnerability is local and executed via CPU I/O operations (not network traffic). The Suricata rule above serves as an alert for network communications that reveal firmware version or exploitation-related content. Real detection for this CVE requires host-based telemetry (EDR, firmware instrumentation), not network monitoring.

Elastic Detection

// EQL Query for Elastic Defend or Endpoint Security
sequence by host.name, process.executable
  [smi where event.action == "smi_trigger" and smi.port == 0xB2 and smi.data != null]
  [process where event.type == "start" and process.name != null and process.Ext.autonomous_system.organization == null]
  [registry where event.action in ("set", "write") and registry.path : "*SWSMI*"]
| head 10

Splunk SPL Query

index=endpoint sourcetype=WinEventLog:Security OR sourcetype=xmlwineventlog
| where EventID IN (1, 4688)
| search "SWSMI" OR "Insyde" OR "GetVariable"
| eval suspicious = if((match(CommandLine, "(?i)(smi|smram|grt|getvariable)") AND User=="SYSTEM" AND Integrity_Level=="System"), "HIGH", "LOW")
| where suspicious=="HIGH"
| stats count by host, User, CommandLine, parent_process
| sort - count

Wazuh OSSEC Rule

<rule id="100953" level="12" frequency="8" timeframe="60">
  <if_matched_sid>100001</if_matched_sid>
  <match>InsydeH2O|SWSMI|GetVariable|gRT</match>
  <description>CVE-2020-5953: Potential SMM call-out exploitation in InsydeH2O firmware</description>
  <group>firmware_security, privilege_escalation, cve_2020_5953</group>
  <options>no_full_log</options>
  <mitre>
    <id>T1546</id>
  </mitre>
</rule>

Mitigation & Patch Guidance

Patch Confidence: 2/4 (CLAIMED — single source claims patch, not independently confirmed)

The NVD entry indicates a patch exists, but no specific version number or vendor advisory is provided. The patch confidence is low because the claim is not independently verified across multiple sources.

Immediate Mitigations:

  1. Inventory firmware versions: Identify all systems using InsydeH2O firmware. Use dmidecode (Linux) or Get-FirmwareType plus vendor tooling (e.g., Insyde's H2OFFT or OEM-specific utilities) to enumerate firmware versions.
  2. Restrict local kernel execution: Since exploitation requires ring 0 code execution, hardening the OS kernel reduces the attack surface. Implement hypervisor-based code integrity (HVCI), enable Kernel DMA Protection, and disable vulnerable kernel drivers.
  3. Limit local access: Physically restrict access to affected machines. Since the attack is local, reducing physical or remote local access lowers exposure.
  4. Monitor SMI/SWSMI activity: Deploy firmware-level monitoring (where supported by the platform) or use EDR agents that can observe unusual SMI generation or runtime service call patterns.
  5. Enable Secure Boot and measured boot: These do not prevent this vulnerability but can block certain boot-time attack chains and provide attestation for detecting firmware tampering.

Patch / Upgrade Steps:

  1. Contact your OEM (Dell, HP, Lenovo, Acer, etc.) or the original equipment manufacturer of the affected device to request a firmware update.
  2. Refer to Insyde's official advisory channels for a statement on affected and patched firmware versions. As of this report, no public vendor advisory from Insyde is available in the provided data.
  3. Apply the firmware update using the OEM's official flashing tool. Keep BitLocker recovery keys and system backups before proceeding.
  4. After updating, re-verify the firmware version via UEFI setup or platform tooling to confirm the patch was applied successfully.

Long-Term Hardening:

  1. Establish a firmware patch lifecycle within the organization — include UEFI firmware in regular patch management cadence.
  2. Enable UEFI Secure Boot with custom keys and enable all available firmware write-protection mechanisms (SPI flash protection, BIOS lock, etc.).
  3. Adopt hardware-rooted attestation (TPM 2.0-based measured boot) to detect firmware tampering during boot.
  4. Implement UEFI firmware update verification: enforce signed updates only (as per UEFI specification) and verify signatures.
  5. For cloud/hosted environments — ensure the physical hosts are patched and virtual firmware is additionally scrutinized.

References

  1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2020-5953
  2. MITRE CVE Record: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5953
  3. Insyde Software (Vendor): https://www.insyde.com/ (official vendor site — check for security advisories)
  4. UEFI Forum — SMM Security Guidance: https://uefi.org/sites/default/files/resources/EDK2%20Security%20Design%20Guidance.pdf
  5. CISA KEV: Not listed in CISA Known Exploited Vulnerabilities catalog.

Known Exploitation Evidence: No public proof-of-concept code has been identified. No threat actor campaigns have been observed exploiting this vulnerability in the wild as of this report. The EPSS score (0.00284) and absence from CISA KEV indicate low exploitation activity. The attack is highly complex, requiring both kernel-level access and deep firmware knowledge — likely limiting it to advanced persistent threat (APT) groups or nation-state actors with UEFI exploitation expertise.

👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

product:Insyde
InsydeH2O UEFI
insyde firmware port 443
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2020-5953/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.