docs/release-notes/17-6-0/README.md
Release date: 2026-07-08
We released OpenProject 17.6.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.
OpenProject 17.6 continues our vision of providing a comprehensive open source platform for project management and collaboration. The new XWiki integration brings project management and enterprise knowledge management closer together, while further improvements for Backlogs, Meetings, and administration help teams plan, collaborate, and execute their work more efficiently.
Take a look at our release video showing the most important features introduced in OpenProject 17.6.0:
[feature: xwiki_integration ]
OpenProject 17.6 introduces a new integration with XWiki, enabling teams to connect project work and documentation more closely. Together, OpenProject and XWiki provide an integrated open source solution for organizations looking to manage both projects and documentation on their own infrastructure. This makes the integration a natural choice for existing XWiki users and for organizations looking to replace proprietary combinations such as Jira and Confluence with a sovereign open source solution. Learn more about the motivation behind the integration and our collaboration with XWiki in our dedicated blog article.
To use the XWiki integration, system administrators first need to configure an external wiki as a Wiki provider in the OpenProject administration settings. See our system admin guide for more information.
Work packages now include a dedicated Wiki tab where users can view related wiki pages, create new pages, and link existing content from XWiki. This makes it easier to access relevant documentation directly from the work package where the work is planned and executed.
The integration also supports references between OpenProject and XWiki. Users can see which wiki pages reference a work package and insert links to wiki pages directly from descriptions, comments, and documents. This helps teams keep project work and documentation connected across both platforms.
[!NOTE] The XWiki integration is designed for organizations that require advanced wiki and documentation capabilities. It is available as an Enterprise add-on in the Corporate plan.
OpenProject's built-in Wiki module is also improved with OpenProject 17.6. It can be used through the new integration as internal provider. System administrators can activate this under Administration → Wikis → Internal wiki.
Users can link to all activated wikis, including internal ones, from the new Wikis tab in work packages. If disabled, the internal wiki is still available as a project module.
In future releases, we plan to further improve the internal wiki.
OpenProject 17.6 introduces sprint goals for Backlogs. When creating or editing a sprint, you can now define a sprint goal directly within the sprint settings.
The sprint goal is then displayed on the sprint header, making it visible to everyone working on the sprint.
OpenProject 17.6 introduces a new All sprints view in the Backlogs module. The new page provides an overview of all sprints in a project.
For each sprint, the overview displays key information such as its status, start and finish dates, and the number of assigned work packages.
OpenProject 17.6 introduces a new Backlog bucket attribute for work packages. If enabled for a work package type, users can view and manage backlog bucket assignments directly from the work package details.
Work packages can now be assigned to backlog buckets without navigating to the Backlogs module. Since a work package can only belong to either a sprint or a backlog bucket, selecting one will automatically remove the other assignment.
OpenProject 17.6 adds support for backlog buckets in work package tables. You can now add the Backlog bucket column to a work package table and use it to filter, sort, and group work packages.
This makes backlog bucket assignments visible in work package tables, allowing teams to organize, filter, and analyze backlog items more effectively.
[feature: sprint_sharing ]
Based on customer feedback, sprint sharing is now included in the Basic Enterprise plan instead of the Corporate plan. This makes the feature available to many more Enterprise customers.
Thank you to everyone who shared constructive feedback and helped shape this decision.
OpenProject 17.6 extends support for project-based (semantic) identifiers across exports. Semantic identifiers are now included consistently in:
This ensures that exported data uses the same identifiers that users see throughout OpenProject.
OpenProject 17.6 extends support for reserved project identifiers to project-based (semantic) identifiers. When a project identifier is renamed, previous identifiers remain reserved so that existing links and integrations continue to work.
Administrators can now unreserve old project-based (semantic) identifiers and make them available for reuse by other projects.
OpenProject 17.6 adds a new Convert to work package action for meeting agenda items. This allows users to turn agenda items directly into work packages without leaving the meeting.
The newly created work package remains linked to the agenda item, helping teams connect meeting discussions with follow-up work.
OpenProject 17.6 introduces project-specific cost type configuration. Project administrators can now control which cost types are available within each project.
To support this, project settings now include a new Time and costs section with a dedicated Cost types tab where available cost types can be configured.
OpenProject 17.6 improves CSV export security by escaping control characters in exported data. This helps prevent spreadsheet applications from interpreting exported values in unintended ways.
If you need to escape unmodified machine-readable CSV exports, you can disable this flag on the new Exports page Administration → System settings → Exports.
This change was originally reported as a security advisory on GitHub. We'd like to thank the contributors of this report, @GEONWOOHAN, @QwQP0, @minnnjuuu, and @dkstjwls06.
[feature: ldap_groups ]
OpenProject 17.6 extends LDAP group synchronization with support for group member attributes. Administrators can now configure synchronization based on attributes such as member or uniqueMember on LDAP groups, in addition to the existing memberOf lookup on user entries.
This improves compatibility with LDAP servers that do not maintain the memberOf attribute. Read more about synchronizing LDAP and OpenProject groups (Enterprise add-on)
To increase the security of OpenProject installations, we've added protections against server-side request forgery in previous releases of OpenProject. These prevent OpenProject from making network requests into private IP address space.
Starting with OpenProject 17.6, these protections also apply to web requests made by storage and wiki integrations. This means if you have a Nextcloud instance or an XWiki instance reachable via a private (i.e. not publicly routable) IP address, you need to add it to the SSRF allowlist to be able to keep the integration working. This is usually achieved by defining the following environment variable:
OPENPROJECT_SSRF_PROTECTION_IP_ALLOWLIST=2001:db8:100::/48
The list accepts one or multiple IP addresses or ranges (in CIDR notation) that shall be exempt from SSRF filtering.
OpenProject 17.6 introduces new endpoints for meeting outcomes, and changes the self link for all meeting related resources to be flat:
That means, some of the responses have changed:
POST/PATCH/DELETE /api/v3/meetings/:id/agenda_items) is no longer available,
they have been moved to the /api/v3/meeting_agendas/ respectively. The same is true for outcomes and sections.
This follows the APIv3 standards, and also fixes a bug related to the self link.
<!-- BEGIN SECURITY FIXES AUTOMATED SECTION -->An authenticated non-admin project member can request the inplace-edit dialog for a raw `custom_field_<id>` project attribute and retrieve the stored comment text for an `admin_only` project custom field.
The normal project custom-field visibility and writable scopes exclude the field for the same user, but the dialog path resolves the custom field by raw id and renders the stored custom-field comment in read-only mode.
The claim is intentionally narrow: this discloses custom-field comment text only. This report does not claim hidden custom-field value disclosure, writes, or mutation.
This vulnerability was reported as part of the YesWeHack.com OpenProject Bug Bounty program, sponsored by the European Commission.
For more information, please see the GitHub advisory #GHSA-63fg-pgqj-3qf8
PATCH /api/v3/work_packages/{id} accepts a writable _links.fileLinks payload property. The update path is missing the user_allowed_to_manage_file_links validation that exists on the create path, and the underlying setter resolves Storages::FileLink records by raw id with no scope. An authenticated user with only edit_work_packages (no manage_file_links, no membership in the victim project) can therefore:
detach (and, via dependent: :delete_all, hard-delete) every FileLink currently attached to a work package they can edit, and
re-parent any FileLink in the database, identified by its numeric id, onto an attacker-controlled work package, gaining read access to its metadata (origin filename, origin id, mime type) and removing it from the victim's work package.
This vulnerability was reported as part of the YesWeHack.com OpenProject Bug Bounty program, sponsored by the European Commission.
For more information, please see the GitHub advisory #GHSA-c6rc-4288-8p4f
GET /api/v3/time_entries and GET /api/v3/cost_entries are instance/workspace-scope collection endpoints. Each entry links a Work Package through the API representer's associated_resource :work_package, which renders _links.workPackage.title (the Work Package subject) and _links.workPackage.href (the sequential Work Package id) without checking that the linked Work Package is visible to the requesting user.
The collection is authorized only by the time-entry / cost-entry project permission (view_time_entries / view_cost_entries), which is an independent project permission with no view_work_packages dependency. A user holding view_time_entries (or view_cost_entries) in a project, but not view_work_packages, therefore reads the subjects and ids of Work Packages they cannot access through the direct Work Package API (which returns 404 for those WPs).
This is the same disclosure class already fixed in GHSA-g387-6rm2-xw88 ("Private work package data disclosure through single meeting agenda item API", Medium, CWE-200/CWE-639), whose fix migrated the meeting-agenda-item representer's linked Work Package from the ungated associated_resource to the visibility-gated associated_visible_resource. The Time Entries and Cost Entries representers were not updated.
This vulnerability was reported by user CyberKareem.
For more information, please see the GitHub advisory #GHSA-v3j7-vqwv-5w5q
OpenProject supports list-type custom fields whose allowed values are stored as CustomOption records. User and group custom fields can be marked admin_only, and the normal visibility scopes hide those fields from non-admin users.
However, GET /api/v3/custom_options/:id resolves a CustomOption by global numeric id and explicitly allows every option whose owning custom field is a UserCustomField or GroupCustomField. It does not check whether the owning custom field is visible to the requester.
An attacker only needs a normal authenticated account. Because custom option ids are sequential numeric ids, and normal API schemas/forms expose visible option links such as /api/v3/custom_options/<id>, the attacker can enumerate nearby ids and read the value returned by successful responses.
As a result, non-admin users can disclose option labels belonging to admin-only user or group custom fields. This leaks hidden internal taxonomies or classifications that administrators intentionally made admin-only.
This vulnerability was reported as part of the YesWeHack.com OpenProject Bug Bounty program, sponsored by the European Commission.
For more information, please see the GitHub advisory #GHSA-wr3w-qchj-p4cm
<!-- END SECURITY FIXES AUTOMATED SECTION --> <!--more-->Resulting from a security advisory report, we have improved how user binds are being protected against brute force inside OpenProject. While we expect production AD systems to perform their own brute force protections, administrators of OpenProject might be confused as the login with an LDAP user bind is transparent, and they might expect our brute force protection settings to apply.
OpenProject 17.6 implements a Rack::Attack throttle rule for internal login mechanisms, also protecting LDAP binds specifically. We'd like to thank the contributors of this report, @GEONWOOHAN, @QwQP0, @minnnjuuu, and @dkstjwls06.
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 Rince wind, Walid Ibrahim, Gábor Alexovics, Brandon Soonaye, and Mohammed Mohiuddin.
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 Maximiliano Spaccesi for translating our FAQ in the documentation into Spanish.
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!