CVE-2024-7594: HashiCorp Vault Auth Bypass Vulnerability

CVE-2024-7594 Overview

CVE-2024-7594 is an improper access control vulnerability affecting HashiCorp Vault's SSH secrets engine. The vulnerability exists because Vault did not require the valid_principals list to contain a value by default. When both the valid_principals and default_user fields of the SSH secrets engine configuration are left unset, an SSH certificate requested by an authorized Vault user could be exploited to authenticate as any user on the target host, leading to unauthorized access and potential privilege escalation.

Critical Impact

Authorized Vault users can obtain SSH certificates that allow authentication as any user on target hosts, potentially compromising entire systems and enabling lateral movement across infrastructure.

Affected Products

• HashiCorp Vault Community Edition (versions prior to 1.17.6)
• HashiCorp Vault Enterprise (versions prior to 1.17.6, 1.16.10, and 1.15.15)
• OpenBao OpenBao

Discovery Timeline

• 2024-09-26 - CVE-2024-7594 published to NVD
• 2025-11-13 - Last updated in NVD database

Technical Details for CVE-2024-7594

Vulnerability Analysis

This vulnerability stems from insecure default configuration in HashiCorp Vault's SSH secrets engine. The SSH secrets engine provides a mechanism for generating signed SSH certificates that can be used for authentication to remote hosts. The security model relies on properly constraining which user principals (usernames) a certificate can authenticate as.

The vulnerability manifests when administrators configure the SSH secrets engine without explicitly setting the valid_principals list or the default_user field. In this misconfigured state, the secrets engine does not impose any restrictions on which principals can be included in generated certificates. This allows any authorized Vault user with permission to request SSH certificates to specify arbitrary principals, effectively granting them the ability to authenticate as any user on hosts that trust the Vault CA.

The impact of this vulnerability is significant because it undermines the principle of least privilege. Users who should only have access to specific service accounts could escalate their access to root or other privileged accounts on target systems.

Root Cause

The root cause is classified under CWE-732 (Incorrect Permission Assignment for Critical Resource). The SSH secrets engine failed to enforce a mandatory security constraint by allowing the valid_principals configuration field to remain empty by default. Without this constraint, the engine cannot properly limit which user identities can be assumed through generated certificates, creating an authorization bypass condition.

Attack Vector

The attack vector is network-based and requires the attacker to have valid credentials to authenticate to Vault and possess the necessary Vault policies to request SSH certificates from the misconfigured secrets engine. The attack flow involves:

1. An authorized user identifies an SSH secrets engine role where valid_principals is unconfigured
2. The attacker requests an SSH certificate with an arbitrary principal (e.g., root)
3. Vault generates and signs the certificate without validating the principal
4. The attacker uses the certificate to authenticate to target hosts as the specified user
5. The attacker gains unauthorized access with the privileges of the impersonated user

The vulnerability does not require user interaction and can be exploited with low complexity once the prerequisite access is obtained. Successful exploitation can result in complete compromise of confidentiality, integrity, and availability on affected hosts.

Detection Methods for CVE-2024-7594

Indicators of Compromise

• Unusual SSH certificate requests with principals that don't match the requesting user's authorized scope
• Authentication logs showing unexpected user logins via SSH certificates
• Vault audit logs containing certificate requests for privileged accounts like root or service accounts
• Multiple SSH certificates issued for different principals to the same Vault identity

Detection Strategies

• Review Vault audit logs for SSH certificate generation requests, particularly those specifying high-privilege principals
• Monitor SSH authentication logs on target hosts for certificate-based authentications from unexpected principals
• Implement alerting on SSH secrets engine role configurations that lack valid_principals settings
• Cross-reference Vault user identities with the principals they request in SSH certificates

Monitoring Recommendations

• Enable comprehensive audit logging in Vault to capture all secrets engine interactions
• Configure centralized log aggregation for both Vault and SSH authentication events
• Establish baseline patterns for SSH certificate usage and alert on anomalies
• Periodically audit SSH secrets engine role configurations for missing valid_principals constraints

How to Mitigate CVE-2024-7594

Immediate Actions Required

• Upgrade HashiCorp Vault Community Edition to version 1.17.6 or later
• Upgrade HashiCorp Vault Enterprise to versions 1.17.6, 1.16.10, or 1.15.15 depending on your release branch
• Review all SSH secrets engine role configurations and ensure valid_principals is explicitly set
• Audit recent SSH certificate requests for potential exploitation indicators

Patch Information

HashiCorp has released fixed versions that address this vulnerability. The patches ensure proper validation and enforcement of the valid_principals configuration. Detailed information is available in the HashiCorp Security Advisory HCSEC-2024-20. Additional vendor impact information is documented in the NetApp Security Advisory NTAP-20250110-0007.

Workarounds

• Explicitly configure the valid_principals list on all SSH secrets engine roles to limit allowed principals
• Set the default_user field to a non-privileged account to prevent arbitrary principal specification
• Implement Vault Sentinel policies (Enterprise) to enforce valid_principals configuration requirements
• Restrict Vault policies to limit which users can request SSH certificates

# Configuration example - Properly configure SSH secrets engine role
vault write ssh/roles/my-role \
    key_type=ca \
    allowed_users="deploy,service-account" \
    default_user="deploy" \
    ttl=30m \
    allow_user_certificates=true