CVE-2026-20775

Executive Summary

CVE-2026-20775 is an unpatched denial-of-service vulnerability affecting some Intel(R) TDX (Trust Domain Extensions) modules operating at Ring 0 privilege. A system software adversary with a privileged user account and local access can trigger an uncaught exception within the TDX module (CWE-248), causing a high-availability-impact failure with no confidentiality or integrity impact. No patch, vendor advisory, public exploit, or CISA KEV listing currently exists, and exploitation likelihood is considered low based on an EPSS score of 0.00102.

Technical Analysis

Intel TDX (Trust Domain Extensions) is a confidential-computing technology that isolates Trust Domains (TDs) from the host virtual machine monitor (VMM), hypervisor, and OS using CPU-enforced memory encryption and integrity protections. The TDX module is the privileged software/firmware component that implements and brokers these protections. The NVD description characterizes the vulnerable component as running "within Ring 0," the highest privilege execution ring on the x86 architecture, meaning the fault condition exists in the most privileged layer of the TDX software stack.

The vulnerability mechanism is an uncaught exception. In CWE-248 terms, the TDX module fails to handle a specific exception condition raised during its execution. Because the exception is not caught or recovered, the fault propagates to an unhandled state, which typically results in uncontrolled termination — a crash, watchdog reset, or unrecoverable module state. The NVD description indicates the attack requires:

• Privileged access: A "system software adversary" — i.e., an attacker who already controls or compromises a privileged component such as a kernel driver, the VMM, or the system firmware stack.
• High complexity: The attacker must satisfy specific technical preconditions or arrange a particular operational sequence. This is not a trivially reproducible crash.
• Local access: The attack vector is local; it cannot be triggered remotely over the network.
• No user interaction: The attack does not require an end user to perform any action.

The NVD description explicitly lists the impact as confidentiality: none, integrity: none, availability: high. This is a pure availability flaw: the attacker cannot read or modify protected TD data, but can render the TDX module inoperable, thereby denying service to Trust Domains and the workloads they host.

It must be stated clearly that the public data for this CVE is sparse. No specific function names, error codes, module version identifiers, or exact trigger conditions are disclosed in the NVD description. The analysis above is therefore at the vulnerability-class level (uncaught exception in privileged Ring 0 TDX code) and no implementation-level specifics can be provided without speculation.

Exploitation Scenarios

Because no public PoC or exploit code has been observed, the attack chain below is inferred strictly from the NVD description and the vulnerability class (CWE-248, uncaught exception). No specific code paths, input formats, or internal function names are available.

1. Reconnaissance / target identification: The attacker identifies a platform or environment where Intel TDX is enabled. Because the attack is local and requires an already-privileged position, the reconnaissance is typically post-compromise or insider-driven: enumerating platform capabilities, confirming that TDX Trust Domains are running, and determining the value of disrupting those workloads (e.g., confidential VMs in a multi-tenant hosting environment).

2. Triggering the flaw: The privileged system software adversary performs a privileged operation or sequence of interactions with the TDX module that causes an exception to be raised inside the module at Ring 0. Because the exception is not caught (CWE-248), the module does not gracefully handle or recover from the fault. The "high complexity" rating indicates the attacker must arrange specific preconditions — the precise operation sequence is unknown from public data, and repeated attempts may be necessary.

3. Payload / execution method: There is no traditional code-execution payload. The "payload" is the triggering operation itself. The attack relies on the attacker's existing privileged position to issue the malformed or out-of-sequence operation to the TDX module. No user interaction is required, and no special internal knowledge of the target system is needed beyond the generic ability to invoke privileged TDX operations.

4. Post-exploitation impact: The uncaught exception causes the TDX module to crash, halt, or enter an unrecoverable state. The result is a denial of service affecting Trust Domain(s), meaning confidential workloads cannot be created, resumed, or continued. Per the NVD description, there is no confidentiality or integrity loss — protected data is not exposed or modified — but availability of the vulnerable system is highly impacted, and the description's wording suggests subsequent system availability can also be impacted.

Note: No public PoC is available; the attack chain above is inferred from the vulnerability class and the constraints stated in the NVD description.

Impact Assessment

The NVD describes the impact profile as confidentiality: none, integrity: none, availability: high — both for the vulnerable system and for subsequent system availability. This is a focused denial-of-service vulnerability with no data-exposure or data-integrity component. NVD has not assigned a CVSS score or vector (CVSS: N/A), so severity must be assessed from the qualitative characteristics: local attack surface, high attacker complexity, privileged account requirement, and high availability impact.

The blast radius is significant for organizations that depend on Intel TDX confidential computing:

• Cloud and hosting providers offering TDX-based confidential VMs suffer availability degradation affecting multiple tenants sharing a physical host, since a single Ring 0 module failure can impact all Trust Domains on that platform.
• Enterprise confidential-computing workloads (e.g., protected data processing, regulated workloads, multi-party computation) experience downtime that may breach SLAs.
• Security operations impact is limited to availability monitoring; the failure does not undermine the confidentiality guarantees of TDX, which is the primary selling point of the technology.

EPSS places exploitation likelihood at 0.00102 (approximately the 1.1th percentile of all exploited CVEs), indicating very low active exploitation probability. The CVE is not listed in CISA's Known Exploited Vulnerabilities catalog. However, the absence of a patch (patch confidence 0/4) means the window of exposure is open-ended, and the vulnerability will likely be resolved only through a future Intel TDX module, microcode, or platform firmware update.

Detection Guidance

Detection for CVE-2026-20775 must focus on host telemetry because the attack is local and manifests as an exception/crash in the Ring 0 TDX module. Key signals include: kernel and module crash logs referencing TDX, system panic or watchdog events, Trust Domain unexpected termination events, VMM/hypervisor error logs, and privileged-session activity immediately preceding such events. Network-based detection is of limited value but can catch centralized syslog forwarding of these host events.

Sigma Rule

title: Intel TDX Module Uncaught Exception - Denial of Service
id: 3f6e253d-8c4a-4f2f-9a10-c176cfa4f7d7
status: experimental
description: >
  Detects host log events indicating an uncaught exception or crash in an
  Intel TDX module, consistent with CVE-2026-20775 denial-of-service behavior.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-20775
author: Valters IT SOC
logsource:
    product: linux
    service: kernel
detection:
    selection_tdx:
        - 'TDX'
        - 'tdx'
        - 'Trust Domain'
    selection_fault:
        - 'uncaught exception'
        - 'general protection fault'
        - 'kernel panic'
        - 'BUG: unable to handle'
    condition: selection_tdx and selection_fault
falsepositives:
    - TDX module firmware update or upgrade events
    - Crash dumps captured during controlled vendor testing
level: medium
tags:
    - attack.impact
    - attack.t1499
    - cve.2026-20775

YARA Rule

rule CVE_2026_20775_Intel_TDX_Exception
{
    meta:
        author      = "Valters IT SOC"
        description = "Matches log or crash-report data referencing Intel TDX uncaught exception / module failure conditions consistent with CVE-2026-20775"
        cve         = "2026-20775"
        reference   = "https://nvd.nist.gov/vuln/detail/CVE-2026-20775"
        threat      = "Denial of Service"

    strings:
        $tdx_name  = "TDX" nocase
        $tdx_full  = "Trust Domain" nocase
        $exc       = "uncaught exception" nocase
        $exc_generic = "exception" nocase
        $ring0     = "Ring 0" nocase
        $panic     = "panic" nocase
        $gpf       = "general protection fault" nocase

    condition:
        ($tdx_name or $tdx_full) and
        ($exc or $panic or $gpf or ($exc_generic and $ring0))
}

Suricata IDS Rule

This vulnerability is local in nature, so network detection is not the primary mechanism. The following rule is intended to flag TDX failure indicators carried over centralized syslog streams to a SIEM collector.

alert tcp any any -> any 514 (msg:"CVE-2026-20775 Intel TDX Module Uncaught Exception DoS Indicator"; flow:to_server,established; content:"TDX"; nocase; content:"exception"; nocase; within:1024; reference:cve,2026-20775; classtype:attempted-dos; sid:20260775; rev:1;)

Note: Analysts should tune this rule for local syslog infrastructure. Given the local attack vector, expect a high false-positive rate on generic networks that do not run Intel TDX.

Elastic Detection

any where
  (message like "*TDX*" and message like "*uncaught exception*") or
  (message like "*Trust Domain*" and (message like "*panic*" or message like "*general protection fault*")) or
  (message like "*TDX*" and message like "*Ring 0*" and message like "*exception*")

This EQL query should be scoped to host logs (kernel, system, hypervisor) in Elastic Security. An additional sequence over privileged authentication events preceding the failure could be layered on, but the core signal is the TDX exception/fault string in the logs.

Splunk SPL Query

index=main (sourcetype=linux:kernel OR sourcetype="WinEventLog:System" OR sourcetype="syslog")
  "TDX" AND ("uncaught exception" OR "general protection fault" OR "panic" OR "Trust Domain")
| stats count min(_time) as first_seen max(_time) as last_seen by host, source
| where count > 0

For a more targeted view, correlate with privileged-access events on the same host within a short time window:

index=main (sourcetype=linux:kernel OR sourcetype="WinEventLog:System")
  "TDX" AND ("uncaught exception" OR "panic" OR "Trust Domain")
| join type=inner host [
    index=main sourcetype=linux:audit (auid!=0 AND success=yes) OR sourcetype="WinEventLog:Security" (EventCode=4624 OR EventCode=4672)
    | stats count as auth_events by host ]
| table _time host source

Wazuh OSSEC Rule

<group name="intel_tdx,">
  <rule id="100275" level="10">
    <match>TDX|Trust Domain</match>
    <regex>uncaught exception|general protection fault|panic</regex>
    <description>CVE-2026-20775: Possible Intel TDX module uncaught exception leading to denial of service</description>
    <mitre>
      <id>T1499</id>
      <tactic>Impact</tactic>
    </mitre>
    <group>denial_of_service,impact,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch status: Patch confidence is 0/4 — no patch evidence from any tracked source. NVD reports no vendor fix, no workarounds, and no affected-version list. There is no CISA KEV entry and no known exploitation in the wild as of this report.

1. Immediate mitigations (compensating controls):

   • Restrict local privileged access to TDX-enabled hosts. Apply strict least-privilege principles for root/administrator accounts and kernel-level access.
   • Enforce multi-factor authentication and break-glass procedures on all privileged accounts capable of interacting with platform firmware or the TDX module.
   • Where TDX confidential computing is not an operational requirement, disable TDX in platform firmware/BIOS to eliminate the attack surface.
   • Enable kernel crash-dump collection and centralized log retention so any TDX exception event can be investigated quickly.
   • Monitor privileged-session activity (auditd, Windows Security logs, VMM logs) for anomalous sequences on confidential-computing hosts.

2. Patch / upgrade steps:

   • Subscribe to the Intel Product Security Center and the NVD feed for CVE-2026-20775; track the CVE until a vendor advisory is released.
   • When Intel publishes a fixed TDX module version, microcode update, or platform firmware update, deploy it through the standard change-management and patch-validation process to confidential-computing platforms first.
   • Because no version range is published, treat all in-service Intel TDX modules as potentially affected until patched.

3. Long-term hardening:

   • Treat this as an accepted risk with compensating controls until an official fix exists; document the risk in the system risk register with the CVSS score marked as N/A.
   • Verify availability SLAs and failover/reboot procedures for Trust Domain workloads so a TDX module failure is survivable.
   • Maintain an incident-response runbook for TDX outages, including how to preserve crash evidence and how to determine whether a crash was accidental or intentionally triggered.
   • Periodically reassess the CVE for newly published exploit code, PoC availability, or vendor advisories; re-run detection signatures against historical logs once signatures are confirmed.

References

• NVD Entry for CVE-2026-20775: https://nvd.nist.gov/vuln/detail/CVE-2026-20775
• MITRE CWE-248 — Uncaught Exception: https://cwe.mitre.org/data/definitions/248.html
• MITRE ATT&CK T1499 — Endpoint Denial of Service: https://attack.mitre.org/techniques/T1499/
• Intel Product Security Center (vendor advisory pending release): https://www.intel.com/content/www/us/en/security-center/default.html
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-20775 not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat-actor / in-the-wild evidence: None identified. The CVE is not listed in CISA KEV, no exploit code or PoC has been observed, and no threat-actor campaign has been publicly associated with this vulnerability. Exploitation likelihood is low per EPSS (0.00102, ~1.1th percentile), but the unpatched status warrants ongoing monitoring.