Teable combines databases, views, forms, APIs, and automation. A share view is not just a rendered table. Its settings can include whether records are returned, whether copying is allowed, whether hidden fields are included, and whether a password or login is required. Those settings decide how much of the base leaves the authenticated workspace.
On 2026-11-04, count-only ZoomEye queries returned 0 for app="Teable" and 17 for title="Teable" with page 1, pagesize 1, and sub_type=all. The title count is small and may contain documentation or unrelated text. It is not a confirmed inventory of exposed Teable instances.
For an authorized deployment review, list every share ID, its base and view, its creation time, and the person who created it. Then compare the share settings with the data classification of the view. A public view that includes records and hidden fields can disclose columns that the workspace UI deliberately hides. A share that allows copying increases the chance that exported data survives after the link is revoked.
Passwords and login requirements need to be evaluated as separate controls. A password protects access to a share, but it should not be shared in the same message as the link and should be rotated when recipients change. A require-login setting may provide stronger identity evidence, but it depends on the identity system and the invitation path. Neither setting removes the need to review the API token that created or reads the share.
API tokens are workspace credentials. Teable's API examples use bearer tokens for table, record, view, and share operations. Separate tokens by integration, record their scope and owner, and test that a token for one workspace cannot read another. If the deployment supports advanced permissions, verify that a token cannot bypass a base or view restriction by calling a lower-level table endpoint.
Automation extends the boundary. A workflow can trigger on record changes and run with stored credentials. When sharing a base, review the linked automations, their execution history, and any webhook or external action. A view that looks read-only may still be connected to a record-change trigger. Disable unused automations and keep execution logs long enough to investigate a data change.
The ZoomEye title count gives 17 candidates, not 17 vulnerable sites. Confirm a Teable deployment only with owner authorization and a documented response. Then inventory shares and APIs as configuration objects, not just URLs. The control that matters is the combination of record visibility, hidden-field inclusion, authentication, copying, and downstream automation.