Nextcloud Tables CVE-2026-45722

The attacker must have a valid Nextcloud account and be granted access to the Tables app (PR:L in the CVSS vector); no user interaction is required and the attack is performed over the network against the standard Nextcloud HTTP endpoints. The vulnerable code path is reached by submitting a sort operation against a table the user can query, so at least one table the attacker can read must exist. Exploitation is inherently rate-limited because ORDER BY injection only leaks one bit per HTTP request, making bulk data exfiltration noisy and slow but still feasible against the entire database the Nextcloud service account can reach.

The CVSS 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L) accurately reflects a network-reachable, low-complexity issue requiring authenticated access with high confidentiality impact and low availability impact (consistent with time-based DoS via SLEEP-style payloads). EPSS and CISA KEV status were not provided in the source data, so widespread exploitation probability cannot be quantified. The PR:L requirement plus the inherent slowness of blind ORDER BY exfiltration (one bit per request) materially lowers real-world urgency compared to a typical pre-auth SQLi, but any tenant where untrusted users have Tables access - common in shared-hosting or community Nextcloud deployments - should treat this as a priority because confidentiality impact extends to the entire Nextcloud database, not just Tables data. No public exploit identified at time of analysis, though the HackerOne report (#3446689) and detailed PR diff give a clear roadmap for one.

An authenticated low-privilege Nextcloud user with access to the Tables app crafts a request to sort a table, injecting a conditional expression into the sort mode parameter (e.g., a CASE WHEN clause that orders rows differently based on a single bit of a target value such as an oc_users password hash). By scripting hundreds of such requests, the attacker reconstructs arbitrary database content byte-by-byte; alternatively, they inject a database SLEEP() to confirm exploitability or cause minor availability degradation.