pyLoad CVE-2026-48484

Requires an authenticated session or a valid X-API-Key to reach the /api/rpc endpoint, and specifically targets RPC functions that accept multipart/form-data file uploads (e.g. check_online_status_container). The vulnerable code path exists in default configurations of pyLoad prior to 0.5.0b3.dev101, since no MAX_CONTENT_LENGTH was set. Exploitation is LIMITED by the authentication requirement (PR:L) and can be mitigated at the perimeter by a reverse-proxy body-size cap (e.g. Nginx client_max_body_size) even on unpatched versions; the fix enforces a 16MB server-side limit.

This is a moderate-severity availability-only flaw. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 6.5) is internally consistent with the description: network-reachable, low attack complexity, no user interaction, and impact limited to availability (process termination via OOM) with no confidentiality or integrity loss. The PR:L metric is corroborated by the GHSA reproduction steps, which require a valid login session or API key - so this is an authenticated DoS, not an unauthenticated one. No EPSS score, SSVC decision, or CISA KEV status was supplied in the input, so exploitation probability and automatability cannot be quantified from the data; the absence of KEV/EPSS is a data gap, not evidence of low risk. A detailed, working proof-of-concept (curl command plus a 10GB truncate file) is published in the vendor's own GHSA advisory, so publicly available exploit code exists. Net: this is a real but bounded issue - trivially reproducible against any authenticated attacker, but it only crashes the service and requires the attacker to already hold valid credentials or an API key, which meaningfully narrows the threat population to insiders or compromised accounts rather than anonymous internet scanners.

An attacker who has obtained a valid pyLoad login session or API key sends a multipart/form-data POST to /api/rpc referencing a file-accepting function (e.g. check_online_status_container) with a multi-gigabyte file attached. The server calls file.read() on the entire upload with no size cap, exhausting RAM until the kernel OOM-killer terminates the pyLoad process, interrupting all active downloads. A complete working PoC is published in the vendor GHSA advisory.