Kaneo EUVD-2025-211089

Requires a valid authenticated account on the same Kaneo instance (PR:L) plus knowledge of valid project, task, label, or workspace identifiers belonging to a different workspace; per the description these identifiers can be harvested out-of-band, for example from shared project links. Affected deployments are Kaneo before 2.1.6, where API routes in the task, label, activity, and search modules lacked the workspaceAccess membership middhorization check. No user interaction is needed. Limiting factors: exploitation is impossible for a fully unauthenticated external attacker, and the attacker must obtain target identifiers - so instances hosting only a single trusted workspace/tenant face substantially lower realistic risk than multi-tenant deployments.

The vendor-supplied CVSS 4.0 score of 7.7 (High) reflects a network-reachable flaw (AV:N) with low complexity (AC:L), no user interaction (UI:N), and full High impact to confidentiality, integrity, and availability of workspace data (VC:H/VI:H/VA:H). Two metrics materially temper the raw score: PR:L means the attacker must already hold a valid authenticated Kaneo account, and AT:P reflects that exploitation requires obtaining valid object identifiers (project/task/label/workspace IDs) belonging to a victim workspace. No EPSS score, CISA KEV listing, or public exploit code is present in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the finding rests on a VulnCheck advisory and a confirmed vendor patch. The signals are internally consistent (the CVSS 4.0 vector, CWE-862 missing authorization, and the source diff adding workspaceAccess membership checks all agree). Realistic priority is moderate: this is a genuine cross-tenant broken-access-control bug that matters most for Kaneo instances hosting multiple untrusted workspaces/tenants, but it is NOT an unauthenticated internet-wide issue and requires both an account and knowledge of target identifiers. Note the input Tag 'Authentication Bypass' is imprecise - the attacker is authenticated and the defect is missing authorization (IDOR-style), not an authentication bypass.

An authenticated low-privileged Kaneo user obtains a project or task identifier belonging to another workspace - for example from a shared project link - and calls API routes (in the task, label, activity, or search modules) that lack membership checks in versions before 2.1.6. With that identifier they can read projects and tasks, modify or delete tasks, labels and comments, and search another workspace's contents. No public exploit code was identified at time of analysis, though the root cause is confirmed by the vendor patch diff.