What is the CVSS score of CVE-2026-44735?

CVE-2026-44735 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.3%.

Is there a patch available for CVE-2026-44735?

Yes, a patch is available for CVE-2026-44735. Update the affected software to the latest version immediately.

OpenProject CVE-2026-44735

EUVD-2026-39880 MEDIUM

Incorrect Authorization (CWE-863)

2026-06-26 GitHub_M

Authentication Bypass Openproject

6.5

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

vuln.today AI

6.5 MEDIUM

Network-accessible REST API (AV:N), no special conditions beyond project membership (AC:L), requires low-privileged authenticated account (PR:L), pure read-only disclosure with no integrity or availability impact (I:N/A:N).

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jun 26, 2026 - 21:02 EUVD

Analysis Generated

Jun 26, 2026 - 20:32 vuln.today

DescriptionCVE.org

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.

AnalysisAI

Incorrect authorization in OpenProject's REST API allows authenticated project members to harvest confidential work package metadata they are not entitled to view. The GET /api/v3/shares endpoint enforces access control only at the project level - not at the individual work package level - meaning any holder of the view_shared_work_packages permission can retrieve share records for every work package in a project, including confidential titles, share recipient identities, and assigned role levels. No public exploit is identified at time of analysis; vendor-released patches exist in versions 17.3.2 and 17.4.0.

Technical ContextAI

OpenProject is an open-source, web-based project management platform (CPE: cpe:2.3:a:opf:openproject:*:*:*:*:*:*:*:*) that models tasks and issues as 'work packages,' which support fine-grained sharing with external or limited-access users at the individual work package level. The REST API endpoint GET /api/v3/shares is designed to return sharing metadata for work packages. The root cause is CWE-863 (Incorrect Authorization): the endpoint's authorization gate checks whether the caller holds the project-level view_shared_work_packages permission but omits a secondary, per-work-package visibility check. This granularity mismatch between the access control plane and the data model means the permission acts as a master key to all share metadata across the project, regardless of whether the caller has direct read access to individual work packages.

RemediationAI

Upgrade to OpenProject 17.3.2 or 17.4.0, both of which contain the fix for the missing per-work-package authorization check in the GET /api/v3/shares endpoint, per the vendor advisory at https://github.com/opf/openproject/security/advisories/GHSA-cfg3-f34w-9xx5. If an immediate upgrade is not feasible, revoke the view_shared_work_packages permission from any project role assignments held by users who should not have broad visibility into work package metadata - this prevents exploitation but will also block legitimate share-viewing workflows for those users, so scope the revocation carefully to roles that do not require it. There is no known endpoint-level workaround that preserves the feature while restricting the over-broad disclosure without a code change.