Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate with any valid user account
-
DeliverySend sequential GET /api/v3/custom_options/:id requests
-
ExploitIdentify 200 responses corresponding to admin_only field options
-
ExecutionExtract option labels from JSON response bodies
-
ImpactReconstruct admin_only custom field metadata
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | 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. |
| Impact | 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. |
| Exploit ScenarioDerived | 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. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 30, 2026
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.
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.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
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.
Know when Openproject gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
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.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Openproject
View allA SQL injection vulnerability in the activities API in OpenProject before 8.3.2 allows a remote attacker to execute arbi
OpenProject is web-based project management software. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
OpenProject is open source project management software. Rated medium severity (CVSS 6.5), this vulnerability is remotely
Authenticated remote code execution affects the official openproject/openproject Docker image, which ships with a hardco
Cross-project folder hijacking in OpenProject before 17.3.3 and 17.4.1 lets a project-admin abuse an insecure direct obj
SQL injection in OpenProject's baseline-comparison (timestamps) functionality lets an authenticated, low-privileged user
OpenProject has a CVSS 9.9 command injection vulnerability allowing authenticated users to execute OS commands on the pr
Remote code execution in OpenProject before 17.3.3 and 17.4.1 arises from cache store poisoning, allowing an attacker wi
OpenProject, a web-based project management platform, contains a critical SQL injection vulnerability in versions prior
OpenProject (before 16.6.4) has a local file read vulnerability through SVG-based ImageMagick exploitation in the PDF ex
OpenProject's Repositories module contains a stored cross-site scripting (XSS) vulnerability that occurs when displaying
Token decryption in OpenProject 17.0 allows authenticated attackers to intercept and decrypt 24-hour authentication toke
EUVD-2026-51281
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB