CVE-2026-62301 in MyTube
Summary
by MITRE • 10/30/2026
MyTube is a self-hosted downloader and player for several video websites. Prior to version 1.10.3, backend video access does not enforce the visitor role's intended public-only restriction when `loginEnabled=true` and a visitor password is configured. The frontend filter in `VideoContext.tsx` is only client-side, `roleBasedAuthMiddleware.ts` allows all visitor GET requests, and `storageService/videos.ts` performs `getVideos()` and `getVideoById(id)` queries without checking the caller's role or `visibility`. A visitor can enumerate `/api/videos` or request `/api/videos/:id` to retrieve hidden `visibility`=0 records, exposing titles, `sourceUrl` values, `videoPath` values, subtitle paths and `thumbnailPath` values. The `serveMountVideo()` path also serves mounted video files without `visibility` checks. Leaked paths work against unauthenticated `/videos/*` and `/subtitles/*` routes, allowing media downloads without credentials. The RSS visitor feed already filters `visibility`=1 content and is not the affected query path. Default loginEnabled=false single-user deployments are unaffected by this role-boundary issue because all callers are owner-equivalent. This issue is fixed in version 1.10.3.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in MyTube prior to version 1.10.3 represents a critical failure in server-side access control, specifically affecting the enforcement of role-based permissions for unauthenticated visitors. In self-hosted video management systems, it is standard practice to distinguish between public content accessible by any user and private or hidden content restricted to authenticated administrators or owners. However, this implementation flaw allows an attacker with no valid credentials to bypass intended visibility restrictions when the application has login functionality enabled and a visitor password configured. The core issue stems from a disconnect between client-side presentation logic and server-side data retrieval mechanisms, resulting in unauthorized information disclosure of sensitive media metadata and direct access to stored video files.
From a technical perspective, the vulnerability arises because the frontend filter located in VideoContext.tsx operates exclusively on the client side, meaning it can be trivially bypassed by an attacker who interacts directly with the application programming interface rather than through the graphical user interface. On the server side, the roleBasedAuthMiddleware.ts file incorrectly permits all GET requests from visitors without validating their authorization level against the requested resource's visibility status. Furthermore, the storageService/videos.ts module executes database queries via getVideos and getVideoById functions that fail to check the caller's role or the record's visibility attribute before returning data. This architectural oversight means that any request targeting /api/videos or /api/videos/:id will return records regardless of whether they are marked as hidden with a visibility value of zero, exposing titles, source URLs, video paths, subtitle paths, and thumbnail paths to unauthenticated parties.
The operational impact of this vulnerability is severe, extending beyond mere metadata leakage to include the direct exfiltration of private media files. The serveMountVideo endpoint serves mounted video files without performing any visibility checks, allowing an attacker who has obtained a valid internal file path from the API responses to download the actual video content through unauthenticated routes such as /videos/ and /subtitles/. This effectively renders privacy settings useless for users relying on this feature to keep their media library private. While the RSS visitor feed correctly filters out visibility=1 content, other query paths remain exposed, creating a fragmented security posture where some interfaces are secure while others are completely open. It is important to note that default deployments with loginEnabled set to false are unaffected by this specific role-boundary issue because all callers are treated as owner-equivalent in single-user modes, but any deployment enabling visitor access remains vulnerable.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-200 Exposure of Sensitive Information to an Unauthorized Actor within the Common Weakness Enumeration framework. In terms of attack tactics, it corresponds to ATT&CK technique T1530 Data from Cloud Storage Objects, as attackers can enumerate and download objects that were intended to be private. To mitigate this issue, developers must enforce server-side authorization checks on all API endpoints that return sensitive data or serve files, ensuring that the visibility attribute is validated against the requester's role before any response is generated. The vulnerability was addressed in version 1.10.3 by correcting these middleware and service layer logic errors to ensure consistent enforcement of access policies across all entry points.