CVE-2026-67529 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/time_entries and GET /api/v3/cost_entries rendered _links.workPackage.title and _links.workPackage.href through associated_resource in modules/costs/lib/api/v3/time_entries/time_entry_representer.rb and modules/costs/lib/api/v3/cost_entries/cost_entry_representer.rb without checking WorkPackage.visible or view_work_packages, allowing users with view_time_entries or view_cost_entries to read private work package subjects and ids. This issue is fixed in 17.6.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/30/2026
This vulnerability exists within OpenProject's API v3 implementation where time entries and cost entries endpoints fail to properly validate access controls before exposing sensitive work package information. The flaw manifests in two specific files: modules/costs/lib/api/v3/time_entries/time_entry_representer.rb and modules/costs/lib/api/v3/cost_entries/cost_entry_representer.rb where the system renders _links.workPackage.title and _links.workPackage.href attributes through an associated_resource mechanism without first verifying that the requesting user possesses adequate permissions. This represents a classic privilege escalation vulnerability that violates fundamental security principles of least privilege and access control validation.
The technical implementation flaw stems from inadequate authorization checks within the API response generation layer. When users with only view_time_entries or view_cost_entries permissions make requests to GET /api/v3/time_entries or GET /api/v3/cost_entries endpoints, the system incorrectly assumes that access to time or cost entries inherently grants access to the associated work package details. This misconfiguration creates an information disclosure scenario where sensitive metadata including work package subjects and identifiers can be accessed without proper authorization. The vulnerability aligns with CWE-284 Access Control Issues, specifically manifesting as improper access control validation in API response handling.
The operational impact of this vulnerability is significant for organizations relying on OpenProject for project management, as it allows unauthorized users to discover private work package information that may contain sensitive project details, resource allocations, or strategic planning data. Attackers could exploit this to gather intelligence about ongoing projects, identify high-value targets within the organization, or correlate information across different project components. This exposure directly violates the principle of separation of duties and can lead to information leakage that compromises business security and competitive advantage. The vulnerability is particularly concerning in enterprise environments where project management systems contain confidential data about upcoming products, client information, or internal strategic initiatives.
This issue falls under the ATT&CK technique T1068 Valid Accounts for privilege escalation and information gathering through API abuse. Organizations should implement immediate mitigations including upgrading to OpenProject version 17.6.0 which addresses this vulnerability through proper access control validation. Additionally, security teams should review their API endpoint configurations and implement comprehensive access control policies that enforce proper authorization checks before exposing related resource metadata. Regular security assessments of API endpoints and implementation of automated monitoring for unauthorized data access patterns can help detect similar issues in other applications.
The vulnerability demonstrates the critical importance of implementing defense-in-depth strategies for API security, particularly around resource linking and cross-component access control validation. Organizations should ensure that all API responses properly validate user permissions against each component being rendered, rather than assuming that access to one resource type grants access to related resources. This incident underscores the necessity of following secure coding practices that incorporate proper authorization checks at every level of application logic, especially in systems where multiple resource types are interconnected through API relationships and metadata exposure.