OpenProject, an open-source web-based project management tool, suffers from a critical SQL injection vulnerability (CVE-2026-32698) in versions prior to 16.6.9, 17.0.6, 17.1.3, and 17.2.1. The flaw stems from improper neutralization of special characters in a custom field's name when generating Cost Reports. Since custom fields can only be created by users with full administrator privileges, the initial attack vector is limited to high-privilege users. However, once exploited, the attacker can execute arbitrary SQL commands on the backend database. This SQL injection can be leveraged to modify the project identifier in the database, bypassing restrictions on allowed characters. Combined with a separate vulnerability in the Repositories module, where the project identifier is used unsanitized to generate the git repository checkout path, an attacker can force the application to checkout repositories into arbitrary filesystem locations. If these locations are within the OpenProject application directory, the attacker can inject malicious Ruby code that executes upon application restart, effectively achieving remote code execution. The vulnerability affects multiple OpenProject versions as specified, and patches have been released in versions 16.6.9, 17.0.6, 17.1.3, and 17.2.1. The CVSS 3.1 score of 9.1 reflects the critical nature of this vulnerability, with network attack vector, low attack complexity, high privileges required, no user interaction, and a scope change leading to full confidentiality, integrity, and availability compromise. No public exploits have been reported yet, but the potential impact is severe.

The impact of CVE-2026-32698 is severe for organizations using vulnerable OpenProject versions. An attacker with administrator privileges can execute arbitrary SQL commands, potentially leading to data leakage, data manipulation, or deletion. The chained exploitation with the Repositories module vulnerability allows remote code execution on the server hosting OpenProject, which can lead to full system compromise. This can result in unauthorized access to sensitive project management data, disruption of project workflows, and potential lateral movement within the organization's network. Given OpenProject's use in managing critical projects and collaboration, such a compromise can affect confidentiality, integrity, and availability of project data and related systems. Organizations relying on OpenProject for regulated or sensitive environments face compliance and reputational risks. The requirement for administrator privileges reduces the attack surface but does not eliminate the risk, especially in environments with multiple administrators or compromised admin accounts.

Organizations should immediately upgrade OpenProject to versions 16.6.9, 17.0.6, 17.1.3, or 17.2.1, depending on their current version branch. Restrict administrator privileges strictly and audit existing custom fields for suspicious or malformed entries. Implement database activity monitoring to detect unusual SQL queries related to custom fields or project identifiers. Harden the server environment by limiting filesystem permissions to prevent unauthorized git repository checkouts outside intended directories. Employ application-level input validation and sanitization for all user-controlled inputs, especially custom fields and project identifiers. Regularly review and update OpenProject and all dependencies to incorporate security patches. Consider network segmentation and firewall rules to limit access to the OpenProject server. Finally, monitor logs for signs of exploitation attempts, such as unexpected SQL errors or unusual repository checkout paths.