OpenProject EUVD-2026-51281

Exploitation requires an authenticated session with any non-admin OpenProject user account (PR:L per CVSS vector). The target instance must have at least one UserCustomField or GroupCustomField configured with the admin_only flag - instances without such fields are not meaningfully exposed. The attack is conducted entirely over the network via the standard REST API; no special network position, local access, or elevated privileges are needed. Exploitation is bounded in scope to reading option labels (the text values of dropdown choices) for admin_only custom fields only - it does not expose values assigned to users or groups, session tokens, credentials, or any other application data. Accounts without any API reachability (blocked at network perimeter) cannot exploit this remotely, but that configuration is not a default hardening measure in OpenProject.

The provided CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N and score of 4.3 (Medium) accurately represent real-world risk. Network accessibility with low complexity and no user interaction means any authenticated user can exploit this with a simple HTTP loop over sequential IDs - no special tooling required. However, the confidentiality impact is narrow: only the option labels (dropdown values) of admin_only custom fields are exposed, not user-assigned field values, credentials, or other application data. No KEV listing and no known POC temper urgency; EPSS data was not provided in the input. The real priority depends on what admin_only custom fields contain - instances using them for sensitive organizational metadata (salary tiers, internal HR categories, confidential group names) face meaningful information disclosure risk; instances with no admin_only user or group custom fields have negligible exposure. This is a genuine authorization bypass worth patching promptly but does not represent an emergency response scenario for most deployments.

An authenticated project member sends sequential GET requests to /api/v3/custom_options/1 through /api/v3/custom_options/N using only a valid session token and standard HTTP tooling such as curl or a simple script. For each ID belonging to an admin_only UserCustomField or GroupCustomField, the API returns HTTP 200 with the option label in the response body rather than the expected HTTP 404, allowing the attacker to reconstruct the full list of restricted dropdown values - such as internal HR tier names or confidential group classifications - without any administrative privileges. No exploit code is publicly known, but the attack requires no special knowledge beyond sequential integer enumeration.