CVE-2026-55095 in OpenProject
Summary
by MITRE • 08/20/2026
OpenProject is open-source, web-based project management software. In version 17.5.1 and earlier, an authenticated non-admin project member can request the inplace-edit dialog for a raw custom_field_ project attribute. The dialog path resolves the project custom field by its raw identifier without enforcing the normal admin_only visibility scope and renders the stored custom-field comment in read-only mode. This discloses hidden comment text but does not disclose the custom-field value or permit writes or mutation. This issue is reported as fixed in version 17.6.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
OpenProject serves as a prominent open-source, web-based platform for project management, facilitating collaboration through features such as task tracking, time reporting, and document sharing. Within this ecosystem, custom fields allow organizations to tailor the software to specific workflow requirements by adding unique data attributes to projects or issues. These custom fields often contain sensitive information that may require restricted access based on user roles within a project. The vulnerability identified in versions 17.5.1 and earlier pertains specifically to the handling of these custom field attributes, particularly when accessed via the inplace-edit dialog interface by authenticated users who do not hold administrative privileges for the specific project.
The core technical flaw lies in how the application resolves and renders raw custom_field identifiers within the user interface logic. When an authenticated non-administrator attempts to access the inplace-edit dialog for a raw custom field, the system fails to enforce the visibility scope that is normally applied during standard interactions. Specifically, while administrative fields are typically restricted from view or modification by regular members, this particular code path bypasses those checks when resolving the project custom field by its raw identifier. Consequently, the interface proceeds to render the stored comment associated with that custom field in a read-only mode. This behavior effectively exposes data that was intended to be hidden from non-administrative users, constituting an information disclosure vulnerability where sensitive contextual notes or metadata attached to otherwise restricted fields become visible through this specific UI pathway.
From an operational impact perspective, while the vulnerability allows for the unauthorized viewing of custom field comments, it is important to note the limitations of the exploit vector. The flaw does not permit the reading of the actual value stored within the custom field itself, nor does it allow any write operations or mutations to the data. This means that attackers cannot alter project configurations or inject malicious content through this specific route. However, the disclosure of hidden comment text can still lead to significant security implications depending on the nature of the comments. If these comments contain internal discussions, strategic plans, credentials embedded in notes, or other confidential organizational intelligence, their exposure compromises the confidentiality aspect of the CIA triad for those specific data points. This could aid an attacker in further reconnaissance or social engineering efforts by revealing insights into project priorities and internal communications that were meant to be restricted.
This vulnerability aligns with CWE-200, which classifies Information Exposure, as it involves the unintended disclosure of information to unauthorized actors. Furthermore, from a tactical perspective within the MITRE ATT&CK framework, this behavior is consistent with techniques related to Discovery, specifically those involving the enumeration of sensitive data or configuration details through application logic flaws rather than direct system exploitation. The attack vector requires authentication and specific user privileges that are below administrative level but sufficient to trigger the flawed UI component, placing it within the context of authenticated privilege escalation via information leakage rather than full access compromise.
To mitigate this risk, organizations running OpenProject must ensure they have upgraded to version 17.6.0 or later, where this logic error has been corrected by enforcing proper visibility checks regardless of how the custom field is referenced in the UI layer. For environments that cannot immediately upgrade due to compatibility constraints with other plugins or integrations, temporary mitigations should focus on restricting access to project members who might attempt such requests and closely monitoring logs for unusual patterns involving raw custom field identifiers. Additionally, security teams should audit existing custom fields to ensure that no critical sensitive data is stored in comments attached to restricted fields, thereby reducing the potential impact of similar logic flaws in other components or future versions until a full patch can be applied. Regular updates and adherence to vendor release notes are essential practices for maintaining the integrity of project management infrastructure against evolving application-level vulnerabilities.