Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 7.14.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 7.13.1 or 7.12.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 7.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Keylime registrar implemented more strict type checking on version 7.12.0. As a result, when updated to version 7.12.0, the registrar will not accept the format of the data previously stored in the database by versions = 7.8.0, raising an exception. This makes the Keylime registrar vulnerable to a Denial-of-Service attack in an update scenario, as an attacker could populate the registrar database by creating multiple valid agent registrations with different UUIDs while the version is still < 7.12.0. Then, when the Keylime registrar is updated to the 7.12.0 version, any query to the database matching any of the entries populated by the attacker will result in failure. Patches Users should upgrade to versions = 7.12.1 Workarounds - Remove the registrar database and re-register all agents Credit Reported by: Anderson Toshiyuki Sasaki/@ansasaki Patched by: Anderson Toshiyuki Sasaki/@ansasaki
Recommended action: Upgrade to 7.12.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 7.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 7.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 7.2.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.…
Recommended action: Upgrade to 6.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Keylime does not enforce that the agent registrar data is the same when the tenant uses it for validation of the EK and identity quote and the verifier for validating the integrity quote. This allows an attacker to use one AK, EK pair from a real TPM to pass EK validation and give the verifier an AK of a software TPM. A successful attack breaks the entire chain of trust because a not validated AK is used by the verifier. This issue is worse if the validation happens first and then the agent gets added to the verifier because the timing is easier and the verifier does not validate the regcount entry being equal to 1. At this time, there are no known workaround.
Recommended action: Upgrade to 6.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.