Teable EUVD-2026-103457

Requires an authenticated Teable session (any valid user account, membership in at least one base) plus knowledge of a valid folderId belonging to a base in which the attacker has no membership - the vulnerable path is PATCH /api/base/:baseId/node/folder/:folderId, which checks the base|update permission only against the URL baseId rather than against the base that owns the supplied folderId. Limiting factors: exploitation is authenticated (not anonymous), depends on the attacker discovering or guessing a non-enumerable foreign folderId (reflected as AT:P in the CVSS 4.0 vector), and yields only folder-rename (low integrity) impact with no data read or deletion; multi-tenant/shared Teable instances are most exposed, while isolated single-tenant deployments have little practical exposure.

This is a low-severity authorization bypass (IDOR / CWE-639) that the vendor-supplied CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N) scores at 2.3. The signals are internally consistent and all point to limited real-world risk: network reachable (AV:N) and low complexity (AC:L), but it requires an authenticated account (PR:L), a specific attack requirement (AT:P, i.e. possession of a valid foreign folderId), and the only impact is low integrity (VI:L) - an attacker can rename folders in bases where they lack membership, but cannot read data (VC:N) or affect availability (VA:N). No EPSS score, KEV listing, or public POC was provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation. This is a genuine access-control defect worth patching, but it is a low-priority, limited-impact issue rather than a widespread exploitation threat - the integrity impact is confined to folder renaming (metadata tampering), not data disclosure or code execution. The one caveat: the tenant-isolation nature of the flaw means it matters more in multi-tenant SaaS deployments of Teable than in single-org self-hosted instances, so prioritization should be weighted by deployment model.

An authenticated Teable user who belongs to one base obtains or enumerates a folderId belonging to a different base they are not a member of, then sends a PATCH /api/base/:baseId/node/folder/:folderId request. Because the server authorizes base|update only against the URL baseId and not against the base that actually owns the folderId, the rename succeeds, letting the attacker tamper with the folder structure of a base they should not be able to modify. No public exploit code is known, but the attack is trivial to script for any logged-in user who can discover a foreign folderId.