CVE-2025-6203

What it actually does

A specially crafted complex request payload that still fits within Vault’s default request size limit can drive excessive memory allocation and CPU use during processing. That resource exhaustion can stall Vault’s auditing subroutine until it times out, after which the Vault process may stop serving API requests and become unresponsive.

Why it matters to the business

Vault is commonly the control plane for secrets, tokens, certificates, and encryption keys, so an unresponsive server can halt application startup, CI/CD, service-to-service authentication, and incident recovery. This issue is a high-availability risk rather than a known mass-exploitation event: it is not in CISA KEV, is not associated with ransomware, has no public exploit, and has a low EPSS (~0.007) with only a small 30-day increase. Organizations that run Vault as a production secrets backend should still treat unpatched clusters as an operational outage risk.

How an attack unfolds

An attacker who is already able to send requests to a vulnerable Vault API submits a complex payload that complies with the default size limit. Vault spends disproportionate CPU and memory handling the request; the auditing path then times out, and the server can stop responding to legitimate clients until it is restarted or otherwise recovered. No public exploit code and no named threat-actor campaigns have been tied to this vulnerability.

How to fix it

Upgrade Vault Community Edition to 1.20.3 or later, or Vault Enterprise to 1.20.3, 1.19.9, 1.18.14, or 1.16.25 (or a later release on the same branch). The upstream fix is in hashicorp/vault commit 818ca8b3575ea937ca48b640baf35e1b2ede1833. Roll the upgrade through all servers, including performance and disaster-recovery replicas, then restart in a controlled sequence so the cluster stays available. Until patched, restrict who can call the Vault API, apply identity and rate-limit policies, and keep listeners off untrusted networks. Do not treat the default request size limit as mitigation—the malicious payload is designed to fit within it.

How to confirm the fix worked

Inventory every Vault node and confirm the running version is Community 1.20.3+ or Enterprise 1.20.3, 1.19.9, 1.18.14, or 1.16.25+ using vault version/status and package or image metadata. Verify standby, performance replica, and DR nodes were upgraded and restarted, and that no leftover unpatched dev or standalone instances remain. After upgrade, exercise normal audit-enabled write paths and confirm audit devices stay healthy and the process remains responsive under expected load.

Typical attack path

1. Obtain the ability to send API requests to a vulnerable Vault listener (typically as a permitted user).
2. Submit a complex payload that remains within the default request size limit.
3. Force Vault to consume excessive CPU and memory while processing the request.
4. Cause Vault’s auditing subroutine to time out.
5. Leave the Vault server unresponsive so legitimate workloads cannot fetch secrets or complete API calls.

How to detect it

No public exploit or campaign IOCs are published for this issue, so hunt for denial-of-service symptoms rather than a unique payload. Review Vault server logs and audit-device health around API outages for audit-path timeouts, stalled requests, client timeouts, and 5xx responses. Correlate host metrics for the vault process (CPU, RSS/memory, thread or goroutine counts if collected) with failed secret reads and cluster unavailability. Look for nodes that recovered only after a process restart. Historical hunts should focus on unexplained Vault outages; a distinctive network or file IOC is not expected.

What your security team should do

• Inventory all Vault Community and Enterprise clusters and flag any node below Community 1.20.3 or Enterprise 1.20.3 / 1.19.9 / 1.18.14 / 1.16.25.
• Patch production secrets clusters first with a rolling upgrade, because availability of Vault is the primary business risk.
• Until patched, restrict Vault API access to trusted identities and networks and enable rate limiting; do not rely on request-size limits.
• Alert on Vault process CPU/memory spikes, audit-device failures or timeouts, and API unavailability that recovers only after a Vault restart.
• Given no KEV listing, no known exploit, and low EPSS, sequence work by Vault criticality, but do not leave production clusters unpatched.