CVE-2026-90551 in AVideo
Summary
by MITRE • 09/12/2026
WWBN AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 fails to validate playlist ownership in the video_from_program API endpoint, allowing unauthenticated access to private playlist contents. Attackers can query the API without authentication to enumerate private playlist names, owner information, and video titles including password-protected content.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified in WWBN AVideo stems from a critical failure in access control logic within the video_from_program API endpoint. This flaw allows unauthenticated actors to bypass intended security restrictions by exploiting the lack of proper ownership validation for playlist resources. In typical web application architectures, private playlists are designed to be accessible only to their designated owners or authorized users who possess valid authentication credentials and appropriate permissions. However, in this specific implementation, the server-side processing of requests directed at the video_from_program endpoint does not adequately verify whether the requesting entity has legitimate ownership rights over the targeted playlist. This oversight creates a direct path for unauthorized data retrieval, effectively rendering privacy controls ineffective against remote attackers who do not possess valid session tokens or API keys.
From a technical perspective, this issue represents a classic Broken Access Control vulnerability where the application fails to enforce proper authorization policies on sensitive resources. The attacker can construct HTTP requests targeting specific playlist identifiers without providing any form of authentication. Because the backend logic does cross-reference these identifiers with user ownership records before returning data, it proceeds to serialize and transmit the requested information regardless of the requester's identity status. This behavior exposes not only public metadata but also content that is explicitly marked as private or password-protected within the application interface. The ability to enumerate playlist names and associated owner details further compounds the risk by facilitating reconnaissance activities, allowing attackers to map out user structures and identify potential targets for more sophisticated attacks such as credential stuffing or targeted phishing campaigns based on revealed personal information.
The operational impact of this vulnerability is significant, particularly regarding data privacy and confidentiality guarantees provided by the platform. Users who rely on AVideo to host private content expect that their videos remain inaccessible to unauthorized parties. The exposure of password-protected video titles and metadata undermines these expectations and may lead to legal or compliance issues if sensitive organizational information is inadvertently shared through this channel. Furthermore, the ability to list playlist contents without authentication enables automated scraping tools to harvest large volumes of data efficiently. This can be leveraged for intellectual property theft, content piracy, or building databases of user-generated material that could later be used in social engineering attacks. The exposure of owner information also increases the risk of targeted harassment or doxxing against individual users who may not have anticipated their identity being linked to specific private media collections.
To mitigate this vulnerability, developers must implement strict access control checks at the API level for all endpoints handling sensitive resources like playlists and videos. Specifically, the video_from_program endpoint should validate that the authenticated user associated with the request is the rightful owner of the requested playlist before processing any data retrieval operations. If unauthenticated requests are intended to be supported for public content only, the system must explicitly distinguish between private and public assets during the validation phase, denying access to anything marked as restricted unless valid credentials are presented. Additionally, implementing rate limiting on API endpoints can help mitigate automated enumeration attempts by detecting and blocking excessive request patterns from single source IP addresses. Regular security audits focusing on authorization logic across all API versions will ensure that similar gaps do not exist elsewhere in the application codebase.
This vulnerability aligns with CWE-284 Improper Access Control, which describes situations where an actor is granted privileges or information they should not have access to under normal circumstances. It also maps closely to MITRE ATT&CK technique T1078 Valid Accounts when considering how attackers might leverage discovered owner identities for subsequent authentication-based attacks, although the initial exploitation here does not require valid accounts due to the lack of enforcement on private resources. Addressing this issue requires a fundamental review of how identity and ownership are validated during API request processing, ensuring that privacy settings defined in the user interface are strictly enforced at the backend logic level without exception for unauthenticated traffic unless explicitly permitted by security policy.