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

CVE-2026-44736 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-44736?

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

OpenProject CVE-2026-44736

EUVD-2026-39876 MEDIUM

Information Exposure (CWE-200)

2026-06-26 GitHub_M

Information Disclosure Openproject Opf

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 API requires only an authenticated session (PR:L); confidentiality is High as restricted work package titles are exposed; no integrity or availability impact applies.

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:31 vuln.today

DescriptionCVE.org

OpenProject is open-source, web-based project management software. Prior to 17.4.0, the GET /api/v3/relations endpoint allows any authenticated user to retrieve relations - and the subject (title) of work packages they have no permission to view - by supplying an arbitrary work package ID in the involved, fromId, or toId filter. This bypasses the Relation.visible scope due to a flawed performance optimization in RelationQuery. This vulnerability is fixed in 17.4.0.

AnalysisAI

Unauthorized information disclosure in OpenProject before 17.4.0 allows any authenticated user to retrieve the subjects (titles) of work packages they have been explicitly denied access to, bypassing project-level visibility controls. The flaw exists in the GET /api/v3/relations REST API endpoint, where supplying arbitrary work package IDs to the involved, fromId, or toId filter parameters circumvents the Relation.visible scope due to a defective performance optimization in RelationQuery. No public exploit has been identified and the vulnerability is not listed in CISA KEV; however, the attack is trivially executable by any platform user with valid credentials, making it a meaningful risk in deployments handling sensitive or confidential project data.

Technical ContextAI

OpenProject is an open-source, Ruby on Rails-based project management platform exposing a REST API v3. The vulnerability resides in the RelationQuery component, specifically in how the Relation.visible scope is applied when processing filter parameters (involved, fromId, toId) on the GET /api/v3/relations endpoint. A performance optimization in this query path incorrectly skips or short-circuits the visibility check, allowing the ORM to return relation records - including the subject field of associated work packages - for items the requesting user has no view permission on. This is a classic CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) pattern: the authorization model is correctly defined at a higher level but is bypassed by an indirect, optimized code path that does not re-apply the same access controls. The affected CPE is cpe:2.3:a:opf:openproject:*:*:*:*:*:*:*:*, covering all versions prior to 17.4.0.

RemediationAI

Upgrade to OpenProject 17.4.0 or later, which corrects the flawed Relation.visible scope enforcement in RelationQuery - this is the only confirmed fix per the vendor advisory at https://github.com/opf/openproject/security/advisories/GHSA-p9gq-hrgh-2645. No patch version below 17.4.0 has been identified as containing a backport. As a compensating control prior to patching, administrators can apply network-layer access controls (WAF rules or reverse-proxy ACLs) to restrict access to the /api/v3/relations endpoint to trusted IP ranges or internal networks only; however, this will break legitimate API integrations relying on that endpoint and does not address the root authorization flaw for users already on the internal network. Reducing the number of active user accounts or enforcing least-privilege role assignments limits the pool of users who can exploit this but does not eliminate the vulnerability for any authenticated user.