Description

ChatWiki before 2.10.0 contains an insecure direct object reference vulnerability in SaveFormField and UpdateFormRequired that allows authenticated users to modify other tenants' form fields. Attackers can pass their own form_id to satisfy the ownership check alongside another tenant's sequential form_field id to alter field names, descriptions, types and required flags, disrupting how submitted entries are stored.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-11-06T15:17:20.910Z",
  "pubdate": "2026-11-06T15:17:20.910Z",
  "executiveSummary": "ChatWiki versions prior to 2.10.0 are susceptible to an Insecure Direct Object Reference (IDOR) vulnerability within the SaveFormField and UpdateFormRequired functions.\nThis vulnerability allows authenticated users to perform unauthorized modifications to form fields belonging to other tenants by manipulating input parameters.\nThe flaw stems from improper access control validation where the system relies on a user-supplied form_id to authorize requests, while a separate, predictable sequential form_field identifier is used to determine the target object for modification.\nSuccessful exploitation enables malicious actors to alter critical form metadata, including field names, descriptions, data types, and mandatory requirement flags.\nThe risk to confidentiality, integrity, and availability is high, as an attacker can disrupt data collection processes, inject malicious schema definitions, or corrupt the structure of submitted entries across tenant boundaries.\nExploitation requires authenticated access to the application, but does not necessitate elevated administrative privileges, making it a significant concern for multi-tenant deployments.",
  "technicalDetails": "The vulnerability originates from a failure to enforce authorization boundaries during the processing of form configuration updates in the SaveFormField and UpdateFormRequired functions.\nIn the affected ChatWiki architecture, form field identification utilizes a sequential integer-based key (form_field id) that is prone to enumeration. While the application implements an ownership check, the logic is flawed: it verifies the user's authority against a user-provided form_id parameter, rather than verifying the relationship between the authenticated user and the specific form_field id requested for modification.\nAn attacker can bypass this security check by supplying their own legitimate form_id (which they own) in the request parameters to satisfy the application's authorization logic, while simultaneously providing an arbitrary, target-tenant form_field id in the specific object identifier field.\nThe backend logic fails to reconcile the ownership of the provided form_field id with the authenticated user session, instead trusting the provided inputs to perform a database update operation.\nThe attack flow follows these steps: 1) The attacker authenticates as a legitimate user within the platform. 2) The attacker identifies a target form_field id belonging to a separate tenant, potentially through predictable sequence discovery. 3) The attacker crafts a malicious POST request to the SaveFormField or UpdateFormRequired endpoints. 4) The attacker populates the request with their own valid form_id and the victim's target form_field id. 5) The server processes the request, erroneously validating the user based on the attacker's form_id, and subsequently updates the target tenant's form configuration.\nThe post-exploitation impact is severe, as the attacker can manipulate the schema of existing forms. By changing the 'required' flags, an attacker can cause data loss or service disruption for the target tenant's forms. Modifying field types can facilitate data corruption, as backend systems may not handle unexpected input types gracefully when entries are stored. This cross-tenant integrity violation undermines the isolation guarantees of the multi-tenant environment."
}