{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/vendors/pyload/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["pyLoad (all versions prior to fix)"],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","persistence","api-security"],"_cs_type":"advisory","_cs_vendors":["pyLoad"],"content_html":"\u003cp\u003epyLoad contains a security flaw where the \u003ccode\u003eApi.set_user_permission\u003c/code\u003e method fails to invalidate active user sessions when an administrator modifies a user's role or permissions via the RPC interface. The vulnerability exists because pyLoad caches authorization data (roles and permissions) within the Flask session cookie during the initial login event and does not perform re-validation against the backend database for subsequent requests.\u003c/p\u003e\n\u003cp\u003eWhile the \u003ccode\u003eupdate_users()\u003c/code\u003e route in the WebUI correctly includes a call to \u003ccode\u003eclear_all_user_sessions(name)\u003c/code\u003e, the public \u003ccode\u003e/api/\u0026lt;func\u0026gt;\u003c/code\u003e RPC dispatcher calls \u003ccode\u003eApi.set_user_permission\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eVictim authenticates to pyLoad via the WebUI, obtaining a valid Flask session cookie containing cached role and permission bits.\u003c/li\u003e\n\u003cli\u003eVictim utilizes their current, elevated permissions to access a sensitive resource, such as \u003ccode\u003e/api/get_userdir\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAdministrator identifies a need to demote the victim and executes a \u003ccode\u003ePOST /api/set_user_permission\u003c/code\u003e request via the public RPC interface.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eApi.set_user_permission\u003c/code\u003e function successfully updates the victim's permission and role bits in the backend database.\u003c/li\u003e\n\u003cli\u003eThe API call returns successfully, but the function fails to trigger a session invalidation routine for the target user.\u003c/li\u003e\n\u003cli\u003eThe victim continues to use their original session cookie to access the application.\u003c/li\u003e\n\u003cli\u003eThe application's \u003ccode\u003eapikey_auth\u003c/code\u003e logic rebuilds the user context directly from the stale session cookie fields.\u003c/li\u003e\n\u003cli\u003eThe application performs authorization checks against the stale, elevated permission bits, permitting the victim to continue unauthorized activity.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eUpdate pyLoad to a patched version that explicitly invokes \u003ccode\u003eclear_all_user_sessions(name)\u003c/code\u003e within the \u003ccode\u003eApi.set_user_permission\u003c/code\u003e method.\u003c/li\u003e\n\u003cli\u003eUntil a patch is applied, audit the use of the \u003ccode\u003e/api/set_user_permission\u003c/code\u003e endpoint and manually terminate user sessions via the WebUI \u0026quot;Manage Users\u0026quot; interface after any manual RPC privilege changes.\u003c/li\u003e\n\u003cli\u003eImplement network-level monitoring to identify unauthorized calls to administrative API endpoints by non-privileged accounts, focusing on the \u003ccode\u003e/api/\u003c/code\u003e URI prefix.\u003c/li\u003e\n\u003cli\u003eReview access logs for instances where sensitive API endpoints are accessed by user accounts that have recently undergone privilege changes.\u003c/li\u003e\n\u003c/ol\u003e\n","date_modified":"2026-10-09T21:27:33Z","date_published":"2026-10-09T21:27:33Z","id":"https://feed.craftedsignal.io/briefs/2026-10-pyload-session-invalidation/","summary":"An improper implementation of the set_user_permission API endpoint in pyLoad allows users to retain elevated permissions for up to 31 days after an administrator has explicitly revoked their access.","title":"pyLoad Session Invalidation Failure After Privilege Revocation","url":"https://feed.craftedsignal.io/briefs/2026-10-pyload-session-invalidation/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["pyload-ng (\u003e= 0.5.0b3.dev1, \u003c= 0.5.0b3.dev101)","pyLoad-ng (\u003c= 0.5.0b3.dev101)"],"_cs_severities":["high"],"_cs_tags":["credential-access","authentication-bypass","web-application"],"_cs_type":"advisory","_cs_vendors":["pyLoad"],"content_html":"\u003cp\u003eResearch has identified a critical vulnerability in pyload-ng (versions 0.5.0b3.dev1 through 0.5.0b3.dev101) originating from an incorrectly implemented permission gate. The \u003ccode\u003eApi.getUserData\u003c/code\u003e and \u003ccode\u003eApi.get_userdata\u003c/code\u003e endpoints are decorated with \u003ccode\u003e@permission(Perms.ANY)\u003c/code\u003e. In the pyload-ng codebase, \u003ccode\u003ePerms.ANY\u003c/code\u003e is defined as \u003ccode\u003e0\u003c/code\u003e, and the permission validation logic uses a bitmask AND operation. Consequently, any authenticated session, regardless of privileges, satisfies the \u003ccode\u003ehas_permission\u003c/code\u003e check. These endpoints act as thin wrappers around the internal \u003ccode\u003echeck_auth\u003c/code\u003e method, which is intended to be restricted to administrators. By passing an arbitrary password to these endpoints, an attacker can determine if the password is valid based on the API response, creating a high-speed brute-force oracle. This vulnerability is significantly amplified by the lack of account lockout mechanisms and a flaw in the rate-limiting implementation that permits bypassing by rotating the \u003ccode\u003eX-Forwarded-For\u003c/code\u003e HTTP header.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains access to a low-privileged account on a pyload-ng instance (e.g., \u003ccode\u003erole=USER\u003c/code\u003e, \u003ccode\u003epermission=0\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eAttacker initiates an authenticated session using their own credentials.\u003c/li\u003e\n\u003cli\u003eAttacker identifies the target administrative account (e.g., 'pyload').\u003c/li\u003e\n\u003cli\u003eAttacker constructs a script to iterate through password guesses using the \u003ccode\u003e/api/getUserData\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eFor each attempt, the attacker modifies the \u003ccode\u003eX-Forwarded-For\u003c/code\u003e header to bypass the 100 req/min rate limit bucket.\u003c/li\u003e\n\u003cli\u003eAttacker monitors the HTTP response: a \u003ccode\u003e200 OK\u003c/code\u003e with null data indicates an incorrect password, while a \u003ccode\u003e200 OK\u003c/code\u003e with user details confirms successful authentication.\u003c/li\u003e\n\u003cli\u003eUpon identifying the correct password, the attacker authenticates as the administrator via the \u003ccode\u003e/login\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eAttacker uses administrative privileges to exfiltrate all user data or perform other unauthorized actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to a patched version of pyload-ng as soon as a fix is available, or remove the vulnerable \u003ccode\u003egetUserData\u003c/code\u003e and \u003ccode\u003eget_userdata\u003c/code\u003e methods if they are not required.\u003c/li\u003e\n\u003cli\u003eImplement strict ingress filtering for web traffic to ensure that the \u003ccode\u003eX-Forwarded-For\u003c/code\u003e header is only trusted when originating from a validated, internal proxy.\u003c/li\u003e\n\u003cli\u003eConfigure the web server to use the real client IP address for rate-limiting calculations instead of trusting client-supplied headers.\u003c/li\u003e\n\u003cli\u003eApply granular rate limiting or account lockout policies to mitigate automated brute-force attempts.\u003c/li\u003e\n\u003cli\u003eEnable account-level monitoring for unusual spikes in failed authentication attempts directed at administrative accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-10-09T21:27:44Z","date_published":"2026-10-09T21:25:58Z","id":"https://feed.craftedsignal.io/briefs/2026-10-pyload-auth-bypass/","summary":"An insecure permission check in the pyload-ng API allows any authenticated user to perform administrative password brute-forcing via a side-channel oracle.","title":"Authentication Bypass and Brute-Force Oracle in pyload-ng","url":"https://feed.craftedsignal.io/briefs/2026-10-pyload-auth-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - PyLoad","version":"https://jsonfeed.org/version/1.1"}