GPU VulnDB

Database/Control plane, storage & DevOps

Keylime registrar: a rogue agent can claim an existing agent's UUID and overwrite its attestation identity

CVSS 8.2CVE-2025-13609Control plane, storage & DevOpscurated

Impact

Keylime is the attestation service many operators use to prove that a node booted the expected firmware and kernel before it is allowed to join the fleet or receive secrets. An attacker who can register an agent is able to re-register an existing agent's UUID with a different TPM, overwriting the legitimate node's recorded identity. From then on attestation results for that UUID describe the attacker's machine, so a tampered or untrusted GPU node can keep showing as attested while the real node's state is no longer being measured. Where attestation gates key release or admission, this turns the control that was supposed to catch a compromised node into a control that endorses one. Red Hat rates it 8.2 and notes the scope change: the damage lands outside keylime, in whatever trusts its verdict.

Who can reach it

Network reach to the keylime registrar plus the ability to run the registration flow - the CVSS vector records high privileges required (PR:H), so this is an actor who already holds agent-level credentials or control of a registered host, not an anonymous caller.

What to do

Update keylime from the distribution: Red Hat shipped fixes in RHSA-2025:23201, 23210, 23628, 23735 and 23852 for RHEL 9 and 10 streams. Cost is a package update plus a restart of the registrar and verifier services - no node drain and no reboot. After updating, review the registrar database for duplicate or recently changed UUID-to-AIK bindings, since a successful overwrite leaves a legitimate agent recorded against the wrong TPM.

References

Related entries

All Control plane, storage & DevOps 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.