A flaw was found in Keylime. An attacker with root access on an enrolled monitored machine, where the Keylime agent runs, can exploit a vulnerability in the Keylime verifier. The verifier uses a hardcoded challenge nonce for Trusted Platform Module (TPM) quote attestation instead of a cryptographically random value. This allows the attacker to stockpile valid TPM quotes and replay them to evade detection after compromising the system. This issue affects only the push model deployment.

CVE-2026-6420: Hardcoded attestation challenge nonce allows replay attacks

Impact

The CertificationParameters.generatechallenge() method in the push attestation protocol uses a hardcoded challenge nonce instead of generating a cryptographically random value. This removes the nonce-based replay protection from TPM quote attestation.

An attacker with root access on a monitored agent node can exploit this by stockpiling valid TPM quotes (using tpm2quote with the known nonce) before compromising the system, then replaying them to evade detection by the verifier. The push attestation timeout (~10s) constrains the generation window, but TPM throughput allows stockpiling ~50-200 quotes, enabling approximately 8-33 minutes of undetected compromise with default settings.

The attack is limited to a single agent node (AK signature binding prevents cross-agent replay). The pull-mode (legacy) attestation path is not affected.

Affected versions: >= 7.14.0, <= 7.14.1

CVSS: 6.3 Medium (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L)

| Metric | Value | Rationale | |---|---|---| | AV | Local | Exploitation requires local access to the agent machine (stop agent, access TPM, run replacement). The network transmission of quotes to the verifier is normal protocol operation. | | AC | Low | Deterministic attack: publicly visible nonce, standard tpm2-tools, no race conditions. | | PR | High | Root on a legitimate enrolled node is required. The vulnerability does not help gain access -- it only helps evade detection after root is obtained. No value against a machine the attacker already controls. | | UI | None | Fully automated after initial setup. | | S | Unchanged | AK signature binding confines impact to the single compromised agent. | | C | High | Compromised node continues receiving bootstrap keys, payloads, and secrets intended for trusted nodes. | | I | High | Verifier cannot distinguish a healthy system from a fully compromised one during the evasion window. | | A | Low | Only the compromised agent's revocation and incident response are suppressed; the system as a whole remains operational. |

The base score does not fully capture the operational severity: Keylime exists to detect machine compromise, so 8-33 minutes of undetected compromise is operationally critical. The fix is a one-line change and should be applied immediately regardless of the base score.

Patches

The fix restores the original random nonce generation (one-line change in keylime/models/verifier/evidence.py):

python Before (vulnerable): def generatechallenge(self, bitlength): # self.challenge = Nonce.generate(bitlength) self.challenge = bytes.fromhex("49beed365aac777dae23564f5ad0ec")

After (fixed): def generatechallenge(self, bitlength): self.challenge = Nonce.generate(bitlength)

Users should upgrade to the version containing this fix (7.14.2).

Workarounds

There is no complete workaround. The following existing mechanisms provide partial mitigation and are already active by default (no configuration needed):

1. TPM clock monotonicity check limits each distinct stockpiled quote to a single use, bounding the total evasion time. 2. Push attestation timeout (default 10s) prevents the attacker from going silent and constrains the quote generation window.

Reducing quoteinterval increases the attestation frequency but does not prevent the stockpiling attack.

References

- CWE-329: Generation of Predictable IV/Nonce (primary -- hardcoded nonce in cryptographic attestation protocol) - CWE-547: Use of Hard-Coded, Security-relevant Constants (hardcoded constant left in production code) - CWE-294: Authentication Bypass by Capture-replay (consequence -- enables replay attacks) - CWE-1241: Use of Predictable Algorithm in Random Number Generator - Introducing commit: 2bf91197 via PR #1814 - TCG TPM 2.0 Library Specification, Part 1, Section 18.4 (TPM2Quote) - IETF RATS Architecture (RFC 9334), Section 8 (Freshness)

Impact

The Keylime registrar does not enforce mutual TLS (mTLS) client certificate authentication since version 7.12.0. The registrar's TLS context is configured with ssl.CERTOPTIONAL instead of ssl.CERTREQUIRED, allowing any client to connect to protected API endpoints without presenting a valid client certificate.

Who is impacted: - All Keylime deployments running versions 7.12.0 through 7.13.0 - Environments where the registrar HTTPS port (default 8891) is network-accessible to untrusted clients

What an attacker can do: - List all registered agents (GET /v2/agents/) - enumerate the entire agent inventory - Retrieve agent details (GET /v2/agents/{uuid}) - obtain public TPM keys, certificates, and network locations (IP/port) of any agent - Delete any agent (DELETE /v2/agents/{uuid}) - remove agents from the registry, disrupting attestation services

Note: The exposed TPM data (EK, AK, certificates) consists of public keys and certificates. Private keys remain protected within TPM hardware. The HMAC secret used for challenge-response validation is stored in the database but is not exposed via the API.

Affected versions: >= 7.12.0, <= 7.13.0

Fixed versions: 7.12.2, >= 7.13.1

Patches

A patch for the affected released versions is available. It removes the line that override the configuration of ssl.verifymode, leaving the CERTREQUIRED value set by webutil.initmtls():

diff diff --git a/keylime/web/base/server.py b/keylime/web/base/server.py index 1d9a9c2..859b23a 100644 --- a/keylime/web/base/server.py +++ b/keylime/web/base/server.py @@ -2,7 +2,6 @@ import asyncio import multiprocessing from abc import ABC, abstractmethod from functools import wraps -from ssl import CERTOPTIONAL from typing import TYPECHECKING, Any, Callable, Optional

import tornado @@ -252,7 +251,6 @@ class Server(ABC): self.httpsport = config.getint(component, "tlsport", fallback=0) self.maxuploadsize = config.getint(component, "maxuploadsize", fallback=104857600) self.sslctx = webutil.initmtls(component) - self.sslctx.verifymode = CERTOPTIONAL

def get(self, pattern: str, controller: type["Controller"], action: str, allowinsecure: bool = False) -> None: """Creates a new route to handle incoming GET requests issued for paths which match the given

Users should upgrade to the patched version once it is released.

Workarounds

If upgrading is not immediately possible, apply one of the following mitigations:

1. Network isolation (Recommended)

Restrict access to the registrar HTTPS port (default 8891) using firewall rules to allow only trusted hosts (verifier, tenant):

Example using iptables iptables -A INPUT -p tcp --dport 8891 -s <verifierip> -j ACCEPT iptables -A INPUT -p tcp --dport 8891 -s <tenantip> -j ACCEPT iptables -A INPUT -p tcp --dport 8891 -j DROP

2. Reverse proxy with mTLS enforcement

Deploy a reverse proxy (nginx, HAProxy) in front of the registrar that enforces client certificate authentication:

Example nginx configuration server { listen 8891 ssl; sslcertificate /path/to/server.crt; sslcertificatekey /path/to/server.key; sslclientcertificate /path/to/ca.crt; sslverifyclient on; # Enforce client certificates

location / { proxypass https://localhost:8892; # Internal registrar port } }

A vulnerability has been identified in keylime where an attacker can exploit this flaw by registering a new agent using a different Trusted Platform Module (TPM) device but claiming an existing agent's unique identifier (UUID). This action overwrites the legitimate agent's identity, enabling the attacker to impersonate the compromised agent and potentially bypass security controls.

A flaw was found in Keylime, a remote attestation solution, where strict type checking introduced in version 7.12.0 prevents the registrar from reading database entries created by previous versions, for example, 7.11.0. Specifically, older versions store agent registration data as bytes, whereas the updated registrar expects str. This issue leads to an exception when processing agent registration requests, causing the agent to fail.

Impact

A security issue was found in the Keylime registrar code which allows an attacker to effectively bypass the challenge-response protocol used to verify that an agent has indeed access to an AIK which in indeed related to the EK.

When an agent starts up, it will contact a registrar and provide a public EK and public AIK, in addition to the EK Certificate. This registrar will then challenge the agent to decrypt a challenge encrypted with the EK.

When receiving the wrong "authtag" back from the agent during activation, the registrar answers with an error message that contains the expected correct "authtag" (an HMAC which is calculated within the registrar for checking). An attacker could simply record the correct expected "authtag" from the HTTP error message and perform the activate call again with the correct expected "authtag" for the agent.

The security issue allows an attacker to pass the challenge-response protocol during registration with (almost) arbitrary registration data. In particular, the attacker can provide a valid EK Certificate and EK, which passes verification by the tenant (or registrar), while using a compromised AIK, which is stored unprotected outside the TPM and is unrelated to former two. The attacker then deliberately fails the initial activation call to get to know the correct "authtag" and then provides it in a subsequent activation call. This results in an agent which is (incorrectly) registered with a valid EK Certificate, but with a compromised/unrelated AIK.

Patches Users should upgrade to release 7.5.0

Impact Keylime registrar is prone to a simple denial of service attack in which an adversary opens a connection to the TLS port (by default, port 8891) blocking further, legitimate connections. As long as the connection is open, the registrar is blocked and cannot serve any further clients (agents and tenants), which prevents normal operation. The problem does not affect the verifier.

Patches Users should upgrade to release 7.4.0

A flaw was found in the keylime attestation verifier, which fails to flag a device's submitted TPM quote as faulty when the quote's signature does not validate for some reason. Instead, it will only emit an error in the log without flagging the device as untrusted.

Impact

This vulnerability creates a false sense of security for keylime users -- i.e. a user could query keylime and conclude that a parcitular node/agent is correctly attested, while attestations are not in fact taking place.

Short explanation: the keylime verifier creates periodic reports on the state of each attested agent. The keylime verifier runs a set of python asynchronous processes to challenge attested nodes and create reports on the outcome.

The vulnerability consists of the above named python asynchronous processes failing silently, i.e. quitting without leaving behind a database entry, raising an error or producing even a mention of an error in a log. The silent failure can be triggered by a small set of transient network failure conditions; recoverable device driver crashes being one such condition we saw in the wild.

Patches

The problem is fixed in keylime starting with tag 6.5.1

Workarounds

This patch can be retroactively applied to any running keylime deployment. Only running verifiers need to be patched. After the patch is applied, the keylime verifier needs to be restarted.

References

The problem, as well as the proposed fix, are described in detail here. Further details about the system where the bug was found, and the conditions in which the bug was found, are available from @galmasi on demand.

For more information

If you have any questions or comments about this advisory, please comment at the bottom of the advisory itself.

A flaw was found in keylime 5.8.1 and older. The issue in the Keylime agent and registrar code invalidates the cryptographic chain of trust from the Endorsement Key certificate to agent attestations.