GHSA-r44w-v6gf-x3p6

## Summary The API-key cache in `check_apikey()` allows an attacker to authenticate with a **forged API key** as long as the legitimate key for the same `key_id` has been used recently. On a cache hit, the API key **secret is never verified**, resulting in a complete authentication bypass during the cache lifetime. --- # Affected Components - `src/pyload/core/api/init.py` - `Api.check_apikey()` - `src/pyload/core/database/apikey_database.py` - `check_apikey()` - `_check_key()` The cache is used by normal API requests through: - `src/pyload/webui/app/helpers.py` which calls: ```python api.check_apikey(api_key) ``` without providing a `ttl`, meaning the default **300-second cache** is always enabled. --- # Root Cause Successful API key validations are cached in: ```python self._apikey_cache ``` using the following structure: ```python { key_id: (timestamp, cached_data) } ``` The cache key is based **only on `key_id`**, and that value is parsed directly from the user-supplied API key rather than being obtained from a trusted lookup. When a cache hit occurs within the TTL, `check_apikey()` returns: ```python { "success": True, "data": cached_data } ``` after checking only: - `expires_at` At no point on this execution path is the supplied secret: ```text apikey[-43:] ``` compared against the stored key hash. --- The actual secret verification exists only in: ```python _check_key() ``` which correctly uses: ```python hmac.compare_digest() ``` However, this function is only reached on a **cache miss** through the database layer's `check_apikey()` implementation. Furthermore, the cached object cannot be used for verification because it intentionally does **not** include the stored key hash. The cached record contains only: - `id` - `user_id` - `name` - `created_at` - `expires_at` - `last_used` Since `key_hash` is absent, the cache lacks the information required to validate the presented secret. As a result, once a legiti