☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
SOON 🐛 CWE-1220
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2025-31938

CVE-2025-31938 Information Disclosure in Intel
📅 PUBLISHED: 2026-08-11 00:00 UTC 🔄 UPDATED: 2026-09-23 10:16 UTC
⏳ SCORE PENDING — ANALYSIS IN PROGRESS [ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.09%
👁️
0.09% probability
2.2× above the median CVE
Tier: LOW
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1005
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
VULNERABLE: UNKNOWN / CHECK VENDOR
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
SOON
PENDING NVD
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2025-31938 is an information-disclosure vulnerability caused by insufficient granularity of access control (CWE-1220) in an undisclosed subsystem of Intel(R) Xeon(R) 6 Scalable processors equipped with Intel(R) Trust Domain Extensions (TDX). An authenticated local adversary who possesses special internal knowledge of the platform can, under high-complexity conditions and without any user interaction, cause the exposure of confidential data. The directly vulnerable subsystem itself reports no confidentiality, integrity, or availability impact, but the downstream (target) system confidentiality impact is rated high, indicating a cross-trust-boundary data leak. As of this writing, no patch, vendor advisory, public proof-of-concept, or in-the-wild exploitation evidence has been confirmed; the CVE is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.

⚡ 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

Intel TDX is a confidential-computing hardware technology for Intel Xeon Scalable processors that isolates "trust domains" — confidential VMs whose memory and execution state are protected from the host, the VMM, and other tenants via hardware memory encryption and access controls. The NVD description for CVE-2025-31938 indicates that the flaw resides in "some subsystem" of the TDX platform, but does not specify which component (TDX module, SEAM module, memory controller interface, I/O subsystem, etc.). Insufficient technical detail is available in the CNA description to identify the exact affected firmware, microcode version, or code path.

The vulnerability class is CWE-1220: Insufficient Granularity of Access Control. This class describes a condition where an access-control mechanism exists and is functionally active, but its granularity is too coarse or too fine, allowing a subject (user, process, guest, or trust domain) to reach objects or resources that should have been isolated. In a TDX context, the mechanism this maps to is the hardware-assisted isolation boundary between trust domains and between the host/VMM and the confidential guests.

The attack preconditions stated by the description are:

  • Authorized adversary with an authenticated user — the attacker already possesses a valid local account on some part of the affected platform.
  • High complexity attack — exploitation requires favorable, hard-to-arrange conditions.
  • Special internal knowledge — the attacker needs non-public knowledge of internal platform state or subsystem layout.
  • Local access — the attack path is local, not network-reachable.
  • No user interaction — no victim action is required.

A notable detail in the description is the dual impact statement: the vulnerability "may impact the confidentiality (none), integrity (none) and availability (none) of the vulnerable system," yet results in "subsequent system confidentiality (high)." This framing strongly suggests the directly vulnerable subsystem is only an access bridge — the component itself is not damaged, but it improperly exposes data belonging to a different system (e.g., another trust domain, the host OS, or a protected memory region). This pattern is consistent with an access-control bypass or a hardware-enforced-isolation failure rather than a software memory-corruption bug.

Because no CVSS vector or score was supplied, the severity can only be reasoned from the textual description: the downstream confidentiality impact is high, but exploitability is constrained by the authenticated-user requirement, high attack complexity, special-knowledge prerequisite, and local-only access. No public exploit code, Nuclei template, or PoC is available, and EPSS scores this CVE at 0.00087 (0.4% percentile of exploited CVEs), indicating a very low current likelihood of exploitation in the wild.

Exploitation Scenarios

No public PoC or exploit code exists for CVE-2025-31938. The following attack chain is inferred from the vulnerability class (CWE-1220) and the NVD description, not from observed or published techniques.

1) Reconnaissance / target identification. The attacker must already be an authenticated local user on a system built on an Intel Xeon 6 Scalable processor with TDX enabled. They would first identify the specific platform configuration, the TDX operating mode, and the presence of the vulnerable subsystem. The "special internal knowledge" requirement implies the attacker needs pre-existing familiarity with platform internals — for example, knowing which subsystem enforces the insufficient access-control granularity, or how to reach it from the local user context.

2) Triggering the flaw. As a local authenticated user, the attacker interacts with the affected subsystem outside the intended access-control boundaries. Because the granularity of access control is insufficient, the subsystem fails to distinguish between two access principals (e.g., host vs. trust domain, or one trust domain vs. another) that should have been separated. The "high complexity" qualifier indicates the attacker must arrange the system into a specific state to make the exposure reachable. No user interaction is required, so victim behavior plays no role in the chain.

3) Payload / execution method (class-level). At the vulnerability-class level, this is not a traditional code-injection or memory-corruption bug. The attacker submits legitimate but improperly authorized queries/requests to the affected subsystem. The access-control check that should reject the request either fails to apply or applies at the wrong granularity, allowing the request to cross a trust boundary and read data outside the attacker's permitted scope. The exact request mechanism (IOCTL, model-specific register access, memory-mapped interface, hypervisor callback, etc.) is not disclosed in the NVD description and must not be inferred.

4) Post-exploitation impact. Successful exploitation yields an information-disclosure primitive: the attacker gains read access to confidential data belonging to another trust domain or to the protected processing environment. Confidentiality of the target data is compromised with high impact; integrity and availability of both the vulnerable subsystem and the downstream system remain unaffected (none). Because the attacker already holds a local authenticated account, the disclosure widens their knowledge of the platform and may feed a subsequent, higher-privilege attack chain — though no such chain is described in the available data.

Note on technical fidelity: The NVD description contains no function names, class names, file paths, API endpoints, or register identifiers. All detection content below is therefore written at the generic platform/log level and should be tuned to local environment knowledge.

Impact Assessment

  • Business impact. Intel Xeon 6 Scalable processors with TDX are marketed toward confidential computing: multi-tenant cloud providers, outsourcing environments, regulated industries (finance, healthcare, government) that run workloads requiring cryptographic isolation from the platform operator. A flaw in TDX-related access control granularity undermines the foundational trust promise of the platform: tenants assume their in-memory data is unreadable by the host/hypervisor or co-tenants. Even a high-complexity local exploit that violates this boundary can have outsized reputational and compliance consequences (e.g., breach of attestation guarantees, regulatory exposure for cloud service providers).
  • Affected systems. Intel Xeon 6 Scalable processors with Intel TDX. The vendor has not published the full affected version/stepping range; the supplied Affected Versions list is empty. Systems with TDX disabled or not present are outside the attack surface.
  • Blast radius. The confidentiality impact on the downstream system is high; integrity and availability are untouched. The attack requires an authenticated user and local access — meaning the attacker already has a foothold on the platform. The blast radius is therefore concentrated on data confidentiality across trust-domain boundaries rather than system availability or data integrity. If the leak allows cross-tenant reads in a public-cloud confidential-computing environment, the business impact could be severe for the cloud provider and its tenants.
  • Risk metrics. CVSS: not provided. EPSS: 0.00087 (0.4% percentile) — very low exploitation likelihood. CISA KEV: not listed. Patch confidence: 0/4 (unpatched). No exploit code, no Nuclei template, PoC status unknown/none.

Detection Guidance

Detection for this CVE is challenging because (a) no specific trigger artifact (function name, syscall, log message string) is disclosed in the NVD description, and (b) local hardware/subsystem access control failures do not always emit conventional endpoint logs. The rules below are generic class-level detectors: they alert on local memory-access primitives, TDX-related errors/denials, and post-exploitation exfiltration patterns. Tune thresholds to your environment before enabling in production.

Sigma Rule

title: Local Information Disclosure Attempt Against Intel TDX Subsystem
id: 719a3f2e-5c4b-4d3a-9b2c-1f6d8e7a3c20
status: experimental
description: Detects local authenticated processes attempting cross-process memory reads
    (debugging or memory dump primitives) combined with TDX-related audit context.
    Correlates with CVE-2025-31938 access-control-granularity information disclosure.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-31938
author: Valtersit Threat Intelligence
date: 2025/06/10
logsource:
    product: linux
    service: auditd
detection:
    selection_syscall:
        type: SYSCALL
        syscall:
            - ptrace
            - process_vm_readv
            - process_vm_writev
    selection_tdx_context:
        key|contains: tdx
    condition: selection_syscall and selection_tdx_context
falsepositives:
    - Legitimate debugging of TDX-enabled confidential workloads by platform administrators
    - Vendor TDX diagnostics tooling using inter-process memory reads
level: high
tags:
    - attack.t1005
    - cve.2025-31938

YARA Rule

rule CVE_2025_31938_TDX_InfoDisclosure_Artifacts
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects binaries or memory/firmware dumps containing TDX-related
            access-control or isolation-boundary strings, which may be artifacts of an
            exploit or tooling targeting CVE-2025-31938."
        cve = "CVE-2025-31938"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2025-31938"
        date = "2025-06-10"
        hash = "unknown"
    strings:
        $tdx1 = "TDX" ascii wide
        $tdx2 = "Trust Domain" ascii wide
        $tdx3 = "SEAM" ascii wide
        $err1 = "access denied" ascii wide
        $err2 = "isolation violation" ascii wide
        $err3 = "insufficient access" ascii wide
        $tool1 = "dump" ascii wide
    condition:
        uint16(0) == 0x5A4D and
        ( (2 of ($tdx*) and 1 of ($err*)) or (2 of ($tdx*) and $tool1) ) and
        filesize < 10MB
}

Suricata IDS Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-31938 Potential Post-Exploit Data Exfiltration from Intel TDX Host"; flow:established,to_server; dsize:>10000; content:"!|00|"; threshold: type both, track by_src, count 100, seconds 60; classtype:attempted-information-leak; priority:1; reference:cve,2025-31938; sid:202531938; rev:1;)

Rationale: CVE-2025-31938 is a local-access vulnerability, so no reliable network pre-exploit signature exists. This rule flags the post-exploitation phase — sustained, large outbound data transfers from a TDX-capable host, which is the observable exfiltration side of an information-disclosure primitive. Tune the byte-count/rate thresholds to your baseline; expect false positives from backups and large file transfers.

Elastic Detection

sequence with maxspan=10m
  [ process where event.type == "start" and
    process.name in ("gdb", "dd", "memdump", "xxd") and
    not user.name in ("root", "tdx-admin") ]
  [ network where event.type == "connection" and
    network.direction == "egress" and
    bytes_out > 1000000 ]

Note: The first event models a local user invoking memory-read tooling (a common exploitation support step), and the second models an anomalous egress data spike. Adjust the tool list and user allowlist to match your environment. The rule is intentionally permissive; apply strict monitoring on TDX-managed hosts only.

Splunk SPL Query

(index=linux_audit OR index=syslog) 
  ( tag=auditd OR sourcetype=linux_audit )
  ( syscall=ptrace OR syscall=process_vm_readv OR syscall=process_vm_writev
    OR "key=tdx" OR "*TDX*error*" OR "*TDX*access*denied*" )
  | eval severity=case(
        match(_raw, "key=tdx"), "high",
        match(_raw, "access denied"), "medium",
        true(), "informational")
  | stats dc(host) as affected_hosts, count as event_count
        by host, user, process_name, severity
  | where event_count > 5 OR severity="high"
  | sort - affected_hosts, event_count

Rationale: Searches audit logs for local memory-access syscalls and TDX-related access-control denials/errors, then aggregates by host, user, and process, surfacing anomalous repeat behavior. Adjust index/sourcetype names to match your deployment.

Wazuh OSSEC Rule

<group name="intel_tdx,">
  <rule id="100531" level="12" frequency="5" timeframe="60">
    <decoded_as>syslog|json</decoded_as>
    <match>TDX|Trust Domain</match>
    <match>access denied|isolation violation|insufficient access|granularity</match>
    <description>CVE-2025-31938: Repeated TDX access-control violations or isolation errors on local subsystem — possible information disclosure attempt</description>
    <groups>local,pci_dss_10.6.1,gpg13_10.1,gdpr_IV_35.7.d</groups>
    <mitre>
      <id>T1005</id>
    </mitre>
  </rule>
</group>

Note: The rule fires after 5 matching events in 60 seconds, reducing noise from occasional benign TDX error messages. Adjust level and frequency based on observed baseline.

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence exists from any tracked source; the vendor Affected Versions list is empty; no Intel advisory has been published.

1) Immediate mitigations (until a patch exists):

  • Restrict local access to TDX-enabled Intel Xeon 6 platforms. Enforce least-privilege local accounts; remove or disable any local accounts that do not have a documented operational need.
  • If TDX/confidential-computing workloads are not a hard requirement, disable TDX in the platform BIOS/firmware to eliminate the attack surface.
  • Disable or tightly control debugging interfaces, memory dump tooling, and ptrace capabilities (kernel.yama.ptrace_scope=1 or 2) on TDX-managed hosts.
  • Monitor the detection content above on all confidential-computing hosts, and alert on TDX-related audit events.
  • Notify multi-tenant/customer workloads relying on TDX isolation about the exposure risk; consider workload migration to non-affected platforms if the data sensitivity warrants it.

2) Patch/upgrade steps:

  • No patch exists. Actively monitor Intel's Product Security Center and Intel PSIRT advisories for an update referencing CVE-2025-31938.
  • Apply firmware, microcode, BIOS, and Intel TDX module updates immediately upon release; schedule a fast-track change window for TDX-capable infrastructure.
  • Track CISA KEV and Intel advisory feeds; reassess severity when the official advisory (with affected SKUs and fixed versions) is published.

3) Long-term hardening:

  • Adopt hardware attestation and integrity verification for all TDX-enabled hosts so trust-domain state and platform configuration are continuously verified.
  • Segment confidential-computing infrastructure from general-purpose compute; require additional authentication factors for local console/IPMI/KVM access.
  • Incorporate this CVE into supply-chain risk assessments for cloud and confidential-computing procurement (Intel Xeon 6 Scalable).
  • Periodically re-run EPSS and CISA KEV checks for CVE-2025-31938; treat unpatched high-confidentiality-impact hardware vulnerabilities with formal risk acceptance if TDX cannot be disabled.

References

  1. NVD Entry — https://nvd.nist.gov/vuln/detail/CVE-2025-31938 (primary source for description, metrics, and metadata).
  2. CWE-1220 — Insufficient Granularity of Access Control — https://cwe.mitre.org/data/definitions/1220.html (vulnerability class reference).
  3. Intel Product Security Center — https://www.intel.com/content/www/us/en/security-center/default.html (monitor here for the pending Intel PSIRT advisory for CVE-2025-31938; no advisory published at time of writing).
  4. CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2025-31938 is not listed; re-check periodically).
  5. FIRST EPSS — https://www.first.org/epss/ (CVE-2025-31938 current EPSS score: 0.00087, 0.4% percentile of exploited CVEs).

Threat-actor and in-the-wild evidence: None known. No public exploit code, no Nuclei template, no campaign data, and no CISA KEV listing exist for this CVE at the time of writing. All exploitation scenarios in this report are inferred from the vulnerability class and NVD description, per reporting-fidelity constraints.

👁️ 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.

"Intel Xeon 6"
"Intel TDX"
"Xeon Scalable"
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2025-31938/ · 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.