Nextcloud Tables CVE-2025-66551

Requires an authenticated Nextcloud account with at least low-privilege access to the Tables app (PR:L) on an instance running Tables prior to 0.8.6 or 0.9.0-beta.1 through 0.9.3. The attacker must be able to create their own table and column, then invoke the column update/move API endpoint against a table they do not own - the missing ownership/authorization check on the pre-patch ColumnController (later folded into Api1Controller) is what permits the cross-table operation. Limiting factors: exploitation is confined to registered users of the same Nextcloud instance, requires no victim interaction (UI:N) but yields only integrity impact to table structure - no confidentiality or availability impact and no privilege escalation beyond tampering with another user's table.

All signals point to a low real-world priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 4.3) describes a network-reachable but authenticated (PR:L) authorization flaw with integrity-only impact (I:L) and no confidentiality or availability impact. EPSS is essentially floor-level at 0.02% (4th percentile), indicating negligible predicted exploitation. There is no CISA KEV listing and no public exploit identified at time of analysis (the HackerOne report #3137895 documents the finding but is not weaponized PoC). This is a classic CWE-639 insecure-direct-object-reference / broken-authorization issue: the finding is legitimate and vendor-confirmed, but the impact ceiling is low - a low-privilege user tampering with another user's table structure, not data theft or code execution. No signals conflict: low CVSS, low EPSS, no KEV, and no PoC are mutually consistent with a genuine-but-minor bug. Note the input Tag 'Authentication Bypass' misrepresents the flaw - this is an authorization/IDOR issue, not an authentication bypass; the user is already authenticated.

An authenticated low-privilege Nextcloud Tables user creates their own table, then issues a column-move/update API request that targets a column into a victim's table they do not own, exploiting the missing per-table ownership check on the column endpoints. The result is unauthorized modification of the victim's table structure. No public exploit code has been identified; only a vendor/HackerOne advisory documents the issue.