CiviForm EUVD-2026-95984

Attacker must already hold an authenticated, admin-provisioned Trusted Intermediary account within a CiviForm instance running a version prior to 3.33.0; with that role they call GET /admin/tiDash/editClientForm/:accountId and vary the accountId path parameter. Exploitation is LIMITED by: (1) the requirement for a legitimate Trusted Intermediary role (not a basic applicant or anonymous user), (2) the narrow data disclosed - only applicant display name and email address, not full benefit-application contents, and (3) applicability only to versions before the 3.33.0 fix. No victim interaction is actually required for the enumeration despite the input vector's UI:R metric.

This is a genuine but moderate-severity authorization flaw (CWE-639, insecure direct object reference). The provided CVSS base score of 4.5 (Medium) reflects that exploitation requires an already-provisioned, authenticated Trusted Intermediary account (PR:H in the input vector) and that impact is limited to confidentiality of applicant display data (C:H/I:N/A:N). No EPSS score, KEV listing, or public exploit code is present in the supplied intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation; this is not a drop-everything priority. Several input signals are internally inconsistent and should be verified: the vector asserts UI:R (user interaction required), yet the described attack is pure server-side enumeration of accountId values via GET requests and realistically needs no victim interaction (UI:N is more defensible); and C:H seems high given that only a display name and email are exposed rather than full application records (C:L is arguably more accurate). The real-world risk is best characterized as a privacy/PII-exposure issue exploitable only by insiders with the Trusted Intermediary role, not by anonymous internet attackers.

A Trusted Intermediary who has been provisioned in a CiviForm deployment iterates numeric accountId values against GET /admin/tiDash/editClientForm/:accountId; because showEditClientForm calls lookupAccount(accountId) without confirming the account belongs to the intermediary's trustedIntermediaryGroup, the server returns the citizen's name and email for accounts outside the attacker's group. No public exploit code is identified at time of analysis, and the fix commit/PR demonstrate the missing authorization check rather than a weaponized exploit. The attack is low-complexity and network-reachable but gated behind holding a legitimate Trusted Intermediary account.