Nextcloud Tables EUVD-2026-111133

The attacker must hold an authenticated Nextcloud account with at least read-data access to the target Tables table and must call the GET /apps/tables/share/table/{tableId} endpoint directly rather than through the web UI. No non-default configuration, user interaction, or elevated privilege is required beyond that existing read-data grant. Limiting factors: exploitation is confined to users who already have some access to the specific table, it works per-table (the attacker needs a valid tableId they can reach), and the disclosure is restricted to the share-recipient list and their permission levels - it does not expose the table's data beyond what the read-data grant already permits.

This is a low-severity information-disclosure flaw (CWE-200), and the combined signals support treating it as a monitor-level issue rather than a priority. The supplied CVSS 3.0 base is 3.3, and the vuln.today Decision label is 'monitor', which aligns. However, the signals are not fully consistent: the supplied vector is AV:L (local), yet the vulnerability is described as a directly callable HTTP API endpoint (GET /apps/tables/share/table/{tableId}), which is network-reachable - the AV:L label appears incorrect and I assess AV:N instead (see assessed vector). Exploitation requires an authenticated account that already holds read-data access to the specific table (PR:L), so it is not a remote-unauthenticated issue. No EPSS score was provided and the CVE is not listed in CISA KEV, so there is no evidence of active exploitation; a public HackerOne report reference (3524971) and a VulDB advisory exist, but the input does not confirm working exploit code. The actual impact is narrow: it leaks the membership and permission levels of a table's share list, not the table data itself. Net: real but minor - worth patching in normal cycles, not an emergency.

An authenticated Nextcloud user who has been granted only read-data access to a Tables table - and who is correctly blocked from seeing sharing details in the web UI - issues a direct GET request to /apps/tables/share/table/{tableId}. Because the endpoint omits the manage-level permission check, the server returns the complete list of users, groups, and teams the table is shared with and each recipient's permission level. A public HackerOne report reference exists describing the issue; it is not verified as working exploit code.