Description

TDuck survey form through 6.0 contains an insecure direct object reference vulnerability that allows authenticated users to delete other users' form submissions by supplying arbitrary submission ids. Attackers can place their own formKey in the path and iterate sequential submission ids in the request body to permanently delete submissions platform-wide.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-10-12T13:17:28.460Z",
  "pubdate": "2026-10-12T13:17:28.460Z",
  "executiveSummary": "TDuck survey form through version 6.0 is vulnerable to an Insecure Direct Object Reference (IDOR) flaw within its submission management functionality.\nThis vulnerability stems from a lack of proper authorization checks on the server side when processing delete requests for form submissions.\nAn authenticated attacker can manipulate submission identifiers within API requests to perform unauthorized deletions of arbitrary data across the entire platform.\nThe risk is critical, as it allows for large-scale data destruction, potentially leading to significant integrity loss and service disruption.\nExploitation requires an active user session, but no administrative privileges are necessary to execute the attack.\nBy iterating through predictable or sequential submission IDs, a malicious actor can systematically purge records that they do not own or have permission to access.",
  "technicalDetails": "The vulnerability resides in the backend logic responsible for processing form submission deletion requests within TDuck survey form version 6.0 and earlier.\nThe root cause is a failure to enforce authorization controls; the application verifies that the user is authenticated but neglects to validate whether the authenticated user maintains ownership or access rights to the specific object requested for deletion.\nThe application architecture uses a predictable request structure where the target resource is identified by a submission ID parameter in the request body, while the form context is defined by a formKey provided in the URI path.\nThe attack flow begins with the adversary initiating a legitimate session by authenticating to the platform, thereby obtaining a valid session token. Once authenticated, the attacker constructs a crafted HTTP request targeting the deletion endpoint.\nIn this request, the attacker specifies an arbitrary submission ID that corresponds to a target they wish to delete. Because the backend does not verify if the current user session is associated with that specific submission ID, the server proceeds to execute the database operation to permanently remove the record.\nSince the submission IDs are sequential, the exploit can be trivially automated using basic scripting techniques. An attacker can iterate through a range of submission IDs by sending a sequence of HTTP requests. The payload behavior involves the server processing each request as a legitimate command, resulting in the sequential destruction of submissions platform-wide.\nThis IDOR flaw exposes the platform to a mass-deletion attack, where the impact is limited only by the attacker's ability to enumerate the submission IDs. Post-exploitation, the organization faces significant data integrity issues and potential denial-of-service conditions if essential survey data is removed. There is no indication of complex bypass requirements; the vulnerability is exposed directly via standard application interfaces accessible to any authenticated user."
}