← Back to Feed CACHED · 2026-08-12 15:04:08 · CACHE_KEY CVE-2026-6726
CVE-2026-6726 · CWE-704 · Disclosed 2026-08-11

An information leakage vulnerability was reported in the TCG TPM 2.0 reference code that could

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

Like forging a notary stamp, but only after you've already broken into the notary's office

CVE-2026-6726 is an object-slot-reuse flaw in the TCG TPM 2.0 reference implementation code. Due to improper type casting and failure to clear sensitive data from reused object slots (CWE-704, CWE-1266), a local attacker with privileged access to the TPM command interface can craft commands that cause the TPM to treat a falsified key as legitimate. The attacker can then present this falsified key — an Attestation Key, DevID key, or TLS authentication key — to a TPM-aware Certificate Authority and obtain a valid credential. This breaks the fundamental trust assertion that TPM-backed keys were genuinely generated inside tamper-resistant hardware. Affected hardware includes AMD fTPM across Ryzen 3000–9000 series and Ryzen AI families, Intel fTPM implementations, and Nuvoton NPCT7xx discrete TPMs with firmware prior to 7.2.4.1 / 7.2.5.0. The installed base is enormous — hundreds of millions of devices.

Despite the massive footprint, the attack requires local administrator or root-level access to the TPM command interface. This is a hard post-compromise prerequisite: the attacker must already own the box before they can abuse the TPM. The blast radius is confined to the compromised host's identity — forging that machine's attestation, not impersonating other machines. Some sources cite a vendor CVSS of 8.5 (HIGH), but no authoritative NVD or MITRE score has been published. The HIGH label overweights the theoretical impact of undermining hardware root-of-trust while underweighting the fact that an attacker with local admin already controls the host. In environments not using TPM-based attestation, conditional access, or device identity certificates, this vulnerability has near-zero practical impact. For organizations relying on Windows Hello for Business, Intune device compliance, or zero-trust device attestation, the residual risk is real but incremental — the attacker is extending an existing compromise, not initiating one.

"Local-admin-only TPM attestation forgery — real but post-compromise and per-host scoped"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Gain privileged local access

The attacker must first achieve administrator or root-level access on the target host through an independent attack chain — phishing, lateral movement, credential theft, or exploitation of an unrelated vulnerability. Without local admin, the TPM command interface is inaccessible. This is the hardest step and is entirely external to CVE-2026-6726.
Conditions required:
  • Local administrator or root access on the target host
  • Access to the TPM command interface (typically available to admin-level processes)
Where this breaks in practice:
  • Requires a full initial-access-to-admin chain independent of this CVE
  • EDR and host-based controls should detect the privilege escalation preceding this step
  • Attack surface is zero for remote-only attackers
Detection/coverage: EDR behavioral detection for privilege escalation; Windows Event ID 4672 (special privileges assigned)
STEP 02

Craft malicious TPM commands exploiting slot reuse

The attacker sends specially crafted TPM2 commands that exploit the object-slot-reuse flaw. By manipulating type conversions, the attacker loads a software-generated (non-TPM) key into a slot previously occupied by a legitimate TPM-resident key. The TPM fails to clear sensitive metadata from the slot, causing it to treat the injected key as hardware-generated. No public proof-of-concept exists; the attacker would need to reverse-engineer the slot management logic or develop tooling from the TCG advisory (TCGVRT0010) details.
Conditions required:
  • Vulnerable TPM firmware (pre-patch)
  • Knowledge of TPM 2.0 command structure and slot management internals
Where this breaks in practice:
  • No public PoC or weaponized tooling available as of 2026-08-12
  • Requires deep TPM protocol expertise — this is not script-kiddie territory
  • TPM command logging (if enabled) can capture anomalous command sequences
Detection/coverage: TPM command audit logging (Windows: tpm.msc → TPM Management snap-in; Linux: tpm2_getcap audit); most enterprises do not actively monitor TPM command streams
STEP 03

Present falsified key to TPM-aware CA

The attacker uses the falsified key (now appearing as a legitimate TPM-backed AK, DevID, or TLS key) to request a credential from a TPM-aware Certificate Authority. The CA validates the key's TPM residency claims and issues a certificate. This certificate can then be used for device attestation, network authentication, or conditional access bypass. The attacker's host now possesses a credential that survives TPM clearing.
Conditions required:
  • Organization operates a TPM-aware CA or uses a service that validates TPM attestation (e.g., Windows Hello for Business, Intune TPM attestation, 802.1X with TPM-backed DevID)
Where this breaks in practice:
  • Many enterprises do not run TPM-aware CAs or rely on TPM attestation for access control
  • Certificate issuance is typically logged and auditable via CA audit logs
  • Conditional access policies often layer multiple signals beyond TPM attestation alone
Detection/coverage: CA audit logs for certificate issuance; Microsoft Intune device compliance anomaly detection; 802.1X RADIUS logs
STEP 04

Abuse forged credential

With a valid-looking TPM-backed certificate, the attacker can bypass device compliance checks, maintain persistent device identity even after remediation of the original compromise, or authenticate to services requiring hardware-attested credentials. The impact is confined to the identity of the single compromised host — the attacker cannot forge attestations for other devices' TPMs.
Conditions required:
  • Target environment enforces access decisions based on TPM attestation
  • Forged credential is accepted by relying parties
Where this breaks in practice:
  • Impact is per-host, not fleet-scale
  • Credential revocation at the CA neutralizes the forged cert
  • Re-provisioning the TPM and rekeying the device eliminates persistence
Detection/coverage: Certificate revocation monitoring; device compliance drift detection in MDM/UEM; anomalous re-enrollment events
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. Not listed in CISA KEV. No reports from threat intelligence vendors of active exploitation campaigns as of 2026-08-12.
Proof-of-ConceptNo public PoC available. Exploitation requires deep TPM 2.0 protocol expertise. Discovered by Liran Perez and Zecharye Galitzky of Intel, reported via TCG coordinated disclosure (TCGVRT0010).
EPSS Score0.00221 — bottom quartile. Probability of exploitation in the next 30 days is extremely low per FIRST EPSS model.
KEV StatusNot listed in CISA Known Exploited Vulnerabilities catalog.
CVSS VectorNo authoritative NVD/MITRE score published. Nuvoton advisory rates as HIGH. Some secondary sources cite 8.5. Likely vector (estimated): CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N — local access, high privileges, high complexity, changed scope due to CA trust impact.
Affected VersionsAMD fTPM: Ryzen 3000–9000, Ryzen AI 300/400, Ryzen AI Max 300, Threadripper, Ryzen Z1/Z2, Ryzen Embedded families. Intel fTPM: affected (details per Intel advisory). Nuvoton NPCT7xx: firmware prior to 7.2.4.1 and version 7.2.5.0.
Fixed VersionsNuvoton: firmware 7.2.4.1, 7.2.5.1+. AMD: patched via AGESA updates distributed through OEM BIOS updates (ASUS, MSI, GIGABYTE confirmed). Intel: firmware updates per OEM. Patches were available before public disclosure.
Scanning / Exposure DataNot remotely scannable. TPM is a local hardware component with no network-facing attack surface. Shodan/Censys/GreyNoise are not applicable. Asset inventory via MDM/UEM or BIOS version auditing is the only way to identify vulnerable hosts.
Disclosure Timeline2026-08-11 public disclosure via CERT/CC VU#431093 and vendor advisories. Coordinated disclosure through TCG Vulnerability Response Team.
Reporting ResearcherLiran Perez and Zecharye Galitzky, Intel — reported to TCG VRT.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.0/10)

Assessed at MEDIUM because the single most decisive factor is the hard prerequisite of privileged local access — the attacker must already be administrator/root on the target host before the TPM flaw becomes reachable, making this a post-compromise identity-persistence technique rather than an initial-access or escalation vector. The per-host blast radius (forgery is confined to the compromised machine's own TPM identity) prevents this from reaching the HIGH floor despite the enormous installed base.

HIGH Vulnerability mechanics and attack prerequisites
MEDIUM CVSS score (no authoritative NVD score; Nuvoton says HIGH, secondary sources say 8.5)
HIGH Exploitation likelihood (no PoC, no ITW, very low EPSS)

Why this verdict

  • Privileged local access required: The attacker must already hold admin/root on the target host. This is a post-compromise prerequisite that eliminates all remote attack scenarios and means an independent, full attack chain must succeed before CVE-2026-6726 becomes relevant. Downward pressure: significant.
  • No public PoC or weaponized tooling: Exploitation requires intimate knowledge of TPM 2.0 command internals and slot management. No researcher has published exploit code. The bar for weaponization is high. Downward pressure: moderate.
  • Per-host blast radius: The forgery applies to the compromised host's TPM only. The attacker cannot impersonate other devices or achieve lateral movement through this flaw alone. Impact is identity persistence on a single already-compromised endpoint. Downward pressure: significant.
  • Role multiplier: (a) *Low-value role (workstation/dev sandbox)*: chain succeeds but impact is trivial — attacker already owns the box and gains only attestation persistence. Blast radius: host-only. (b) *Typical role (enterprise endpoint with Intune/WHfB)*: chain succeeds and attacker gains conditional-access bypass persistence on that single device. Blast radius: host → tenant-edge (one device's compliance posture). (c) *High-value role (TPM-aware CA server, HSM host, confidential-computing node)*: chain could succeed if the server runs vulnerable firmware, but these roles represent <1% of the TPM installed base (most TPMs are in endpoints, not servers running CA services). Even in this role, impact is identity forgery for that one server, not domain/fleet compromise. No high-value-role outcome reaches the domain-takeover or fleet-compromise threshold needed to trigger the HIGH floor.
  • Enormous installed base is offset by attack locality: Hundreds of millions of devices carry vulnerable firmware, but the vulnerability has zero remote attack surface. The population-at-risk is not 'all devices with TPMs' but 'all devices where an attacker has already achieved local admin AND the org relies on TPM attestation.' This is a small fraction of deployments.

Why not higher?

To warrant HIGH, the vulnerability would need either a remote attack vector, a path to fleet-scale impact, or active exploitation. CVE-2026-6726 has none of these. The local+privileged prerequisite means an attacker has already won the host before this flaw matters. The forgery is per-host and cannot propagate. No PoC exists and EPSS is bottom-quartile. While the installed base is vast, the *reachable* population (local admin + TPM attestation reliance) is narrow.

Why not lower?

Dropping to LOW would undervalue the real-world impact in organizations that have invested in TPM-based zero-trust architectures (Windows Hello for Business, Intune device compliance, 802.1X DevID). In those environments, forging TPM attestation undermines a deliberate security control and provides meaningful persistence. The flaw is also in a foundational security primitive (hardware root of trust), and the CWE combination (type confusion + data reuse) suggests a design-level weakness in the reference implementation that may have downstream implications beyond the currently documented attack.

05 · Compensating Control

What to do — in priority order.

  1. Audit TPM firmware versions fleet-wide via MDM/UEM — Use Intune, SCCM, or your UEM platform to inventory TPM firmware versions across all managed endpoints. Identify hosts running pre-patch firmware. This is the foundation for a targeted remediation campaign. No mitigation SLA applies at MEDIUM — go straight to the 365-day remediation window.
  2. Deploy OEM BIOS/firmware updates containing patched AGESA/TPM firmware — AMD, Intel, and Nuvoton have released fixes through OEM partners. Coordinate with ASUS, MSI, GIGABYTE, Lenovo, Dell, HP for BIOS updates. Prioritize hosts in environments using TPM-based attestation (WHfB, Intune compliance, 802.1X DevID). Apply within the 365-day noisgate remediation SLA.
  3. Enable TPM command audit logging — On Windows, enable TPM diagnostics via Group Policy (Computer Configuration > Administrative Templates > System > Trusted Platform Module Services). On Linux, configure tpm2-abrmd logging. This provides detection coverage for anomalous TPM command sequences that could indicate exploitation attempts.
  4. Layer conditional access beyond TPM attestation alone — Ensure conditional access policies do not rely solely on TPM attestation. Layer with user MFA, device compliance posture (OS patch level, EDR health), network location, and risk scoring. This limits the value of a forged TPM credential even if exploitation occurs.
  5. Monitor CA audit logs for anomalous certificate issuance — If you operate a TPM-aware CA (e.g., ADCS with key attestation), review certificate issuance logs for unusual enrollment patterns. Flag certificates issued to devices with mismatched hardware identifiers or unexpected re-enrollment.
What doesn't work
  • Network segmentation / firewalling — this is a local hardware vulnerability with no network attack surface. Network controls are irrelevant to the attack path.
  • EDR signature-based detection for this specific CVE — no public PoC exists, so no EDR vendor has published specific detection signatures. EDR is useful for detecting the *prerequisite* privilege escalation, not the TPM exploitation itself.
  • TPM clearing / ownership reset without firmware update — clearing the TPM does not fix the underlying firmware vulnerability. The slot-reuse flaw persists until firmware is patched. Clearing only removes existing keys.
06 · Verification

Crowdsourced verification payload.

Run on each target Windows host as Administrator. Example: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-6726.ps1. Requires admin privileges to query TPM firmware version. For Linux hosts with AMD fTPM, check BIOS/AGESA version instead.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# Check-CVE-2026-6726.ps1
# Checks TPM firmware version against known-vulnerable ranges for CVE-2026-6726
# Run as Administrator on target Windows host
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

$ErrorActionPreference = 'Stop'

try {
    $tpm = Get-TpmStatus -ErrorAction Stop
    if (-not $tpm.TpmPresent) {
        Write-Output "UNKNOWN - No TPM detected on this system"
        exit 2
    }

    $tpmInfo = Get-CimInstance -Namespace 'root\cimv2\Security\MicrosoftTpm' -ClassName 'Win32_Tpm' -ErrorAction Stop
    $manufacturer = $tpmInfo.ManufacturerIdTxt
    $fwVersion = $tpmInfo.ManufacturerVersion
    $specVersion = $tpmInfo.SpecVersion

    Write-Output "TPM Manufacturer: $manufacturer"
    Write-Output "Firmware Version: $fwVersion"
    Write-Output "Spec Version:     $specVersion"

    # Check if TPM 2.0
    if ($specVersion -notlike '2.0*') {
        Write-Output "UNKNOWN - TPM is not version 2.0; CVE-2026-6726 applies to TPM 2.0 only"
        exit 2
    }

    # Nuvoton NPCT7xx check
    if ($manufacturer -match 'NTC|Nuvoton') {
        # Vulnerable: < 7.2.4.1 or exactly 7.2.5.0
        # Fixed: >= 7.2.4.1 (in 7.2.4.x line) or >= 7.2.5.1
        if ($fwVersion -match '^7\.2\.5\.0$') {
            Write-Output "VULNERABLE - Nuvoton firmware $fwVersion is affected by CVE-2026-6726"
            exit 1
        }
        try {
            $parts = $fwVersion.Split('.') | ForEach-Object { [int]$_ }
            $ver = [version]$fwVersion
            $fixed = [version]'7.2.4.1'
            if ($ver -lt $fixed) {
                Write-Output "VULNERABLE - Nuvoton firmware $fwVersion is below fixed version 7.2.4.1"
                exit 1
            } else {
                Write-Output "PATCHED - Nuvoton firmware $fwVersion is at or above fixed version"
                exit 0
            }
        } catch {
            Write-Output "UNKNOWN - Could not parse Nuvoton firmware version: $fwVersion"
            exit 2
        }
    }

    # AMD fTPM check - rely on BIOS/AGESA version
    if ($manufacturer -match 'AMD') {
        Write-Output "UNKNOWN - AMD fTPM detected. Firmware is updated via BIOS/AGESA update."
        Write-Output "Check your OEM support site for BIOS updates addressing CVE-2026-6726."
        Write-Output "Current BIOS info:"
        $bios = Get-CimInstance -ClassName Win32_BIOS
        Write-Output "  BIOS Version: $($bios.SMBIOSBIOSVersion)"
        Write-Output "  BIOS Date:    $($bios.ReleaseDate)"
        exit 2
    }

    # Intel fTPM check
    if ($manufacturer -match 'INTC|Intel') {
        Write-Output "UNKNOWN - Intel fTPM detected. Check Intel SA advisory and OEM BIOS updates for CVE-2026-6726 fix status."
        Write-Output "Firmware version: $fwVersion"
        exit 2
    }

    # Other manufacturers
    Write-Output "UNKNOWN - Manufacturer '$manufacturer' not in known-affected list. Check vendor advisory."
    exit 2

} catch {
    Write-Output "UNKNOWN - Error querying TPM: $($_.Exception.Message)"
    exit 2
}
07 · Bottom Line

If you remember one thing.

TL;DR
CVE-2026-6726 is a real flaw in a foundational security primitive, but it is a post-compromise, local-only, per-host identity forgery issue — not a fire drill. As a MEDIUM under the noisgate framework, there is no mitigation SLA — go straight to the 365-day noisgate remediation SLA by applying OEM BIOS/firmware updates. Prioritize hosts in environments that enforce TPM-based attestation (Windows Hello for Business, Intune device compliance, 802.1X DevID). Monday morning: task your endpoint team to run a TPM firmware version inventory via your MDM/UEM, identify the vulnerable population, and begin scheduling BIOS updates through your normal firmware patching cycle. If you do not use TPM attestation for any access-control decision, this drops further in your backlog. No emergency patching is warranted.

Sources

  1. CERT/CC VU#431093 — TCG TPM 2.0 information leakage and timing side-channel advisory
  2. Nuvoton SA-006 — Information leakage via falsified TPM keys
  3. AMD Security Bulletin SB-7064 — TPM Reference Code Errata
  4. Lenovo PS500722 — TPM 2.0 Reference Code Vulnerability (Firmware TPMs)
  5. CISA ICS Advisory ICSA-26-111-01 — Siemens TPM 2.0
  6. Quarkslab — Vulnerabilities in the TPM 2.0 reference implementation code
  7. CISA Known Exploited Vulnerabilities Catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.