CVE-2026-52782: OpenProject Auth Bypass Vulnerability

CVE-2026-52782 Overview

OpenProject contains an Insecure Direct Object Reference (IDOR) vulnerability in the project storage settings endpoint. Prior to versions 17.3.3 and 17.4.1, a project administrator can send a crafted PATCH request to /projects/<A>/settings/project_storages/<A_ps_id> and manipulate the storages_project_storage[project_folder_id] parameter. This allows the attacker to reference the managed Nextcloud or OneDrive folder belonging to another project on the same storage backend. The next managed-folder synchronization overwrites the access control list (ACL) on the victim folder with the attacker project's user list, granting unauthorized access to files owned by another project [CWE-639].

Critical Impact
An authenticated project administrator can hijack managed cloud storage folders belonging to other projects, exposing confidential files and rewriting folder ACLs during the next sync cycle.

Affected Products

OpenProject versions prior to 17.3.3
OpenProject 17.4.x versions prior to 17.4.1
OpenProject instances integrated with Nextcloud or OneDrive managed storage

Discovery Timeline

2026-06-26 - CVE-2026-52782 published to NVD
2026-06-29 - Last updated in NVD database

Technical Details for CVE-2026-52782

Vulnerability Analysis

OpenProject links each project to a managed Nextcloud or OneDrive folder through a Storages::ProjectStorage record. The record stores a project_folder_id value that identifies the managed folder tied to that project. The PATCH /projects/<project_id>/settings/project_storages/<ps_id> endpoint accepts updates to this field without validating that the referenced folder belongs to the requesting project.

A project administrator on project A can submit a PATCH request that writes project B's project_folder_id into project A's Storages::ProjectStorage row. OpenProject's managed-folder synchronization worker then reconciles ACLs based on the stored project_folder_id. During the next sync, it rewrites the ACL on project B's folder to match project A's user list, granting attacker-controlled users access to another project's files.

Root Cause

The endpoint fails to enforce ownership validation on the project_folder_id parameter. The application trusts the client-supplied identifier without verifying that the folder is owned by the current project's storage context. This is a classic IDOR pattern in which a server-side authorization check is missing on a user-controllable object reference.

Attack Vector

An authenticated user with project-administrator privileges on any project sharing a storage backend with the target can exploit this flaw. The attack requires network access to the OpenProject web interface and a valid session. No user interaction from the victim is required. The scope changes because the compromise crosses a project trust boundary and affects folders governed by a different authorization domain.

Exploitation steps at a high level:

Enumerate project_folder_id values for the target project on the shared Nextcloud or OneDrive backend.
Send a PATCH request to the attacker-controlled project's storage settings endpoint, setting storages_project_storage[project_folder_id] to the victim folder identifier.
Wait for the next managed-folder sync, which overwrites the victim folder ACL with the attacker project's user list.

Detection Methods for CVE-2026-52782

Indicators of Compromise

PATCH requests to /projects/*/settings/project_storages/* where the storages_project_storage[project_folder_id] value does not match a folder previously associated with the requesting project.
Unexpected ACL changes on Nextcloud or OneDrive managed folders that add users from unrelated OpenProject projects.
Audit log entries showing a Storages::ProjectStorage update immediately followed by a folder sync affecting a different project's folder.

Detection Strategies

Correlate OpenProject application logs with Nextcloud or OneDrive audit events to identify ACL rewrites triggered by cross-project project_folder_id changes.
Alert on PATCH requests to project storage settings that modify project_folder_id fields, particularly when the new value maps to a folder governed by another project.
Baseline expected project_folder_id values per project and flag any deviation.

Monitoring Recommendations

Enable OpenProject audit logging for project storage configuration changes and forward events to a centralized logging platform.
Monitor storage-side ACL modifications and reconcile them against OpenProject project-membership records.
Review project-administrator role assignments and reduce the number of accounts holding this privilege on shared storage instances.

How to Mitigate CVE-2026-52782

Immediate Actions Required

Upgrade OpenProject to version 17.3.3 or 17.4.1 as documented in the OpenProject GitHub Security Advisory.
Audit all Storages::ProjectStorage records to confirm each project_folder_id maps to a folder owned by the correct project.
Review Nextcloud and OneDrive folder ACLs for unexpected user additions following any recent managed-folder sync.

Patch Information

OpenProject fixed the vulnerability in versions 17.3.3 and 17.4.1. The patch adds server-side validation to ensure the project_folder_id value belongs to the requesting project's storage context. Refer to the OpenProject GitHub Security Advisory GHSA-3vpx-94qx-xpw6 for release notes and upgrade instructions.

Workarounds

Restrict the project-administrator role to trusted users on any OpenProject instance sharing a Nextcloud or OneDrive backend across projects.
Temporarily disable the managed-folder sync feature until upgrading to a fixed release.
Segment storage backends so projects with different trust levels do not share the same Nextcloud or OneDrive storage instance.

bash

# Verify installed OpenProject version and confirm the fix is applied
sudo openproject run bundle exec rake about | grep -i version
# Expected output: 17.3.3 or 17.4.1 (or later)