TDuck Survey Form EUVD-2026-80860

Requires an authenticated account on the TDuck survey-form application (PR:L) but NO ownership of the target form: the WebhookConfigController performs neither a form-ownership check nor webhook-URL validation, so any authenticated user can attach a webhook to another user's form. Exploitation is remote over the network against default behavior of the webhook feature (no non-default configuration needed), and no user interaction by the victim beyond normal form submissions is required. The main limiting factors are the need for a valid low-privilege login and that impact is scoped to data flowing through webhooks (form submissions) plus SSRF reachability of internal targets from the server.

This is a genuine but moderate-priority issue best understood as a dual flaw: a broken-access-control / IDOR problem (WebhookConfigController does not verify form ownership) chained with an SSRF (webhook URLs are never validated). The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N, base 7.1) is internally consistent with the description and points to confidentiality as the dominant impact - exfiltration of other users' form submissions - with a secondary SSRF reach into internal addresses. Exploitation requires only a low-privilege authenticated account (PR:L), which is realistic for a self-service survey/form SaaS-style product where any registered user can create forms. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so despite the network vector and low complexity this reads as a real-but-not-urgent issue rather than a mass-exploited one. Confidence is limited by the absence of EPSS/KEV/POC signals; the source code line references (WebhookConfigController.java#L43-47, WebhookSenderService.java#L84-100) corroborate the technical root cause but there is no vendor patch version cited.

An attacker registers or already holds a low-privilege account on a TDuck instance, then calls the webhook configuration endpoint referencing a form ID they do not own (no ownership check) and points the webhook at an attacker-controlled external server. Subsequent submissions to the victim's form are delivered to the attacker, silently exfiltrating respondent data; alternatively the URL is aimed at an internal/cloud-metadata address to perform SSRF. No public exploit code was identified at time of analysis.