CVE-2026-44735: OpenProject Authorization Bypass Leaks Work Package Share Metadata

Technical summary

The vulnerability exists in the GET /api/v3/shares endpoint of OpenProject prior to versions 17.3.2 and 17.4.0. The authorization mechanism performs only project-level permission validation—it checks whether a user has the view_shared_work_packages permission on the project—but omits per-resource authorization checks. This is a classic broken access control pattern (CWE-863). A user with project membership can query the shares endpoint and receive complete share metadata for all work packages in that project, including work package IDs, titles, the identities of users and groups granted access, and their assigned roles, regardless of whether the requesting user has permissions to view those specific work packages. The flaw is data confidentiality-focused; no integrity or availability impact occurs.

Business impact

In organizations using OpenProject for confidential or compartmentalized project work, this vulnerability enables unauthorized information disclosure. Project members can discover the existence and names of work packages they were intentionally excluded from, learn which colleagues have been granted access to sensitive deliverables, and infer team structure and access patterns. This undermines access control policies and may violate confidentiality agreements or regulatory requirements (such as those governing contractor or partner access). For managed service providers or consulting firms using OpenProject, the risk is heightened if clients expect strict data isolation within shared projects.

Affected systems

OpenProject versions prior to 17.3.2 and 17.4.0 are affected. The vulnerability is specific to the API endpoint and affects any deployment where the view_shared_work_packages permission is granted to users. Self-hosted, on-premise, and cloud-hosted instances are all in scope. Note that vendors_products data was not available in the source, so verification of exact affected versions and release dates should be cross-referenced with the official OpenProject advisory.

Exploitability

Exploitability is straightforward. The vulnerability requires only network access (AV:N), low privilege (PR:L—any authenticated project member), no user interaction (UI:N), and produces a consistent, deterministic outcome (AC:L). An attacker with even minimal project membership can query the API programmatically and extract all share metadata in seconds. No special tools, social engineering, or race conditions are required. The attack surface is the public API endpoint, making it discoverable to any authenticated user.

Remediation

Upgrade OpenProject to version 17.3.2 or 17.4.0 or later. These releases include authorization fixes that enforce per-work-package permission checks on the shares endpoint. Organizations should verify the exact version available in their deployment track (Community, Professional, or Enterprise editions) and plan patching accordingly. Until patching is complete, restrict the view_shared_work_packages permission to only users and roles that require it, though this does not eliminate the underlying flaw.

Patch guidance

Review the official OpenProject release notes and security advisories for versions 17.3.2 and 17.4.0 to confirm patch details and any additional changes or deprecations. If your deployment is on an earlier version, prioritize upgrading to one of these fixed versions. Test the upgrade in a non-production environment first to ensure no breaking changes. If you are on a maintenance branch (e.g., 17.3.x), verify that 17.3.2 is available; if on a newer branch, 17.4.0 or later applies. Coordinate with your OpenProject vendor or community support channel if you encounter blockers.

Detection guidance

Monitor API logs for repeated or suspicious calls to GET /api/v3/shares, particularly from service accounts or users with lower privilege levels. Look for patterns such as sequential access to the endpoint, extraction of large numbers of work package share records, or access outside normal business hours. If running OpenProject on-premise, enable detailed API audit logging to capture requests, response sizes, and requesting user identities. Check for any third-party integrations or plugins that might be calling the shares endpoint and review their authorization logic. Post-patch, re-examine access logs to determine if the vulnerability was exploited before the fix was deployed.

Why prioritize this

This vulnerability merits timely patching despite a CVSS score of 6.5 (Medium). The attack vector is unauthenticated-adjacent (requires only project membership), the exploitability is trivial, and the impact is direct information disclosure of sensitive work package metadata and access control information. Organizations using OpenProject for confidential work, regulatory compliance, or multi-tenant access control should treat this as high priority. Even for less sensitive deployments, the low barrier to exploitation makes it an easy vector for insider threats. The lack of KEV status does not diminish urgency; patch as part of your regular update cadence but accelerate if your environment handles sensitive project data.

Risk score, explained

The CVSS 3.1 score of 6.5 reflects a high-confidence attack path (low complexity, low privileges required) with significant confidentiality impact (C:H) but no integrity or availability impact. The score appropriately captures the risk to information disclosure but may underweight the contextual severity in regulated or multi-tenant environments. Organizations handling sensitive intellectual property, client data, or compliance-restricted information should consider this a 7+ priority regardless of the CVSS rating.

Frequently asked questions