Skip to content

GHSA-g46h-2rq9-gw5m BIT-openbao-2025-59043 CVE-2025-59043 GO-2025-4039

OpenBao has potential Denial of Service vulnerability when processing malicious unauthenticated JSON requests

High Go
Severity
7.5 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.69%
Chance of exploitation in the next 30 days. Higher than 52.73% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-400 Uncontrolled Resource Consumption
Fix
2.4.1
Upgrade github.com/openbao/openbao to this version or later

Description

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 [max_request_size (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 max_request_json_memory and max_request_json_strings.

Impact

  • Unauthenticated Denial of Service

Resources

This issue was disclosed directly to HashiCorp and is the OpenBao equivalent of the following tickets:

HashiCorp attributes the problem to the audit subsystem. For OpenBao, it was noted the problem was additionally in the requests handling logic.

Affected versions

Go

PackageVulnerableFixed in
github.com/openbao/openbao
< 2.4.1
2.4.1
github.com/openbao/openbao
all versions
No fix yet

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/openbao/openbao Go → 2.4.1

go
go get github.com/openbao/openbao@v2.4.1 && go mod tidy

Severity breakdown

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-400: Uncontrolled Resource Consumption

The product does not properly control the allocation and maintenance of a limited resource.

How to prevent it
  • Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
  • Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
  • Implementation: Ensure that all failures in resource allocation place the system into a safe posture.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-xp3c-3jw3-4vcr
OpenBao Skips Stricter Deny Policy for LIST operations
Medium Also affects github.com/openbao/openbao
GHSA-34fc-gh42-pj53
OpenBao's Recovery Mode Vulnerable To Token Leakage via Timing Attack
Critical Also affects github.com/openbao/openbao
GHSA-444v-8vxr-p36h
OpenBao Agent Writes Secrets to Stdout
Low Also affects github.com/openbao/openbao
GHSA-59w7-v8rr-pr4p
OpenBao's Templated Policies Allow Privilege Escalation via Wildcard Characters
High Also affects github.com/openbao/openbao
GHSA-8w8f-r2xv-4q4j
OpenBao: Transit secrets engine crashes on key creation with `derived: true` for asymmetric key types
Medium Also affects github.com/openbao/openbao
GHSA-mwr2-wmgp-crj6
OpenBao's System Backend allows Unauthorized Management of the containing Namespace
Low Also affects github.com/openbao/openbao
GHSA-c36x-h252-g9x2
OpenBao: Cross-namespace lease revocation/renewal via canonical sys/leases/{revoke,renew} — incomplete fix of CVE-2026-45808
Low Also affects github.com/openbao/openbao
GHSA-6mwx-4547-5vc9
OpenBao: LDAPi ldaputil (wrong escape func)
Medium Also affects github.com/openbao/openbao
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor