CVE-2026-123814

Prior to 0.5.0b3.dev101, pyLoad's Api.check_apikey caches successful validation in self._apikey_cache using only the attacker-controlled key_id. After a legitimate key populates the cache, a forged API key with the same key_id reaches the cache-hit path without comparing apikey[-43:] to the stored hash via hmac.compare_digest. Since key identifiers are small sequential integers, an unauthenticated remote attacker can enumerate an active identifier and inherit the cached key owner's permissions during the 300-second cache lifetime.

Prior to 0.5.0b3.dev102, pyLoad does not invalidate existing Flask sessions when an administrator changes a user's permissions or password via /api/set_user_permission or /api/change_password. Api.set_user_permission and Api.change_password update the database, but session authorization continues to use role and permission values copied at login by set_session in webui/app/helpers.py. A user can therefore retain revoked privileges or continue using a session established with an old password for the configured session lifetime.

In pyLoad prior to version 0.5.0b3.dev100, there is a vulnerability that allows a user with Perms.MODIFY to specify arbitrary directories as download locations for a package through the set_package_data() API function. The lack of sanitization in the '_folder' key enables this action.

In pyLoad prior to version 0.5.0b3.dev100, the set_config_value() API method improperly managed security-sensitive options, allowing authenticated users with SETTINGS permission to enable proxying and route traffic through a host they control.

In pyLoad, UnTar._safe_extractall validates archive member paths and link targets but does not call TarInfo.isdev to reject special tar member types before tarfile.extractall. On Python 3.9–3.13, tarfile defaults to the fully_trusted filter, so a user with ADD and STATUS permissions can cause extraction of a crafted archive containing character devices, block devices, or FIFOs. When pyLoad runs with OS privileges permitting device creation (e.g., official root-based Docker), this can expose raw devices and compromise the host.

pyLoad in version 0.5.0b3.dev96 and earlier has an SSRF vulnerability. The fix for CVE-2026-33992 added IP validation, but pycurl automatically follows HTTP redirects and redirect targets are not validated. An authenticated user with ADD permission can bypass the SSRF filter by using a URL that redirects to an internal address.

Vulnerability in pyLoad where the `/web/<path:filename>` route renders Jinja2 templates without authentication. An exception attribute typo leaks internal Jinja2 variable names in HTTP 500 responses.

Vulnerability in pyLoad where the API `rpc` function reads the entire uploaded file into memory without a size limit, potentially exhausting server memory and terminating the process.

In pyLoad 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.

In pyLoad prior to 0.5.0b3.dev101, is_global_address in src/pyload/core/utils/web/check.py relies on Python's global-address classification without examining IPv4 destinations embedded in 6to4 or NAT64 IPv6 addresses. A low-privileged user can submit an IPv6 literal through parse_urls to the pre-resolution is_global_host guard, and curl resolves hostnames before the same vulnerable check is applied, permitting connections to embedded loopback, private, CGNAT, or link-local IPv4 addresses.