CVE-2026-44734: OpenProject Missing Authorization in Cost Reports (6.5 CVSS)

Technical summary

The CostReportsController in OpenProject fails to enforce authorization checks in the rename and update action handlers. When an authenticated user submits a request to modify a public cost report, the application does not verify that the requester owns or has explicit permission to edit that report. The vulnerability is classified as CWE-862 (Missing Authorization). An attacker leveraging this flaw can iterate through or guess numeric report IDs to enumerate and modify public reports' metadata and query logic. No authentication bypass is required; the attacker must already have valid login credentials. The attack surface is limited to public reports, as the authorization gap does not affect private or restricted-access reports.

Business impact

In environments where OpenProject manages shared project financials and cost tracking, this vulnerability can result in corrupted or misleading cost reports. Malicious or negligent insiders can rename reports to obscure their origin, change filter criteria to hide costs, or reconfigure grouping to misrepresent spending patterns. This could compromise financial audit trails, delay decision-making based on inaccurate data, and create compliance concerns. Organizations relying on OpenProject for cost visibility across projects face potential data integrity incidents and operational confusion until affected reports are restored or verified.

Affected systems

OpenProject installations running versions before 17.3.2 (on the 17.3 branch) and before 17.4.0 (on the 17.4 branch, if applicable) are affected. The vulnerability is specific to the CostReportsController and impacts only public cost reports. Private reports and user-level access controls are unaffected. Any OpenProject deployment with authenticated users and public cost reports enabled is potentially at risk.

Exploitability

Exploitability is moderate. The attacker must possess valid login credentials—ruling out unauthenticated attacks—but no elevated privileges are required. Report IDs are numeric and potentially guessable or discoverable through interface inspection. The attack is straightforward: an authenticated user simply submits a rename or update request with a report ID they do not own. No special tools, scripts, or proof-of-concept exploitation is necessary; standard HTTP requests suffice. Organizations with strong access controls and smaller user bases will see lower practical risk; large organizations with many external collaborators face higher exposure.

Remediation

Apply OpenProject version 17.3.2 or 17.4.0, depending on your branch. Before patching, restrict report creation and public visibility settings to trusted users, or temporarily disable public cost report features if operationally feasible. Audit recent modifications to public cost reports to detect unauthorized changes. After patching, verify that authorization enforcement is active in your environment and re-enable public reporting features if they were disabled.

Patch guidance

Update OpenProject to 17.3.2 (if on the 17.3 branch) or 17.4.0 (if on the 17.4 branch). Consult the vendor's release notes and upgrade instructions before proceeding. Plan the upgrade during a maintenance window; cost reports will be inaccessible during the patch process. Test the patch in a non-production environment first to confirm that existing public reports and their access controls remain intact. After upgrade, verify that unauthenticated or unauthorized users can no longer modify reports owned by others.

Detection guidance

Monitor OpenProject access logs and application audit trails for repeated or anomalous rename and update requests to CostReportsController. Look for activities by users who do not typically interact with a given report. If audit logging is available, check the report modification history for unexpected ownership changes or filter alterations. Organizations with a SIEM or centralized logging platform should correlate OpenProject activity with user identity and report ownership metadata. Manual review of public cost report configurations against known owners can help identify tampering post-incident.

Why prioritize this

Although marked as MEDIUM severity (CVSS 6.5), this vulnerability carries elevated business risk in environments where cost reports inform financial or operational decisions. The ease of exploitation—no special tools required, only valid credentials—and the direct impact on data integrity justify prompt attention. Organizations managing distributed projects with shared cost tracking should prioritize patching within their next maintenance cycle. Smaller or non-financial-focused OpenProject deployments can defer patching slightly, but should not leave it unaddressed.

Risk score, explained

The CVSS 3.1 score of 6.5 reflects a network-accessible, low-complexity vulnerability (AC:L) that requires authentication (PR:L) but delivers high integrity impact (I:H) to public cost reports. There is no confidentiality or availability impact; the attacker cannot read sensitive data or delete reports, only modify their metadata and configuration. The scope is unchanged (S:U), meaning the impact is contained to the OpenProject application. This scores as MEDIUM, which appropriately captures the localized but meaningful damage that unauthorized report modifications can inflict on operational trust.

Frequently asked questions