pyload-ng: getUserData/get_userdata exposed at Perms.ANY allow any authenticated account to brute-force the administrator password
## Summary
`Api.getUserData` (legacy) and `Api.get_userdata` are declared with `@permission(Perms.ANY)` and are reachable at `/api/getUserData` and `/api/get_userdata`. Because `Perms.ANY == 0` and pyLoad's permission check is a bitmask AND, that gate is a no-op: **every authenticated account passes, including one holding zero permission bits.**
Both methods are thin wrappers around `check_auth()`, which the maintainers deliberately restricted to administrators by omitting `@permission` (no entry in `perm_map`, so `is_authorized()` returns `False` for non-admins). The wrappers undo that protection.
An attacker holding the lowest-privileged
pyLoad: Rate-Limit Bypass and Audit-Log Spoofing via Trusted Client-Controlled `X-Forwarded-For` Header
## 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 attributi
pyLoad: Privilege revocation and password change through the REST API do not invalidate the user's session
An admin who revokes a user's privileges through the REST API does not actually revoke them, because the session carrying those privileges is never invalidated.
pyLoad authorizes each request from values copied into the Flask session at login. set_session in webui/app/helpers.py writes role and perms once, and both login_required and the session branch of apikey_auth read them back from the session rather than from the database. The fix for GHSA-66hx-chf7-3332 handled this by deleting the user's session files, but the call was added only in webui/app/blueprints/json_blueprint.py, at the three WebUI form handlers. Api.set_user_permission and
pyLoad: Api.set_user_permission never invalidates the target's session
### Summary
An admin who revokes or downgrades a non-admin user's permissions through pyLoad's own documented
`/api/<func>` RPC surface — e.g. `POST /api/set_user_permission` (or its legacy alias
`/api/setUserPermission`) — updates the target's database row but never invalidates that user's
existing Flask cookie session. The demoted user keeps their pre-revocation `role`/`permission` bits
on every subsequent WebUI page load and every subsequent `/api/<func>` call made with that cookie,
for up to the default `session_lifetime` of ~31 days, or until they voluntarily log out. No action
by the demoted user is required beyond already being logged
pyLoad WindowsPhoneNotify addon: non-admin SETTINGS user triggers SSRF via unguarded http.client notification host
## Summary
pyLoad ships the WindowsPhoneNotify addon, whose `send()` method opens an HTTP connection to a host taken directly from the plugin's `pushurl` configuration value. A user holding the standard non-admin `SETTINGS` permission can set `pushurl` and `pushid` and enable the addon through the web API, since these plugin options are not in the admin-only option set. Once enabled, the addon activates dynamically without a restart, and any completed download (download events fire globally, not per user) causes the addon to send an HTTP POST to the configured host and path. The request is made with Python's `http.client.HTTPConnection`, so
pyLoad: Tar extraction creates device nodes and FIFOs (member types not filtered; tarfile extractall without filter=)
### Summary
`UnTar._safe_extractall` — the hardening added for GHSA-mvwx-582f-56r7 — validates member
**names** and symlink/hardlink **targets**, but never checks member **types**, and calls
`tarfile.extractall` without a `filter=`. On Python < 3.14 the default extraction filter is
`fully_trusted`, so a crafted tar containing device or FIFO entries makes pyLoad create
them on disk. When pyLoad runs as root (the official Docker deployment), a block-device
member grants raw disk access — full host compromise — reachable by any low-privileged user
who can trigger archive extraction (ADD to supply an archive, STATUS to invoke
`ExtractArchive.ext
pyLoad is a free and open-source download manager written in Python. Prior to 0.5.0b3.dev97, the /json/package_order, /json/link_order, and /json/abort_link 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. This vulnerability is fixed in 0.5.0b3.dev97.
pyLoad has an incomplete fix for CVE-2026-33509: unprotected storage_folder enables arbitrary file write to Flask session store and code execution
pyLoad is a free and open-source download manager written in Python. The fix for CVE-2026-33509 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. This vulnerabilit
pyLoad vulnerable to remote code execution through js2py onCaptchaResult
pyload is an open-source Download Manager written in pure Python. An unsafe JavaScript evaluation vulnerability in pyLoad’s CAPTCHA processing code allows unauthenticated remote attackers to execute arbitrary code in the client browser and potentially the backend server. Exploitation requires no user interaction or authentication and can result in session hijacking, credential theft, and full system remote code execution. Commit 909e5c97885237530d1264cfceb5555870eb9546, the patch for the issue, is included in version 0.5.0b3.dev89.
An open redirection vulnerability exists in pyload/pyload version 0.5.0. The vulnerability is due to improper handling of the 'next' parameter in the login functionality. An attacker can exploit this vulnerability to redirect users to malicious sites, which can be used for phishing or other malicious activities. The issue is fixed in pyload-ng 0.5.0b3.dev79.
pyLoad vulnerable to remote code execution by download to /.pyload/scripts using /flashgot API
pyLoad is a free and open-source Download Manager. The folder `/.pyload/scripts` has scripts which are run when certain actions are completed, for e.g. a download is finished. By downloading a executable file to a folder in /scripts and performing the respective action, remote code execution can be achieved in versions prior to 0.5.0b3.dev87. A file can be downloaded to such a folder by changing the download folder to a folder in `/scripts` path and using the `/flashgot` API to download the file. This vulnerability allows an attacker with access to change the settings on a pyload server to execute arbitrary code and completely compromise the
pyLoad allows upload to arbitrary folder lead to RCE
pyload is an open-source Download Manager written in pure Python. An authenticated user can change the download folder and upload a crafted template to the specified folder lead to remote code execution. There is no fix available at the time of publication.