<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:webfeeds="http://webfeeds.org/rss/1.0"><channel><title>PyLoad (All Versions Prior to Fix) - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/pyload-all-versions-prior-to-fix/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Fri, 09 Oct 2026 21:27:33 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/pyload-all-versions-prior-to-fix/feed.xml" rel="self" type="application/rss+xml"/><image><url>https://feed.craftedsignal.io/favicon-32x32.png</url><title>CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/</link><width>32</width><height>32</height></image><webfeeds:icon>https://feed.craftedsignal.io/favicon.svg</webfeeds:icon><item><title>pyLoad Session Invalidation Failure After Privilege Revocation</title><link>https://feed.craftedsignal.io/briefs/2026-10-pyload-session-invalidation/</link><pubDate>Fri, 09 Oct 2026 21:27:33 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-10-pyload-session-invalidation/</guid><description>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.</description><content:encoded><![CDATA[<p>pyLoad contains a security flaw where the <code>Api.set_user_permission</code> 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.</p>
<p>While the <code>update_users()</code> route in the WebUI correctly includes a call to <code>clear_all_user_sessions(name)</code>, the public <code>/api/&lt;func&gt;</code> RPC dispatcher calls <code>Api.set_user_permission</code> 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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Victim authenticates to pyLoad via the WebUI, obtaining a valid Flask session cookie containing cached role and permission bits.</li>
<li>Victim utilizes their current, elevated permissions to access a sensitive resource, such as <code>/api/get_userdir</code>.</li>
<li>Administrator identifies a need to demote the victim and executes a <code>POST /api/set_user_permission</code> request via the public RPC interface.</li>
<li>The <code>Api.set_user_permission</code> function successfully updates the victim's permission and role bits in the backend database.</li>
<li>The API call returns successfully, but the function fails to trigger a session invalidation routine for the target user.</li>
<li>The victim continues to use their original session cookie to access the application.</li>
<li>The application's <code>apikey_auth</code> logic rebuilds the user context directly from the stale session cookie fields.</li>
<li>The application performs authorization checks against the stale, elevated permission bits, permitting the victim to continue unauthorized activity.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>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.</p>
<h2 id="recommendation">Recommendation</h2>
<ol>
<li>Update pyLoad to a patched version that explicitly invokes <code>clear_all_user_sessions(name)</code> within the <code>Api.set_user_permission</code> method.</li>
<li>Until a patch is applied, audit the use of the <code>/api/set_user_permission</code> endpoint and manually terminate user sessions via the WebUI &quot;Manage Users&quot; interface after any manual RPC privilege changes.</li>
<li>Implement network-level monitoring to identify unauthorized calls to administrative API endpoints by non-privileged accounts, focusing on the <code>/api/</code> URI prefix.</li>
<li>Review access logs for instances where sensitive API endpoints are accessed by user accounts that have recently undergone privilege changes.</li>
</ol>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>privilege-escalation</category><category>persistence</category><category>api-security</category></item></channel></rss>