OpenProject 17.1.3
Release date: 2026-03-16
We released OpenProject OpenProject 17.1.3. The release contains several bug fixes and we recommend updating to the newest version. Below you will find a complete list of all changes and bug fixes.
Security fixes
CVE-2026-32698 - SQL Injection via Custom Field Name can be chained to Remote Code Execution
OpenProject is 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.
This vulnerability was reported by user sam91281 as part of the YesWeHack.com OpenProject Bug Bounty program, sponsored by the European Commission.
For more information, please see the GitHub advisory #GHSA-jqhf-rf9x-9rhx
CVE-2026-32703 - Repository files are served with the MIME type allowing them to be used to bypass Content Security Policy
When using the Repositories module in a project, it was possible to access the raw files via the browser with a URL like /projects/{project}/repository/revisions/{commit_id}/raw/{file}.js.raw. For those files, the MIME type was detected via the filename extension. For JavaScript and CSS files those files were then served from the same domain name as the application with the correct MIME type for active content and could be used to bypass the Content Security Policy. Together with other areas, where unsanitized HTML was served, this allowed persistent XSS attacks.
The MIME type detection for Repository files has been removed and files are served as application/octet-stream which will block their execution via the Content Security Policy.
Two places that could be used to abuse this vulnerability have been fixed:
The Repositories module did not properly escape filenames displayed from repositories. This allowed an attacker with push access into the repository to create commits with filenames that included HTML code that was injected in the page without proper sanitation. This allowed a persisted XSS attack against all members of this project that accessed the repositories page to display a changeset where the maliciously crafted file was deleted.
When a work package name contains HTML content and the work package is attached to a meeting, the work package name is rendered in the activities feed without proper sanitation.
All of those vulnerabilities were reported by user sam91281 as part of the YesWeHack.com OpenProject Bug Bounty program, sponsored by the European Commission.
For more information, please see the GitHub advisory #GHSA-p423-72h4-fjvp