CVE-2026-48987 in pyLoad
Summary
by MITRE • 09/15/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in pyLoad, a popular open-source download manager written in Python, represents a critical resource exhaustion flaw within its event management subsystem. Specifically located in the src/pyload/core/managers/event_manager.py module, this issue stems from an improper implementation of client lifecycle management for authenticated API interactions. The EventManager component is responsible for tracking active clients connected via the getEvents API endpoint, which utilizes unique UUIDs to identify individual sessions or connections. Under normal operational conditions, when a client disconnects or becomes inactive, the system should invoke a cleanup routine to remove these stale objects from memory. However, prior to version 0.5.0b3.dev101, this critical clean method was not invoked for clients associated with unique UUIDs submitted during authenticated requests. This oversight creates a scenario where every new request containing a distinct UUID results in the creation and retention of a new Client object within an internal list, regardless of whether that client remains active or has already disconnected.
From a technical perspective, this flaw constitutes a classic resource management error where resources are allocated but never released under specific conditions. The absence of garbage collection for these inactive clients leads to unbounded memory growth on the host system running pyLoad. As an authenticated attacker repeatedly submits unique UUID values through the getEvents endpoint, the process consumes increasing amounts of RAM with each request. Since there is no upper limit or timeout mechanism implemented in this version to purge stale entries, the memory footprint expands linearly with the volume of requests sent by the adversary. This behavior effectively transforms a standard API interaction into a vector for sustained resource depletion, bypassing typical rate-limiting protections that might otherwise mitigate such attacks if they were based on connection counts rather than unique identifier generation.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition against the pyLoad service and potentially the underlying host infrastructure. As memory consumption escalates due to the accumulation of orphaned Client objects, the process approaches its allocated memory limits or exhausts available system RAM entirely. This triggers operating-system level interventions, such as the Out-Of-Memory killer in Linux environments, which forcibly terminates the affected process. In a production environment, this sudden termination disrupts all ongoing downloads and renders the download manager unavailable to legitimate users. Furthermore, if pyLoad is running on a resource-constrained system or shares memory with other critical services, the exhaustion can lead to broader host-wide instability, affecting other applications and degrading overall system performance until resources are freed through manual intervention or service restart.
This vulnerability aligns closely with CWE-400, which describes uncontrolled resource consumption, specifically falling under subcategories related to excessive allocation of memory without proper bounds checking or cleanup mechanisms. In the context of the MITRE ATT&CK framework, this exploit technique maps to T1498 Network Denial of Service, where an attacker leverages application-level logic flaws to degrade service availability rather than relying on network-layer flooding. The attack requires authentication, which classifies it as a lower-severity initial access vector but significantly increases its potential impact due to the ease with which authenticated users can trigger the condition without needing complex exploitation tools or external dependencies.
Mitigation for this vulnerability involves upgrading pyLoad to version 0.5.0b3.dev101 or later, where the developers have implemented the necessary cleanup logic to ensure inactive clients are properly removed from memory after their sessions conclude. For organizations unable to immediately patch due to dependency constraints, temporary mitigations include implementing strict rate limiting on the getEvents API endpoint at the network perimeter using a Web Application Firewall or reverse proxy configuration. Additionally, deploying monitoring alerts for abnormal spikes in pyLoad process memory usage can provide early detection of such attacks, allowing administrators to restart the service before total system failure occurs. Long-term architectural improvements should involve enforcing session timeouts and implementing automated garbage collection routines that periodically scan and purge stale client entries regardless of explicit disconnect signals.