CVE-2026-112004 in Teable
Summary
by MITRE • 10/18/2026
Teable before 2026-10-12T12-45-53Z.3331 contains an authorization bypass vulnerability that allows authenticated users to rename folders in other bases by supplying a foreign folderId. The PATCH /api/base/:baseId/node/folder/:folderId endpoint checks base|update only against the URL baseId, so attackers can rename folders in bases where they lack membership.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in Teable versions prior to October 12, 2026, represents a critical failure in server-side access control mechanisms, specifically manifesting as an authorization bypass within the application's folder management subsystem. This flaw allows authenticated users to perform state-changing operations on resources that they do not own or have permission to modify. The core of the issue lies in how the backend validates user permissions against the requested resource identifiers during API requests. In a secure implementation, access control checks must verify that the requesting user has explicit privileges for both the container (the base) and the specific child entity (the folder). However, Teable's implementation relies exclusively on the base identifier provided within the URL path to determine authorization scope, neglecting to validate whether the target folder actually belongs to that specified base or if the user holds sufficient rights over it.
Technically, this flaw is located in the PATCH /api/base/:baseId/node/folder/:folderId endpoint. When a client sends a request to rename a folder, the server extracts the baseId from the URL parameters and checks if the authenticated session has update permissions for that specific base ID. The critical omission occurs because the system fails to cross-reference this permission check with the actual ownership or membership status of the target folder identified by the folderId parameter supplied in the request body or path. By manipulating these parameters, an attacker can supply a foreign folderId belonging to a different base where they are not a member. Since the server only validates access against the provided baseId and does not verify that the folderId corresponds to a resource within that base or under the user's jurisdiction, the operation is erroneously permitted. This constitutes a classic case of Insecure Direct Object Reference (IDOR), categorized under CWE-639 in the Common Weakness Enumeration standard.
The operational impact of this vulnerability extends beyond simple unauthorized renaming. An attacker with valid authentication credentials can disrupt the organizational structure of other users' workspaces by altering folder names, potentially causing confusion or data misinterpretation for legitimate members. Furthermore, such manipulation could be leveraged as a stepping stone in more complex attack chains, such as social engineering campaigns where altered folder structures are used to disguise malicious content or facilitate phishing efforts within collaborative environments. The ability to modify metadata of resources outside one's authorized scope undermines the integrity and trustworthiness of the multi-tenant architecture, exposing sensitive organizational data structures to unauthorized modification.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK technique T1078, specifically Valid Accounts, as it exploits legitimate credentials to perform actions beyond their intended privileges. It also reflects aspects of T1496, Resource Hijacking, in the context of manipulating shared resources for disruptive purposes. To mitigate this risk, immediate remediation is required by implementing strict server-side validation that ensures the folderId provided in the request actually belongs to the baseId specified in the URL and that the authenticated user has explicit update permissions on both the specific folder resource and its parent container. This involves querying the database to verify ownership or membership relationships before processing any state-changing requests, thereby enforcing proper object-level access control policies consistent with industry best practices for secure API design.