GHSA-vq8p-m3wm-gv5f: Input Validation
Description: The API rpc function in apiblueprint.py handles multipart/form-data uploads by reading the whole content of the uploaded file into memory with file.read(). This occurs before the data is sent to the underlying function. Since there is no size limit set at this point, a large file upload can exhaust the server's available memory which led to process termination.
VulnerableCode & Path: https://github.com/pyload/pyload/blob/8e447958b8a66c5899775e725a8b90bce6643004/src/pyload/webui/app/blueprints/apiblueprint.py#L73
Steps to Reproduce: 1. Log in to pyLoad (or use an API key, here i used api to communicate). 2. Prepare a large file (e.g., 10GB) . bash truncate -s 10G largefile.bin 3. Send a multipart request to an API function that accepts a file, such as checkonlinestatuscontainer: bash curl -X POST "http://localhost:8000/api/rpc" \ -H "X-API-Key: YOURAPIKEY" \ -F "func=checkonlinestatuscontainer" \ -F "container=@largefile.bin" 4. Monitor the server's memory usage. The process will attempt to allocate memory for the entire file and last the process will be killed by the kernel. <img width="1902" height="610" alt="dos-process-kill-poc" src="https://github.com/user-attachments/assets/2b9bfd0f-5b9f-48dd-983f-f97dfcc358cc" />
Impact - Denial of Service (DoS): The pyLoad process will be killed by the Operating System's Out-Of-Memory (OOM) killer, or the entire system may become unresponsive due to swap thrashing or memory exhaustion. - Service Instability: Any active downloads or tasks will be interrupted.
Mitigations - Implement File Size Limits: Enforce a maximum size for uploaded files in the web server configuration (e.g., Nginx clientmaxbodysize).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/pyload-ngto a version that resolves this vulnerability.Fixed in 0.5.0b3.dev101 - Configuration
Configure Nginx client_max_body_size to enforce a maximum size for uploaded files.
Nginx client_max_body_size = maximum permitted upload size
Event History
Frequently Asked Questions
Who can trigger the memory-exhaustion condition?
An attacker must be authenticated to pyLoad, either by logging in or by using an API key. They also need network access to the API endpoint and an API function that accepts a file upload.
What request causes the service disruption?
A multipart/form-data POST to /api/rpc that selects a file-accepting function, such as check_online_status_container, can supply an oversized file. The API reads the complete upload into memory before passing it to the underlying function, allowing the process to be terminated when memory is exhausted.
How can administrators determine whether an instance has been affected?
Look for unusually large multipart uploads to the API RPC endpoint and corresponding rapid memory growth in the pyLoad process. The documented outcome is kernel termination of the process after it attempts to allocate memory for the entire uploaded file.