CVE-2026-32698 in openproject
Summary
by MITRE • 03/19/2026
OpenProject is an open-source, web-based project management software. Versions prior to 16.6.9, 17.0.6, 17.1.3, and 17.2.1 are vulnerable to an SQL injection attack via a custom field's name. When that custom field was used in a Cost Report, the custom field's name was injected into the SQL query without proper sanitation. This allowed an attacker to execute arbitrary SQL commands during the generation of a Cost Report. As custom fields can only be generated by users with full administrator privileges, the attack surface is somewhat reduced. Together with another bug in the Repositories_module, that used the project identifier without sanitation to generate the checkout path for a git repository in the filesystem, this allowed an attacker to checkout a git repository to an arbitrarily chosen path on the server. If the checkout is done within certain paths within the OpenProject application, upon the next restart of the application, this allows the attacker to inject ruby code into the application. As the project identifier cannot be manually edited to any string containing special characters like dots or slashes, this needs to be changed via the SQL injection described above. Versions 16.6.9, 17.0.6, 17.1.3, and 17.2.1 fix the issue.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/23/2026
The vulnerability described in CVE-2026-32698 represents a critical security flaw in OpenProject software that combines multiple attack vectors to enable remote code execution. This vulnerability affects versions prior to 16.6.9, 17.0.6, 17.1.3, and 17.2.1, demonstrating how interconnected security issues can create severe exploitation pathways within web applications. The primary vulnerability manifests as an SQL injection attack that occurs when custom field names are processed within Cost Report generation functionality, creating a direct pathway for attackers to manipulate database queries through unsanitized input.
The technical implementation of this vulnerability follows a classic SQL injection pattern where user-controllable data flows directly into database queries without proper sanitization or parameterization. The custom field name parameter becomes the injection point when used in Cost Report generation, allowing attackers to craft malicious SQL commands that execute with the privileges of the database user. This SQL injection vulnerability specifically targets the custom field processing logic within the reporting module, where the field name is directly embedded into SQL query construction without adequate input validation or escaping mechanisms.
While the vulnerability requires administrative privileges to create custom fields, this limitation does not prevent exploitation as demonstrated by the chained attack scenario. The attack chain extends beyond the initial SQL injection to include a secondary vulnerability in the repositories module that allows arbitrary file system path manipulation. The combination of these vulnerabilities creates a sophisticated attack pathway where an attacker first uses the SQL injection to modify project identifiers, then leverages the unsanitized project identifier in the repository checkout functionality to place git repositories in arbitrary locations on the server filesystem.
The exploitation of this chained vulnerability demonstrates how seemingly isolated security issues can combine to create significant impact. The repository checkout vulnerability specifically targets the project identifier parameter, which when unsanitized, allows attackers to specify arbitrary paths for git repository checkouts. When these repositories are placed within specific application directories, subsequent application restarts trigger code execution through Ruby code injection. This represents a privilege escalation scenario where administrative database access can be leveraged to achieve full application compromise through file system manipulation and code injection.
The vulnerability aligns with CWE-89 which specifically addresses SQL injection flaws, and follows patterns commonly identified in ATT&CK framework under T1078 for valid accounts and T1566 for social engineering. The attack requires a specific sequence of steps involving database manipulation followed by file system exploitation, making it more sophisticated than typical single-vector attacks. The requirement for administrative privileges to initially create custom fields provides some defense in depth, but does not prevent exploitation when combined with the SQL injection vulnerability that allows modification of system parameters. The fix implemented in versions 16.6.9, 17.0.6, 17.1.3, and 17.2.1 addresses both the SQL injection in custom field processing and the unsanitized project identifier in repository checkout functionality, demonstrating the importance of comprehensive input validation across all application modules. Organizations should prioritize immediate patching of affected versions to prevent exploitation, as the chained nature of this vulnerability makes it particularly dangerous for unpatched systems.