*Published: June 2024*  
*By: [Your Name or Alias]*


HashiCorp Vault is a popular tool for securing secrets, tokens, and certificates in the cloud-native world. But in 2022, security researchers and the HashiCorp team unearthed a subtle but critical vulnerability — CVE-2022-41316 — that undermined the expected trust of its TLS certificate authentication. This post breaks down how this bug worked, what it meant for real-world users, and how you can keep your Vault safe.

What is CVE-2022-41316?

In a nutshell, CVE-2022-41316 is an authentication vulnerability that crept into HashiCorp Vault and Vault Enterprise's TLS certificate auth method. When Vault started up, it didn’t always load the Certificate Revocation List (CRL) from memory, even if you had a CRL configured. This gap left a hole where revoked certificates might slide by, allowing unauthorized users access — that you meant to explicitly block!

Breaking That Down…

- CRLs are lists of certificates that the CA has explicitly marked as “NOT TRUSTED.” Think “security stoplist.”

If a client uses a revoked certificate, Vault should block them.

- BUT, until Vault fetched the CRL (which could be delayed), it wouldn’t check if a cert was revoked.

If you were running these Vault versions, you were vulnerable

- Vault/Enterprise 1.9.x: before 1.9.10
- Vault/Enterprise 1.10.x: before 1.10.7
- Vault/Enterprise 1.11.x: before 1.11.4
- Vault/Enterprise 1.12.x: before 1.12. (but 1.12. and later are safe)

Why is This Dangerous?

Imagine you revoked someone’s certificate for leaving your company or misbehaving. You set up Vault to check a CRL. You expect: “That cert shouldn’t ever work again.”  
Reality (with the bug): If Vault is just starting up (or hasn’t refreshed the CRL), it might not even look at the CRL when these users try to log in.

You restart Vault — maybe for a config change or upgrade.

3. Before Vault fetches/reloads the CRL, attacker presents the revoked certificate.

Vault authenticates the attacker! 🙁

> ⚠️ If you use short CRL fetch intervals, you *minimize* this attack window, but can’t remove it!

Here’s what a basic TLS cert authentication could look like in Vault

# Enable cert auth method
vault auth enable cert

# Configure a role that trusts your CA
vault write auth/cert/roles/goodguys \
    allowed_cn="legit-user.example.com" \
    certificate=@/path/to/ca.pem \
    crl_distribution_point="http://ca.example.com/crl.pem";

With the vulnerability, when Vault starts, it should ideally fetch http://ca.example.com/crl.pem right away — but if it doesn't, the CRL in memory is *empty*, and NO revocation checks are meaningfully done until Vault fetches the CRL later.

Try to authenticate using the now-revoked cert.

5. If Vault authenticates you before it reloads/fetches the CRL, the bug is present!

Python Example: Authenticate with Revoked Cert

import requests

# These should point to your Vault and a revoked client cert
VAULT_ADDR = "https://vault.example.com:820";
CLIENT_CERT = ("revoked-cert.pem", "revoked-key.pem")

resp = requests.post(
    f"{VAULT_ADDR}/v1/auth/cert/login",
    cert=CLIENT_CERT,
    verify="vault-ca.pem"
)
print(resp.json())

With the bug: You may get a Vault token.  
Without the bug: You should get a 400 error like "certificate revocation check failed".

The Fix

HashiCorp’s fix ensures Vault *loads the CRL into memory on startup*, so even right after a restart the latest list of revoked certs is in use.

If you can’t upgrade right away

- Lower the CRL refresh interval to the fastest possible (e.g., every minute), so the attack window is minimal.

Final Notes

Certificate revocation is a critical security function. Even a few minutes of “blindness” could let a bad actor in, so take this bug seriously if you use Vault’s cert-based authentication.

References

- HashiCorp Security Bulletin
- CVE-2022-41316 at NVD
- Vault Documentation on Cert Auth


Stay safe. Double-check your CRL config — and keep Vault freshly updated!  
Have questions? Leave a comment or reach out for more Vault tips.


*Exclusively compiled and written for [Your Blog or Website], June 2024*

Timeline

Published on: 10/12/2022 21:15:00 UTC
Last modified on: 10/13/2022 17:37:00 UTC