Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
35 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The API-key cache in checkapikey() allows an attacker to authenticate with a forged API key as long as the legitimate key for the same keyid has been used recently. On a cache hit, the API key secret is never verified, resulting in a complete authentication bypass during the cache lifetime. --- Affected Components - src/pyload/core/api/init.py - Api.checkapikey() - src/pyload/core/database/apikeydatabase.py - checkapikey() - checkkey() The cache is used by normal API requests through: - src/pyload/webui/app/helpers.py which calls: without providing a ttl, meaning the default 300-second cache is always enabled. --- Root Cause Successful API key validations are cached in: using the following structure: The cache key is based only on keyid, and that value is parsed directly from the user-supplied API key rather than being obtained from a trusted lookup. When a cache hit occurs within the TTL, checkapikey() returns: after checking only: - expiresat At no point on this execution…
Recommended action: Upgrade to 0.5.0b3.dev101 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The /web/<path:filename route in src/pyload/webui/app/blueprints/appblueprint.py renders Jinja2 templates without any authentication requirement. Every equivalent direct route (/logs, /settings, /queue, /dashboard, etc.) is protected by @loginrequired, 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/appblueprint.py, lines 32–36 Every other sensitive route in the same file is protected: The /web/<path:filename route has no such decorator, allowing any unauthenticated HTTP client to render arbitrary templates by…
Recommended action: Upgrade to 0.5.0b3.dev101 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The API rpc function in apiblueprint.py handles multipart/form-data uploads by reading the whole content of the uploaded file into memory with file.read(). This occurs before the data is sent to the underlying function. Since there is no size limit set at this point, a large file upload can exhaust the server's available memory which led to process termination. VulnerableCode & Path: https://github.com/pyload/pyload/blob/8e447958b8a66c5899775e725a8b90bce6643004/src/pyload/webui/app/blueprints/apiblueprint.py#L73 Steps to Reproduce: 1. Log in to pyLoad (or use an API key, here i used api to communicate). 2. Prepare a large file (e.g., 10GB) . 3. Send a multipart request to an API function that accepts a file, such as checkonlinestatuscontainer: 4. Monitor the server's memory usage. The process will attempt to allocate memory for the entire file and last the process will be killed by the kernel. <img width="1902" height="610" alt="dos-process-kill-poc"…
Recommended action: Upgrade to 0.5.0b3.dev101 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SSRF mitigation added in commit 33c55da for GHSA-7gvf-3w72-p2pg is incomplete. The PREREQFUNCTION-based private IP check was correctly applied to HTTPChunk (download path) but not to HTTPRequest (used by the parseurls API). An authenticated attacker can supply a URL pointing to an attacker-controlled server that responds with a 302 redirect to an internal/private IP address, bypassing the isglobalhost() check on the initial URL. Details The parseurls API method validates the initial URL hostname: geturl() is imported from requestfactory.py and creates an HTTPRequest with default settings: HTTPRequest.init sets allowprivateip = True by default: The inithandle() method enables redirect following: The prerequestcallback that should block redirects to private IPs is a no-op when allowprivateip is True: The fix at commit 33c55da correctly set allowprivateip = False in HTTPChunk (httpchunk.py:136) for the download path, but HTTPRequest used by RequestFactory.geturl() retains…
Recommended action: Upgrade to 0.5.0b3.dev100 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/appblueprint.py:32-36 - @bp.route("/web/<path:filename", endpoint="web") - data = rendertemplate(filename) with user-controlled filename - no @loginrequired(...) on this route 2. Global exception handler exposes traceback to response: - src/pyload/webui/app/handlers.py:14-27 - tb = traceback.formatexc() - messages.extend(tb.split('\n')) - returned in rendered error page for all exceptions 3. Error page renders all messages: -…
Recommended action: Upgrade to 0.5.0b3.dev100 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
No sanitization of package folder name allows writing files anywhere outside the intended download directory. Affected Component - src/pyload/core/api/init.py - Function: setpackagedata() Details When passing a folder name in the setpackagedata() API function call inside the data object with key "folder", there is no sanitization at all, allowing a user with Perms.MODIFY to specify arbitrary directories as download locations for a package. PoC 1) Create a package, note response package ID e.g. 5 2) Call setpackagedata for this package ID with an arbitrary directory 3) New download folder will be set without any checks Response: Impact Allows Absolute Path Traversal to write in an arbitrary directory as long as the pyLoad process has write access.
Recommended action: Upgrade to 0.5.0b3.dev100 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Insufficient sanitization of package folder names allows writing files outside the intended download directory. Affected Component - src/pyload/core/api/init.py - Function: addpackage() Description Package folder names are sanitized using insufficient string replacement: The ../ replacement is bypassable. The pattern ....// becomes .. after replacement (partial removal), leaving .. which can be exploited when the path is later resolved by the OS. Proof of Concept Setup Exploit Verification Check where files would be written: Impact Authenticated users with ADD permission can: - Write files outside the download directory - Potentially overwrite system files (depending on permissions) - Clutter system directories with downloaded content
Recommended action: Upgrade to 0.5.0b3.dev100 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The setconfigvalue() API method (@permission(Perms.SETTINGS)) in src/pyload/core/api/init.py gates security-sensitive options behind a hand-maintained allowlist ADMINONLYCOREOPTIONS. The allowlist contains ("proxy", "username") and ("proxy", "password") — which protect the proxy credentials — but it does not include ("proxy", "enabled"), ("proxy", "host"), ("proxy", "port"), or ("proxy", "type"). Any authenticated user with the non-admin SETTINGS permission can enable proxying and point pyload at any host they control. From that point, every outbound download, captcha fetch, update check, and plugin HTTP call is transparently routed through the attacker. Gating only the proxy credentials is ineffective: the attacker is the proxy endpoint, so they do not need pyload's proxy-auth secret. proxy.username / proxy.password were designed so an admin could authenticate to a trusted corporate proxy; they do not help when the non-admin attacker is free to choose the proxy itself. This…
Recommended action: Upgrade to 0.5.0b3.dev100 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The setconfigvalue() API method (@permission(Perms.SETTINGS)) in src/pyload/core/api/init.py gates security-sensitive options behind a hand-maintained allowlist ADMINONLYCOREOPTIONS. The option ("general", "sslverify") is not on that allowlist. Any authenticated user with the non-admin SETTINGS permission can set general.sslverify = off, and every subsequent outbound pycurl request is made with SSLVERIFYPEER=0 and SSLVERIFYHOST=0 — TLS peer and hostname verification are fully disabled. An on-path attacker can then present forged certificates for any hostname pyload fetches. This is a direct continuation of the fix family CVE-2026-33509 / CVE-2026-35463 / CVE-2026-35464 / CVE-2026-35586, each of which patched a different missed option in the same allowlist. Details Writer — src/pyload/core/api/init.py, setconfigvalue() (around lines 215–290). The function is decorated with @permission(Perms.SETTINGS) and only rejects writes when (category, option) appears in…
Recommended action: Upgrade to 0.5.0b3.dev100 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The setsessioncookiesecure beforerequest handler in src/pyload/webui/app/init.py reads the X-Forwarded-Proto header from any HTTP request without validating that the request originates from a trusted proxy, then mutates the global Flask configuration SESSIONCOOKIESECURE on every request. Because pyLoad uses the multi-threaded Cheroot WSGI server (requestqueuesize=512), this creates a race condition where an attacker's request can influence the Secure flag on other users' session cookies — either downgrading cookie security behind a TLS proxy or causing a session denial-of-service on plain HTTP deployments. Details The vulnerable code is in src/pyload/webui/app/init.py:75-84: The root cause has two components: 1. No origin validation (CWE-346): The X-Forwarded-Proto header is read from any client request. This header is only trustworthy when set by a known reverse proxy. Without ProxyFix middleware or a trusted proxy allowlist, any client can spoof it. The code itself…
Recommended action: Upgrade to 0.5.0b3.dev98 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.5.0b3.dev97 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The safeextractall() function in src/pyload/plugins/extractors/UnTar.py uses os.path.commonprefix() for its path traversal check, which performs character-level string comparison rather than path-level comparison. This allows a specially crafted tar archive to write files outside the intended extraction directory. The correct function os.path.commonpath() was added to the codebase in the GHSA-7g4m-8hx2-4qh3 fix (commit 5f4f0fa) but was never applied to safeextractall(), making this an incomplete fix. Details The GHSA-7g4m-8hx2-4qh3 fix (commit 5f4f0fa) added a correct iswithindirectory() function to src/pyload/core/utils/fs.py:384-391 using os.path.commonpath(): However, the safeextractall() function in UnTar.py:10-22 was left unchanged with the broken os.path.commonprefix(): os.path.commonprefix() is a string operation, not a path operation. For extraction destination /downloads/pkg and a malicious member ../pkgevil/payload (resolving to /downloads/pkgevil/payload): -…
Recommended action: Upgrade to 0.5.0b3.dev97 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ADMINONLYCOREOPTIONS authorization set in setconfigvalue() uses incorrect option names sslcert and sslkey, while the actual configuration option names are sslcertfile and sslkeyfile. This name mismatch causes the admin-only check to always evaluate to False, allowing any user with SETTINGS permission to overwrite the SSL certificate and key file paths. Additionally, the sslcertchain option was never added to the admin-only set at all. Details The vulnerability is in src/pyload/core/api/init.py. The ADMINONLYCOREOPTIONS set is defined at lines 237-248: The actual config option names are defined in src/pyload/core/config/default.cfg:39-41: The authorization check at line 267 compares the incoming (category, option) tuple against this set: When a request arrives with option=sslcertfile, the check evaluates ("webui", "sslcertfile") in ADMINONLYCOREOPTIONS which is False because the set contains ("webui", "sslcert"), not ("webui", "sslcertfile"). The admin-only guard is…
Recommended action: Upgrade to 0.5.0b3.dev97 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Host Header Spoofing vulnerability in the @localcheck decorator allows unauthenticated external attackers to bypass local-only restrictions. This grants access to the Click'N'Load API endpoints, enabling attackers to remotely queue arbitrary downloads, leading to Server-Side Request Forgery (SSRF) and Denial of Service (DoS). Details The pyload WebUI provides an API for the Click'N'Load plugin, which is intended to be accessed only from the local machine (e.g., via a browser extension sending requests to localhost:9666). To enforce this, the pyload application uses a @localcheck decorator on the relevant routes in src/pyload/webui/app/blueprints/cnlblueprint.py. However, the @localcheck implementation relies on the user-controlled HTTPHOST (derived from the HTTP Host header) to verify the origin: Because httphost is read directly from the Host header of the HTTP request, an external attacker can easily spoof this header (e.g., Host: 127.0.0.1:9666). When this spoofed header…
Recommended action: Upgrade to 0.5.0b3.dev97 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The editpackage() function implements insufficient sanitization for the packfolder parameter. The current protection relies on a single-pass string replacement of "../", which can be bypassed using crafted recursive traversal sequences. Exploitation An authenticated user with MODIFY permission can bypass the sanitization by submitting a payload such as: packfolder=..././..././..././tmp After the single-pass replacement, this becomes: ../../../tmp Because the traversal sequences are not properly validated, the resulting normalized path escapes the intended storage directory and writes files to /tmp or other locations.
Recommended action: Upgrade to 0.5.0b3.dev97 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pyLoad web interface contained insufficient input validation in both the Captcha script endpoint and the Click'N'Load (CNL) Blueprint. This flaw allowed untrusted user input to be processed unsafely, which could be exploited by an attacker to inject arbitrary content into the web UI or manipulate request handling. The vulnerability could lead to client-side code execution (XSS) or other unintended behaviors when a malicious payload is submitted. user-supplied parameters from HTTP requests were not adequately validated or sanitized before being passed into the application logic and response generation. This allowed crafted input to alter the expected execution flow. CNL (Click'N'Load) blueprint exposed unsafe handling of untrusted parameters in HTTP requests. The application did not consistently enforce input validation or encoding, making it possible for an attacker to craft malicious requests. PoC 1. Run a vulnerable version of pyLoad prior to commit f9d27f2. 2. Start the…
Recommended action: Upgrade to 0.5.0b3.dev91 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Dear Maintainers, I am writing to you on behalf of the Tencent AI Sec. We have identified a potential vulnerability in one of your products and would like to report it to you for further investigation and mitigation. Summary 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. Details - Endpoint: flash/addcrypted2 - affected file: https://github.com/pyload/pyload/blob/develop/src/pyload/webui/app/blueprints/cnlblueprint.py#L123 https://github.com/pyload/pyload/blob/develop/src/pyload/core/utils/misc.py#L42 affected code PoC download pyload and run locally, send the following request - PoC The 30000 can be modified to any large value. Impact System resources are exhausted, causing services to be temporarily interrupted or stopped, making them inaccessible to normal users. Use…
Recommended action: Upgrade to 0.5.0b3.dev92 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The parameter addlinks in the API /json/addpackage is vulnerable to SQL Injection. SQL injection vulnerabilities can lead to sensitive data leakage. Details - Affected file：https://github.com/pyload/pyload/blob/develop/src/pyload/core/database/filedatabase.py#L271 - Affected code: statuses is constructed from data, and data is the value of the addlinks parameter entered by the user through /json/addpackge. Because {statuses} is directly spliced into the SQL statement, it leads to the SQL injection vulnerability. - Vulnerability Chain PoC <img width="1599" height="827" alt="image" src="https://github.com/user-attachments/assets/9bdcef37-59b8-4e60-a2b5-beb8a88c3202" / Remediation Impact Attackers can modify or delete data in the database, causing data errors or loss.
Recommended action: Upgrade to 0.5.0b3.dev91 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Path Traversal in pyLoad-ng CNL Blueprint via package parameter allows Arbitrary File Write leading to Remote Code Execution (RCE) The addcrypted endpoint in pyload-ng suffers from an unsafe path construction vulnerability, allowing unauthenticated attackers to write arbitrary files outside the designated storage directory. This can be abused to overwrite critical system files, including cron jobs and systemd services, leading to privilege escalation and remote code execution as root. Details Endpoint: POST /addcrypted Issue: src/pyload/webui/app/blueprints/cnlblueprint.py Vulnerable Code PoC Decoded payload: Send crafted POST Impact The vulnerability allows unauthenticated attackers to write arbitrary files outside the intended directory via a path traversal flaw in the addcrypted endpoint in pyload-ng parameter. when exploited, it enables remote code execution as root by injecting malicious cron jobs or system files, turning a simple file upload endpoint into a full system…
Recommended action: Upgrade to 0.5.0b3.dev90 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authenticated path traversal vulnerability exists in the /json/upload endpoint of the pyLoad By manipulating the filename of an uploaded file, an attacker can traverse out of the intended upload directory, allowing them to write arbitrary files to any location on the system accessible to the pyLoad process. This may lead to: Remote Code Execution (RCE) Local Privilege Escalation System-wide compromise Persistence and backdoors --- Vulnerable Code File: src/pyload/webui/app/blueprints/jsonblueprint.py Issue: No sanitization or validation on file.filename, allowing traversal via ../../ sequences. (Proof of Concept) 1. Clone and install pyLoad from source (pip install pyload-ng): 2. Or install via pip (PyPi) in virtualenv: 1. Login and obtain session token 2. Create malicious cron payload 3. Upload file with path traversal filename 4. On the next cron tick, a reverse shell or payload will be triggered. BurpSuite HTTP Request
Recommended action: Upgrade to 0.5.0b3.dev90 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 rce. Details The vulnerable code resides in The onCaptchaResult() function directly passes CAPTCHA results (sent from the user) into eval() No sanitization or validation is performed on this input A malicious CAPTCHA result can include JavaScript such as fetch() or childprocess.exec() in environments using NodeJS Attackers can fully hijack sessions and pivot to remote code execution on the server if the environment allows it Reproduction Methods 1. Official Source Installation: 2. Virtual Environment: CAPTCHA Endpoint Verification Technical Clarification: 1. The vulnerable endpoint is actually: 2. Complete PoC Request: 3. Curl Command…
Recommended action: Upgrade to 0.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. 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. Details Configuration changes 1. Change the download folder to /home/<user/.pyload/scripts 2. Change permissions for downloaded files: 1. Change permissions of downloads: on 2. Permission mode for downloaded files: 0744 Making the request to download files The flashgot API provides functionality to download files from a provided URL. Although pyload tries to prevent non-local requests from being able to reach this API, it relies on checking the Host header and the Referer header of the incoming request. Both of these can be set by an attacker to arbitrary values, thereby…
Recommended action: Upgrade to 0.5.0b3.dev87 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Open redirect vulnerability due to incorrect validation of input values when redirecting users after login. Details pyload is validating URLs via the getredirecturl function when redirecting users at login. The URL entered in the next variable goes through the issafeurl function, where a lack of validation can redirect the user to an arbitrary domain. The documentation in the urllib library shows that improper URLs are recognized as relative paths when using the urlparse function. (https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlparse) For example, When an unusual URL like https:///example.com is entered, urlparse interprets it as a relative path, but in the actual request it is converted to https://example.com due to url normalization. PoC 1. In the next variable, insert the URL to which you want to redirect the user. 2. Check that it is possible to bypass url validation and redirect users to an arbitrary url. Impact An attacker can use this vulnerability…
Recommended action: Upgrade to 0.5.0b3.dev79 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The pyload API allows any API call to be made using GET requests. Since the session cookie is not set to SameSite: strict, this opens the library up to severe attack possibilities via a Cross-Site Request Forgery (CSRF) attack. This proof of concept shows how an unauthenticated user could trick the administrator's browser into creating a new admin user. PoC We host the following HTML file on an attacker-controlled server. If we now trick an administrator into visiting our malicious page at https://attacker.com/CSRF.html, we see that their browser will make a request to /api/adduser/%22hacker%22,%22hacker%22, adding a new administrator to the pyload application. The attacker can now authenticate as this newly created administrator user with the username hacker and password hacker. Impact Any API call can be made via a CSRF attack by an unauthenticated user.
Recommended action: Upgrade to 0.5.0b3.dev78 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Any unauthenticated user can browse to a specific URL to expose the Flask config, including the SECRETKEY variable. Details Any unauthenticated user can browse to a specific URL to expose the Flask config, including the SECRETKEY variable. PoC Run pyload in the default configuration by running the following command Now browse to http://localhost:8000/render/info.html. Notice how the Flask configuration gets displayed. I was quite amused by this finding. I think it's a very interesting coming together of things that is so unlikely to happen. Below I will detail my process a bit more. I was looking through the code to see how the authorization mechanism is implemented when I spotted this route, which can be accessed by any unauthenticated actor - https://github.com/pyload/pyload/blob/57d81930edb59177c60830ad8ac36a91d0ec4c4e/src/pyload/webui/app/blueprints/appblueprint.py#L33C1-L37C51 This route allows me to load in any of the predefined templates. However, these templates will…
Recommended action: Upgrade to 0.5.0b3.dev77 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.