Description

pyLoad is a free and open-source download manager written in Python. Prior to 0.5.0b3.dev101, EventManager in src/pyload/core/managers/event_manager.py appends a Client object to the clients list for each unique uuid submitted to the authenticated getEvents API endpoint, but get_events does not invoke the available clean method to remove inactive clients. An authenticated user can repeatedly submit unique UUID values, causing retained client objects and process memory to grow without bound even after requests stop. The resulting memory exhaustion can trigger an operating-system out-of-memory termination of pyLoad or host-wide instability and denial of service. This issue is fixed in version 0.5.0b3.dev101.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-15T15:17:16.397Z",
  "pubdate": "2026-09-15T15:17:16.397Z",
  "executiveSummary": "A memory leak vulnerability exists within the pyLoad download manager, specifically within the EventManager component. This vulnerability is classified as an improper resource management flaw, resulting in unbounded memory growth. The issue arises due to the failure of the get_events function to invoke necessary cleanup procedures for inactive client objects stored within the application's memory space.\nSuccessful exploitation allows an authenticated attacker to perform a Denial of Service (DoS) attack by programmatically injecting unique UUIDs into the authenticated getEvents API endpoint. Each submission forces the application to allocate and retain new client objects in memory that are never garbage collected or purged, leading to continuous heap expansion. Continued exploitation results in critical memory exhaustion, potentially triggering an Out-of-Memory (OOM) event that causes the pyLoad process to crash or introduces host-wide system instability.\nThe vulnerability affects pyLoad versions prior to 0.5.0b3.dev101. The requirement for authentication limits the threat actor profile to authorized users; however, the impact on availability is significant for environments relying on pyLoad for continuous operation.",
  "technicalDetails": "The vulnerability resides in the EventManager component located in src/pyload/core/managers/event_manager.py. The primary architectural flaw involves the management of client sessions tracked by unique UUIDs. When a request is made to the getEvents API endpoint, the application logic appends a new Client object to an internal list structure keyed by the submitted UUID.\nThe root cause of the vulnerability is the absence of a cleanup mechanism within the get_events execution flow. Although a clean method is defined within the EventManager to purge inactive or stale clients, it is not invoked during the handling of events. Consequently, the application maintains a persistent list of client objects that grows monotonically with each unique request, regardless of the client's actual activity state or session lifecycle.\nThe exploitation flow is as follows: 1) An authenticated user initiates a series of requests to the getEvents API endpoint. 2) The attacker varies the UUID parameter in each request, ensuring that every submission is perceived as a unique client by the EventManager. 3) The server processes these requests and performs an append operation to the internal clients list, allocating memory for a new Client object for each request. 4) Because the application fails to execute the clean method, these objects are never removed, even after the initial request cycle concludes. 5) By rapidly cycling unique UUIDs, the attacker forces the Python process to consume increasing amounts of RAM.\nOver time, the cumulative allocation of these leaked objects exerts severe pressure on the heap. This leads to increased memory footprint for the pyLoad process, eventually consuming the total available memory for the application or the host machine. When memory limits are reached, the Operating System's OOM killer may terminate the pyLoad process, or system-wide resource contention may occur, impacting other services running on the same infrastructure. This vulnerability is effectively a state-exhaustion attack that targets the persistent memory management logic of the application's event loop."
}