Secure Data Forms CVE-2026-102109

Requires (1) an authenticated Kiteworks Secure Data Forms session with at least low-privilege access, and (2) a deployment where a specific optional feature (unnamed in the advisory) is in use - installs without that feature are not exploitable. Exploitation is further shaped by its second-order nature: the attacker must place the payload into a value derived from their stored account data, which is only later concatenated into a database query, so the injection triggers through the feature's normal query-building path rather than a direct crafted request. Affected versions are Secure Data Forms below 9.5.1; the fix is available from the vendor. Limiting factors: authentication requirement (PR:L), non-default optional-feature dependency, and no availability impact (A:N).

This is a genuine but moderate-priority issue best characterized as a mid-severity, condition-gated flaw rather than a high-urgency one. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, base 7.1) indicates network reachability with low attacker privileges and no user interaction, which I concur with. However, two factors materially reduce real-world risk: it requires an authenticated session (PR:L), and it only applies to deployments where a specific optional feature is enabled - so the vulnerable population is a subset of Kiteworks Secure Data Forms installs. It is also a second-order/stored SQLi: the injected value derives from the authenticated user's stored account data rather than a direct request parameter, adding a step versus classic inline injection. No EPSS score, KEV listing, or public POC was provided in the input; there is no public exploit identified at time of analysis and no evidence of active exploitation. The C:H/I:L/A:N impact suggests strong database read exposure with limited write and no availability effect, consistent with data exfiltration via SQLi rather than full DB takeover. Net: a real issue worth patching on a normal cycle, not a drop-everything emergency, absent exploitation signals.

An attacker with a valid low-privilege Kiteworks account on an instance where the relevant optional Secure Data Forms feature is enabled manipulates a value stored in their own account profile so that it contains SQL syntax. When the application later incorporates that stored value into a database query without sanitization, the injected SQL executes, allowing the attacker to read data they should not have access to (C:H). No user interaction or elevated privileges are required beyond the authenticated session. No public exploit code was identified at time of analysis.