CVE-2025-59043
📋 TL;DR
OpenBao versions before 2.4.1 have a memory exhaustion vulnerability where specially crafted JSON payloads can cause disproportionate memory consumption during deserialization, similar to a zip bomb. This allows unauthenticated attackers to bypass max_request_size limits and cause denial of service through out-of-memory crashes. All OpenBao deployments using vulnerable versions are affected.
💻 Affected Systems
- OpenBao
📦 What is this software?
Openbao by Openbao
⚠️ Risk & Real-World Impact
Worst Case
Complete service outage due to out-of-memory crashes, potentially affecting all secrets management operations and dependent applications.
Likely Case
Service degradation or temporary unavailability due to memory exhaustion, impacting authentication and secrets retrieval.
If Mitigated
Minimal impact if proper rate limiting and request filtering are in place, though memory spikes may still occur.
🎯 Exploit Status
The advisory provides technical details that make exploitation straightforward for attackers familiar with JSON deserialization attacks.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 2.4.1
Vendor Advisory: https://github.com/openbao/openbao/security/advisories/GHSA-g46h-2rq9-gw5m
Restart Required: Yes
Instructions:
1. Backup OpenBao configuration and data. 2. Stop OpenBao service. 3. Upgrade to OpenBao 2.4.1 using your package manager or direct download. 4. Restart OpenBao service. 5. Verify service is running and accessible.
🔧 Temporary Workarounds
Rate Limiting and Request Filtering
allImplement network-level controls to limit request sizes and filter suspicious JSON payloads before they reach OpenBao.
Memory Limits and Monitoring
linuxConfigure strict memory limits for OpenBao process and implement aggressive monitoring for memory spikes.
# For systemd: edit /etc/systemd/system/openbao.service
# Add: MemoryMax=2G
# Then: systemctl daemon-reload && systemctl restart openbao
🧯 If You Can't Patch
- Implement WAF or reverse proxy with JSON payload inspection and size limits
- Isolate OpenBao instances and implement strict network segmentation to limit attack surface
🔍 How to Verify
Check if Vulnerable:
Check OpenBao version: if version is less than 2.4.1, the system is vulnerable.Check Version:
openbao versionVerify Fix Applied:
After patching, verify version is 2.4.1 or higher and test with normal JSON requests to ensure functionality.📡 Detection & Monitoring
Log Indicators:
- Memory allocation errors
- Process crashes/restarts
- Unusually large request sizes in access logs
- High CPU usage by audit subsystem
Network Indicators:
- Large JSON payloads to OpenBao endpoints
- Repeated requests with complex JSON structures
SIEM Query:
source="openbao" AND ("out of memory" OR "panic" OR "request size" > 1000000)🔗 References
- https://github.com/openbao/openbao/blob/788536bd3e10818a7b4fb00aac6affc23388e5a9/http/logical.go#L50
- https://github.com/openbao/openbao/commit/d418f238bc99adc72c73109faf574cc2b672880c
- https://github.com/openbao/openbao/pull/1756
- https://github.com/openbao/openbao/security/advisories/GHSA-g46h-2rq9-gw5m
