While the update_users() route in the WebUI correctly includes a call to clear_all_user_sessions(name), the public /api/<func> RPC dispatcher calls Api.set_user_permission directly, bypassing this crucial invalidation step. Consequently, a user whose privileges have been demoted retains their original session cookie, which continues to grant access to restricted endpoints for the duration of the 31-day session lifetime, unless the user voluntarily terminates the session. This vulnerability poses a significant risk to organizations relying on pyLoad's RPC interface for automated user management.

Attack Chain

1. Victim authenticates to pyLoad via the WebUI, obtaining a valid Flask session cookie containing cached role and permission bits.
2. Victim utilizes their current, elevated permissions to access a sensitive resource, such as /api/get_userdir.
3. Administrator identifies a need to demote the victim and executes a POST /api/set_user_permission request via the public RPC interface.
4. The Api.set_user_permission function successfully updates the victim's permission and role bits in the backend database.
5. The API call returns successfully, but the function fails to trigger a session invalidation routine for the target user.
6. The victim continues to use their original session cookie to access the application.
7. The application's apikey_auth logic rebuilds the user context directly from the stale session cookie fields.
8. The application performs authorization checks against the stale, elevated permission bits, permitting the victim to continue unauthorized activity.

Impact

The impact of this vulnerability is unauthorized access to privileged features by users who have been demoted by an administrator. This access can persist for up to 31 days, the default session lifetime in pyLoad. This may lead to unauthorized data access, persistence of configuration changes, or misuse of administrative functions if the demoted user retains access to management APIs. The vulnerability affects all deployments of pyLoad that utilize the RPC interface for user management and have not applied the necessary session invalidation patches.

Recommendation

1. Update pyLoad to a patched version that explicitly invokes clear_all_user_sessions(name) within the Api.set_user_permission method.
2. Until a patch is applied, audit the use of the /api/set_user_permission endpoint and manually terminate user sessions via the WebUI "Manage Users" interface after any manual RPC privilege changes.
3. Implement network-level monitoring to identify unauthorized calls to administrative API endpoints by non-privileged accounts, focusing on the /api/ URI prefix.
4. Review access logs for instances where sensitive API endpoints are accessed by user accounts that have recently undergone privilege changes.

Attack Chain

1. Attacker gains access to a low-privileged account on a pyload-ng instance (e.g., role=USER, permission=0).
2. Attacker initiates an authenticated session using their own credentials.
3. Attacker identifies the target administrative account (e.g., 'pyload').
4. Attacker constructs a script to iterate through password guesses using the /api/getUserData endpoint.
5. For each attempt, the attacker modifies the X-Forwarded-For header to bypass the 100 req/min rate limit bucket.
6. Attacker monitors the HTTP response: a 200 OK with null data indicates an incorrect password, while a 200 OK with user details confirms successful authentication.
7. Upon identifying the correct password, the attacker authenticates as the administrator via the /login endpoint.
8. Attacker uses administrative privileges to exfiltrate all user data or perform other unauthorized actions.

Impact

Successful exploitation results in full administrative takeover of the pyload-ng instance. An attacker can recover the administrator's password via automated brute force, as there are no failed-login throttles or account lockout policies. Once the admin account is compromised, the attacker gains complete control over the application, including the ability to dump sensitive user data and credentials stored in the system.

Recommendation

• Upgrade to a patched version of pyload-ng as soon as a fix is available, or remove the vulnerable getUserData and get_userdata methods if they are not required.
• Implement strict ingress filtering for web traffic to ensure that the X-Forwarded-For header is only trusted when originating from a validated, internal proxy.
• Configure the web server to use the real client IP address for rate-limiting calculations instead of trusting client-supplied headers.
• Apply granular rate limiting or account lockout policies to mitigate automated brute-force attempts.
• Enable account-level monitoring for unusual spikes in failed authentication attempts directed at administrative accounts.