CVE-2026-111722 in LingGuo-Drama
Summary
by MITRE • 10/16/2026
LingGuo-Drama through commit 8a6924a contains an insecure direct object reference vulnerability that allows registered users to access other users' projects because projects.Get lacks an owner check. Self-registered attackers can iterate numeric IDs via GET, PUT and DELETE /admin/v1/projects/:id to read, overwrite, reassign or delete any user's short-drama projects.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in the LingGuo-Drama application represents a classic insecure direct object reference (IDOR) flaw, formally categorized under CWE-639 within the Common Weakness Enumeration framework. This security defect arises from a fundamental failure in access control logic, specifically within the project management module of the web application. The core technical issue lies in the projects.Get endpoint, which processes requests based on numeric identifiers provided by the client without verifying whether the authenticated user initiating the request is the legitimate owner or an authorized administrator of that specific resource. In secure software design, every access to a sensitive object must be validated against the permissions associated with the current session context; however, this implementation relies solely on the predictability and sequential nature of database primary keys, allowing any valid credential holder to manipulate data belonging to others simply by altering the identifier parameter in their HTTP requests.
From an operational perspective, this vulnerability grants registered users significant unauthorized capabilities over other users' content. By iterating through numeric IDs via GET, PUT, and DELETE methods on the /admin/v1/projects/:id endpoint, attackers can perform a comprehensive range of malicious actions against short-drama projects hosted by victims. A GET request allows for the exfiltration of private project data, potentially exposing sensitive creative assets or proprietary information. The availability of PUT requests enables an attacker to overwrite existing project details, leading to integrity violations where legitimate content is replaced with unauthorized modifications. Furthermore, DELETE capabilities allow for the permanent destruction of other users' work, resulting in denial of service conditions and significant operational disruption for affected creators. This level of access effectively bypasses all intended isolation boundaries between user accounts, turning a standard authentication mechanism into a vector for widespread data compromise.
The exploitation path is straightforward and aligns with common attack patterns observed in web application security assessments. Attackers typically employ automated scripts to cycle through sequential ID ranges, testing each endpoint response to identify valid targets that return success codes rather than authorization errors. This activity can be detected as anomalous traffic if monitoring systems are configured to flag rapid succession of requests targeting different resource identifiers from a single source. The impact extends beyond immediate data loss or corruption; it undermines the trust model of the application, potentially leading to reputational damage and legal liabilities for the service provider due to failure in protecting user-generated content and personal information associated with those projects.
To mitigate this vulnerability, developers must implement robust object-level access control checks within the backend logic handling these API endpoints. Specifically, every request targeting a project resource should include a verification step that compares the authenticated user's identity against the ownership field of the requested record in the database. If there is no match and the user does not possess elevated administrative privileges explicitly defined for cross-user management tasks, the server must reject the request with an appropriate HTTP 403 Forbidden status code. Additionally, implementing rate limiting on these endpoints can help mitigate automated enumeration attacks by restricting the number of requests a single IP address or session can make within a given timeframe. Regular security audits and static application security testing (SAST) should be integrated into the development lifecycle to detect such logic flaws before deployment, ensuring that all API interactions adhere strictly to the principle of least privilege as outlined in industry standards like OWASP Top Ten guidelines for broken access control.