CVE-2026-44735 in openproject
Summary
by MITRE • 06/26/2026
OpenProject is open-source, web-based project management software. Prior to 17.3.2 and 17.4.0, the GET /api/v3/shares endpoint returns share details for ALL work packages in a project to any user with the view_shared_work_packages permission. The authorization check operates at the project level only — it does not verify the requesting user can actually view each individual shared work package. This allows a regular project member to discover work package IDs and subjects (including confidential titles), which users have been granted shared access, what role level was assigned (Editor, Commenter, Viewer). This vulnerability is fixed in 17.3.2 and 17.4.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 06/27/2026
The vulnerability in OpenProject versions prior to 17.3.2 and 17.4.0 represents a critical authorization bypass flaw that undermines the software's access control mechanisms. This issue specifically affects the GET /api/v3/shares endpoint which is designed to provide share details for work packages within projects. The flaw stems from an insufficient authorization check that operates solely at the project level rather than implementing proper individual work package level verification. Security researchers identified that users with merely the view_shared_work_packages permission could enumerate complete information about all shared work packages within a project, regardless of whether they should have access to each specific item.
The technical implementation of this vulnerability exposes sensitive information through improper access control validation. When a user makes a request to the shares endpoint, the system fails to validate that the requesting user has legitimate access rights to view each individual work package before returning its details. This authorization gap creates a scenario where attackers can systematically discover work package identifiers, subjects, and role assignments without proper authorization. The exposed information includes confidential titles of work packages, which may contain sensitive project data, along with role levels assigned to different users such as Editor, Commenter, or Viewer permissions. This represents a clear violation of the principle of least privilege and demonstrates inadequate input validation and access control enforcement.
The operational impact of this vulnerability extends beyond simple information disclosure to potentially enable more sophisticated attacks. Regular project members who should only have limited visibility can now discover the complete scope of shared work packages within projects, including those they might not normally be authorized to view. This information exposure could facilitate social engineering attacks, allow for targeted phishing attempts against specific users with particular role assignments, or provide attackers with detailed knowledge of project structures and user permissions. The vulnerability essentially provides a reconnaissance mechanism that allows unauthorized users to map the complete sharing landscape of projects, potentially revealing sensitive project timelines, resource allocations, and user roles within the organization.
This security flaw aligns with CWE-284, which describes improper access control vulnerabilities where systems fail to properly enforce authorization checks. The issue also relates to ATT&CK technique T1069.003, which involves credential access through permission groups, as it allows unauthorized users to gain information about user roles and permissions within the system. The vulnerability demonstrates a fundamental failure in implementing proper authorization boundaries and represents a classic example of how insufficient access control validation can lead to information disclosure attacks. Organizations using affected versions of OpenProject should immediately implement mitigations including upgrading to version 17.3.2 or 17.4.0, which contain the necessary authorization fixes. Additionally, administrators should review existing user permissions and implement additional monitoring for unusual API access patterns that might indicate exploitation attempts. The fix addresses the core issue by implementing proper individual work package level authorization checks before returning share details, ensuring that users can only access information about work packages they are legitimately authorized to view.