Introduction
A single oversized API request can crash Rancher Manager and disrupt Kubernetes operations for entire organizations. CVE-2024-58259 is a flaw in how Rancher Manager handles incoming request bodies. Attackers can use it to exhaust server memory and cause a denial of service.
About Rancher Manager and SUSE: Rancher Manager, developed by SUSE, is a leading open-source platform for managing Kubernetes clusters at scale. Enterprises use it widely to orchestrate containerized workloads across different environments. SUSE is a major vendor in enterprise Linux and container management, serves thousands of organizations globally, and has a strong track record of responding to security issues.
Technical Information
CVE-2024-58259 comes from Rancher Manager's failure to enforce request body size limits on multiple API endpoints. Both unauthenticated endpoints (notably /v3-public/*) and several authenticated endpoints are affected. An attacker sends HTTP requests with extremely large payloads to these endpoints. The server processes the entire request body in memory before any validation or size check, so a remote attacker can exhaust available memory and make the Rancher Manager service unresponsive or crash it.
Key technical points:
- The API handling logic does not check request body size.
- Both public (unauthenticated) and authenticated endpoints are affected, which widens the attack surface.
- Some endpoints need no valid credentials, so internet-exposed instances face higher risk.
- The flaw is classified under CWE-770 (Allocation of Resources Without Limits or Throttling).
- The patched versions set a hard limit of 1MB on request body size. Requests over that limit receive a 413 error and are rejected before they consume excessive memory.
Advisories and published research have not included any vulnerable code snippets at this time.
Patch Information
The Rancher Manager developers patched the vulnerability by enforcing strict size limits on request bodies for both public and authenticated API endpoints. With the patch, the server no longer processes payloads large enough that they could exhaust memory and cause a denial of service.
The patch sets a maximum size for incoming request bodies. When a request exceeds that limit, the server immediately terminates the connection and returns an error response to the client. This protects server resources from both malicious and accidental overloads.
In the updated code, the server configuration includes a parameter along these lines:
const maxRequestBodySize = 1048576 // 1MB
This line sets the maximum request body size to 1 megabyte. During request processing, the server checks the size of each incoming request:
if r.ContentLength > maxRequestBodySize { http.Error(w, "Request entity too large", http.StatusRequestEntityTooLarge) return }
Here r.ContentLength is the size of the incoming request. If it exceeds maxRequestBodySize, the server responds with a 413 Request Entity Too Large status code and terminates the request.
These checks mitigate the risk of denial-of-service attacks from oversized request bodies. The fix ships in the following patched versions:
- 2.12.1
- 2.11.5
- 2.10.9
- 2.9.12
Users are strongly encouraged to upgrade to one of these versions to protect their systems against this vulnerability.
Patch source: https://github.com/rancher/rancher/security/advisories/GHSA-4h45-jpvh-6p5j
Detection Methods
The detection sources cited here address the Log4j vulnerability (CVE-2021-44228), not CVE-2024-58259. For Log4j, detecting exploitation attempts means monitoring logs and network traffic for specific patterns. (gist.github.com)
Log Analysis:
Search your system logs for patterns that indicate possible exploitation attempts. This command scans uncompressed log files:
sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log
It recursively searches the /var/log directory for strings that match the exploit pattern. (gist.github.com)
Network Traffic Monitoring:
Intrusion detection system (IDS) rules can help identify malicious network activity tied to Log4j exploitation. Emerging Threats provides a set of signatures designed to detect these attempts. (github.com)
Automated Scanning Tools:
Specialized tools can scan your environment for vulnerable Log4j instances. The log4j-detector tool, for example, analyzes .class files to determine the Log4j version and whether it is vulnerable. (gist.github.com)
Detection sources:
- https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
- https://github.com/EmergingThreats/log4shell-detection
Affected Systems and Versions
- Rancher Manager versions before 2.12.1, 2.11.5, 2.10.9, and 2.9.12 are vulnerable.
- The vulnerability affects both public (unauthenticated) and authenticated API endpoints.
- Endpoints under
/v3-public/*can be exploited without authentication. - All configurations that expose these endpoints are at risk, especially those reachable from untrusted networks or the internet.
Vendor Security History
SUSE has responded to past Rancher Manager security issues promptly and transparently. Earlier advisories documented resource exhaustion and authentication vulnerabilities, with patch releases across multiple versions and detailed technical guidance. The vendor runs a mature vulnerability disclosure and remediation process, publishes advisories through multiple channels, and coordinates them with security databases.
