docs/release-notes/17-4-0/README.md
Release date: 2026-04-23
We released OpenProject 17.4.0. The release contains several bug fixes and we recommend updating to the newest version. In these Release Notes, we will give an overview of important feature changes. At the end, you will find a complete list of all changes and bug fixes.
<!-- BEGIN CVE AUTOMATED SECTION -->When an attacker knew the secret key base that the application used to derive internal keys from, they could construct encrypted cookies that on the server side were decoded using Object Marshalling which allowed the attacker to execute almost arbitrary ruby code within the container, up to a complete remote code execution. This was especially present in Docker containers that shipped with a default value as the secret key base, when it was not manually overwritten, as mentioned in the documentation.
As a fix, the docker containers now validate that a proper SECRET_KEY_BASE environment variable is set Otherwise the application aborts the boot process with an error message. The documentation has been updated to make it even clearer, that the SECRET_KEY_BASE env variable must be set. And the decoding of the encrypted cookies has been updated to use JSON encoding instead of Object Marshalling.
Administrators that have not set a **SECRET_KEY_BASE** environment before need to set one now. Otherwise the application will not boot.
This will force all users using 2 factor authentication to authenticate on their next login, even if they have saved a cookie to skip 2FA for the next 14 days.
Guides to setting this for your installation method:
Packaged installations: This secret is already being generated automatically. You are not affected
Docker-compose: Add SECRET_KEY_BASE=<your-secret-key-base> to your .env file. See https://www.openproject.org/docs/installation-and-operations/installation/docker-compose/ for more information
Docker All-in-One: Add SECRET_KEY_BASE=<your-secret-key-base> to your docker run call. See https://www.openproject.org/docs/installation-and-operations/installation/docker/ for more information
Helm-charts: Version 13.5.4 and higher of the helm chart will automatically create a kubernetes secret using a random string.
If you have not used a SECRET_KEY_BASE env previously, we recommend updating to the newest helm version.
If you have an existing strong secret, you are safe already and nothing needs to be done. You can optionally place it as the existingSecret as shown in the Helm chart documentation to use the conventional secret to pass it into the specs.
This vulnerability was responsibly reported by GitHub user hkolvenbach.
For more information, please see the GitHub advisory #GHSA-r85r-gjq2-f83r
OpenProject's rich text (markdown) rendering pipeline uses Sanitize::Config::RELAXED[:css] for inline style sanitization. This configuration permits essentially all CSS properties in style attributes on permitted HTML elements (figure, img, table, th, tr, td).
This allows any authenticated user with write access to formattable text fields (work package descriptions, comments, project descriptions, news) to inject CSS that:
This vulnerability was reported by GitHub user NOTTIBOY137
For more information, please see the GitHub advisory #GHSA-j9q2-49mp-hmq5
The web application's meetings filter feature leaks whether a given user ID corresponds to a valid account and discloses the user's full name, allowing an attacker to enumerate all existing user accounts by probing user IDs and observing differences in the server response.
This vulnerability was reported by user tuannq_gg as part of the YesWeHack.com OpenProject Bug Bounty program, sponsored by the European Commission.
For more information, please see the GitHub advisory #GHSA-x7j3-cfgf-7mc4
OpenProject exposes a document update endpoint used to modify existing documents. The target document is loaded with visibility checks and then updated .
During update, attacker-controlled attributes are applied to the persisted record before authorization is enforced. As a result, a user without :manage_documents in the source project can move and modify foreign project documents by setting project_id in a single PATCH request.
This vulnerability was reported by 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-mqvv-5mvc-7pg7
A password validation flaw in the change password behavior allows attackers to change a user's password only with an active session takeover.
This vulnerability was reported by user herdiyanitdev as part of the YesWeHack.com OpenProject Bug Bounty program, sponsored by the European Commission.
For more information, please see the GitHub advisory #GHSA-px7f-cj9f-7m4m
A Missing Authorization vulnerability exists in OpenProject's CostReportsController. The rename and update actions allow any authenticated user to modify the name, filters, and grouping of any Public cost report in the system without verifying ownership or permission level.
An attacker who discovers or guesses a public report's numeric ID can rename or overwrite its filter configuration without any warning to the report's owner.
This vulnerability was reported by user herdiyanitdev as part of the YesWeHack.com OpenProject Bug Bounty program, sponsored by the European Commission.
For more information, please see the GitHub advisory #GHSA-c767-34gh-gh2h
The GET /api/v3/shares endpoint returns share details for ALL work packages in a project to any user with the view_shared_work_packages permission. The authorization check operates at the project level only — it does not verify the requesting user can actually view each individual shared work package.
This vulnerability was reported by GitHub user DAVIDAROCA27.
For more information, please see the GitHub advisory #GHSA-cfg3-f34w-9xx5
The GET /api/v3/relations endpoint allows any authenticated user to retrieve relations — and the subject (title) of work packages they have no permission to view — by supplying an arbitrary work package ID in the involved, fromId, or toId filter. This bypasses the Relation.visible scope due to a flawed performance optimization in RelationQuery.
This vulnerability was reported by GitHub user mlgzackfly.
For more information, please see the GitHub advisory #GHSA-p9gq-hrgh-2645
<!-- END CVE AUTOMATED SECTION -->Take a look at our release video showing the most important features introduced in OpenProject 17.4.0:
With the release of OpenProject 17.4, the Jira Migrator is now available without a feature flag and can be used directly. While the feature is not yet fully complete and still in Beta, it is ready to be tested – preferably first in a non productive environment. We encourage users to try the Jira Migrator and share their feedback.
[!NOTE] If you would like to share anonymized data from your Jira Migrator usage to support our development team, please reach out to us. We are happy to sign an NDA to ensure confidentiality.
It is now possible to migrate basic custom fields from Jira to OpenProject. This includes custom fields that have a corresponding field type in OpenProject, such as text, numbers, dates, and select lists. This helps transfer existing data and maintain a consistent work package structure after migration.
We will continue to expand support for additional custom field types in future releases to enable even more complete migrations.
See our documentation to learn more about the OpenProject Jira Migrator.
Backlog buckets are now available. They allow you to group work packages within the backlog into clearly structured lists. Each bucket can be named individually and helps organize large backlogs into manageable sections, making it easier to prioritize work packages and focus on specific groups.
Work packages can be moved between buckets, sorted within each bucket, and adjusted as priorities change.
Learn more about Backlog and sprints with OpenProject.
Backlog cards are now fully draggable, making it easier to move work packages during backlog refinement and sprint planning. At the same time, you can still open a work package in the side panel with a single click to quickly view and edit details without losing context.
You can now start and complete sprints directly from the sprint header by clicking the respective buttons. This makes these actions easier to access and provides a clearer overview of the sprint status.
[!NOTE] Please note that these buttons represent actions you can take, such as starting or completing a sprint, and do not indicate the current sprint status.
You can now copy workflow settings from one role to other roles, using a dedicated dialog. This makes it easier to apply consistent workflows across roles and reduces manual configuration effort.
See our system admin guide to learn about work package workflows in OpenProject.
A new "My meetings" widget shows your upcoming meetings directly on the Home and Project Overview pages. It displays the most relevant information at a glance, helping you stay on top of your schedule and quickly access upcoming meetings.
Please note that with this update, the Users widget on the Home page (showing newest registered users in the instance) has been removed and replaced by the new "My meetings" widget.
The default modules enabled in demo and trial projects have been updated. Budgets and Calendars are now enabled by default in the Demo project. Meetings are now enabled by default in the Scrum project. Please note that for some of the newly enabled modules, example content may not yet be available.
displayId field for rendering work package identifiers instead of idAs part of our efforts to simplify migrations from Jira to OpenProject, the next release (17.5) will introduce project-based work package identifiers such as #ABC-123. Developers of API V3 clients can and should already prepare for this change now. With the current release (17.4), the API V3 exposes a dedicated field, displayId, which contains the work package’s current identifier. API clients should use this field whenever rendering links or captions intended for human users.
Starting with 17.5, administrators will be able to switch from the current numeric identifiers, such as #12345, to project-based identifiers like #ABC-123. The displayId field will return the correct identifier format depending on how the instance is configured.
If you are building or maintaining an application that uses the OpenProject API V3, we recommend using displayId instead of id when displaying work package identifiers.
The id field will continue to return the internal database ID and should still be used for API requests such as filtering.
For more information about project-based work package identifiers in OpenProject, see the Epic currently being developed by our team
New APIv3 endpoints are now available for meetings and recurring meetings. These include support for managing agenda items, sections, and occurrences, enabling full access to meeting data via the API.
You can now configure webhook secrets for GitHub and GitLab integrations. This improves the security of incoming webhook requests.
<!--more-->A very special thank you goes to Helmholtz-Zentrum Berlin, City of Cologne, Deutsche Bahn and ZenDiS for sponsoring released or upcoming features. Your support, alongside the efforts of our amazing Community, helps drive these innovations. Also a big thanks to our Community members for reporting bugs and helping us identify and provide fixes. Special thanks for reporting and finding bugs go to Andreas H., Madhu Reddy, and Anna Mund.
We also want to thank Community contributor K. Uihlein for contributing to our documentation of the OpenProject GitLab Integration. This is much appreciated.
Last but not least, we are very grateful for our very engaged translation contributors on Crowdin, who translated quite a few OpenProject strings! This release we would like to particularly thank the following users:
Would you like to help out with translations yourself? Then take a look at our translation guide and find out exactly how you can contribute. It is very much appreciated!