CVE-2026-67528 in OpenProject
Summary
by MITRE • 07/30/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/30/2026
This vulnerability affects OpenProject versions prior to 17.6.0 and represents a critical access control flaw that undermines the software's security model. The issue stems from improper authorization checks within the API endpoint GET /api/v3/custom_options/:id which handles retrieval of CustomOption records. The system failed to validate whether the requesting user had appropriate permissions to access specific custom field options, allowing authenticated users to bypass normal access restrictions through predictable numeric ID enumeration.
The technical flaw manifests in the application's handling of custom option resolution where it accepts global numeric identifiers without proper authorization verification. This creates a privilege escalation vector through information disclosure, as non-admin users can systematically enumerate sequential IDs and access labels associated with custom fields that should be restricted to administrators. The vulnerability specifically impacts UserCustomField and GroupCustomField options, which are designed to contain sensitive administrative data but were accessible through this unauthenticated path.
Operationally, this issue enables attackers to gather intelligence about the system's internal structure and administrative configurations. By sequentially accessing custom option IDs, authenticated users can discover the existence of administrative custom fields, their associated labels, and potentially infer organizational structures or security practices. This reconnaissance capability significantly weakens the overall security posture by providing attackers with valuable information for further exploitation attempts. The vulnerability is particularly concerning as it allows for passive information gathering without requiring elevated privileges.
The fix implemented in version 17.6.0 addresses this through proper authorization checks that validate current_user permissions against the requested custom option records. This aligns with security best practices outlined in CWE-284 Access Control Checks and follows ATT&CK technique T1213 Data from Information Repositories by preventing unauthorized access to administrative data repositories. Organizations should immediately upgrade to version 17.6.0 or later to remediate this vulnerability, as the information disclosure could enable more sophisticated attacks including targeted privilege escalation attempts.
The root cause of this vulnerability demonstrates inadequate input validation and access control implementation in the API layer. The system's failure to enforce proper authorization boundaries when resolving global identifiers represents a classic example of insufficient privilege checking that violates fundamental security principles. This issue highlights the importance of implementing robust access control mechanisms at all levels of application architecture, particularly within API endpoints that handle sensitive configuration data. Security teams should conduct thorough audits of similar API endpoints to ensure proper authorization checks are implemented across the entire codebase.