Mytube EUVD-2026-16521

MyTube versions prior to 1.8.72. Remote unauthenticated attacker can trigger repeated failed login attempts across three publicly accessible password verification endpoints sharing a single login-attempts.json state file to lock out administrator and visitor accounts from password-based authentication. No victim interaction required.

This vulnerability carries moderate-to-high real-world risk despite the absence of a CVSS score and EPSS probability data. The attack vector is unauthenticated and network-accessible (publicly accessible endpoints per description), attack complexity is low (simple HTTP POST loop required), and the technical impact is high (complete denial of password-based authentication for indefinite duration). The lack of authentication requirements means any remote attacker can trigger the exploit from any network location without credentials. The technical impact is not confidentiality or integrity of data but availability of the authentication service itself, which is a critical dependency. The exploit is highly automatable and requires minimal sophistication-a simple script repeatedly sending invalid credentials will lock out all users. A patched version (1.8.72) has been released and commits are available on GitHub, indicating vendor responsiveness. Without CVSS or EPSS scores, prioritization should rely on: (1) attack vector = network, (2) no authentication required, (3) automatable, (4) affects availability of core authentication, (5) patch available. This is a genuine priority for any MyTube deployment, particularly self-hosted instances exposed to untrusted networks.

An attacker identifies a MyTube instance on a public network and sends rapid-fire HTTP requests with invalid credentials to any of the three password endpoints (e.g., /login, /visitor-login, or similar endpoints that share the login-attempts.json state). After approximately 5-10 failed requests (exact threshold depends on cooldown logic), the shared counter reaches its limit and activates a 24-hour account lockout affecting all three endpoints. The attacker then waits 24 hours and sends one more failed request, immediately re-triggering the lockout. Legitimate administrators and users are unable to log in via password-based authentication, forcing a manual intervention (e.g., direct file modification or service restart) to regain access. No sophisticated tools or public exploit code are required; a simple bash loop or curl script suffices.