Trust No One (Except Everyone): The Keylime mTLS Bypass

In the world of Cloud Native computing, you can't trust the hardware you're running on. That's where Keylime comes in. It is the CNCF's heavy hitter for remote attestation—a fancy way of using a Trusted Platform Module (TPM) to mathematically prove that a server hasn't been tampered with before you send it your secrets.

The Keylime architecture relies on three pillars: the Agent (running on the node), the Verifier (checking the TPM quotes), and the Registrar. Think of the Registrar as the secure phonebook. It's the first place an Agent calls home to drop off its public keys (Endorsement Key and Attestation Identity Key). If you compromise the Registrar, you can disrupt the chain of trust before it even begins.

Usually, Keylime is paranoid. It uses Mutual TLS (mTLS) for everything. The Agent needs a cert, the Verifier needs a cert, and the Registrar needs a cert. It's a zero-trust party where everyone checks ID at the door. Or at least, it was supposed to be.

The vulnerability (CVE-2026-1709) is a classic case of 'Explicit is better than Implicit, unless you explicitly choose the wrong setting.'

In Python's ssl module, SSLContext.verify_mode controls how the server treats client certificates. A secure mTLS setup requires ssl.CERT_REQUIRED. This tells the server: 'If the client doesn't show a valid certificate signed by our CA, hang up immediately.'

However, in Keylime versions 7.12.0 through 7.13.0, the code was changed to use ssl.CERT_OPTIONAL. In the documentation, this mode sounds harmless enough: it asks for a certificate if the client has one. But the fatal nuance is what happens when the client doesn't have one. With CERT_OPTIONAL, the handshake succeeds anonymously.

It's like a bouncer at a club who asks for ID, but if you just shrug and say 'I left it at home,' he lets you in anyway. The authentication logic downstream assumed that if a connection existed, it must have been authenticated. It was not.

Let's look at the smoking gun in keylime/web/base/server.py. The developers had a perfectly good helper function, web_util.init_mtls, which presumably set up the context correctly. But then, they manually overrode it.

Here is the diff that fixed the issue. Notice the line being removed:

# keylime/web/base/server.py
 
  self._ssl_ctx = web_util.init_mtls(component)
- self._ssl_ctx.verify_mode = CERT_OPTIONAL

That single line, - self._ssl_ctx.verify_mode = CERT_OPTIONAL, was the kill switch for authentication. It effectively downgraded the Registrar's API from a fortress to a public library. By removing this line in the patch, the _ssl_ctx reverts to the default secure settings defined in init_mtls, which enforces CERT_REQUIRED.

Exploiting this does not require heap spraying, ROP chains, or race conditions. You just need curl and a lack of manners.

Normally, to talk to the Registrar, you'd need a command like this:

curl --cert client.crt --key client.key --cacert ca.crt https://registrar:8891/v2/agents/

But thanks to CERT_OPTIONAL, an attacker on the same network can simply do:

# The --insecure flag here just ignores the server's cert validity,
# but crucially, we are NOT providing a client cert.
curl --insecure https://registrar:8891/v2/agents/

The Result: Instead of a 401 Unauthorized or a TLS handshake failure, the server happily responds with a JSON list of all registered agents and their statuses.

From there, the attacker can:

1. Recon: List every node in the cluster.
2. Intel: Query specific UUIDs (/v2/agents/{uuid}) to grab public keys.
3. Destruction: Issue a DELETE request to /v2/agents/{uuid}. This deregisters the node. When the Verifier next tries to attest that node, it will fail, likely causing the orchestration layer (Kubernetes/OpenShift) to mark the node as untrusted and terminate workloads. It is a trivial Denial of Service against the infrastructure's trust layer.

If you are running Keylime 7.12.x or 7.13.0, you are vulnerable. The fix is straightforward:

1. Patch Immediately: Upgrade to 7.12.2 or 7.13.1. These versions remove the dangerous CERT_OPTIONAL override.
2. Network Segmentation: Why is your management interface exposed to the general network? Restrict access to port 8891. Only the Tenant CLI and the Agents need to talk to the Registrar. Firewall everything else.
3. Reverse Proxy: If you can't patch immediately, place an Nginx or HAProxy instance in front of the Registrar. Configure the proxy to enforce ssl_verify_client on; (in Nginx) and forward the traffic only if the certificate is valid.