CVE-2026-47193 OpenProject Journal Diff Information Disclosure

Technical summary

CVE-2026-47193 is a broken access control vulnerability in OpenProject's journal diff endpoint. The endpoint returns historical field value changes without enforcing object-level or field-level visibility controls, allowing an unauthenticated remote actor to retrieve sensitive field change history. The vulnerability stems from missing authorization checks on the diff retrieval logic, permitting disclosure of fields that should be hidden based on project permissions or field configuration. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects network-based exploitation requiring no authentication or user interaction, with high confidentiality impact and no integrity or availability impact.

Business impact

Organizations using vulnerable OpenProject instances face exposure of confidential project management metadata, including task descriptions, internal notes, status transitions, and other field changes that may contain business strategy, financial figures, personnel information, or other sensitive context. The leakage occurs without user awareness or audit trail alerts, allowing silent reconnaissance of project history. For teams managing customer projects, contracts, or regulatory workflows, this disclosure can breach client confidentiality, violate data protection obligations, or provide competitive intelligence to unauthorized parties. The impact is particularly severe in industries handling regulated data or requiring strong project confidentiality (legal, finance, healthcare, consulting).

Affected systems

OpenProject versions prior to 17.3.3 (in the 17.3.x branch) and prior to 17.4.1 (in the 17.4.x branch) are vulnerable. Self-hosted and cloud-deployed instances using these versions are affected. The vulnerability does not require specific plugins or configuration—any OpenProject deployment with journal/diff functionality accessible over the network is at risk. Environments where OpenProject is internet-facing or accessible from untrusted networks face immediate exposure.

Exploitability

Exploitability is straightforward and requires no special privileges. The attack is a simple HTTP request to the journal diff endpoint with no authentication required. An attacker can enumerate project IDs and iterate through field changes to extract historical data. No user interaction, complex configuration, or advanced tools are needed. The low attack complexity and lack of authentication barriers make this vulnerability trivial to weaponize at scale. The primary barrier is discovering accessible OpenProject instances and identifying valid project or object identifiers.

Remediation

Upgrade OpenProject to version 17.3.3 or later (for 17.3.x branch) or 17.4.1 or later (for 17.4.x branch) as soon as possible. These versions implement proper visibility checks on the journal diff endpoint to ensure users can only retrieve historical data for objects and fields they are authorized to view. Review instance logs for evidence of unauthorized access to the diff endpoint during the vulnerability window. In environments where immediate patching is not possible, restrict network access to the OpenProject instance to trusted internal networks only, and disable or restrict the journal diff endpoint via reverse proxy rules if the application supports such configuration.

Patch guidance

Download and apply the fixed versions from the official OpenProject repository or release channels. Version 17.3.3 addresses the vulnerability in the 17.3.x line; 17.4.1 does the same for 17.4.x. Verify that the patched version is running by checking the application version string in the web interface or API. Test access to the journal diff endpoint after patching to confirm that field visibility rules are now enforced. If your deployment is behind a load balancer or in a clustered configuration, ensure all nodes are updated before completing remediation. Back up your database before applying patches to enable safe rollback if needed.

Detection guidance

Monitor access logs for requests to endpoints containing 'journal' or 'diff' patterns, particularly those using GET requests without authentication or with low-privilege accounts. Search for requests with multiple sequential project or object ID parameters, indicating enumeration attempts. Implement or review Web Application Firewall (WAF) rules to flag or block journal diff requests from unexpected sources. Log analysis should focus on time windows when the vulnerability was present and known; cross-reference with access patterns from external IP addresses or high-volume request sources. Use OpenProject's audit logging (if enabled) to identify which journal endpoints were accessed and by whom during the vulnerable period.

Why prioritize this

This vulnerability merits immediate priority despite not yet appearing in the CISA KEV catalog. The CVSS score of 7.5 (HIGH) reflects high confidentiality impact with zero barriers to exploitation—no authentication, no user interaction, and network-based access. The combination of ease of exploitation and sensitive nature of historical project data makes this a strong candidate for rapid exploitation by competitors, espionage actors, or opportunistic threat hunters. Organizations running internet-facing OpenProject instances should prioritize this ahead of lower-severity issues. The lack of KEV status does not diminish urgency; it indicates the community may not yet be tracking active exploitation, presenting a brief window for proactive patching.

Risk score, explained

The HIGH severity score reflects the high confidentiality impact (unauthorized access to sensitive historical field data) combined with zero authentication barriers and low attack complexity. The vulnerability does not permit modification or destruction of data, so integrity and availability impacts are none. The attack surface is broad—any OpenProject deployment exposes the endpoint. The technical controls bypass (missing visibility checks) combined with the sensitivity of project management data justify the 7.5 score. Organizations should treat this as equivalent to or exceeding many critical-rated vulnerabilities in impact, given the nature of exposed information and ease of exploitation.

Frequently asked questions