AppFlowy-Cloud CVE-2026-85619

Attacker must hold a valid AppFlowy-Cloud account on the target instance (PR:L - authenticated, low privilege). The attacker must additionally know or successfully enumerate at least one collab object ID from a victim workspace (AT:P per CVSS 4.0 - attack prerequisites present; AC:H - specific object ID required). The AppFlowy-Cloud HTTP API must be reachable by the attacker. No special server-side configuration is required beyond a default multi-workspace deployment. Exploitation is bounded to authenticated users of the same AppFlowy-Cloud instance; unauthenticated external parties and users on separate instances cannot exploit this flaw. Single-workspace deployments where all users share one workspace have no meaningful isolation boundary at risk.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N) signals a network-exploitable vulnerability requiring authentication (PR:L) and specific attack prerequisites (AT:P, AC:H) - namely, the attacker must know or enumerate a victim's collab object ID. All three impact metrics on the vulnerable system are rated High (VC:H/VI:H/VA:H), reflecting full read, write, and delete access to cross-workspace data. Subsequent-system impact is absent (SC:N/SI:N/SA:N), consistent with the breach being contained within the same AppFlowy-Cloud instance. No KEV listing and no public exploit code at time of analysis tempers immediate exploitation pressure; however, the public GitHub issue (#1624) fully documents the flaw and the affected source file is pinned, lowering attacker research effort significantly. Real-world risk is meaningful for multi-tenant AppFlowy-Cloud deployments (e.g., SaaS operators or shared organizational instances) where distinct workspaces serve as security isolation boundaries. Single-user or single-workspace deployments face no practical risk.

An authenticated AppFlowy-Cloud user enumerates or obtains a collab object ID from a victim's workspace - for example, via a shared link, API response leak, or sequential ID guessing. The attacker then submits an HTTP API request referencing the victim's object ID alongside their own valid workspace ID. The authorization layer confirms the attacker's workspace membership but neglects to verify the object belongs to that workspace, returning the victim's document contents or permitting modification or deletion.