CVE-2026-85619: AppFlowy-Cloud Authorization Bypass Flaw

CVE-2026-85619 Overview

CVE-2026-85619 is a broken access control vulnerability in AppFlowy-Cloud version 0.9.64. The authorization layer fails to verify that requested collab objects actually belong to the workspace referenced in the request. An authenticated attacker can supply a victim's object ID paired with their own workspace ID to bypass authorization checks. This grants read, modify, and delete access to documents and database rows across workspace boundaries. The flaw is classified under CWE-863: Incorrect Authorization and affects the HTTP API surface exposed by the collab service.

Critical Impact

Authenticated users can access, alter, or destroy documents and database rows belonging to other AppFlowy workspaces, breaking tenant isolation.

Affected Products

• AppFlowy-Cloud version 0.9.64
• Collab HTTP API endpoints backed by libs/access-control/src/casbin/collab.rs
• Multi-tenant AppFlowy-Cloud deployments serving multiple workspaces

Discovery Timeline

• 2026-09-04 - CVE-2026-85619 published to NVD
• 2026-09-10 - Last updated in NVD database

Technical Details for CVE-2026-85619

Vulnerability Analysis

AppFlowy-Cloud enforces access to collab objects (documents, database rows, folders) through a Casbin-based authorization layer. The check confirms the caller has a role on the workspace identified in the request path. It does not confirm that the requested object ID actually belongs to that workspace. An attacker who legitimately owns Workspace A can therefore submit an object ID that belongs to Workspace B, tunneled through the Workspace A authorization context.

The backend resolves the object by its identifier regardless of ownership, returning or mutating the record. This defeats the intended per-workspace isolation model that underpins the SaaS multi-tenant deployment. Impact spans confidentiality, integrity, and availability of collaborative content across every workspace on the instance.

Root Cause

The authorization logic in the collab access control module checks the actor-workspace relationship but omits an object-workspace binding check. Object IDs are treated as globally addressable while permissions are scoped per workspace. The mismatch enables cross-tenant object references to pass authorization. See the vulnerable module at libs/access-control/src/casbin/collab.rs and the upstream discussion in GitHub Issue #1624.

Attack Vector

Exploitation requires an authenticated account with low privileges on any workspace on the target instance. The attacker enumerates or otherwise obtains an object ID (UUID) belonging to a victim workspace. They then issue HTTP API calls to collab endpoints using their own workspace_id in the path while placing the victim's object_id in the request body or parameters. The server authorizes the request against the attacker's workspace and executes the read, update, or delete against the victim's data. Further exploitation details are documented in the VulnCheck Advisory on AppFlowy.

Detection Methods for CVE-2026-85619

Indicators of Compromise

• HTTP API requests to collab endpoints where the supplied object_id cannot be traced to the workspace_id in the same request path.
• Unexpected read, update, or delete operations on collab objects performed by user principals that are not members of the owning workspace.
• Enumeration patterns against /api/workspace/{workspace_id}/collab/{object_id} style routes using rotating object IDs.

Detection Strategies

• Correlate collab API access logs against workspace membership records and alert when the requesting user has no role in the workspace that owns the referenced object.
• Deploy a WAF or reverse-proxy rule that parses request bodies and rejects calls where the object_id is not registered under the URL-path workspace_id.
• Baseline normal object access rates per user and flag sudden bursts of distinct object_id values in short time windows.

Monitoring Recommendations

• Enable verbose audit logging on all collab service routes, including the resolved workspace-object binding for each request.
• Ship AppFlowy-Cloud application logs and reverse-proxy access logs to a centralized SIEM for cross-workspace access correlation.
• Monitor database write and delete volumes on collab tables and alert on activity attributable to non-owning workspace principals.

How to Mitigate CVE-2026-85619

Immediate Actions Required

• Restrict network exposure of AppFlowy-Cloud 0.9.64 instances until a patched release is deployed, especially for multi-tenant environments.
• Audit collab access logs for cross-workspace object references dating back to the deployment of version 0.9.64.
• Rotate any credentials, tokens, or secrets stored inside AppFlowy documents or database rows that may have been exposed.
• Notify tenants whose workspace data was accessible during the vulnerable window if evidence of unauthorized access is found.

Patch Information

At the time of publication, no fixed release is referenced in the NVD entry. Track the upstream AppFlowy-Cloud repository and GitHub Issue #1624 for remediation status. Upgrade to a release later than 0.9.64 that adds a workspace-object binding check inside the collab authorization path once available.

Workarounds

• Place AppFlowy-Cloud behind an authenticating reverse proxy that validates the object_id in each request against a lookup of workspace ownership before forwarding.
• Limit account creation and workspace provisioning on shared instances to trusted users to reduce the pool of accounts able to perform authenticated cross-workspace access.
• Deploy separate AppFlowy-Cloud instances per tenant where feasible, eliminating multi-workspace exposure on a single database.

# Example reverse-proxy check (pseudocode) to reject cross-workspace object access
# Reject request when object_id does not belong to workspace_id in the URL path
location ~ ^/api/workspace/(?<ws>[0-9a-f-]+)/collab/(?<obj>[0-9a-f-]+) {
    access_by_lua_block {
        local ok = require("appflowy_guard").verify_object_in_workspace(ngx.var.ws, ngx.var.obj)
        if not ok then
            return ngx.exit(403)
        end
    }
    proxy_pass http://appflowy_upstream;
}