Openproject CVE-2026-34717

Exploitation requires authenticated access to the OpenProject instance with permissions to access the reporting module. The attacker must have at minimum a low-privilege user account (PR:L) capable of creating or editing custom reports that utilize filter operators. The vulnerability is present when the reporting module processes user-supplied filter criteria through the =n (equals-not) operator defined in modules/reporting/lib/report/operator.rb. No special network conditions, non-default configurations, or user interaction beyond the attacker's own authenticated session are required (AC:L/UI:N). Exploitation is limited by the authentication boundary - unauthenticated remote attackers cannot exploit this vulnerability. The database user account privileges under which OpenProject operates will constrain the scope of SQL injection impact, though default installations typically grant broad database permissions to support normal application operations.

Real-world risk assessment reveals a nuanced threat profile despite the critical CVSS 9.9 rating. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:C) indicates network-accessible exploitation with low complexity, but the PR:L requirement means attackers must possess valid authenticated credentials to the OpenProject instance. The changed scope and high integrity/availability impact ratings reflect database-level access that could affect the entire application. However, EPSS probability of 0.04% (13th percentile) suggests security researchers and mass-scanning adversaries are not prioritizing this vulnerability, likely due to the authentication barrier and the smaller attack surface of OpenProject compared to more ubiquitous platforms. No CISA KEV listing confirms this is not being exploited in widespread campaigns. The GitHub Security Advisory (GHSA-5rrm-6qmq-2364) as the disclosure source indicates responsible disclosure rather than in-the-wild discovery. Priority should be MODERATE for most organizations: the technical severity is real (authenticated users can compromise database integrity), but the practical exploitation landscape shows limited active threat activity. Organizations with untrusted authenticated users (public-facing instances, low-privilege guest accounts, or compromised credentials scenarios) should prioritize patching. Internal deployments with trusted user bases face lower immediate risk but should still patch within standard maintenance cycles given the low patch complexity.

An authenticated attacker with low-privilege access to an OpenProject instance navigates to the reporting module and crafts a custom report filter using the equals-not (=n) operator. By injecting SQL metacharacters and commands into the filter value field (for example: ' OR 1=1 UNION SELECT password FROM users --), the attacker bypasses input validation and causes the reporting module to execute arbitrary SQL against the backend database. The attacker extracts sensitive data including user credentials, project information, and system configuration, then modifies database records to escalate their own privileges to administrator level or plant backdoor accounts. With the scope change allowing impact beyond the reporting module boundary, the attacker leverages database access to compromise application integrity and availability.