CVE-2026-42312: 
Python vulnerability analysis and mitigation

CVE-2026-42312 is an incorrect authorization vulnerability in pyload-ng that allows authenticated non-admin users with the SETTINGS permission to disable outbound TLS certificate verification for all connections. The flaw exists in the set_config_value() API method, where the general.ssl_verify option is absent from the ADMIN_ONLY_CORE_OPTIONS allowlist, enabling privilege escalation to silently weaken TLS policy. It affects pyload-ng versions up to and including 0.5.0b3.dev99; the patched version is 0.5.0b3.dev100. The vulnerability was published on April 24, 2026, and has a CVSS v3.1 base score of 6.8 (Medium) (Github Advisory). It is a direct continuation of the fix family CVE-2026-33509 / CVE-2026-35463 / CVE-2026-35464 / CVE-2026-35586, each addressing a different missed option in the same allowlist (Github Advisory).

The root cause is an incomplete allowlist (ADMIN_ONLY_CORE_OPTIONS) in src/pyload/core/api/__init__.py that governs which configuration options are restricted to admin users (CWE-863: Incorrect Authorization, CWE-295: Improper Certificate Validation, CWE-306: Missing Authentication for Critical Function). The ("general", "ssl_verify") tuple is absent from this set, so any user with Perms.SETTINGS can call the setConfigValue API endpoint with category=general&option=ssl_verify&value=off&section=core, which persists the value to disk without requiring a restart. The sink in src/pyload/core/network/http/http_request.py reads this value on every new pycurl handle creation and sets pycurl.SSL_VERIFYPEER=0 and pycurl.SSL_VERIFYHOST=0, fully disabling TLS peer and hostname verification for all subsequent outbound requests. A complete PoC using curl commands is publicly available in the official security advisory (Github Advisory, pyload Advisory).

Successful exploitation enables a man-in-the-middle (MITM) attack on all outbound HTTPS traffic from the pyload instance, including file downloads, captcha fetches, update checks, and plugin HTTP calls. An on-path attacker (e.g., on a shared LAN, via a compromised upstream router, or through DNS hijacking) can present forged TLS certificates for any hostname pyload contacts, intercepting or tampering with downloaded content. This also re-enables SSRF attacks against HTTPS cloud-metadata endpoints and internal HTTPS services that were previously mitigated by host allowlist patches (CVE-2026-33992 / CVE-2026-35459), since TLS no longer authenticates those endpoints. The change is silent to administrators, as all adjacent TLS-related options are already admin-only, creating a false sense of security (Github Advisory).

A complete, step-by-step PoC using curl commands is publicly documented in the official GitHub Security Advisory, demonstrating login, the setConfigValue API call to disable TLS, and the resulting MITM condition (pyload Advisory). Exploitation requires low privileges (an authenticated account with Perms.SETTINGS) and high attack complexity (requiring an on-path network position to complete the MITM). No in-the-wild exploitation or threat actor attribution has been reported. The EPSS score is approximately 0.017% (6th percentile), indicating a low current probability of active exploitation (Github Advisory). The vulnerability is not listed in the CISA KEV catalog.

1. Obtain SETTINGS-permission credentials: Acquire credentials for any pyload account that has been granted the Perms.SETTINGS permission bit but is not an admin — this could be through credential theft, phishing, or insider access.
2. Authenticate to the pyload API: Log in via the API endpoint to obtain a session cookie:

   curl -c cookies.txt -X POST http://pyload.example:8000/api/login \
       -d 'username=settings_user&password=<password>'

3. Disable TLS verification: Call setConfigValue to set general.ssl_verify=off, which is persisted to disk immediately:

   curl -b cookies.txt -X POST http://pyload.example:8000/api/setConfigValue \
       -d 'category=general&option=ssl_verify&value=off&section=core'
   # Returns: 200 OK

4. Position for MITM: Establish an on-path network position between the pyload server and its download targets using techniques such as ARP spoofing on a shared LAN, DNS hijacking, or a compromised upstream router.
5. Present a forged certificate: Intercept outbound HTTPS connections from pyload and respond with a self-signed or mismatched TLS certificate for the target hostname — pyload will accept it because SSL_VERIFYPEER=0 and SSL_VERIFYHOST=0 are now set on every new pycurl handle.
6. Intercept or tamper with traffic: Decrypt and inspect or modify downloaded files, plugin responses, update payloads, or captcha API responses in transit (pyload Advisory).

• Logs: pyload API access logs showing a POST request to /api/setConfigValue with parameters category=general, option=ssl_verify, value=off, section=core from a non-admin user account.
• File System: The pyload configuration file (typically pyload.cfg or equivalent) containing ssl_verify = off under the [general] section, especially if changed without admin action.
• Network: Outbound HTTPS connections from the pyload server that succeed against endpoints presenting self-signed, expired, or hostname-mismatched TLS certificates; unexpected TLS handshakes completing without certificate validation errors in network captures.
• Process/Debug: In a debug build of pyload, pycurl debug output showing SSL_VERIFYPEER=0 for outbound requests (pyload Advisory).

Upgrade pyload-ng to version 0.5.0b3.dev100 or later, which adds ("general", "ssl_verify") to the ADMIN_ONLY_CORE_OPTIONS allowlist, restricting this setting to admin users only (Github Advisory). As an interim workaround, audit all non-admin user accounts and revoke the Perms.SETTINGS permission from any account that does not strictly require it. Additionally, verify the pyload configuration file to ensure ssl_verify is set to on and monitor for unauthorized changes. Restricting network access to the pyload API to trusted hosts can reduce the attack surface for credential-based exploitation.