OpenProject CVE-2026-52779

Exploitation requires an authenticated OpenProject user account with management-level permissions in at least one project on the target instance (CVSS PR:L confirmed). The target must be a public or shared Calendar or Team Planner Query object belonging to a different project on the same instance. The attacker must know or discover the numeric :id of the target query (e.g., by enumerating shared views visible via Query.visible scope). Exploitation is limited to delete operations only - no read or modify path on private data is described. Limiting factors: authentication and project management role are mandatory prerequisites; the impact is confined to deletion of shared views rather than data exfiltration or privilege escalation; the flaw does not affect private (non-public) queries that are not visible to the attacker's account.

The CVSS 3.1 score of 5.4 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L accurately reflects the bounded real-world risk. The PR:L metric is key: exploitation requires an authenticated account that already holds management-level permissions in at least one project on the target instance, which significantly narrows the attacker population compared to fully unauthenticated flaws. The integrity and availability impacts are Low - the attacker can delete shared views but cannot read private data, escalate privileges, or execute code. No EPSS data was provided in the intelligence sources; given the absence of KEV listing and no public exploit code, this vulnerability is unlikely to see widespread opportunistic exploitation. The primary threat actor profile is a malicious or disgruntled internal user who has legitimate project management access and seeks to disrupt other teams' shared planning views. For multi-tenant or large enterprise OpenProject deployments with many projects and shared views, the risk is meaningfully higher than for small single-team instances. No conflicting signals were identified between the CVSS vector and the description.

An attacker with a legitimate OpenProject account holding management permissions in Project A identifies the numeric IDs of public Calendar or Team Planner queries belonging to Project B (discoverable by browsing shared views or through the API). The attacker crafts a deletion HTTP request using Project A's :project_id in the URL path but substitutes Project B's query :id as the resource identifier; the server authorizes the request against Project A's context and deletes the unrelated Project B query without error. No public exploit code exists at time of analysis, but the attack is straightforward to reproduce manually given knowledge of the authorization flaw.