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

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

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

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

OpenProject CVE-2026-67528

EUVD-2026-51281 MEDIUM

Incorrect Authorization (CWE-863)

2026-07-30 GitHub_M

Authentication Bypass Openproject

4.3

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

4.3 MEDIUM

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

vuln.today AI

4.3 MEDIUM

Network API requires only a valid user session (PR:L); exposure is limited to admin_only field option labels (C:L); no integrity or availability impact applies.

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

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/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

Low

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jul 30, 2026 - 20:03 EUVD

Source Code Evidence Fetched

Jul 30, 2026 - 19:53 vuln.today

Analysis Generated

Jul 30, 2026 - 19:53 vuln.today

DescriptionCVE.org

OpenProject is open-source, web-based project management software. Prior to 17.6.0, GET /api/v3/custom_options/:id resolved CustomOption records by global numeric id and allowed UserCustomField and GroupCustomField options without checking visible(current_user), so authenticated non-admin users could enumerate sequential custom option ids and read labels belonging to admin_only user or group custom fields. This issue is fixed in 17.6.0.

AnalysisAI

Incorrect authorization in OpenProject's REST API before 17.6.0 allows any authenticated non-admin user to enumerate sequential custom option IDs via GET /api/v3/custom_options/:id and read option labels belonging to admin_only UserCustomField and GroupCustomField records. The root cause, confirmed by commit diff, is that the authorization handler returned true unconditionally for these two custom field types instead of invoking the visible(current_user) scope filter. No public exploit code exists and this is not listed in CISA KEV, but the low attack complexity and standard network API surface make this trivially exploitable by any account holder on an affected instance.

Technical ContextAI

OpenProject exposes a Grape-based REST API at /api/v3. The custom_options_api.rb endpoint resolves CustomOption records by sequential global integer ID - a design that enables enumeration attacks when authorization is incomplete. The authorization function authorize_custom_option_visibility dispatches on custom field type, but the prior when UserCustomField, GroupCustomField branch returned true unconditionally, bypassing the .visible(current_user) ActiveRecord scope that enforces admin_only visibility. CWE-863 (Incorrect Authorization) applies precisely: an authorization decision point existed in the code but was implemented to always permit access for these two types. The fix adds authorized_user_custom_option and authorized_group_custom_option helper methods that query .visible(current_user).exists? on the parent custom field and raise API::Errors::NotFound (returning HTTP 404) if the field is not visible to the caller. The CPE string cpe:2.3:a:opf:openproject:*:*:*:*:*:*:*:* indicates all versions of the opf/openproject application are in scope up to the fix.

RemediationAI

Upgrade to OpenProject 17.6.0 or later, which incorporates the fix from commit a13fa079bc8040449570384c19f2d98f637179f1 adding proper visible(current_user) authorization to the custom_options API endpoint. The release is available at https://github.com/opf/openproject/releases/tag/v17.6.0 and the vendor advisory at https://github.com/opf/openproject/security/advisories/GHSA-wr3w-qchj-p4cm. As a compensating control prior to patching, administrators can restrict access to the /api/v3/custom_options/* endpoint at the network or reverse-proxy layer to trusted internal IP ranges, though this may break legitimate API integrations and automation that rely on this endpoint. Alternatively, converting or removing admin_only custom field option labels to non-sensitive values reduces information exposure risk without addressing the underlying authorization flaw. Neither workaround is a substitute for upgrading.