OpenProject 17.5.0

Release date: 2026-06-10

We released OpenProject 17.5.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.

Important feature changes

Take a look at our release video showing the most important features introduced in OpenProject 17.5.0:

Release video of OpenProject 17.5

Project-based work package identifiers for clearer references and Jira migrations

OpenProject 17.5 introduces optional project-based work package identifiers in Beta. Administrators can choose between the default numerical sequence and project-based IDs for the entire OpenProject instance.

Note

The setting can be reverted later. Existing numerical IDs remain valid and continue to resolve to the same work packages throughout the application, including existing URLs, bookmarks, and references.

Project-based work package identifiers are especially useful for organizations migrating from Jira, as existing Jira issue identifiers can now be preserved in OpenProject. Beyond migrations, project-based IDs provide shorter sequence numbers and clearer project context, making it easier to recognize, reference, and share work packages across projects, emails, documents, chats, and integrations.

Switching between numerical and project-based IDs

Switching to project-based work package identifiers is an instance-wide administrative change that affects how work packages are referenced throughout OpenProject. Administrators should communicate the change to users before enabling it in production environments, as work package identifiers, URLs, and references will use the new format. OpenProject validates existing project identifiers and can automatically generate shorter, compatible identifiers where necessary.

Note

Historical references remain functional when project identifiers change.

Support across URLs, searches, exports, and integrations

Even in Beta, project-based work package identifiers are supported across important areas of OpenProject, including URLs, searches, filters, exports, email notifications, APIs, and work package references in Documents and text editors.

Existing integrations such as GitHub and GitLab already support the new identifier format.

Note

Project-based work package identifiers are still in Beta. While the feature is supported across important areas of OpenProject, some areas may continue to display numerical identifiers until support for project-based identifiers is fully implemented. In these cases, numerical identifiers remain fully functional and continue to resolve to the same work packages.

See our system admin guide for detailed information on how to manage work package identifiers.

Releasing unused numerical identifiers

When switching from the default numerical sequence to project-based work package identifiers, previously reserved numerical identifiers can be released again if they are no longer needed. This helps administrators avoid unnecessary gaps and keep numerical identifiers available if they later revert to the default sequence.

Note

Releasing an identifier cannot be undone. External links and integrations using it will stop resolving, and the name becomes available for any new project to claim.

Jira Migrator support for Jira identifiers, due dates, and more

OpenProject 17.5 further improves the Jira Migrator that was introduced in Beta with OpenProject 17.4. Jira issue identifiers can now be preserved during migration when using project-based work package identifiers.

This helps organizations maintain existing references, naming conventions, and established workflows when transitioning from Jira to OpenProject.

In addition to Jira identifiers, OpenProject 17.5 also adds support for migrating due dates, estimated hours, and remaining hours. Read more about the Jira Migrator in our documentation.

Option to exclude work package types from Backlogs

OpenProject 17.5 introduces more flexible backlog configuration by allowing project administrators to exclude specific work package types from Backlogs. This helps teams keep sprint planning and backlog refinement focused on actionable work items.

For example, higher-level planning items such as Epics or Milestones can now be excluded from backlog views while still remaining available elsewhere in the project. The configuration is available in the Backlogs project settings and can be customized per project.

OpenProject 17.5 also extends project-specific "done" status configuration to the Backlogs module. Work packages with statuses configured as done are now handled consistently across backlog views and sprint completion. For example, teams can treat development work as complete once testing is finished, even if documentation tasks remain open, allowing sprints to be completed without carrying over already finished development work.

Read more about the OpenProject Backlogs module.

Redesigned sprint views and work package cards

OpenProject 17.5 redesigns sprint headers, backlog containers, and work package cards in the Backlogs module to improve readability and usability during agile planning.

Sprint views now provide clearer visual hierarchy, more consistent actions, and improved visibility of important information such as parent work packages, story points, priorities, assignees, and sprint status. Work package cards have also been redesigned to make important work item details easier to scan during sprint planning and backlog refinement.

Allow inline work package links within text paragraphs in the Documents module

OpenProject 17.5 makes it easier to reference work packages naturally within Documents, which use the BlockNote editor. Work package links can now be inserted directly inside text paragraphs instead of always appearing as separate blocks.

This allows teams to create more readable and structured documentation while still linking directly to relevant work packages. Inline work package links behave like regular inline elements and continue to open the referenced work package in a new tab.

Read more about OpenProject's Documents module.

Expanded work package mentions in CKEditor

OpenProject 17.5 also improves work package references in CKEditor-based text fields such as work package descriptions, agenda items in meetings, and wiki pages.

Work package mentions using the ## and ### notation now expand directly inside the editor. Instead of displaying only the identifier, OpenProject now shows additional context such as the work package type, status, and subject while still editing.

This makes referenced work packages easier to recognize without leaving the editor.

Monthly scheduling options for meeting series

OpenProject 17.5 adds more flexible scheduling options for recurring meetings. Meeting series can now repeat monthly based on patterns such as the first Monday or last Friday of a month.

This makes it easier to schedule recurring coordination meetings, steering committees, retrospectives, or review meetings that follow common organizational schedules.

Debounce meeting emails to reduce email...

OpenProject 17.4.1

Release date: 2026-06-08

We released OpenProject 17.4.1.
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-47193 - Journal diff endpoint bypasses object, journal, and field visibility checks

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-f2rx-x2qj-2hgj

CVE-2026-49355 - Private work package data disclosure through single meeting agenda item API

GET /api/v3/meetings/:meeting_id/agenda_items/:agenda_item_id discloses private work package data from a linked work package that belongs to a private/inaccessible project.

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-g387-6rm2-xw88

GHSA-3vpx-94qx-xpw6 - IDOR through /projects//settings/project_storages/<A_ps_id> via PATCH parameter "storages_project_storage[project_folder_id]" leads to Access to Unauthorized Resources

A project-admin in one project can hijack the managed Nextcloud or OneDrive folder of another project on the same storage by writing the victim project's project_folder_id into the attacker's Storages::ProjectStorage row. The next managed-folder sync overwrites the ACL on the referenced folder with the attacker project's user list.

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-3vpx-94qx-xpw6

GHSA-6crw-7f5r-4qj9 - CSRF on TARGET through /users/:id via POST parameter "user[admin]"

Turbo Drive auto-injects CSRF tokens (from <meta name="csrf-token">) on forms injected via the XSS's append Turbo Stream action. A second action, dispatch_event with name="submit", auto-submits the form with no victim interaction beyond viewing the work package, resulting in a CSRF attack

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-6crw-7f5r-4qj9

GHSA-98vw-2r87-fx2r - SQL injection in timestamps functionality

OpenProject baseline comparison allows callers to request historic work-package attributes using the timestamps parameter.

The timestamp parser accepts a relative date keyword on the first line because its regular expression uses line anchors. The parser validates the input, but the original multi-line string is kept and later interpolated into a raw SQL CASE ... THEN '<timestamp>' expression.

An authenticated user who can save a query can persist a timestamp array value containing literal commas and trigger a top-level data-modifying CTE. This gives the attacker a generic database write primitive as the OpenProject application database role.

The demonstrated impact is administrator privilege escalation: the attacker uses that write primitive to update their own account record, setting the account's administrator flag to true. The same injection also allows in-band data disclosure through work-package timestamp metadata.

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-98vw-2r87-fx2r

GHSA-h83w-5q5x-pq27 - Information Disclosure (cleartext storage of data) on localhost through memcached via Others "storage..httpx_access_token" leads to Sensitive Data Exposure

OpenProject's Storages module writes the OneDrive/SharePoint userless OAuth access_token plaintext to Rails.cache under the deterministic key storage.<id>.httpx_access_token, repopulated continuously by an hourly cron and every userless-OAuth call site (see Write cadence). None of the three allowed cache backends (file_store, memcache, redis) encrypts at rest. An attacker with read access to the cache backend recovers the Azure-AD application-tier bearer with an anonymous get over the memcached binary protocol (or the equivalent against Redis)

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-h83w-5q5x-pq27

GHSA-q33w-f822-hg8x - Stored XSS on openproject.example.com through /api/v3/projects/{project}/work_packages via POST parameter "description"

The HTML sanitizer grants <macro> elements unrestricted data-* attributes via :data wildcard. An attacker injects data-controller="poll-for-changes" into a work package description, causing Stimulus.js to mount a controller that fetches an attacker-uploaded attachment and passes it to renderStreamMessage(). This executes arbitrary Turbo Stream actions — including redirect_to — in every victim's authenticated browser session, redirecting them to an attacker-controlled server.

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-q33w-f822-hg8x

GHSA-qj96-f42f-6336 - Cache store poisoning leads to Remote Code Execution (RCE)

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-qj96-f42f-6336

Bug fixes and changes

• Bugfix: Migration 20250929070310 failing due to update code failing on not-yet fully migrated schema [#75286]

Contributions

A big thanks to our Community members for reporting bugs and helping us identify and provide fixes.
This release, special thanks for reporting and finding bugs go to Alexander Aleschenko.

OpenProject 17.3.4

Release date: 2026-06-08

We released OpenProject 17.3.4.
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.

Bug fixes and changes

• Bugfix: Memcached serialization is broken in 17.3.3 [#75753]

OpenProject 17.3.3

Release date: 2026-06-08

We released OpenProject 17.3.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-47193 - Journal diff endpoint bypasses object, journal, and field visibility checks

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-f2rx-x2qj-2hgj

GHSA-3vpx-94qx-xpw6 - IDOR through /projects//settings/project_storages/<A_ps_id> via PATCH parameter "storages_project_storage[project_folder_id]" leads to Access to Unauthorized Resources

A project-admin in one project can hijack the managed Nextcloud or OneDrive folder of another project on the same storage by writing the victim project's project_folder_id into the attacker's Storages::ProjectStorage row. The next managed-folder sync overwrites the ACL on the referenced folder with the attacker project's user list.

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-3vpx-94qx-xpw6

GHSA-6crw-7f5r-4qj9 - CSRF on TARGET through /users/:id via POST parameter "user[admin]"

Turbo Drive auto-injects CSRF tokens (from <meta name="csrf-token">) on forms injected via the XSS's append Turbo Stream action. A second action, dispatch_event with name="submit", auto-submits the form with no victim interaction beyond viewing the work package, resulting in a CSRF attack

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-6crw-7f5r-4qj9

GHSA-98vw-2r87-fx2r - SQL injection in timestamps functionality

OpenProject baseline comparison allows callers to request historic work-package attributes using the timestamps parameter.

The timestamp parser accepts a relative date keyword on the first line because its regular expression uses line anchors. The parser validates the input, but the original multi-line string is kept and later interpolated into a raw SQL CASE ... THEN '<timestamp>' expression.

An authenticated user who can save a query can persist a timestamp array value containing literal commas and trigger a top-level data-modifying CTE. This gives the attacker a generic database write primitive as the OpenProject application database role.

The demonstrated impact is administrator privilege escalation: the attacker uses that write primitive to update their own account record, setting the account's administrator flag to true. The same injection also allows in-band data disclosure through work-package timestamp metadata.

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-98vw-2r87-fx2r

GHSA-h83w-5q5x-pq27 - Information Disclosure (cleartext storage of data) on localhost through memcached via Others "storage..httpx_access_token" leads to Sensitive Data Exposure

OpenProject's Storages module writes the OneDrive/SharePoint userless OAuth access_token plaintext to Rails.cache under the deterministic key storage.<id>.httpx_access_token, repopulated continuously by an hourly cron and every userless-OAuth call site (see Write cadence). None of the three allowed cache backends (file_store, memcache, redis) encrypts at rest. An attacker with read access to the cache backend recovers the Azure-AD application-tier bearer with an anonymous get over the memcached binary protocol (or the equivalent against Redis)

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-h83w-5q5x-pq27

GHSA-q33w-f822-hg8x - Stored XSS on openproject.example.com through /api/v3/projects/{project}/work_packages via POST parameter "description"

The HTML sanitizer grants <macro> elements unrestricted data-* attributes via :data wildcard. An attacker injects data-controller="poll-for-changes" into a work package description, causing Stimulus.js to mount a controller that fetches an attacker-uploaded attachment and passes it to renderStreamMessage(). This executes arbitrary Turbo Stream actions — including redirect_to — in every victim's authenticated browser session, redirecting them to an attacker-controlled server.

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-q33w-f822-hg8x

GHSA-qj96-f42f-6336 - Cache store poisoning leads to Remote Code Execution (RCE)

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-qj96-f42f-6336

Bug fixes and changes

OpenProject 17.4.0

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.

Security fixes

GHSA-r85r-gjq2-f83r - Docker Container starts with SECRET_KEY_BASE default value

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

CVE-2026-44696 - Stored CSS injection via Sanitize::Config::RELAXED[:css] enables phishing overlays and data exfiltration

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

CVE-2026-44731 - Improper Access Control on OpenProject through /projects/[projectName]/meetings via "invited_user_id" in GET parameter "filters" leads to user names disclosure

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

CVE-2026-44732 - IDOR on OpenProject through /api/v3/documents/{id} via PATCH parameter "project_id" leads to Unauthorized Modification of Resources

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

CVE-2026-44733 - Business Logic Error on OpenProject through PATCH request to /api/v3/users/me permits to bypass password requirements

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

CVE-2026-44734 - Improper Access Control on OpenProject through the POST request to /projects/[PROJECT_NAME]/cost_reports/[REPORT_ID]/rename

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

CVE-2026-44735 - Shares API Information Disclosure

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

CVE-2026-44736 - Relations API Filter Bypasses Visibility Scope, Leaking Cross-Project Work Package Subjects

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

Important feature changes

Take a look at our release video showing the most important features introduced in OpenProject 17.4.0:

Release video of OpenProject 17.4

Support basic custom fields migration from Jira

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 Jir...

OpenProject 17.3.2

Release date: 2026-05-13

We released OpenProject 17.3.2.
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

GHSA-r85r-gjq2-f83r - Docker Container starts with SECRET_KEY_BASE default value

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.

This vulnerability was responsibly reported by GitHub user hkolvenbach.

For more information, please see the GitHub advisory #GHSA-r85r-gjq2-f83r

CVE-2026-44731 - Improper Access Control on OpenProject through /projects/[projectName]/meetings via "invited_user_id" in GET parameter "filters" leads to user names disclosure

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

CVE-2026-44732 - IDOR on OpenProject through /api/v3/documents/{id} via PATCH parameter "project_id" leads to Unauthorized Modification of Resources

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

CVE-2026-44733 - Business Logic Error on OpenProject through PATCH request to /api/v3/users/me permits to bypass password requirements

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

CVE-2026-44734 - Improper Access Control on OpenProject through the POST request to /projects/[PROJECT_NAME]/cost_reports/[REPORT_ID]/rename

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

CVE-2026-44735 - Shares API Information Disclosure

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

Bug fixes and changes

• Bugfix: Performance impact of large Markdown/HTML templates caused by the tagfilter GFM extension [#74151]
• Bugfix: Budget widget breaks when lots of cost types defined [#74189]
• Bugfix: Direct login prevents authentication from mobile app [#74569]

OpenProject 17.2.4

Release date: 2026-05-13

We released OpenProject 17.2.4.
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

GHSA-r85r-gjq2-f83r - Docker Container starts with SECRET_KEY_BASE default value

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.

This vulnerability was responsibly reported by GitHub user hkolvenbach.

For more information, please see the GitHub advisory #GHSA-r85r-gjq2-f83r

CVE-2026-44731 - Improper Access Control on OpenProject through /projects/[projectName]/meetings via "invited_user_id" in GET parameter "filters" leads to user names disclosure

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

CVE-2026-44732 - IDOR on OpenProject through /api/v3/documents/{id} via PATCH parameter "project_id" leads to Unauthorized Modification of Resources

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

CVE-2026-44733 - Business Logic Error on OpenProject through PATCH request to /api/v3/users/me permits to bypass password requirements

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

CVE-2026-44734 - Improper Access Control on OpenProject through the POST request to /projects/[PROJECT_NAME]/cost_reports/[REPORT_ID]/rename

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

CVE-2026-44735 - Shares API Information Disclosure

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

Bug fixes and changes

OpenProject 17.3.1

Release date: 2026-04-20

We released OpenProject OpenProject 17.3.1.
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.

Bug fixes and changes

• Bugfix: Some macros cannot be used (displayed behind modal) while creating a new child via relations tab [#62585]
• Bugfix: The 'Reload' action in the banner about the meeting being updated in the background no longer auto-scrolls to the previous position [#70559]
• Bugfix: Items multiplying on page and page becoming unresponsive when macros and code snippet are used [#73117]
• Bugfix: Remove a 2FA device from a user as admin does not work [#73218]
• Bugfix: Error when changing wp type from the wp list [#73224]
• Bugfix: Internal error on custom actions form [#74131]

OpenProject 17.3.0

Release date: 2026-04-15

We released OpenProject 17.3.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.

Important feature changes

Take a look at our release video showing the most important features introduced in OpenProject 17.3.0:

Release video of OpenProject 17.3

Improvements to agile planning and execution with sprints and backlogs

OpenProject 17.3 introduces several improvements to agile planning and execution, making it easier to structure and manage work with sprints and backlogs and reducing the need for manual setup. These changes are part of our ongoing efforts to further strengthen agile workflows in OpenProject.

Important

If you are already working with the Backlogs module, you will notice updates to the layout and behavior when updating to OpenProject 17.3. All existing data will be preserved, and no manual action is required. To learn more about the reason behind these changes, please see this blog article.

Dedicated sprint objects

OpenProject introduces dedicated sprint objects for agile planning, replacing the previous use of versions as a workaround. Sprints are now a core entity within the Backlogs module, allowing teams to plan, organize, and track their work more intuitively.

Work packages can be assigned directly to sprints, and sprints include key attributes such as name, status, and dates. This provides a clearer structure for agile workflows and aligns OpenProject more closely with established Scrum practices.

All work packages visible on backlogs

Backlogs now display all work package types within a project, removing previous limitations on which types could be included. This allows teams to manage and prioritize all relevant work in one place without additional configuration.

By making all work packages visible in backlogs and sprint planning, OpenProject provides a more consistent and flexible approach to organizing work across different use cases.

Automatic board creation when starting a sprint

When starting a sprint, a dedicated board is now created automatically and configured based on the project’s workflows. Teams are directly taken to the board, allowing them to start working without any additional setup.

This reduces manual configuration and ensures that sprint boards are consistently structured across projects.

Closing a sprint and handling remaining work

Active sprints can now be completed directly from the sprint view, making it easier to transition to the next iteration. When closing a sprint, users are guided to handle unfinished work packages in bulk.

Remaining work can be moved to the backlog or reassigned to another sprint, helping teams to continue their work without manual adjustments.

---

See our documentation to learn more about backlog and sprints with OpenProject.

Action boards available in the Community edition

With the improvements to agile planning features such as sprints and backlogs, boards play a central role in organizing and tracking work. To support this, all action board types are now available in the Community edition.

This extends the existing board functionality in the Community edition and allows teams to use a wider range of board configurations, such as Kanban or parent-child boards, without requiring an Enterprise plan.

In-place editing of project attributes on the project overview page

Project attributes on the project overview page (Project home) can now be edited directly in place, without opening a separate dialog. This allows users to update project information more quickly and with fewer interruptions.

Depending on the attribute type, changes can be applied immediately or confirmed within the field, providing a more streamlined and consistent editing experience.

Sharing of meeting templates (Enterprise add-on, Basic plan)

Meeting templates, introduced as an Enterprise add-on in OpenProject 17.2, can now be shared across projects, making it easier to reuse standardized agendas and structures. Depending on the configuration, templates can be made available within a project, across subprojects, or throughout the entire instance.

For more details, please refer to the Meetings documentation.

Improved workflow configuration for administrators

Workflow configuration has been improved to make it easier to focus on relevant types, roles, and statuses. A new index page allows workflows to be accessed by type, reducing complexity when navigating and editing configurations.

When editing workflows, only relevant statuses are displayed, and role selection is streamlined. In addition, saving changes is now more reliable, with improved handling of unsaved changes and a fixed save action.

Read more about workflow management in our system admin guide.

Improved handling of project identifiers

Project identifiers can now be easily changed without invalidating existing links. Previous identifiers remain valid and continue to redirect to the project.

In addition, identifier handling has been improved when creating or copying projects, including automatic suggestions and updated validation. These improvements also apply to API-based project creation.

Improved work package search when selecting items across the application

Work package search has been continuously improved in recent releases. With OpenProject 17.3, these improvements are now extended to more areas of the application.

When selecting work packages in relations, boards, meetings, time tracking, or filters, it is now possible to search by attributes such as type and status. This aligns the search behavior with the global search and makes it easier to find and select the correct work packages in different workflows.

Nested groups for improved user and permission management

Groups can now be nested, allowing memberships and permissions to be inherited through the group hierarchy. This lays the foundation for further improvements in structuring and managing groups.

Security fixes

CVE-2026-33667 - 2FA OTP Verification Missing Rate Limiting

The 2FA OTP verification (confirm_otp action) has no rate limiting, lockout mechanism, or failed-attempt tracking. An attacker who knows a user's password can brute-force the 6-digit TOTP code without any protection slowing or blocking the attempts.

The existing brute_force_block_after_failed_logins setting only counts password login failures and does not apply to the 2FA verification stage.

This vulnerability was reported by GitHub user Wernerina. Thank you for responsibly disclosing your findings.

For more information, please see the GitHub advisory #GHSA-234r-45m2-w6cv

GHSA-hh5...

OpenProject 17.2.3

Release date: 2026-03-31

We released OpenProject OpenProject 17.2.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-34717 - SQL Injection in Cost Reporting =n Operator via parse_number_string

The =n operator in cost reports did not appropriately treat user input

This vulnerability was reported by user Ochk0 through a GitHub security advisory. Thank you for responsibly disclosing your findings.

For more information, please see the GitHub advisory #GHSA-5rrm-6qmq-2364

Bug fixes and changes