CVE-2026-44732: OpenProject Authorization Bypass in Document Management

Technical summary

The vulnerability exists in OpenProject's document update endpoint (PATCH request handler). When a user submits a request to modify a document, the application loads the target document and performs initial visibility checks. However, before enforcing authorization rules, the endpoint applies attacker-controlled attributes—including project_id—to the database record. This allows an authenticated attacker to reassign a document from its original project to another project by manipulating the project_id parameter, bypassing the :manage_documents permission requirement for the source project. The flaw is classified as CWE-639 (Authorization Bypass Through User-Controlled Key).

Business impact

This vulnerability allows unauthorized document manipulation across project boundaries within an OpenProject instance. A team member in one project could alter, move, or otherwise modify documents in other projects they do not have access to, potentially exposing sensitive project information, corrupting document structures, or disrupting project workflows. The risk is heightened in multi-project environments where documents contain confidential or regulatory information. The CVSS 4.3 MEDIUM score reflects the need for authentication and the information integrity focus, but the cross-project nature and ease of exploitation warrant prompt remediation in shared environments.

Affected systems

OpenProject versions prior to 17.3.2 and 17.4.0 are affected. Organizations running any version in the 17.x series before these fixed releases should verify their deployed version and prioritize patching. Self-hosted and managed instances are equally vulnerable if not updated.

Exploitability

Exploitation requires valid OpenProject credentials and network access to the instance. An authenticated user can craft a single PATCH request targeting the document endpoint with a modified project_id parameter to reassign documents. No user interaction, special privileges, or complex exploitation chain is needed; the flaw is trivial to exploit once an attacker has login access. The low barrier to exploitation—a single HTTP request with a parameter change—combined with the straightforward impact makes this practical for insider threats or compromised low-privilege accounts.

Remediation

Upgrade OpenProject to version 17.3.2 or 17.4.0, whichever is appropriate for your deployment track. These versions enforce authorization checks before applying user-supplied attributes to the document record, eliminating the timing window. Verify the upgrade by confirming the version in the OpenProject admin interface and testing that unprivileged users cannot modify cross-project documents.

Patch guidance

Apply the fix by upgrading to OpenProject 17.3.2 (if on the 17.3.x branch) or 17.4.0 (if on the 17.4.x branch or later). Consult the official OpenProject release notes and upgrade documentation for your deployment model (Docker, package manager, or source). No configuration changes are required post-upgrade. Plan the upgrade during a maintenance window to minimize disruption, though the vulnerability does not require emergency downtime if your environment has limited cross-project sharing or strong access controls at the database level.

Detection guidance

Monitor OpenProject logs for PATCH requests to document endpoints with anomalous project_id values, particularly requests that modify documents in projects the authenticated user is not a member of. Inspect audit logs (if available in your instance) for document moves or updates originating from users without :manage_documents permissions in the affected project. Check the current version with `openproject -v` or via the admin interface. Use vulnerability scanners to verify your version against known vulnerable ranges.

Why prioritize this

Prioritize this patch for multi-project OpenProject environments, especially those handling sensitive documents or operating under compliance requirements (regulatory, contractual, or operational). While the CVSS score is MEDIUM, the ease of exploitation and cross-project document access implications warrant timely remediation. Organizations with single-project deployments or restricted user access may deprioritize slightly, but the fix should still be scheduled within normal maintenance cycles.

Risk score, explained

The CVSS 3.1 score of 4.3 reflects low attack complexity, the need for authentication (PR:L), and integrity impact limited to document attributes rather than system-level compromise (I:L, C:N, A:N). The score appropriately captures that this is not a critical remote code execution or widespread availability impact. However, the practical risk in busy multi-project environments is amplified by ease of exploitation and the insider threat vector; treat this as high-priority in your specific context if document integrity and confidentiality are business-critical.

Frequently asked questions