GPU VulnDB

Database/Firmware, BMC & network fabric

TPM 2.0 reference code: leak lets a privileged local user obtain a CA credential for a falsified TPM key

CVSS 7.9CVE-2026-6726Firmware, BMC & network fabriccurated

Impact

An information leak in the TCG TPM 2.0 reference implementation lets a local attacker who already holds elevated privileges get a TPM-aware CA to issue a credential for a key that is not actually TPM-resident - an attestation key, a DevID, or a TLS authentication key - and then produce further TPM 2.0 attestations with it. For a GPU datacenter, the value at risk is everything built on the TPM being the anchor: node identity for provisioning, measured-boot attestation before a node is admitted to a cluster, and TLS identities issued to nodes on that basis. A compromised node can present itself as healthy and correctly measured, and can mint an identity that a management plane will trust, which defeats the check that was supposed to catch the compromise. The record is a TCG advisory against the reference code; which shipped TPM parts and firmware levels inherit it depends on each silicon and platform vendor.

Who can reach it

A local attacker on the host with elevated privileges (root or equivalent) able to issue commands to the TPM. Not remotely reachable and not available to an unprivileged tenant process; the realistic path is a node already compromised at the OS level, or an insider with administrative access to a node.

What to do

There is no software patch an operator applies directly - the fix flows from the TCG errata for the TPM 2.0 library specification into TPM vendor firmware and then into platform BIOS/BMC bundles. Track your TPM and server vendors for a firmware release citing TCG VRT0010, and plan a firmware flash with the node out of service; on many platforms a TPM firmware update also requires re-provisioning the endorsement/attestation hierarchy and re-enrolling the node, so budget for re-issuing node identities and re-sealing anything bound to PCRs. Until then, treat TPM-backed attestation as evidence that a node was not tampered with by an unprivileged attacker, not as proof against a root-level compromise, and keep the CA that issues credentials on TPM evidence under separate review.

References

Related entries

All Firmware, BMC & network fabric entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.