<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-11T00:37:16.558909+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-123816</id>
    <title>fkie_cve-2026-123816</title>
    <updated>2026-11-11T00:37:16.560480+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>pyLoad is a free and open-source download manager written in Python. Prior to 0.5.0b3.dev101, 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 through hmac.compare_digest. Key identifiers are small sequential integers, so an unauthenticated remote attacker can enumerate an active identifier and inherit the cached key owner's permissions during the 300-second cache lifetime. This issue is fixed in version 0.5.0b3.dev101.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-123816"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-r44w-v6gf-x3p6</id>
    <title>GHSA-r44w-v6gf-x3p6 — pyLoad has an authentication bypass in API key validation (check_apikey cache)</title>
    <updated>2026-11-11T00:37:16.560564+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: pyload-ng</p>
<p>## Summary</p>
<p>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.</p>
<p>On a cache hit, the API key **secret is never verified**, resulting in a complete authentication bypass during the cache lifetime.</p>
<p>---</p>
<p># Affected Components</p>
<p>- `src/pyload/core/api/init.py`
  - `Api.check_apikey()`</p>
<p>- `src/pyload/core/database/apikey_database.py`
  - `check_apikey()`
  - `_check_key()`</p>
<p>The cache is used by normal API requests through:</p>
<p>- `src/pyload/webui/app/helpers.py`</p>
<p>which calls:</p>
<p>```python
api.check_apikey(api_key)
```</p>
<p>without providing a `ttl`, meaning the default **300-second cache** is always enabled.</p>
<p>---</p>
<p># Root Cause</p>
<p>Successful API key validations are cached in:</p>
<p>```python
self._apikey_cache
```</p>
<p>using the following structure:</p>
<p>```python
{
    key_id: (timestamp, cached_data)
}
```</p>
<p>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.</p>
<p>When a cache hit occurs within the TTL, `check_apikey()` returns:</p>
<p>```python
{
    "success": True,
    "data": cached_data
}
```</p>
<p>after checking only:</p>
<p>- `expires_at`</p>
<p>At no point on this execution path is the supplied secret:</p>
<p>```text
apikey[-43:]
```</p>
<p>compared against the stored key hash.</p>
<p>---</p>
<p>The actual secret verification exists only in:</p>
<p>```python
_check_key()
```</p>
<p>which correctly uses:</p>
<p>```python
hmac.compare_dig…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-r44w-v6gf-x3p6"/>
  </entry>
</feed>
