Pyload-Ng (>= 0.5.0b3.dev1, <= 0.5.0b3.dev101) - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/pyload-ng--0.5.0b3.dev1--0.5.0b3.dev101/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 09 Oct 2026 21:25:58 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgAuthentication Bypass and Brute-Force Oracle in pyload-nghttps://feed.craftedsignal.io/briefs/2026-10-pyload-auth-bypass/Fri, 09 Oct 2026 21:25:58 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-10-pyload-auth-bypass/An insecure permission check in the pyload-ng API allows any authenticated user to perform administrative password brute-forcing via a side-channel oracle.Research 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 Api.getUserData and Api.get_userdata endpoints are decorated with @permission(Perms.ANY). In the pyload-ng codebase, Perms.ANY is defined as 0, and the permission validation logic uses a bitmask AND operation. Consequently, any authenticated session, regardless of privileges, satisfies the has_permission check. These endpoints act as thin wrappers around the internal check_auth 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 X-Forwarded-For HTTP header.

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.
]]>highadvisorycredential-accessauthentication-bypassweb-application