Keylime Pie with a Side of Open Access: The CVE-2026-1709 Deep Dive

Keylime is the sort of tool you deploy when you are paranoid. It is a Cloud Native Computing Foundation (CNCF) project built for remote boot attestation. It uses Trusted Platform Modules (TPMs) to cryptographically prove that a remote server hasn't been tampered with. It is the digital equivalent of a guard dog that checks your ID badge, scans your retina, and takes a blood sample before letting you into the data center.

At the heart of this paranoid ecosystem sits the Registrar. The Registrar is the database of record for all Keylime agents. When a new node comes online, it talks to the Registrar. When the Verifier needs to check a node's integrity, it talks to the Registrar. Because this component holds the public keys and metadata for the entire fleet, it is supposed to be locked down tighter than a drum. Access is strictly controlled via Mutual TLS (mTLS).

Or at least, it was supposed to be. In version 7.12.0, a change was introduced that turned that snarling guard dog into a golden retriever. Instead of demanding a valid client certificate, the Registrar was configured to merely suggest one. If you showed up without ID, it just wagged its tail and let you in.

To understand this bug, you have to understand Python's ssl module. It offers a few modes for verification, specifically CERT_REQUIRED and CERT_OPTIONAL.

To a weary developer or a rushed sysadmin, CERT_OPTIONAL sounds like a reasonable fallback: "Check the cert if they have one, but maybe let them handle authentication at the application layer if they don't." That is not what it does in this context.

When verify_mode is set to ssl.CERT_OPTIONAL, the server requests a certificate during the TLS handshake. If the client sends one, the server validates it. If the client sends nothing, the server says, "Fair enough, come on in." It is the "Fail Open" of cryptography. For a system like Keylime, which relies entirely on mTLS for authentication (it doesn't typically use passwords or tokens for these service-to-service calls), setting this mode is equivalent to removing the lock from the door entirely.

The vulnerability lived in keylime/web/base/server.py. The initialization logic for the web server creates an SSL context. Interestingly, the helper function web_util.init_mtls actually did its job correctly—it returned a context with verification set to CERT_REQUIRED.

But then, the Server class explicitly overruled it. Here is the smoking gun from the vulnerable code:

def _use_config(self, component: str) -> None:
    # ... configuration loading ...
    self._ssl_ctx = web_util.init_mtls(component)
    self._ssl_ctx.verify_mode = CERT_OPTIONAL  # <--- The root of all evil

That single line, added in version 7.12.0, effectively disabled the security model for the Registrar. It explicitly told the SSL context to stop enforcing the requirement for client certificates. The fix, implemented in commit a37fe134e6d22e52f5cbd07e0c9bfca9d5c8a31d, was embarrassingly simple: just delete the line.

Exploiting this does not require a zero-day in the kernel or heap Feng Shui. It requires curl. Because the server negotiates the TLS handshake without demanding a certificate, any tool that speaks HTTPS can interact with the API.

The Attack Chain:

1. Recon: Identify a Keylime Registrar. It typically listens on port 8891.
2. Access: Send a request without providing a client certificate.

# List all agents (The "Who is here?" attack)
curl -k https://target-registrar:8891/agents/
 
# Delete an agent (The Denial of Service attack)
curl -X DELETE -k https://target-registrar:8891/agents/c4a929fe-2e3b-4652-9b55-bf3c7e583c88

> [!NOTE] > The -k flag in curl is necessary because the attacker likely doesn't trust the server's CA, but the irony is that the server doesn't care if it trusts the attacker.

In a proper mTLS setup, the handshake would fail before the HTTP request is ever processed. Here, the handshake succeeds, and the Python application processes the request as an anonymous user, which the code logic failed to reject.

Why should you panic? If an attacker can delete agents from the Registrar, the Verifier (the component that checks health) loses track of them. The system effectively goes blind. You could have a compromised node in your cluster, but if the attacker deletes its registration, Keylime stops monitoring it.

Furthermore, the Registrar API exposes public keys and TPM metadata. While not as critical as private keys, this information allows an attacker to map out the infrastructure, identify specific hardware (via TPM Endorsement Keys), and prepare for more sophisticated attacks against specific nodes.

This is a CVSS 9.4 for a reason. It is network-accessible, requires no privileges, and completely undermines the integrity and availability of the trust system.

The fix is straightforward: upgrade. The Keylime team patched this in versions 7.12.2 and 7.13.1 by removing the offending line of code.

If you cannot upgrade immediately:

1. Firewall Rules: The Registrar should not be exposed to the open internet. Restrict access to port 8891 to only the IP addresses of your Verifier and Tenant nodes.
2. Reverse Proxy: Put Nginx or HAProxy in front of the Registrar. Configure the proxy to perform the mTLS termination. If the proxy demands a certificate, the request will never reach the vulnerable Python code without one.