Teable share views expose more than a table

Teable is a platform that combines databases, views, forms, APIs, and automation. A share view is more than just a rendered table; it can be customized with various settings that determine what data is exposed. These settings include retrieving specific records, allowing copying, including hidden fields, and requiring authentication such as passwords or login credentials. The settings of a share view can determine how much of the base data remains accessible within an authenticated workspace.

On November 4, 2026, queries to ZoomEye, a security information and event management platform, returned zero instances for an application named Teable and 17 instances for a page titled "Teable" when using page 1 and a page size of 1. This suggests that the number of exposed Teable instances may be smaller than the zoomeye count indicates.

To ensure a thorough evaluation of a Teable deployment, it is crucial to list each share ID along with its associated base and view, the creation time, and the individual who created it. Then, compare the settings of each share with the data classification of the view. A public view that includes sensitive records and hidden fields could inadvertently expose information that the workspace UI typically hides.

Additionally, a share with the ability to copy data increases the risk of sensitive data persisting beyond the intended access period.

When reviewing share settings, it is essential to evaluate passwords and login requirements as separate controls. While a password protects access to a share, it should be managed independently from the link provided to users. The password should be changed periodically when recipients update their credentials. Similarly, a require-login setting may provide stronger identity assurance, but its effectiveness depends on the underlying identity system and invitation process.

A require-login setting contributes to data security but does not eliminate the need to review the API token associated with the share. API tokens act as workspace credentials, and it is necessary to verify their scope and ownership. Tokens should be distinct for each integration and tested to ensure that a token from one workspace cannot access another workspace's resources.

If the Teable deployment supports advanced permissions, a token should not be able to bypass restrictions set at the base or view level by making lower-level table endpoint calls.

Automation features in Teable can extend the scope of potential data exposure. A workflow that triggers on record changes and executes with stored credentials can inadvertently access sensitive data. When sharing a base, it is crucial to review all linked automations, their execution history, and any external webhooks or actions that may be triggered. Even if a view appears read-only, it may still be connected to a record-change trigger, posing a risk if the trigger is exploited.

To confirm whether a Teable deployment is vulnerable, it is necessary to obtain authorization from the deployment owner and conduct a documented response. After confirming the deployment, it is essential to inventory all shares and APIs as configuration objects rather than solely relying on URLs. The ultimate control that matters is the combination of record visibility, hidden-field inclusion, authentication methods, copying permissions, and downstream automation processes.