Authentication Bypass in pyLoad API Key Caching Mechanism (GHSA-R44W-V6GF-X3P6)

The open-source download manager pyLoad (specifically the pyload-ng Python package) exposes a web user interface and a programmatic API interface to facilitate remote configuration, download task scheduling, and state monitoring. The system uses API keys to authenticate headless systems, automated daemons, and client applications. These API endpoints are exposed on the default pyLoad port (typically port 8000) and represent a significant portion of the application's external attack surface.

This vulnerability is classified under CWE-287 (Improper Authentication). The core issue resides in the logical design of the API key validation caching layer, where the cache key index is decoupled from the cryptographic secret verification. Because authorization decisions are cached on guessable public identifiers rather than the secret token itself, the system permits unauthenticated requests that match a currently cached key index.

An attacker who can intercept or anticipate API key usage can bypass authentication entirely during the 300-second (5-minute) cache lifetime. Once a legitimate user authenticates successfully, their authorization status is cached. Any subsequent request presenting the target's public key identifier, combined with an arbitrary, forged secret string, is accepted by the server as authenticated. This allows the attacker to execute arbitrary administrative API methods.

The vulnerability stems from the internal structure of pyLoad's API key validation system. When an administrative user generates an API key, the application produces a string formatted as pl_<key_id><43-character-secret>, where the key_id is a sequential integer (e.g., 1, 2, 3) stored in the database. During authentication, the check_apikey() function splits this string to extract the key_id and the secret suffix.

To minimize repetitive, resource-intensive database operations, the application uses an internal dictionary, self._apikey_cache, to cache validation states. The dictionary is defined with the format {key_id: (timestamp, data)}. This design choice represents the fundamental logical flaw: the dictionary uses only the public, sequential key_id as the cache key index instead of incorporating the private, high-entropy secret portion of the credential.

When evaluating an API request, the system checks whether the extracted key_id exists in self._apikey_cache. If a cache hit occurs and the TTL is valid, the function immediately returns a success status along with the cached user metadata. The validation logic does not perform any comparison between the incoming secret token and the database or cache records during a cache hit. Consequently, the high-entropy secret portion of the credential is completely ignored, and the request is authorized solely based on the presence of the key_id in the cache.

The vulnerable implementation in src/pyload/core/api/__init__.py exposes the logical bypass on cache hits. The application checks the cache prior to conducting database validation. Because database validation (which uses safe comparison routines) is skipped during a cache hit, any client supplying a matching key_id bypasses authentication entirely.

Below is the comparison of the vulnerable logic versus the patched logic implemented in the pyLoad repository:

# VULNERABLE LOGIC:
# Cache indexed by public key_id integer
self._apikey_cache = {}  # Format: {key_id: (timestamp, data)}
 
def check_apikey(self, apikey: str, ttl: int = 5 * 60):
    # ... (extract key_id from apikey)
    if ttl > 0:
        with self._apikey_cache_lock:
            if key_id in self._apikey_cache:
                # Cache Hit: immediately return success without verifying secret!
                return {"success": True, "data": cached_data}

# PATCHED LOGIC:
# Cache indexed by full apikey string (incorporating secret)
self._apikey_cache = {}  # Format: {apikey: (timestamp, data)}
 
def check_apikey(self, apikey: str, ttl: int = 5 * 60):
    if ttl > 0:
        with self._apikey_cache_lock:
            if apikey in self._apikey_cache:
                # Cache Hit: Only occurs if the complete, secret-bearing string matches exactly
                return {"success": True, "data": cached_data}

In addition to modifying the check_apikey search key, the patch updates the cache eviction logic. In functions such as remove_user and delete_apikey, the cache invalidation routine was rewritten to iterate over the dictionary items, finding and removing cached entries based on nested user and key metadata. This prevents stale authorization sessions from persisting when keys are revoked or deleted.

Exploitation of this vulnerability requires two primary conditions: a target system with an active API key, and a legitimate authentication event that populates the cache. The attack vector is remote, network-accessible, and requires zero prior privileges. Because the public key_id is a sequential integer, attackers can easily enumerate valid key IDs to target active systems.

The timeline of a successful attack is represented in the sequence diagram below:

To verify the vulnerability, an attacker can execute two sequential curl commands. The first command simulates the legitimate administrative user populating the cache. The second command uses the same key_id prefix but changes the high-entropy secret portion to an arbitrary string. On a vulnerable deployment, both commands return a 200 OK status with the target resource payload, proving the bypass works.

The direct technical impact of this vulnerability is complete compromise of the pyLoad instance's administrative and management functions. The pyLoad API provides routes to manage files, retrieve system configuration, configure download paths, execute shell commands, and control system integration daemons. An unauthenticated remote attacker can leverage this bypass to perform unauthorized file operations, read system configs containing administrative passwords, or write malicious payloads to the host system.

The CVSS v3.1 base score is 8.1, indicating High severity. The vector string is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The high attack complexity rating reflects the dependency on a race-like window: the attacker must issue their request within the 300-second window following a legitimate user's authentication event. However, in automated deployments or systems with frequent polling (such as browser extensions or script integrations), this window is almost continuously open.

From a downstream risk perspective, download managers frequently execute with administrative or local system privileges to allow writing to restricted directories. If pyLoad is running inside a Docker container, the compromise can serve as an initial foothold for container escape or network scanning of internal assets, amplifying the risk beyond the application boundary.

The immediate remediation for this vulnerability is upgrading the pyload-ng package to version 0.5.0b3.dev101 or later. This updates the dictionary cache indexing to key off the entire API key string rather than the public ID. If upgrading is not immediately possible, administrators should disable external access to the API paths (such as /api/*) or apply IP-based access control lists (ACLs) to restrict the attack surface.

From an architectural standpoint, caching plaintext keys in-memory represents an operational security risk. Although the patch resolves the logical bypass, the full API key is retained in plaintext within the process heap space as a dictionary key. A more resilient architectural design would index the cache dictionary using a cryptographic hash of the API key, such as hashlib.sha256(apikey.encode()).hexdigest().

Additionally, developers should avoid using sequential, guessable identifiers (key_id) as public-facing references in security-sensitive interfaces. Using high-entropy, cryptographically secure random identifiers (UUIDv4) prevents target enumeration and limits the effectiveness of structured replay or side-channel attacks.