A newly disclosed vulnerability, CVE-2026-5052, impacts HashiCorp Vault's Public Key Infrastructure (PKI) engine, particularly when using the Automatic Certificate Management Environment (ACME) protocol. The flaw allows attackers to trick Vault into sending ACME validation requests to local network addresses, leading to possible information disclosure.

This post breaks down what happened, why it’s dangerous, how you might exploit it, and what has been done to fix it – all in straightforward language.

What Is the Vault PKI ACME Endpoint?

HashiCorp Vault is a popular tool for managing secrets and certificates. Its PKI engine can act as a certificate authority, handing out TLS certificates via an API.

The ACME protocol (used by Let's Encrypt) lets devices and websites prove they own a domain by solving challenges like http-01 and tls-alpn-01. Normally, Vault, when acting as an ACME server, makes requests to the public internet to validate these challenges.

What Went Wrong: The Bug Explained

In versions before the fix, Vault’s ACME endpoint did not check if the validation challenge was pointing to a local or private IP address.

Why Is This Bad?

An attacker could register a challenge for a hostname or an IP address pointing inside your company (like localhost or a machine on 10.../8). Vault would obediently send network requests there to validate the challenge.

- Information Disclosure: If that internal service gives up useful info when it receives unexpected HTTP(s) requests, that might be leaked to outside attackers.

Example Exploit Scenario

A malicious user requests a certificate from Vault via ACME using a challenge pointing to an internal address.

Step 1: Register a DNS name (if DNS-01 is also misconfigured, but with this bug, even a direct IP can be used).

Step 2: Supply a validation target like 127...1 or 10.1.2.3 for the http-01 challenge.

Step 3: Vault's ACME engine sends an HTTP or TLS request to that local address.

Step 4: The internal service receives the crafted request and potentially leaks data.

Pseudo Code Example

# Step 1: Run a dummy HTTP server inside internal network
python3 -m http.server 808

# Step 2: Craft an ACME client to request a cert with the challenge for 127...1
acme-client --directory https://vault:820/v1/pki/acme/directory \
  --challenge http-01 \
  --hostname 127...1 \
  --address 127...1:808

Or, in Go

// Not full ACME client - concept
http.Post("https://vault:820/v1/pki/acme/challenge";,
  "application/json",
  strings.NewReader(`{
     "type": "http-01",
     "identifier": {"type":"ip", "value":"127...1"}
  }`))

Result: Vault reaches toward 127...1 (or another internal target), crossing intended boundaries.

Internal APIs might be hit by Vault with attacker-controlled payloads.

- Sensitive information might be disclosed if internal services respond with secrets, error messages, or headers.

Fixed Versions

The bug affects Vault Community Edition and Enterprise Edition with the PKI ACME engine enabled.

Vault Enterprise: 2.., 1.21.5, 1.20.10, 1.19.16

Upgrading is critical! Those versions now block challenges for local and private targets.

Network Isolation: Make sure Vault only has the necessary network access.

4. Monitor Logs: Look for suspicious ACME challenge requests targeting internal IPs/hostnames.

Technical References

- Vault Changelog
- Official Security Advisory from HashiCorp
- ACME RFC 8555 Specification

Conclusion

CVE-2026-5052 is a classic example of “Don’t trust user-supplied input” — especially in certificate workflows managing trust. If you’re using Vault’s PKI ACME features, patch now and audit your configs.

Timeline

Published on: 04/17/2026 02:55:25 UTC
Last modified on: 04/17/2026 17:57:55 UTC