CVE-2026-111621

Executive Summary

CVE-2026-111621 is a missing authorization (CWE-639, Insecure Direct Object Reference / broken object-level authorization) vulnerability in TDuck Survey Form through version 5.3. Any authenticated user can retrieve another form owner's raw form settings — including the form write password, owner notification e-mail address, and associated WeChat openIds — by supplying the form key to the GET /user/form/setting/{key} endpoint. The disclosure has low direct confidentiality impact per CVSS (4.3) but enables follow-on account takeover and phishing because it leaks a write credential and identity data.

Technical Analysis

TDuck is a self-hosted survey/form building platform. According to the NVD description, the application exposes an endpoint at GET /user/form/setting/{key} that returns the raw form settings object for the form identified by {key}. The {key} is an 8-character identifier that is present in public fill links distributed to survey respondents — meaning the key is effectively public and not a secret.

The core defect is a missing authorization check: the endpoint validates that the caller is authenticated but does not verify that the authenticated user actually owns (or is otherwise authorized for) the requested form before returning its settings. In object-property terms, the access decision is made on the subject (is there a session?) but not on the object (does this user own this {key}?). This is the definition of CWE-639 — Authorization Bypass Through User-Controlled Key.

Because the endpoint returns the raw settings (not a sanitized public representation), the response includes sensitive fields that should never be exposed to non-owners:

• the form write password (a credential controlling write access to the form),
• the owner notification e-mail (used for submissions/alerts), and
• WeChat openIds (persistent platform identifiers tied to the owner's WeChat identity).

The 8-character form key is the user-controlled object identifier. It appears in every public fill link, so obtaining a valid key requires no authentication and no guessing — an attacker collects keys from shared links, embedded forms, or crawlable pages.

The CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N is consistent with this: network reachable, low complexity, requires only a low-privilege authenticated account, no user interaction, limited confidentiality impact only (no disclosed integrity or availability impact). Note that the low PR:L prerequisite is trivially satisfied on public registrations or any valid low-privileged account.

No public proof-of-concept, Nuclei template, or exploit code was available at the time of analysis. The patch confidence is 0/4 — no vendor fix has been identified in any tracked source. Technical detail beyond the description above (e.g., exact settings schema, token format, session handling) is not available and is intentionally not inferred.

Exploitation Scenarios

The attack chain is straightforward and derives directly from the missing object-level authorization on GET /user/form/setting/{key}.

1. Reconnaissance / target identification. The attacker enumerates TDuck deployments (internet-facing instances serving survey forms) and collects form keys from public fill links. Because the key is an 8-character identifier embedded in every respondent link, it is readily harvested from shared URLs, QR codes, embedded widgets, and search indexes. No authentication is needed for this step.

2. Triggering the flaw class. The attacker authenticates with any low-privileged account (e.g., a self-registered account or a compromised user) and sends GET /user/form/setting/{key} using a key that belongs to a different owner. The application returns the object because it checks only that a session exists, not that the session owns the object. This is the classic IDOR pattern: substitute a victim's object identifier into an authorized request.

3. Data retrieval. The raw settings response discloses the form write password, the owner's notification e-mail, and WeChat openIds. No payload crafting, special encoding, or privilege escalation is required — the request is a benign-looking GET.

4. Post-exploitation impact. The leaked write password can be used to modify or tamper with the form or its submissions (depending on how the write password is enforced by the application). The owner's e-mail and WeChat openIds enable targeted phishing, social engineering, and potential impersonation or account-recovery abuse against the owner or the respondents. Keys can be iterated across multiple forms to harvest credentials and identities at scale from the same deployment.

No public PoC is available; the above chain is inferred from the vulnerability class (IDOR / missing authorization) and the endpoint and fields named in the NVD description. Specific request/response bodies or parameter schemas beyond {key} are not documented and are not asserted here.

Impact Assessment

The direct impact per CVSS 3.1 is 4.3 (Medium): confidentiality is rated Low (C:L) because the exposed data is the form configuration and identifiers rather than bulk respondent data or full credential material; there is no integrity or availability impact recorded in the vector (I:N/A:N), no scope change (S:U), and no user interaction required (UI:N).

The practical business impact is higher than the base score suggests because the leaked form write password is a credential — its exposure can enable unauthorized modification of the form and its content, and the leaked owner e-mail and WeChat openIds are identity attributes usable for spear-phishing and impersonation. An affected organization's survey integrity and owner-account trust are both at risk. Blast radius spans any TDuck deployment (through 5.3) that serves public forms: any authenticated user on that instance can pivot across every other owner's settings whose key they can observe. Since keys are embedded in public links, effectively all forms on an affected instance are reachable. No privilege escalation to application administrator is described, so impact is bounded to per-form settings and owner identity data.

Detection Guidance

Sigma Rule

title: Potential IDOR Access to TDuck Form Settings via Non-Owned Form Key
id: 3f9b2c71-tduck-111621-idor
status: experimental
description: Detects authenticated requests to TDuck GET /user/form/setting/{key} that may indicate object-level authorization bypass (CVE-2026-111621)
logsource:
  category: webserver
detection:
  selection_endpoint:
    cs-method: 'GET'
  selection_path:
    cs-uri-stem|contains: '/user/form/setting/'
  selection_status:
    sc-status: 200
  condition: selection_endpoint and selection_path and selection_status
fields:
  - c-ip
  - cs-uri-stem
  - cs-uri-query
  - sc-status
falsepositives:
  - Legitimate owners retrieving their own form settings
  - Application health checks or admin tooling
level: low
tags:
  - attack.t1190
  - cve.2026.111621

YARA Rule

rule CVE_2026_111621_TDuck_Form_Setting_IDOR
{
    meta:
        description = "Detects HTTP requests targeting the TDuck form settings endpoint involved in CVE-2026-111621"
        author = "Threat Intel"
        reference = "CVE-2026-111621"
        date = "2026-01-01"
    strings:
        $ep = "/user/form/setting/" ascii nocase wide
        $hd = "GET " ascii
        $keylen = /\/user\/form\/setting\/[A-Za-z0-9]{8}[ \/]/ ascii
    condition:
        $ep and #keylen > 0
}

Suricata IDS Rule

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CVE-2026-111621 TDuck Form Setting IDOR Access Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/user/form/setting/"; pcre:"/\/user\/form\/setting\/[A-Za-z0-9]{8}(\/|\?|$)/"; reference:cve,2026-111621; classtype:attempted-recon; sid:2026111621; rev:1;)

Elastic Detection

sequence by user.name with maxspan=60s
  [ authentication where event.outcome == "success" ]
  [ network where http.request.method == "GET" and url.path : "/user/form/setting/*" ]

Splunk SPL Query

index=web sourcetype=access_combined
| eval method=cs_method, path=cs_uri_stem, status=sc_status
| where method="GET" AND like(path, "/user/form/setting/%") AND status=200
| rex field=path "/user/form/setting/(?<form_key>[A-Za-z0-9]{8})"
| stats count values(form_key) as form_keys by src_ip, user
| where mvcount(form_keys) > 3

Wazuh OSSEC Rule

<group name="web,td_uck,cve_2026_111621,">
  <rule id="2026116" level="5">
    <decoded_as>json</decoded_as>
    <field name="http.method">^GET$</field>
    <field name="http.path" type="pcre2">^/user/form/setting/[A-Za-z0-9]{8}</field>
    <description>CVE-2026-111621: TDuck form settings endpoint accessed (possible IDOR)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED, no patch evidence from any tracked source.

1. Immediate mitigations. Treat the GET /user/form/setting/{key} endpoint as sensitive: restrict it to form owners via a manual authorization check (verify the authenticated user owns the requested form key before returning settings), or disable/block the endpoint at the reverse proxy/WAF until a fix is available. Ensure the raw settings response never includes the write password, owner e-mail, or WeChat openIds for non-owners. Audit existing form configurations for exposed keys and, where possible, rotate compromised write passwords. Review web logs for repeated accesses from one account across multiple distinct form keys.
2. Patch/upgrade steps. No vendor patch is currently identified; monitor the TDuck project for an updated release addressing CVE-2026-111621 and apply it as soon as it is published. Validate the fix by confirming the settings endpoint enforces object-level ownership.
3. Long-term hardening. Adopt server-side ownership/ABAC checks on every object-keyed endpoint (not just authentication). Avoid embedding sensitive configuration (passwords, e-mail, openIds) in raw settings objects returned to clients — use a dedicated, redacted public representation for fill pages. Enforce least privilege by limiting self-registration where possible and enabling per-account rate limiting on form-setting requests to slow enumeration.

References

• NVD entry for CVE-2026-111621: https://nvd.nist.gov/vuln/detail/CVE-2026-111621
• CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
• CVSS v3.1 Specification: https://www.first.org/cvss/specification-document
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• TDuck project repository (monitor for advisory/patched release): https://github.com/td_uck

No public threat-actor campaign or exploit-in-the-wild evidence is currently available for this CVE. It is not listed in CISA KEV.