pyload-ng authentication bypass in getUserData/get_userdata

Severity: high · CVSS 8.1 · Published 2026-10-09

pyload-ng is a download manager with a web interface that supports multiple user accounts with varying permission levels. A flaw in the permission check allows any authenticated user, even those with no privileges, to brute-force the administrator account password with no lockout or effective rate limiting, leading to full administrative takeover.

Technologies: pyload-ng (PyPI). Vendors: PyPI.

Quick answers

Is This vulnerability exploited in the wild?
No. Junglewise Threat Intelligence has no report of This vulnerability being exploited in the wild.
How severe is This vulnerability?
High severity, with a CVSS score of 8.1, published 9 October 2026.
Which products and versions are affected?
Pyload-Ng 0.5.0b3 and likely earlier versions including 0.4.x and 0.5.0b2; pyload-ng (PyPI) >= 0.5.0b3.dev1, <= 0.5.0b3.dev101.
Is there a fix for This vulnerability?
No fixed version is recorded yet. Remove the @permission(Perms.ANY) decorator from getUserData and get_userdata methods, or remove these legacy compatibility shims entirely. Do not rely on X-Forwarded-For for rate limiting buckets unless running behind a trusted proxy; use request.remote_addr instead. Implement per-account failed-authentication throttling or account lockout.</anigation> <parameter name="timeline">[{"kind":"disclosed","at":"2026-10-09"}] If you run it, Junglewise drafts a mitigation that fits your setup and applies it once you approve, with senior security engineers behind it.
How is This vulnerability attacked?
It is attacked over the network, in a software library.
Am I affected?
Check whether you run Pyload-Ng or pyload-ng (PyPI) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

Remove the @permission(Perms.ANY) decorator from getUserData and get_userdata methods, or remove these legacy compatibility shims entirely. Do not rely on X-Forwarded-For for rate limiting buckets unless running behind a trusted proxy; use request.remote_addr instead. Implement per-account failed-authentication throttling or account lockout.</anigation> <parameter name="timeline">[{"kind":"disclosed","at":"2026-10-09"}]

Technical details

The getUserData and get_userdata API methods are decorated with @permission(Perms.ANY), where Perms.ANY is defined as 0. The permission check uses bitwise AND (required_perms == user_perms & required_perms), which always evaluates to true for a required permission of 0, making the gate ineffective. These methods wrap check_auth() which deliberately lacks permission decoration to restrict access to admins only. An attacker with a low-privilege account can exploit this to repeatedly query the endpoints with password guesses, receiving different responses for correct vs incorrect passwords, enabling brute-force attack. Rate limiting can be bypassed by rotating the X-Forwarded-For header, and there is no account lockout mechanism.

Affected products

  • pyload-ng pyload-ng 0.5.0b3 and likely earlier versions including 0.4.x and 0.5.0b2

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.