CVE-2024-5798 Overview
CVE-2024-5798 is an authentication bypass vulnerability in HashiCorp Vault and Vault Enterprise. The flaw resides in the JWT authentication method, where Vault did not properly validate the role-bound audience (aud) claim within a JSON Web Token (JWT). As a result, Vault could accept tokens whose audience claim did not match the audience bound to the role, permitting invalid logins that should have been rejected. HashiCorp addressed the issue in Vault and Vault Enterprise 1.17.0, 1.16.3, and 1.15.9. The weakness is classified as improper authentication [CWE-287].
Critical Impact
Attackers who can present a JWT signed by a trusted issuer can authenticate against Vault roles without matching the required audience, bypassing an intended access control boundary.
Affected Products
- HashiCorp Vault versions prior to 1.15.9
- HashiCorp Vault versions 1.16.0 through 1.16.2
- HashiCorp Vault Enterprise equivalents prior to 1.17.0
Discovery Timeline
- 2024-06-12 - CVE-2024-5798 published to the National Vulnerability Database
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-5798
Vulnerability Analysis
The Vault JWT authentication method allows clients to authenticate by presenting a signed JWT. Vault roles can be constrained by bound_audiences, which specifies the audience values Vault must find in the token's aud claim before granting a login. In affected versions, Vault did not correctly enforce this comparison. When the token's audience did not match the role's bound_audiences, the validation logic still permitted the login to succeed. The confidentiality and availability of the system are not directly impacted, but integrity is compromised because Vault produces an authentication decision inconsistent with the configured role policy.
Root Cause
The root cause is improper authentication logic in the JWT auth backend [CWE-287]. Audience validation is a fundamental JWT security control defined in RFC 7519, ensuring a token intended for one recipient cannot be reused against another. The flawed code path failed to reject tokens whose aud claim did not match the role's bound audience, breaking the intended trust boundary between roles and issuers.
Attack Vector
Exploitation requires the attacker to obtain or generate a JWT signed by an issuer that Vault trusts under any JWT auth role. Because Vault did not enforce audience binding correctly, that token could then be presented against a different role with a mismatched audience. The role's policies would be granted despite the mismatch. The attack is network-reachable and requires no user interaction or prior Vault privileges. No verified public exploit code is available for this vulnerability. Consult the HashiCorp Security Advisory HCSEC-2024-11 for authoritative technical details.
Detection Methods for CVE-2024-5798
Indicators of Compromise
- Successful login audit events on JWT auth mounts where the token's aud claim does not match the role's bound_audiences configuration.
- Authentication events originating from JWT issuers or client identifiers not previously observed for a given Vault role.
- Unexpected policy grants tied to JWT auth roles, especially roles associated with CI/CD or Kubernetes workloads.
Detection Strategies
- Review Vault audit logs for auth/jwt/login requests and correlate the presented JWT aud claim against each role's bound_audiences value.
- Enumerate configured JWT roles using vault read auth/jwt/role/<name> and validate that every role has a non-empty, restrictive bound_audiences list.
- Alert on Vault versions running below the patched releases (1.15.9, 1.16.3, 1.17.0) using inventory or configuration management data.
Monitoring Recommendations
- Forward Vault audit device logs to a centralized log platform and retain them for at least the token's maximum TTL window.
- Baseline expected JWT issuers, subjects, and audiences per role, and alert on deviations.
- Track privileged secret access following any JWT login to identify potential post-authentication abuse.
How to Mitigate CVE-2024-5798
Immediate Actions Required
- Upgrade Vault or Vault Enterprise to 1.17.0, 1.16.3, 1.15.9, or later without delay.
- Audit all JWT auth roles and confirm bound_audiences, bound_subject, and bound_claims values enforce least privilege.
- Rotate any Vault-issued tokens and downstream secrets that may have been retrieved via JWT auth during the exposure window.
Patch Information
HashiCorp fixed the vulnerability in Vault and Vault Enterprise 1.17.0, 1.16.3, and 1.15.9. Details are documented in the HashiCorp Security Advisory HCSEC-2024-11. Operators should follow HashiCorp's standard upgrade procedure for their deployment topology (single node, HA cluster, or Enterprise replication).
Workarounds
- If immediate upgrade is not possible, restrict which JWT issuers Vault trusts by scoping jwks_url, oidc_discovery_url, or jwt_validation_pubkeys to the minimum necessary issuers.
- Tighten each role with additional bound_claims and bound_subject constraints so that audience misvalidation alone is insufficient for a successful login.
- Restrict network access to the Vault API so that only trusted workloads and administrative networks can reach the JWT auth endpoint.
# Configuration example: review and harden a JWT auth role
vault read auth/jwt/role/my-role
vault write auth/jwt/role/my-role \
bound_audiences="https://vault.example.com/my-role" \
bound_subject="repo:my-org/my-repo:ref:refs/heads/main" \
bound_claims_type="string" \
user_claim="sub" \
token_policies="my-role-policy" \
token_ttl="15m"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

