CVE-2026-90536 in AVideo
Summary
by MITRE • 09/12/2026
WWBN AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 fails to authorize access to the adsInfo API endpoint, allowing unauthenticated attackers to retrieve password-protected video owner identifiers. Attackers can call the adsInfo API with a videos_id parameter to obtain the owner's user ID and personalized ad creative URLs without authentication or permission checks.
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 represents a critical failure in access control mechanisms within the application's advertising information subsystem. Specifically, commit c3edcc274c389816d434acadac07ee78eaf330c1 introduced or failed to remediate an issue where the adsInfo API endpoint lacks proper authorization checks. This architectural flaw allows unauthenticated actors to interact with sensitive backend logic that is intended to be restricted to authorized users, such as video owners or administrators who manage ad placements and revenue streams. The absence of authentication requirements for this specific endpoint creates a direct pathway for data exfiltration without the need for valid credentials or session tokens.
From a technical perspective, the core flaw lies in the misconfiguration of role-based access control (RBAC) or function-level security checks within the API handler. When an attacker submits a request to the adsInfo endpoint with a specific videos_id parameter, the server processes this input and returns detailed metadata associated with that video's advertising configuration. This includes the owner's unique user identifier and personalized ad creative URLs. These data points are typically considered sensitive because they link public content identifiers to private account information and financial infrastructure details. The system fails to verify whether the requesting entity has permission to view these specific attributes, treating all requests as valid regardless of their source or context.
The operational impact of this vulnerability is significant for both individual creators and platform administrators. By retrieving password-protected video owner identifiers, attackers can perform user enumeration attacks, mapping out the structure of the user base even when content is restricted by passwords. This information facilitates targeted phishing campaigns where adversaries use known user IDs to craft convincing social engineering messages. Furthermore, access to personalized ad creative URLs may allow attackers to analyze monetization strategies or potentially inject malicious redirects if those URLs are manipulated in downstream contexts. The exposure of internal identifiers also aids in further reconnaissance efforts, allowing threat actors to correlate public video data with private account details for more sophisticated attacks such as credential stuffing or targeted brute-force attempts against specific high-value accounts.
This vulnerability aligns closely with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials if the API relies on static keys, though it primarily exemplifies a lack of authorization enforcement. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts for initial access facilitation through enumeration and T1592 Gather Victim Host Information by collecting user identifiers that can be used in subsequent phases of an attack chain. The ability to retrieve owner IDs without authentication effectively bypasses the intended security boundary between public-facing content and private account management features.
Mitigation strategies must focus on implementing strict authorization checks at the API level before any data retrieval occurs. Developers should ensure that every endpoint requiring sensitive information verifies the user's role and permissions against a secure session or token validation mechanism. It is essential to apply the principle of least privilege, ensuring that only authenticated users with explicit rights to manage ad settings can access the adsInfo functionality. Additionally, implementing rate limiting on API endpoints can help mitigate automated enumeration attempts by unauthenticated actors. Regular security audits and static code analysis should be employed to detect similar misconfigurations in other parts of the application where sensitive data is exposed through public-facing interfaces.