CVE-2026-109164 is a high severity insecure direct object reference (CVSS 7.1) in TDuck survey form through version 6.0. Authenticated users can delete other users' form submissions by supplying other submission ids. The record lists no fixed version, so check the project and restrict access in the meantime.
What's affected
The record says TDuck survey form through 6.0 is affected. VulnCheck's advisory, which we fetched, says tduck-survey-form 6.0 and earlier. Neither source names a fixed version. The advisory page links to the vulnerable code in the project repository, so the maintainers' response is the place to check for a patched release.
The weakness is CWE-639, authorization bypass through a user controlled key. The vector is network reachable, low complexity, low privileges and no user interaction, with low integrity impact and high availability impact. VulnCheck rates its own CVSS 4.0 vector at 7.1 as well, and its severity label as high.
The record describes the effect as permanent deletion of submissions across the whole platform. That is a loss of data and not a theft of it, and the vector reflects that with no confidentiality impact. For a survey platform, the submissions are the product, so deletion is a real harm.
The record says an attacker must be authenticated. Whether that is a hurdle depends on whether your deployment allows open registration.
How to check if you're exposed
First identify whether you run TDuck survey form and which version. Look at the version in the project files or the deployment notes, and compare it with 6.0.
Next, determine who can obtain an account. If registration is open to the public, anyone can become an authenticated user and the flaw is within reach of the internet. If accounts are created by administrators only, your exposure is narrower.
Check your backups. Because the impact is deletion, the key question is whether you can restore submissions. Test a restore of the database that holds form data and note how recent the last good backup is.
Look at access logs for the delete endpoint described in the VulnCheck advisory, and look for one account issuing many delete calls in sequence, which is the pattern the record describes.
What to do now
- Check the TDuck project repository and release notes for a version newer than 6.0 that fixes the issue, and upgrade when one exists.
- Disable open registration if you do not need it, so only trusted users hold accounts.
- Take a fresh database backup now and test a restore.
- Put the application behind a web application firewall or proxy rule that limits the rate of delete calls per account.
- If you maintain a fork, add a server side check that the submission being deleted belongs to the form that the caller owns.
Why it matters
An insecure direct object reference happens when the server accepts an identifier from the user and acts on it without checking that the user owns the object. Here the record says an attacker can place their own form key in the path, which passes the ownership check for the form, and then supply other users' submission ids in the body. The server deletes them, because it never asks whether those submissions belong to that form.
The ids are sequential, so they can be counted through. This is the textbook case for why authorization has to be tied to the object and not to the route: checking that you own the form is not the same as checking that the thing you are changing belongs to it.
The fix is small: load the submission, confirm its form key matches the one the caller owns, and only then delete. Until a fix exists for this product, the options are operational. The record does not mark this CVE as known exploited.
Quick check
Is there a patched version?
Neither the record nor the VulnCheck advisory names one. Check the project repository.
What does an attacker gain?
The record describes permanent deletion of other users' submissions, not data theft.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.
