CVE-2025-59043: OpenBao vulnerable to denial of service via malicious JSON request processing
Summary
JSON objects after decoding might use more memory than their serialized version. It is possible to tune a JSON to maximize the factor between serialized memory usage and deserialized memory usage (similar to a zip bomb). While reproducing the issue, we could reach a factor of about 35. This can be used to circumvent the [maxrequestsize (https://openbao.org/docs/configuration/listener/tcp/) configuration parameter, which is meant to protect against Denial of Service attacks, and also makes Denial of Service attacks easier in general, as the attacker needs much less resources.
Details
The request body is parsed into a map[string]interface{} https://github.com/openbao/openbao/blob/788536bd3e10818a7b4fb00aac6affc23388e5a9/http/logical.go#L50 very early in the request handling chain (before authentication), which means an attacker can send a specifically crafted JSON object and cause an OOM crash. Additionally, for simpler requests with large numbers of strings, the audit subsystem can consume large quantities of CPU.
To remediate, set maxrequestjsonmemory and maxrequestjsonstrings.
Impact
- Unauthenticated Denial of Service
Resources
This issue was disclosed directly to HashiCorp and is the OpenBao equivalent of the following tickets:
- https://discuss.hashicorp.com/t/hcsec-2025-24-vault-denial-of-service-though-complex-json-payloads/76393 - https://nvd.nist.gov/vuln/detail/CVE-2025-6203
HashiCorp attributes the problem to the audit subsystem. For OpenBao, it was noted the problem was additionally in the requests handling logic.
Other sources
OpenBao is an open source identity-based secrets management system. In OpenBao versions prior to 2.4.1, JSON objects after decoding may use significantly more memory than their serialized version. It is possible to craft a JSON payload to maximize the factor between serialized memory usage and deserialized memory usage, similar to a zip bomb, with factors reaching approximately 35. This can be used to circumvent the maxrequestsize configuration parameter which is intended to protect against denial of service attacks. The request body is parsed into a map very early in the request handling chain before authentication, which means an unauthenticated attacker can send a specifically crafted JSON object and cause an out-of-memory crash. Additionally, for requests with large numbers of strings, the audit subsystem can consume large quantities of CPU. The vulnerability is fixed in version 2.4.1.
— MITRE
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2025-59043?
CVE-2025-59043 has a high severity due to the potential memory exploitation it poses.
How do I fix CVE-2025-59043?
To mitigate CVE-2025-59043, upgrade to OpenBao version 2.4.1 or later.
What impact does CVE-2025-59043 have on affected systems?
CVE-2025-59043 can lead to excessive memory usage due to inefficient JSON object handling.
Which versions of OpenBao are affected by CVE-2025-59043?
CVE-2025-59043 affects OpenBao versions up to and including 2.4.0.
Is there a workaround for CVE-2025-59043?
Currently, the best approach to avoid CVE-2025-59043 is to update to the patched version.