OpenProject CVE-2026-67527

Exploitation requires an authenticated account holding the edit_work_packages permission on a project but NOT the manage_file_links permission, targeting the PATCH /api/v3/work_packages/{id} endpoint with a _links.fileLinks payload; external file storage integration must be in use so that Storages::FileLink records exist to detach, hard-delete, or re-parent. Limiting factors: the attacker must already be a legitimate low-privileged project editor (PR:L, not unauthenticated), no user interaction is needed, and the behavior affects OpenProject versions prior to 17.6.0; cross-project re-parenting depends on the attacker knowing or enumerating raw FileLink database ids.

The supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L, base 7.6) is internally consistent with the description: network-reachable API, low complexity, and low privileges (an existing project member with edit rights), yielding high integrity impact through unauthorized deletion/re-parenting of FileLinks, low confidentiality from metadata disclosure, and low availability from data destruction. No EPSS score, KEV entry, POC, or SSVC decision data was provided, so real-world exploitation likelihood cannot be quantified - but the low bar (any authenticated editor, no user interaction, default configuration once storages are enabled) makes this a credible insider or compromised-account privilege-boundary issue rather than a mass-exploited internet threat. The primary limiting factor is that the attacker must already be an authenticated user with edit_work_packages on a project, so this is an authorization-boundary escalation, not unauthenticated RCE; prioritize patching where external file storages hold sensitive documents.

A user granted only edit_work_packages on a project sends a PATCH request to /api/v3/work_packages/{id} with a crafted _links.fileLinks array referencing FileLink ids from other projects. The API resolves those ids without a manage_file_links check, letting the attacker re-parent another project's file links onto their own work package (leaking origin filename, id, and MIME type) or omit existing ids to hard-delete them. No public exploit is identified at time of analysis, but the attack is a single authenticated API call with low complexity.