GHSA-VQ8P-M3WM-GV5F
Vulnerability from github – Published: 2026-10-09 16:26 – Updated: 2026-10-09 16:26Description:
The API rpc function in api_blueprint.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/api_blueprint.py#L73
Steps to Reproduce:
- Log in to pyLoad (or use an API key, here i used api to communicate).
- Prepare a large file (e.g., 10GB) .
bash truncate -s 10G large_file.bin - Send a multipart request to an API function that accepts a file, such as
check_online_status_container:
curl -X POST "http://localhost:8000/api/rpc" \
-H "X-API-Key: YOUR_API_KEY" \
-F "func=check_online_status_container" \
-F "container=@large_file.bin"
- 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.
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
client_max_body_size).
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pyload-ng"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.0b3.dev101"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48484"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T16:26:53Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Description:\nThe API `rpc` function in `api_blueprint.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\u0027s available memory which led to process termination.\n\n## VulnerableCode \u0026 Path: \nhttps://github.com/pyload/pyload/blob/8e447958b8a66c5899775e725a8b90bce6643004/src/pyload/webui/app/blueprints/api_blueprint.py#L73 \n\n## Steps to Reproduce:\n1. Log in to pyLoad (or use an API key, here i used api to communicate).\n2. Prepare a large file (e.g., 10GB) .\n ```bash\ntruncate -s 10G large_file.bin\n ```\n3. Send a multipart request to an API function that accepts a file, such as `check_online_status_container`:\n```bash\ncurl -X POST \"http://localhost:8000/api/rpc\" \\\n -H \"X-API-Key: YOUR_API_KEY\" \\\n -F \"func=check_online_status_container\" \\\n -F \"container=@large_file.bin\"\n```\n4. Monitor the server\u0027s memory usage. The process will attempt to allocate memory for the entire file and last the process will be killed by the kernel.\n\u003cimg width=\"1902\" height=\"610\" alt=\"dos-process-kill-poc\" src=\"https://github.com/user-attachments/assets/2b9bfd0f-5b9f-48dd-983f-f97dfcc358cc\" /\u003e\n\n## Impact\n- **Denial of Service (DoS)**: The pyLoad process will be killed by the Operating System\u0027s Out-Of-Memory (OOM) killer, or the entire system may become unresponsive due to swap thrashing or memory exhaustion.\n- **Service Instability**: Any active downloads or tasks will be interrupted.\n\n## Mitigations\n- **Implement File Size Limits**: Enforce a maximum size for uploaded files in the web server configuration (e.g., Nginx `client_max_body_size`).",
"id": "GHSA-vq8p-m3wm-gv5f",
"modified": "2026-10-09T16:26:53Z",
"published": "2026-10-09T16:26:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pyload/pyload/security/advisories/GHSA-vq8p-m3wm-gv5f"
},
{
"type": "WEB",
"url": "https://github.com/pyload/pyload/commit/461cd66f30fa9e96453fb4d8c5c47467e452363c"
},
{
"type": "PACKAGE",
"url": "https://github.com/pyload/pyload"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "pyLoad: Lack of Input Size Validation Leads to Denial of Service (DoS) and Process Termination"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.