CVE-2026-109165 in TDuck Survey Form
Summary
by MITRE • 10/12/2026
TDuck survey form through 6.0 contains a broken access control vulnerability that allows authenticated users to add fields to other users' forms via POST /user/form/item/batch/create. Attackers can submit an array whose first element references their own form and later elements reference a victim's formKey, injecting attacker-chosen fields onto the victim's public fill page.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in TDuck survey software versions up to 6.0 represents a critical failure in server-side access control mechanisms, specifically within the endpoint responsible for batch creation of form items. This flaw allows authenticated users to manipulate data belonging to other users by exploiting insufficient validation on the input parameters passed during POST requests to /user/form/item/batch/create. In a properly secured system, an API endpoint handling resource modification must strictly verify that the requesting user possesses authorization over every target resource identified in the request payload. However, TDuck fails to enforce this boundary check effectively when processing arrays of form identifiers. The application logic accepts an array where the first element may belong to the authenticated attacker, but subsequent elements can reference a victim's unique formKey without verifying ownership or permission rights for those specific targets. This architectural oversight enables an attacker to inject arbitrary fields into another user’s public-facing survey interface simply by including that target’s identifier in the batch request alongside their own valid identifiers.
From a technical perspective, this issue is classified under CWE-284 Improper Access Control and aligns with MITRE ATT&CK technique T1078 Valid Accounts, as it requires initial authentication but leverages flawed authorization logic rather than credential theft. The operational impact of this vulnerability extends beyond simple data modification; by injecting fields into a victim’s public fill page, an attacker can alter the structure and content of surveys that are intended for external respondents. This could lead to the collection of sensitive information from unsuspecting users if the injected fields request personal or confidential data. Furthermore, it compromises the integrity of the survey platform, potentially causing confusion among end-users who encounter unexpected form elements during completion. In enterprise environments where TDuck is used for internal feedback or customer research, such manipulation can damage organizational credibility and lead to inaccurate data aggregation due to corrupted input structures.
The severity of this flaw lies in its potential for widespread abuse with minimal effort from the attacker. Since it relies on standard HTTP POST requests that are already part of the application’s normal workflow, detection by basic intrusion prevention systems may be difficult without deep packet inspection or behavioral analysis focused on authorization failures. An authenticated user can systematically iterate through known form keys to inject malicious fields into multiple victims’ forms, effectively turning a single account compromise into a multi-user data integrity attack vector. This type of vulnerability highlights the importance of implementing robust object-level access controls where every resource modification operation must explicitly check the relationship between the actor and the target entity before proceeding with database updates or UI rendering logic changes.
To mitigate this risk, immediate remediation should focus on enforcing strict ownership verification at the application layer for all batch operations involving user-specific resources. Developers must ensure that when processing an array of form identifiers in a create request, each identifier is validated against the authenticated user’s permissions list before any database insertion occurs. Implementing atomic transactions where either all items are added to authorized forms or none are added can prevent partial state corruption during failed authorization checks. Additionally, adopting principle of least privilege for API endpoints and logging detailed audit trails of form modifications will aid in detecting anomalous patterns indicative of exploitation attempts. Long-term solutions should include integrating automated security testing into the CI/CD pipeline to catch such access control regressions early in development cycles, ensuring that future updates maintain rigorous validation standards across all user-facing functionalities.