CVE-2026-107856 in CiviForm
Summary
by MITRE • 10/10/2026
CiviForm simplifies applications for government benefits programs by reusing applicant data across multiple benefit applications. Prior to 3.33.0, GET /admin/tiDash/editClientForm/:accountId verifies that the requester is a Trusted Intermediary but showEditClientForm performs a raw lookupAccount(accountId) without confirming that the citizen account belongs to the requester's trustedIntermediaryGroup. An authenticated Trusted Intermediary can enumerate accountId values and read the applicant display name, including the citizen's name and email address, for accounts outside the intermediary's group. This issue is fixed in version 3.33.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The vulnerability identified in CiviForm versions prior to 3.33.0 represents a critical failure in access control logic within the application administration interface. CiviForm serves as a platform for government entities to manage benefit programs, often relying on Trusted Intermediaries who assist citizens with applications while maintaining specific group-based boundaries around which applicants they are authorized to view or edit. The core technical flaw resides in an inconsistency between two distinct API endpoints used during the client form editing workflow. Specifically, the endpoint GET /admin/tiDash/editClientForm/:accountId correctly implements a security check that verifies whether the authenticated requester holds the role of a Trusted Intermediary. However, the subsequent function showEditClientForm executes a raw database lookup for the account using the provided accountId without validating that this specific citizen account is associated with the trustedIntermediaryGroup to which the requesting intermediary belongs. This architectural oversight creates a direct path for unauthorized data access because the system trusts the role of the user but fails to enforce granular ownership constraints on the resource being accessed.
From an operational perspective, this flaw allows any authenticated Trusted Intermediary to perform account enumeration and exfiltrate personally identifiable information belonging to citizens outside their authorized scope. By iterating through sequential or predictable accountId values, a malicious actor can retrieve display names, including full legal names and email addresses of applicants who have no relationship with the intermediary’s organization. This constitutes a significant breach of data privacy principles and regulatory compliance requirements such as GDPR or HIPAA, depending on the jurisdiction and type of benefits managed. The ability to harvest this sensitive personal information facilitates further social engineering attacks, identity theft, or targeted phishing campaigns against vulnerable populations seeking government assistance. The impact is compounded by the fact that Trusted Intermediaries are inherently trusted entities within the system, meaning their credentials provide legitimate access to parts of the application ecosystem, making detection of such lateral movement more difficult for security monitoring tools.
This vulnerability aligns with CWE-284 Improper Access Control and specifically reflects CWE-639 Authorization Bypass Through User-Controlled Key, as the attacker leverages a user-controlled parameter (accountId) to access resources they are not authorized to view. In terms of offensive cybersecurity frameworks, this behavior maps directly to ATT&CK technique T1078 Valid Accounts, where an adversary uses legitimate credentials to gain initial access and then exploits misconfigured permissions to move laterally or escalate privileges within the application layer. The root cause is a classic case of insufficient server-side validation, where business logic assumes that role-based authentication implies resource-level authorization without explicit checks for ownership or group membership.
To mitigate this vulnerability, organizations must upgrade CiviForm to version 3.33.0 or later, which addresses the missing authorization check in the showEditClientForm function. Until an update can be applied, administrators should implement strict input validation and access control middleware that explicitly verifies the relationship between the authenticated user’s trustedIntermediaryGroup and the target citizen account before rendering any sensitive data. Additionally, implementing rate limiting on enumeration-prone endpoints like GET /admin/tiDash/editClientForm/:accountId can help detect and block automated scanning attempts. Security teams should also audit other API endpoints for similar patterns where role-based checks are present but resource-specific ownership validations are absent to prevent analogous bypasses in other parts of the application.