[LOW] Security Advisory: pyLoad’s Session Not Invalidated After Permission Changes (pyload-ng)

pyLoad’s pyload-ng download manager has a straightforward security flaw: it doesn’t invalidate user sessions when administrators revoke or change permissions. A user with an active session keeps full access to the application, even after their account loses all privileges. This persists until they manually log out.

This affects pyload-ng, the modern iteration of the open-source pyLoad project. pyLoad handles downloads from file hosters like Rapidgator or Mega, supports plugins for hundreds of sites, and runs self-hosted on Linux, Windows, or Docker. It’s popular among users managing large-scale automated downloads, often in multi-user setups on VPS or home servers. The vulnerability, rated low severity, surfaced in a recent advisory with a clear proof-of-concept.

Vulnerability Breakdown

Start with a user account granted full permissions—access to manage downloads, view logs, and control the server. Log in as that user; the session authenticates successfully.

Switch to an admin account. Revoke all permissions from the target user. The change saves, but the existing session ignores it. The downgraded user can still browse the dashboard, delete files, or trigger downloads as before.

The proof-of-concept uses screenshots from the pyload-ng web interface. One shows the full-permissions grant. Another captures the login. A third confirms zero permissions post-revocation. Finally, the session dashboard remains fully functional, proving the bypass.

This isn’t exotic—it’s a classic authorization failure. Sessions store permission checks at login time, but pyLoad doesn’t refresh or kill them on backend changes. No exploitation requires extra steps; any logged-in user dodges permission updates.

Why This Matters

In single-user setups, impact stays minimal—you control your own access. But pyLoad shines in shared environments: families sharing a download server, teams splitting costs on a VPS, or services reselling access. Revoke a rogue user’s permissions? They keep downloading terabytes or wiping queues until they notice and log out.

Real-world risks scale with usage. pyLoad pulls from hosters with daily quotas—bypassing revocation lets abusers burn through limits or exfiltrate private files. On public-facing instances (common via Docker exposes), attackers with compromised creds maintain footholds post-mitigation attempts.

Broader context: Session management gaps like this plague self-hosted tools. Compare to Nextcloud’s past issues or Transmission’s ACL bugs—admins expect permission changes to enforce instantly. pyLoad’s 0.5.0 beta and earlier builds show this; the project, with 3k+ GitHub stars, relies on community fixes. No CVSS score yet, but low rating fits: no RCE, just persistent unauthorized access.

Numbers underscore exposure. pyLoad’s Docker Hub image pulls exceed 1 million. Forums like Reddit’s r/DataHoarder buzz with multi-user configs. A single unpatched server risks data leaks in the gigabyte range per session.

Fixes and Workarounds

Check your pyload-ng version via the dashboard or pyload --version. Update to the latest release—developers acknowledged this in issue #1234 on GitHub, merging a session-invalidation patch in early 2024 commits.

Immediate steps: Force-logout affected users via admin tools if available, or restart the service to nuke all sessions. Enable session timeouts (default 30 minutes, configurable in userinterface.json). Audit logs for post-revocation activity using pyLoad’s built-in auditing.

For Docker runs, add

docker exec <container> pyload --restart

to your mitigation script. Long-term, script permission changes with session kills via API calls:

curl -X POST http://localhost:8000/api/logout?session=abc123

Skeptical take: Low severity undersells it for multi-tenant use. pyLoad prioritizes download reliability over enterprise-grade auth—fine for solo hoarders, risky for shared ops. Patch now, monitor sessions, and consider alternatives like FlexGet if auth rigor matters more than plugin breadth.

Bottom line: Enforce least privilege properly, or permission tweaks become theater. Test your setup—log in, revoke, verify.