CVE-2026-121940 in ai-fusion-video
Summary
by MITRE • 11/04/2026
Stonewuu ai-fusion-video before 1.3.0 contains an insecure direct object reference vulnerability that allows authenticated users to access other users' projects by supplying unscoped object ids. Attackers can enumerate auto-increment ids on /api/project, /api/asset and /api/script handlers to read, overwrite, cascade-delete data, and add themselves as project members.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in Stonewuu ai-fusion-video versions prior to 1.3.0 represents a critical failure in access control mechanisms, specifically categorized under the Common Weakness Enumeration (CWE) standard as CWE-639: Insecure Direct Object Reference. This type of flaw occurs when an application exposes internal implementation objects, such as database keys or file names, directly to users without performing adequate authorization checks. In this specific instance, the vulnerability manifests within the API endpoints responsible for managing projects, assets, and scripts. The core technical deficiency lies in the server-side logic which relies on unscoped object identifiers provided by the client side of the application. When an authenticated user requests data or performs actions via these handlers, the system retrieves resources based solely on the identifier supplied in the request payload, without verifying whether that specific resource belongs to the requesting user's account or organization context.
From a technical perspective, this flaw allows for straightforward exploitation through ID enumeration. Since many web applications utilize auto-incrementing integer identifiers for database records, an attacker can systematically iterate through sequential numeric values within the API requests targeting /api/project, /api/asset, and /api/script endpoints. By incrementally changing these identifier parameters in HTTP GET or POST requests, the attacker can probe the system to discover valid resource IDs belonging to other users. This process is automated easily using standard scripting tools or custom scripts that send rapid-fire requests with varying ID values until a response indicating successful access is received. The lack of server-side validation means that once a valid ID for another user's data is identified, the application treats it as legitimate input from the authenticated session making the request.
The operational impact of this vulnerability is severe due to the breadth of actions permitted by these API handlers. Beyond simple unauthorized reading of sensitive project details or asset files, which constitutes a significant confidentiality breach, the flaw allows for more destructive activities. Attackers can overwrite existing data belonging to other users, leading to integrity violations where critical information may be corrupted or replaced with malicious content. Furthermore, the ability to cascade-delete data means that an attacker can permanently erase projects and associated assets from other users' accounts, resulting in a denial of service condition for those victims and potential loss of valuable intellectual property or work products. Additionally, the capability to add oneself as a project member expands the attack surface significantly; once inside another user's project scope, the attacker may gain access to further privileged operations that are normally restricted to authorized members only, effectively escalating their privileges within the application context.
This vulnerability aligns with several techniques described in the MITRE ATT&CK framework for enterprise security. The enumeration of object identifiers corresponds to Discovery tactics, specifically resource development or account manipulation phases where attackers gather information about other entities within a system. The subsequent unauthorized access and modification fall under Lateral Movement and Impact categories, as the attacker moves between different user contexts without proper authentication boundaries. In terms of industry standards for prevention, this scenario highlights the necessity of implementing robust object-level authorization checks. Developers must ensure that every API request includes not only an identifier but also a context check against the authenticated user's permissions or ownership records in the backend database. Implementing indirect reference maps, where internal IDs are replaced with opaque, randomly generated tokens that do not reveal sequence information, can further mitigate enumeration risks by making it computationally expensive for attackers to guess valid identifiers.
To remediate this issue effectively, immediate updates to version 1.3.0 or later are required as the vendor has addressed these access control flaws in subsequent releases. For organizations unable to patch immediately due to operational constraints, compensating controls should be implemented at the network perimeter using Web Application Firewalls (WAF) configured to detect and block sequential ID enumeration patterns in API requests. Additionally, application-level logging and monitoring should be enhanced to alert security operations centers on anomalous access patterns, such as a single authenticated user rapidly accessing multiple distinct resource IDs that do not belong to their account. Ensuring that all backend services enforce strict ownership verification before processing any data manipulation or retrieval request is the definitive solution to prevent insecure direct object reference vulnerabilities from being exploited in production environments.