CVE-2024-5798 - How a JWT Audience Validation Bug in HashiCorp Vault Could Let Attackers In

Vault and Vault Enterprise are powerful tools for managing secrets and protecting sensitive data. Many organizations trust them for critical workloads. But in June 2024, a new vulnerability—CVE-2024-5798—was revealed. This bug could have let an attacker log in with an invalid JWT (JSON Web Token) under certain conditions. Let's break it down, see why it happened, and walk through a practical example of how exploitation could work.

What Is CVE-2024-5798?

Vault has an authentication method called JWT auth. It lets users log in with a JWT token that's typically issued by an identity provider (IDP). One key check during login is that the JWT token’s audience claim (aud) matches what the Vault role expects. If the check is too weak or absent, someone with a stolen or crafted JWT could log in as a user they’re NOT supposed to be.

In short:
*Vault did not properly validate the “audience” (aud) claim in JWT tokens, possibly letting logins happen that should have failed.*

Versions before 1.17., 1.16.3, and 1.15.9

- Anyone using the Vault JWT Auth Method.

Why Does JWT Audience Claim Matter?

The aud claim in a JWT is meant to specify who the token is for.
A secure system must ensure the aud matches the role-bound audience in Vault’s JWT configuration.

Example

{
  "iss": "https://your-idp.com/";,
  "sub": "user123",
  "aud": "vault-production-role"
}

If someone can hand in a JWT with the wrong audience, or even none at all, that should not be accepted.

The Bug in Detail

The bug here was that Vault didn’t enforce the role-bound audience claim *strictly* enough.
That means if you sent a JWT with a mismatched or missing aud claim, Vault might still validate it, and let you log in—even when it shouldn’t.

Relevant Fix in the Code

This commit in the Vault repo shows the patch:

if !contains(role.Audiences, claims.Audience) {
    return nil, errors.New("audience claim does not match")
}

Before the fix, it would not always check that the aud matched the set audiences for the role.

How Could It Be Exploited?

Let’s say an attacker gets a JWT from a legitimate system, but it’s for another audience (maybe for a different app, or for testing purposes).
*Because Vault wasn't checking the aud claim properly, they could just use this JWT to log in.*
Vault would think it’s fine, even though the JWT wasn’t intended for Vault at all.

Here’s an example using curl

export FAKE_JWT="ey...<snip>...g"

curl -s --request POST \
    --data "{\"jwt\":\"${FAKE_JWT}\", \"role\":\"privileged-role\"}" \
    http://vault.example.com:820/v1/auth/jwt/login

With the fix, the response is

{
  "errors": [
    "audience claim does not match"
  ]
}

But without the fix, you may get back a working Vault token, and access you should never have had!

Vault 1.15.9

- HashiCorp Advisory
- GitHub Security Advisory

Final Thoughts

JWT flaws like CVE-2024-5798 are subtle but very dangerous—they let attackers bypass crucial login checks and get into places they should never reach. If you’re using Vault with JWT, patch ASAP. Always make sure your tokens are strictly validated, especially on claims like aud.

Timeline

Published on: 06/12/2024 19:15:51 UTC
Last modified on: 06/13/2024 19:32:53 UTC