CVE-2026-111344 in APITable
Summary
by MITRE • 10/16/2026
APITable through 1.14.0-beta contains an authorization bypass vulnerability that allows authenticated users to read node descriptions from other spaces by supplying a user-controlled nodeId. Attackers can request GET /node/{nodeId}/description, which skips space membership and node permission checks, to disclose cross-tenant datasheet, folder, and form descriptions.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in APITable versions up to 1.14.0-beta represents a critical failure in access control mechanisms, specifically categorized under CWE-285 Improper Authorization. This flaw allows authenticated users to bypass intended security restrictions by manipulating input parameters related to resource identification. In the context of web applications and API-driven services like APITable, which often serve multiple tenants or distinct workspaces, maintaining strict isolation between these logical boundaries is paramount for data confidentiality. The specific technical defect lies in the endpoint handling node descriptions via a GET request to /node/{nodeId}/description. When an attacker supplies a user-controlled nodeId that belongs to a different space than their own, the application fails to verify whether the requesting user has permission to access that specific resource or even if they have any membership within the target space at all. This indicates a logic error where the authorization middleware likely relies solely on the validity of the authentication token rather than performing a secondary check against the permissions associated with the requested resourceId and its parent container, such as a workspace or folder structure.
From an operational perspective, this vulnerability enables unauthorized cross-tenant data disclosure. Although APITable is designed to support multi-tenancy where different teams or organizations may operate within isolated environments on the same instance, this flaw allows one tenant to窥视 (peek into) sensitive information belonging to another. The disclosed data includes descriptions of datasheets, folders, and forms. While these fields might seem less critical than raw database records, they often contain contextual metadata that can reveal business logic, project names, internal processes, or proprietary strategies. For example, a folder description might indicate the existence of a confidential merger discussion, while a form description could expose customer feedback mechanisms used by competitors. In high-security environments, even indirect information leakage is considered a significant breach because it aids attackers in social engineering attacks or further reconnaissance to identify more valuable targets within the compromised organization's infrastructure.
The exploitation vector for this vulnerability is straightforward and does not require complex payload construction beyond parameter manipulation. An authenticated user simply needs to craft an HTTP GET request with a nodeId that they know, or can enumerate through trial and error if node IDs are sequential or predictable, belonging to another space. This simplicity increases the risk of automated scanning tools detecting and exploiting this weakness across large installations. The impact is compounded by the fact that APITable users typically trust the platform's security model regarding data isolation between spaces. Consequently, organizations relying on APITable for collaborative work may suffer reputational damage and potential regulatory penalties if personal identifiable information or protected intellectual property is inadvertently exposed through these descriptive fields.
To mitigate this vulnerability, immediate action should be taken to upgrade APITable to a version where the authorization logic has been corrected to enforce strict space-level permissions before serving any node metadata. In addition to patching, organizations should implement defense-in-depth strategies such as Web Application Firewalls that can detect anomalous patterns of cross-space resource access attempts. It is also advisable to conduct an internal audit of API endpoints to ensure no other similar bypasses exist where resourceId parameters are not validated against the user's assigned roles and space memberships. Regular penetration testing focusing on broken object level authorization flaws, aligned with MITRE ATT&CK technique T1530 Data from Cloud Storage Object or T1537 Transient Infrastructure, will help identify such gaps before they can be exploited by malicious actors. Ensuring that all API endpoints consistently apply the principle of least privilege and verify ownership at every step of the request lifecycle is essential for maintaining robust multi-tenant security postures.