Skip to content

GHSA-g3cm-qg2v-2hj5 CVE-2024-24808 PYSEC-2026-1817

pyLoad open redirect vulnerability due to improper validation of the is_safe_url function

Medium PyPI
Severity
6.1 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.55%
Chance of exploitation in the next 30 days. Higher than 45.77% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
Fix
0.5.0b3.dev79
Upgrade pyload-ng to this version or later

Description

Summary

Open redirect vulnerability due to incorrect validation of input values when redirecting users after login.

Details

pyload is validating URLs via the get_redirect_url function when redirecting users at login. 301715649-f533db41-d0bd-44f7-8735-be1887fbd06c

The URL entered in the next variable goes through the is_safe_url function, where a lack of validation can redirect the user to an arbitrary domain. 301715667-2819b1d3-8a14-42f4-89c8-3d2fa84fc309

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. 301715949-bb1451eb-5e84-451d-83b4-5c3e204d1df7

  2. Check that it is possible to bypass url validation and redirect users to an arbitrary url. 301715824-3de6584a-878d-4ec4-a3d5-a34d11c6c0ac 301716107-ba5ab7b9-7aa8-4b7a-8924-eba82442b4c3

Impact

An attacker can use this vulnerability to redirect users to malicious websites, which can be used for phishing and similar attacks.

Affected versions

PyPI

PackageVulnerableFixed in
pyload-ng
< 0.5.0b3.dev79
0.5.0b3.dev79

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

pyload-ng PyPI → 0.5.0b3.dev79

pip
pip install --upgrade "pyload-ng>=0.5.0b3.dev79"
poetry
poetry add "pyload-ng>=0.5.0b3.dev79"
uv
uv add "pyload-ng>=0.5.0b3.dev79"

Severity breakdown

CVSS 3.1 6.1

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
Required
Scope
Changed
Confidentiality
Low
Integrity
Low
Availability
None

Weakness

CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

How to prevent it
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. Use a list of approved URLs or domains to be used for redirection.
  • Architecture and Design: Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.
  • Architecture and Design: When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs. For example, ID 1 could map to "/login.asp" and ID 2 could map to "http://www.example.com/". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
  • Architecture and Design: Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).
  • Architecture and Design, Implementation: Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls. Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.
  • Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-68w4-83fh-f2w8
pyload-ng: getUserData/get_userdata exposed at Perms.ANY allow any authenticated account to brute-force the administrator password
High Also affects pyload-ng
GHSA-9q47-3cm2-2rp8
pyLoad: Rate-Limit Bypass and Audit-Log Spoofing via Trusted Client-Controlled `X-Forwarded-For` Header
Medium Also affects pyload-ng
GHSA-jq7h-wrvp-3rgx
pyLoad: Privilege revocation and password change through the REST API do not invalidate the user's session
High Also affects pyload-ng
GHSA-889w-m37p-88m5
pyLoad: Api.set_user_permission never invalidates the target's session
High Also affects pyload-ng
GHSA-p3pr-8f3m-4qp8
pyLoad WindowsPhoneNotify addon: non-admin SETTINGS user triggers SSRF via unguarded http.client notification host
Medium Also affects pyload-ng
GHSA-fr26-jjhm-638c
pyLoad: Tar extraction creates device nodes and FIFOs (member types not filtered; tarfile extractall without filter=)
High Also affects pyload-ng
GHSA-r44w-v6gf-x3p6
pyLoad has an authentication bypass in API key validation (check_apikey cache)
High Also affects pyload-ng
GHSA-j92p-c242-7hfx
pyLoad: Unauthenticated access to /web/<path:filename> bypasses authentication on sensitive templates and leaks internal error details via exception attribute typo
Medium Also affects pyload-ng
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor