CVE-2026-111656 in ChatWiki
Summary
by MITRE • 10/16/2026
ChatWiki through 2.9.6 contains an insecure direct object reference vulnerability that allows authenticated users to access another tenant's form filters by supplying arbitrary form_id values. Attackers can send sequential form_id values to getFormFilterList, getFormFilterInfo and updateFormFilterSort to read filter rules and overwrite another tenant's filter sort order.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in ChatWiki versions through 2.9.6 represents a critical failure in access control mechanisms, specifically classified as an Insecure Direct Object Reference or IDOR under the CWE-639 standard. This flaw stems from the application server's reliance on client-supplied identifiers to retrieve and manipulate data without performing adequate authorization checks against the authenticated user's associated tenant context. The system assumes that if a user is logged in, they are permitted to interact with any resource identified by the provided form_id parameter. Consequently, there is no validation step ensuring that the requested form belongs to the same multi-tenant environment as the requesting user. This architectural oversight allows an attacker who has obtained valid credentials for one tenant account to traverse across organizational boundaries within the platform's data structure.
From a technical perspective, the exploitation vector involves manipulating specific API endpoints such as getFormFilterList, getFormFilterInfo, and updateFormFilterSort. These functions accept arbitrary form_id values passed by the client side. When an authenticated user submits these requests with identifiers belonging to other tenants, the backend processes them without verifying ownership or permissions. The read operations allow for the extraction of sensitive configuration data, specifically filter rules that define how forms are presented or processed within a tenant's workspace. These filters may contain logic related to business workflows, data validation criteria, or user-specific preferences that could reveal internal operational procedures or expose structural details about other organizations using the platform.
The write operations present an even more severe risk by enabling unauthorized modification of system state. By supplying arbitrary form_id values to updateFormFilterSort, an attacker can overwrite the sort order and configuration of filters belonging to another tenant. This action constitutes a denial of service against those tenants as their forms may become unusable or display incorrectly due to corrupted sorting logic. Furthermore, this capability facilitates data integrity violations where critical business rules are altered without authorization. The ability to sequentially probe form_id values suggests that the identifiers might be predictable or easily enumerated, allowing for automated scanning tools to rapidly map out resources across multiple tenants and maximize the scope of impact with minimal effort from the attacker.
In terms of operational impact, this vulnerability compromises confidentiality, integrity, and availability within a multi-tenant SaaS environment. The breach of confidentiality arises from the exposure of proprietary filter configurations which may contain intellectual property or sensitive business logic specific to other organizations. Integrity is compromised as attackers can disrupt workflows by altering sort orders and filter parameters, potentially leading to data processing errors or loss of productivity for affected tenants. Availability is impacted because corrupted filters can render forms inaccessible or functionally broken until administrators manually correct the settings. For platform operators, this represents a severe trust violation where isolation between customers fails, exposing them to legal liabilities and reputational damage due to cross-tenant data leakage and service disruption.
Mitigation strategies must focus on implementing robust authorization checks at every point of access control. Developers should enforce strict tenant context validation by ensuring that the authenticated user's session contains their specific tenant_id or organization_id, which is then compared against the ownership metadata associated with each form resource before any read or write operation proceeds. This check must occur server-side and cannot rely on client-supplied data for authorization decisions. Additionally, implementing randomization in identifier generation can reduce the efficiency of sequential enumeration attacks, although this should not be considered a primary defense since it does not address the underlying access control flaw. Input validation alone is insufficient; explicit permission verification linking the user identity to the resource ownership is required.
To align with industry frameworks such as MITRE ATT&CK, this vulnerability maps primarily to T1078 Valid Accounts and T1530 Data from Cloud Storage or Object Storage depending on how filters are stored, but more accurately reflects techniques associated with unauthorized access to cloud services through misconfigured permissions. Remediation efforts should also include comprehensive logging of all form filter access attempts to detect patterns indicative of enumeration attacks. Security testing procedures must be updated to explicitly test for cross-tenant data leakage by attempting to access resources belonging to different organizational units using valid credentials from a separate tenant. Regular code reviews focusing on object reference handling and multi-tenancy isolation are essential to prevent similar flaws in future releases, ensuring that the principle of least privilege is strictly enforced across all API endpoints managing shared infrastructure components.