CVE-2026-75597

CVE-2026-75597 is a medium-severity missing authentication for critical function vulnerability in pyload-ng (pip), affecting versions <= 0.5.0b3.dev100. It is fixed in 0.5.0b3.dev101.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

pyLoad: Unauthenticated access to /web/<path:filename> bypasses authentication on sensitive templates and leaks internal error details via exception attribute typo

The /web/<path:filename> route in src/pyload/webui/app/blueprints/app_blueprint.py renders Jinja2 templates without any authentication requirement. Every equivalent direct route (/logs, /settings, /queue, /dashboard, etc.) is protected by @login_required, but the underlying templates for all of these pages are accessible unauthenticated via this endpoint. Combined with an exception attribute typo in src/pyload/webui/app/handlers.py (exc.desc instead of exc.description), internal Jinja2 variable names are leaked in HTTP 500 response bodies to unauthenticated callers. An attacker can also enumerate all valid template names by observing 200 vs 500 response differentiation.

Details

Bug 1, Missing authentication on /web/<path:filename>

File: src/pyload/webui/app/blueprints/app_blueprint.py, lines 32–36

@bp.route("/web/<path:filename>", endpoint="web")
def render(filename):                          # ← no @login_required
    mimetype = mimetypes.guess_type(filename)[0] or "text/html"
    data = render_template(filename)
    return flask.Response(data, mimetype=mimetype)

Every other sensitive route in the same file is protected:

@bp.route("/logs", ...)
@login_required("LIST")       # protected

@bp.route("/settings", ...)
@login_required("SETTINGS")  # protected

@bp.route("/files", ...)
@login_required("DOWNLOAD")  # protected

The /web/<path:filename> route has no such decorator, allowing any unauthenticated HTTP client to render arbitrary templates by supplying their filename in the URL path.

Bug 2, Exception attribute typo causes internal details in error responses

File: src/pyload/webui/app/handlers.py, lines 12–20

def handle_exception_error(exc):
    try:
        code = exc.code
        desc = exc.desc          # BUG: attribute does not exist on standard exceptions
    except AttributeError:       # always raised, falls here for every exception
        code = 500
        desc = exc               # raw exception object assigned to desc
    message = f"Error {code}: {desc}"   # str(exc) embedded in response body
    return render_template("error.html", messages=[message]), code

exc.desc does not exist on standard Python or Jinja2 exceptions. The AttributeError branch is always taken for template rendering failures. desc is set to the raw exception object, and str(exc) is embedded in the HTML response body returned to the unauthenticated caller. For a UndefinedError this produces 'conf' is undefined. For TemplateNotFound it produces the template filename.

PoC

Tested against pyload-ng develop branch (0.5.0b3.dev), default install, no authentication cookies or credentials used in any request.

Test 1, Unauthenticated page render confirmed (HTTP 200)

curl -si http://TARGET:8000/web/logs.html | grep "HTTP\|title"

Test 2, System info page with sensitive field labels rendered unauthenticated

html

<dt><b>Python Version:</b></dt>
<dt><b>OS Platform:</b></dt>
<dt><b>Installation Folder:</b></dt>
<dt><b>Config Folder:</b></dt>```

Test 3, Internal Jinja2 variable name leaked in HTTP 500 body (unauthenticated)
```curl -si http://TARGET:8000/web/settings.html | grep "HTTP\|Error"
HTTP/1.1 500 INTERNAL SERVER ERROR
<p><b>Error 500: 'conf' is undefined</b></p>```
Test 4, Template enumeration via response code differentiation
```curl -o /dev/null -sw "%{http_code}\n" http://TARGET:8000/web/logs.html
curl -o /dev/null -sw "%{http_code}\n" http://TARGET:8000/web/info.html
curl -o /dev/null -sw "%{http_code}\n" http://TARGET:8000/web/dashboard.html
curl -o /dev/null -sw "%{http_code}\n" http://TARGET:8000/web/settings.html
curl -o /dev/null -sw "%{http_code}\n" http://TARGET:8000/web/queue.html
curl -o /dev/null -sw "%{http_code}\n" http://TARGET:8000/web/collector.html
curl -o /dev/null -sw "%{http_code}\n" http://TARGET:8000/web/filemanager.html
curl -o /dev/null -sw "%{http_code}\n" http://TARGET:8000/web/nonexistent_xyz.html
200  ← logs.html        (exists, renders without auth)
200  ← info.html        (exists, renders without auth)
200  ← dashboard.html   (exists, renders without auth)
500  ← settings.html    (exists, missing auth context, leaks 'conf' is undefined)
500  ← queue.html       (exists, missing auth context)
500  ← collector.html   (exists, missing auth context)
500  ← filemanager.html (exists, missing auth context)
500  ← nonexistent_xyz  (does not exist, same 500, no differentiation on miss)```

###Impact
An unauthenticated remote attacker can:

Render application page templates without any credentials, bypassing the access control model enforced on all direct routes
Access the system information page (info.html) exposing field structure for Python version, OS platform, pyLoad version, installation folder, config folder, and WebUI port, values are populated via JS but field labels confirm application structure
Access the full log viewer UI (logs.html) and download dashboard (dashboard.html) without authentication
Extract internal Jinja2 template variable names from HTTP 500 response bodies ('conf' is undefined, etc.)
Enumerate all valid template filenames by observing 200 vs 500 response codes

The access control inconsistency is the core issue: the authentication model enforced on direct routes is completely bypassed via the /web/<path:filename> endpoint. Any future template that renders sensitive data server-side would be immediately exposed to unauthenticated access through this route.

Impact

A critical operation is accessible without requiring any authentication. Typical impact: any user can invoke the privileged function.

CVE-2026-75597 has a CVSS score of 5.3 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.5.0b3.dev101); upgrading removes the vulnerable code path.

Affected versions

pyload-ng (<= 0.5.0b3.dev100)

Security releases

pyload-ng → 0.5.0b3.dev101 (pip)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade pyload-ng to 0.5.0b3.dev101 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-75597? CVE-2026-75597 is a medium-severity missing authentication for critical function vulnerability in pyload-ng (pip), affecting versions <= 0.5.0b3.dev100. It is fixed in 0.5.0b3.dev101. A critical operation is accessible without requiring any authentication.
  2. How severe is CVE-2026-75597? CVE-2026-75597 has a CVSS score of 5.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of pyload-ng are affected by CVE-2026-75597? pyload-ng (pip) versions <= 0.5.0b3.dev100 is affected.
  4. Is there a fix for CVE-2026-75597? Yes. CVE-2026-75597 is fixed in 0.5.0b3.dev101. Upgrade to this version or later.
  5. Is CVE-2026-75597 exploitable, and should I be worried? Whether CVE-2026-75597 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-75597 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-75597? Upgrade pyload-ng to 0.5.0b3.dev101 or later.

Other vulnerabilities in pyload-ng

Stop the waste.
Protect your environment with Kodem.