Skip to content

GHSA-ccxc-x975-4hh9 CVE-2026-42312 PYSEC-2026-126

pyload-ng: non-admin SETTINGS users can disable outbound TLS peer verification via unrestricted `ssl_verify` config (incomplete fix for CVE-2026-33509 / -35463 / -35464 / -35586)

Medium PyPI
Severity
6.8 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.17%
Chance of exploitation in the next 30 days. Higher than 6.86% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-295 Improper Certificate Validation
CWE-306 Missing Authentication for Critical Function
CWE-863 Incorrect Authorization
Fix
0.5.0b3.dev100
Upgrade pyload-ng to this version or later

Description

Summary

The set_config_value() API method (@permission(Perms.SETTINGS)) in src/pyload/core/api/__init__.py gates security-sensitive options behind a hand-maintained allowlist ADMIN_ONLY_CORE_OPTIONS. The option ("general", "ssl_verify") is not on that allowlist. Any authenticated user with the non-admin SETTINGS permission can set general.ssl_verify = off, and every subsequent outbound pycurl request is made with SSL_VERIFYPEER=0 and SSL_VERIFYHOST=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, set_config_value() (around lines 215–290). The function is decorated with @permission(Perms.SETTINGS) and only rejects writes when (category, option) appears in ADMIN_ONLY_CORE_OPTIONS:

ADMIN_ONLY_CORE_OPTIONS = {
    ("general", "storage_folder"),
    ("log", "syslog_host"), ("log", "syslog_port"),
    ("proxy", "password"), ("proxy", "username"),
    ("reconnect", "script"),
    ("webui", "host"),
    ("webui", "ssl_certfile"), ("webui", "ssl_keyfile"), ("webui", "ssl_certchain"),
    ("webui", "use_ssl"),
}
...
if (category, option) in ADMIN_ONLY_CORE_OPTIONS and not is_admin:
    self.pyload.log.error(...); return
self.pyload.config.set(category, option, value)

("general", "ssl_verify") is absent. config.set() in src/pyload/core/config/parser.py:329 calls cast() which has no branch for enum-string types — "off" is stored verbatim and persisted to disk via self.save().

Reader — src/pyload/core/network/request_factory.py:109-110:

def get_options(self):
    return {
        "interface": self.iface(),
        "proxies":   self.get_proxies(),
        "ipv6":      self.pyload.config.get("download", "ipv6"),
        "ssl_verify": self.pyload.config.get("general", "ssl_verify"),
        ...
    }

Sink — src/pyload/core/network/http/http_request.py:193-206:

if "ssl_verify" in options:
    aiachaser_on = b"on (using aia-chaser)"
    if options["ssl_verify"] in [True, b"on", aiachaser_on]:
        ...
        ssl_verify = 1
    else:
        ssl_verify = 0
    self.c.setopt(pycurl.SSL_VERIFYPEER, ssl_verify)
    self.c.setopt(pycurl.SSL_VERIFYHOST, ssl_verify * 2)

Because get_options() is invoked every time a new pycurl handle is built, the new config value takes effect on the very next outbound request — no pyload restart required.

PoC

Authenticated as any user who has Perms.SETTINGS but is not admin (e.g. a user with Role.USER + the SETTINGS permission bit):

# 1) Log in as the SETTINGS (non-admin) user.
curl -c cookies.txt -X POST http://pyload.example:8000/api/login \
    -d 'username=settings_user&password=<password>'

# 2) Disable TLS verification for all outbound downloads.
curl -b cookies.txt -X POST http://pyload.example:8000/api/setConfigValue \
    -d 'category=general&option=ssl_verify&value=off&section=core'
# -> 200 OK. Config persisted.

# 3) Enqueue any HTTPS download. An on-path attacker (shared LAN,
#    compromised upstream router, DNS hijack, or a malicious proxy
#    enabled via the sibling advisory on the proxy.* options) can
#    now present a forged cert for any target — pyload accepts it.

Verification: observe pycurl SSL_VERIFYPEER=0 in a debug build, or confirm that a download from an HTTPS endpoint served with a self-signed / mismatched cert succeeds after step 2 and fails before it.

Impact

  • Who: any authenticated user whose role was granted Perms.SETTINGS. In multi-user pyload deployments that delegate settings administration to non-admins, this is an unintended privilege escalation from "can change UI/download settings" to "can silently disable TLS cert validation for all outbound fetches".
  • What:
    1. Man-in-the-middle on all HTTPS downloads, captcha fetches, update checks, and plugin HTTP calls.
    2. Extends the impact of the already-published SSRF chain (CVE-2026-33992 / CVE-2026-35459). The URL-hostname validation those patches added is only meaningful if the TLS channel authenticates the endpoint; with ssl_verify=off, an on-path attacker can present forged certs for already-validated hosts — so HTTPS cloud-metadata endpoints and internal HTTPS services behind the host allowlist become reachable again.
    3. Silent to the admin. Every adjacent security-critical option (proxy.password, SSL certfile/keyfile/certchain, use_ssl) is already admin-only, so the admin's mental model is that TLS policy cannot be weakened by a non-admin.
  • Not impacted: unauthenticated attackers; users holding only DOWNLOAD / LIST roles.

Affected versions

PyPI

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

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.dev100

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

Severity breakdown

CVSS 3.1 6.8

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

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Weakness

CWE-295: Improper Certificate Validation

The product does not validate, or incorrectly validates, a certificate.

How to prevent it
  • Architecture and Design, Implementation: Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
  • Implementation: If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

CWE-306: Missing Authentication for Critical Function

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

How to prevent it
  • Architecture and Design: Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
  • Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  • Architecture and Design: Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks. In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
  • Implementation, System Configuration, Operation: When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

CWE-863: Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

How to prevent it
  • Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
  • Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
  • System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

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