Opf
Monthly
Information disclosure in OpenProject 17.5.1 and earlier allows authenticated non-admin project members to read hidden admin-only custom field comment text by directly requesting the inplace-edit dialog endpoint with a raw custom_field_ identifier. The dialog resolves the field without enforcing the admin_only visibility scope, exposing stored comment content in read-only mode; the custom field value itself and all write operations remain inaccessible. No active exploitation is confirmed and no public exploit has been identified; a vendor patch is available in version 17.6.0.
Authenticated users with time or cost entry viewing permissions can read private work package subjects and IDs via the OpenProject REST API in versions prior to 17.6.0. The /api/v3/time_entries and /api/v3/cost_entries endpoints expose _links.workPackage.title and _links.workPackage.href through the associated_resource rendering path without enforcing WorkPackage.visible or view_work_packages permission checks. An attacker with only view_time_entries or view_cost_entries can enumerate titles and IDs of work packages they should not have access to, violating project confidentiality controls. No public exploit or CISA KEV listing exists; the fix is available in v17.6.0.
Incorrect authorization in OpenProject's REST API before 17.6.0 allows any authenticated non-admin user to enumerate sequential custom option IDs via GET /api/v3/custom_options/:id and read option labels belonging to admin_only UserCustomField and GroupCustomField records. The root cause, confirmed by commit diff, is that the authorization handler returned true unconditionally for these two custom field types instead of invoking the visible(current_user) scope filter. No public exploit code exists and this is not listed in CISA KEV, but the low attack complexity and standard network API surface make this trivially exploitable by any account holder on an affected instance.
Broken authorization in OpenProject before 17.6.0 lets authenticated users holding only the edit_work_packages permission manipulate file-storage links they should not control. By submitting _links.fileLinks to PATCH /api/v3/work_packages/{id}, an attacker lacking manage_file_links can resolve Storages::FileLink records by raw id to detach or hard-delete them, re-parent FileLinks from other projects onto their own work package, and read origin filename, origin id, and MIME-type metadata. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the flaw is remotely reachable by any low-privileged project editor.
Password validation bypass in OpenProject's REST API allows an attacker who has already seized a valid user session to change that account's password without supplying the current password, exploiting CWE-620 (Unverified Password Change) via a crafted PATCH request to /api/v3/users/me. Affected versions are all OpenProject releases prior to 17.3.2 and 17.4.0 (CPE cpe:2.3:a:opf:openproject:*:*:*:*:*:*:*:*). No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV; however, when chained with a session-takeover primitive, it converts transient access into persistent account control.
User account enumeration in OpenProject's meetings filter feature allows authenticated attackers to probe arbitrary user IDs and, by observing differences in server responses, determine whether each ID corresponds to a valid account and retrieve the associated user's full name. All versions prior to 17.3.2 and 17.4.0 are affected. No public exploit code or active exploitation has been identified at time of analysis, though the low-complexity attack path makes this straightforward to weaponize for reconnaissance.
OpenProject's document update endpoint before versions 17.3.2 and 17.4.0 contains an authorization order-of-operations flaw (CWE-639) that allows any authenticated low-privilege user to move or modify documents belonging to projects they do not have permission to manage. By sending a single crafted PATCH request containing a `project_id` attribute pointing to a foreign project, the attacker exploits the endpoint's incorrect sequence - attributes are applied to the record before authorization is enforced - bypassing the `:manage_documents` permission check entirely. No public exploit code has been identified at time of analysis and this CVE is not listed in CISA KEV; however, the attack requires only a valid user session and standard HTTP tooling.
Missing authorization in OpenProject's CostReportsController allows any authenticated user to rename or overwrite the filter and grouping configuration of any Public cost report system-wide, bypassing ownership checks entirely. All OpenProject deployments running versions prior to 17.3.2 and 17.4.0 are affected. An attacker with only a low-privilege account who enumerates or guesses a public report's numeric ID can silently corrupt shared cost reporting configurations with no warning to the report's owner. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Incorrect authorization in OpenProject's REST API allows authenticated project members to harvest confidential work package metadata they are not entitled to view. The `GET /api/v3/shares` endpoint enforces access control only at the project level - not at the individual work package level - meaning any holder of the `view_shared_work_packages` permission can retrieve share records for every work package in a project, including confidential titles, share recipient identities, and assigned role levels. No public exploit is identified at time of analysis; vendor-released patches exist in versions 17.3.2 and 17.4.0.
CSS injection in OpenProject's rich text rendering pipeline prior to version 17.4.0 allows any authenticated user with write access to inject arbitrary CSS into formattable text fields (work package descriptions, comments, project descriptions, news). The misconfigured Sanitize::Config::RELAXED[:css] setting permits all CSS properties on permitted HTML elements, enabling UI redressing, phishing overlays, and potential CSS-based side-channel data exfiltration when a victim views the malicious content. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis; the vendor-released fix is available in 17.4.0.
The meeting agenda items REST API in OpenProject before 17.4.0 leaks private work package data to authenticated users who lack project-level access. When a meeting agenda item is linked to a work package belonging to a private or inaccessible project, the GET /api/v3/meetings/:meeting_id/agenda_items/:agenda_item_id endpoint returns that work package's confidential data in its response, silently bypassing project-level authorization checks. No public exploit is identified at time of analysis and this vulnerability is not listed in CISA KEV; a vendor-released patch is available in version 17.4.0.
Unauthorized information disclosure in OpenProject before 17.4.0 allows any authenticated user to retrieve the subjects (titles) of work packages they have been explicitly denied access to, bypassing project-level visibility controls. The flaw exists in the GET /api/v3/relations REST API endpoint, where supplying arbitrary work package IDs to the involved, fromId, or toId filter parameters circumvents the Relation.visible scope due to a defective performance optimization in RelationQuery. No public exploit has been identified and the vulnerability is not listed in CISA KEV; however, the attack is trivially executable by any platform user with valid credentials, making it a meaningful risk in deployments handling sensitive or confidential project data.
Authenticated remote code execution affects the official openproject/openproject Docker image, which ships with a hardcoded Rails secret (ENV SECRET_KEY_BASE=OVERWRITE_ME). Because the application uses cookies_serializer = :marshal, any logged-in user who knows this deterministic key can forge a signed cookie containing a malicious Marshal payload that is deserialized when reaching the /my/two_factor_devices cookie reader, yielding code execution on the server (CVSS 9.9, scope-changed). At the time of analysis there is no public exploit identified and the issue is not in CISA KEV, but the predictability of the default key makes exploitation straightforward for anyone running an unmodified image.
Remote code execution in OpenProject before 17.3.3 and 17.4.1 arises from cache store poisoning, allowing an attacker with adjacent-network access and no authentication (CVSS:3.1 AV:A/PR:N) to corrupt cached entries and ultimately execute arbitrary code on the server. The CVSS 9.6 score reflects a scope change (S:C) with full confidentiality, integrity, and availability impact. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Cross-project IDOR in OpenProject's Calendar and Team Planner modules allows an authenticated low-privileged user with management rights in one project to delete public or shared Calendar and Team Planner Query views belonging to entirely separate projects on the same instance. The authorization context is established using :project_id from the URL (Project A), but the targeted Query object is resolved independently by :id through Query.visible(current_user), with no check that the loaded Query belongs to the authorized project - enabling cross-project privilege misuse. Versions prior to 17.3.3 and 17.4.1 are affected; no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
Information disclosure in OpenProject before 17.3.3 and 17.4.1 lets remote attackers read hidden historical field values through the journal diff endpoint, which fails to enforce object- and field-level visibility checks. The flaw (CWE-200) carries a CVSS 7.5 driven entirely by high confidentiality impact, exposing prior values of work-package fields that should be restricted. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV.
Stored XSS in OpenProject's HTML sanitizer allows authenticated project contributors to execute arbitrary Turbo Stream actions - including forced redirects - in every other user's authenticated browser session. The sanitizer's `:data` wildcard for `<macro>` elements permits injection of `data-controller` attributes that Stimulus.js silently mounts, chaining an attacker-uploaded attachment through `renderStreamMessage()` to achieve cross-user session manipulation without victim interaction beyond viewing the work package. Patch-confirmed by vendor GitHub Security Advisory GHSA-q33w-f822-hg8x; no public exploit identified at time of analysis.
Cross-project folder hijacking in OpenProject before 17.3.3 and 17.4.1 lets a project-admin abuse an insecure direct object reference (CWE-639) to take over another project's managed Nextcloud or OneDrive storage folder. By PATCHing the storages_project_storage[project_folder_id] parameter on /projects/<id>/settings/project_storages/<ps_id>, an attacker writes a victim project's folder ID into their own ProjectStorage row, and the next managed-folder sync rewrites the target folder's ACL to the attacker's project member list. CVSS is 9.9 and the issue carries a scope change, but there is no public exploit identified at time of analysis and it is not on CISA KEV.
Cleartext credential disclosure in OpenProject's Storages module (versions prior to 17.3.3 and 17.4.1) writes the userless OneDrive/SharePoint OAuth access_token in plaintext to Rails.cache under the deterministic key storage.<id>.httpx_access_token, refreshed by an hourly cron and every userless-OAuth call. Because none of the supported cache backends (file_store, memcache, redis) encrypts at rest, an attacker who can read the cache backend retrieves the Azure-AD application-tier bearer token via an anonymous memcached/Redis get. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV.
Privilege escalation in OpenProject before 17.3.3 and 17.4.1 lets an attacker forge a cross-site request to /users/:id carrying the POST parameter user[admin], coercing a logged-in privileged user's browser into granting administrator rights to an arbitrary account. The flaw (CWE-352) rates CVSS 8.8 because a successful forgery yields full administrative control over the instance; no public exploit is identified at time of analysis and it is not listed in CISA KEV. Both the 17.3.x and 17.4.x maintenance lines are affected, with fixes shipped in 17.3.3 and 17.4.1.
SQL injection in OpenProject's baseline-comparison (timestamps) functionality lets an authenticated, low-privileged user inject SQL through the timestamps parameter used to request historic work-package attributes, affecting all versions prior to 17.3.3 and 17.4.1. Rated CVSS 9.9 with a changed scope, it can expose or alter database contents beyond the user's normal authorization. No public exploit identified at time of analysis; the issue is fixed in 17.3.3 and 17.4.1.
OpenProject versions prior to 17.3.0 allow authenticated users with manage_agendas permission in any single project to inject malicious agenda items into meetings across all other projects on the instance, including projects to which the attacker has no access. The vulnerability requires only valid project membership with limited permissions and no knowledge of target meetings, enabling an attacker to systematically compromise meeting integrity across an entire OpenProject deployment. No public exploit code has been identified, and the vendor has released patched version 17.3.0 addressing this privilege escalation flaw.
Two-factor authentication bypass in OpenProject before 17.3.0 allows attackers with a known password to brute-force the TOTP code, gaining full account access. No rate limiting or lockout mechanism exists for the 2FA verification endpoint, making it possible to cycle through the 6‑digit code in roughly 11 hours under default settings. The flaw also affects backup code verification, completely negating 2FA protection; publicly available exploit code exists based on SSVC intelligence, though EPSS indicates a low exploitation probability.
SQL injection in OpenProject's reporting module allows authenticated attackers to execute arbitrary database queries via the =n operator. Affects all versions prior to 17.2.3. Attack complexity is low with no user interaction required, enabling authenticated users to escalate privileges, modify data integrity, and potentially compromise availability across scope boundaries. Vendor-released patch confirms fix in version 17.2.3. EPSS score of 0.04% (13th percentile) indicates low probability of mass exploitation, though the CVSS 9.9 critical rating reflects severe potential impact in targeted scenarios. No CISA KEV listing or public exploit code identified at time of analysis.
OpenProject's Repositories module contains a stored cross-site scripting (XSS) vulnerability that occurs when displaying filenames from repository changesets. Attackers with repository push access can inject malicious HTML code via specially crafted filenames, which executes when project members view affected changesets. This affects OpenProject versions prior to 16.6.9, 17.0.6, 17.1.3, and 17.2.1, with a CVSS score of 9.1 indicating critical severity.
OpenProject, a web-based project management platform, contains a critical SQL injection vulnerability in versions prior to 16.6.9, 17.0.6, 17.1.3, and 17.2.1. When custom fields are used in Cost Reports, insufficient input sanitization allows attackers with administrator privileges to execute arbitrary SQL commands. This vulnerability can be chained with a path traversal issue in the Repositories module to achieve remote code execution by injecting malicious Ruby code into the application. No current KEV listing or public POC is documented in available sources.
Information disclosure in OpenProject 17.5.1 and earlier allows authenticated non-admin project members to read hidden admin-only custom field comment text by directly requesting the inplace-edit dialog endpoint with a raw custom_field_ identifier. The dialog resolves the field without enforcing the admin_only visibility scope, exposing stored comment content in read-only mode; the custom field value itself and all write operations remain inaccessible. No active exploitation is confirmed and no public exploit has been identified; a vendor patch is available in version 17.6.0.
Authenticated users with time or cost entry viewing permissions can read private work package subjects and IDs via the OpenProject REST API in versions prior to 17.6.0. The /api/v3/time_entries and /api/v3/cost_entries endpoints expose _links.workPackage.title and _links.workPackage.href through the associated_resource rendering path without enforcing WorkPackage.visible or view_work_packages permission checks. An attacker with only view_time_entries or view_cost_entries can enumerate titles and IDs of work packages they should not have access to, violating project confidentiality controls. No public exploit or CISA KEV listing exists; the fix is available in v17.6.0.
Incorrect authorization in OpenProject's REST API before 17.6.0 allows any authenticated non-admin user to enumerate sequential custom option IDs via GET /api/v3/custom_options/:id and read option labels belonging to admin_only UserCustomField and GroupCustomField records. The root cause, confirmed by commit diff, is that the authorization handler returned true unconditionally for these two custom field types instead of invoking the visible(current_user) scope filter. No public exploit code exists and this is not listed in CISA KEV, but the low attack complexity and standard network API surface make this trivially exploitable by any account holder on an affected instance.
Broken authorization in OpenProject before 17.6.0 lets authenticated users holding only the edit_work_packages permission manipulate file-storage links they should not control. By submitting _links.fileLinks to PATCH /api/v3/work_packages/{id}, an attacker lacking manage_file_links can resolve Storages::FileLink records by raw id to detach or hard-delete them, re-parent FileLinks from other projects onto their own work package, and read origin filename, origin id, and MIME-type metadata. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the flaw is remotely reachable by any low-privileged project editor.
Password validation bypass in OpenProject's REST API allows an attacker who has already seized a valid user session to change that account's password without supplying the current password, exploiting CWE-620 (Unverified Password Change) via a crafted PATCH request to /api/v3/users/me. Affected versions are all OpenProject releases prior to 17.3.2 and 17.4.0 (CPE cpe:2.3:a:opf:openproject:*:*:*:*:*:*:*:*). No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV; however, when chained with a session-takeover primitive, it converts transient access into persistent account control.
User account enumeration in OpenProject's meetings filter feature allows authenticated attackers to probe arbitrary user IDs and, by observing differences in server responses, determine whether each ID corresponds to a valid account and retrieve the associated user's full name. All versions prior to 17.3.2 and 17.4.0 are affected. No public exploit code or active exploitation has been identified at time of analysis, though the low-complexity attack path makes this straightforward to weaponize for reconnaissance.
OpenProject's document update endpoint before versions 17.3.2 and 17.4.0 contains an authorization order-of-operations flaw (CWE-639) that allows any authenticated low-privilege user to move or modify documents belonging to projects they do not have permission to manage. By sending a single crafted PATCH request containing a `project_id` attribute pointing to a foreign project, the attacker exploits the endpoint's incorrect sequence - attributes are applied to the record before authorization is enforced - bypassing the `:manage_documents` permission check entirely. No public exploit code has been identified at time of analysis and this CVE is not listed in CISA KEV; however, the attack requires only a valid user session and standard HTTP tooling.
Missing authorization in OpenProject's CostReportsController allows any authenticated user to rename or overwrite the filter and grouping configuration of any Public cost report system-wide, bypassing ownership checks entirely. All OpenProject deployments running versions prior to 17.3.2 and 17.4.0 are affected. An attacker with only a low-privilege account who enumerates or guesses a public report's numeric ID can silently corrupt shared cost reporting configurations with no warning to the report's owner. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Incorrect authorization in OpenProject's REST API allows authenticated project members to harvest confidential work package metadata they are not entitled to view. The `GET /api/v3/shares` endpoint enforces access control only at the project level - not at the individual work package level - meaning any holder of the `view_shared_work_packages` permission can retrieve share records for every work package in a project, including confidential titles, share recipient identities, and assigned role levels. No public exploit is identified at time of analysis; vendor-released patches exist in versions 17.3.2 and 17.4.0.
CSS injection in OpenProject's rich text rendering pipeline prior to version 17.4.0 allows any authenticated user with write access to inject arbitrary CSS into formattable text fields (work package descriptions, comments, project descriptions, news). The misconfigured Sanitize::Config::RELAXED[:css] setting permits all CSS properties on permitted HTML elements, enabling UI redressing, phishing overlays, and potential CSS-based side-channel data exfiltration when a victim views the malicious content. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis; the vendor-released fix is available in 17.4.0.
The meeting agenda items REST API in OpenProject before 17.4.0 leaks private work package data to authenticated users who lack project-level access. When a meeting agenda item is linked to a work package belonging to a private or inaccessible project, the GET /api/v3/meetings/:meeting_id/agenda_items/:agenda_item_id endpoint returns that work package's confidential data in its response, silently bypassing project-level authorization checks. No public exploit is identified at time of analysis and this vulnerability is not listed in CISA KEV; a vendor-released patch is available in version 17.4.0.
Unauthorized information disclosure in OpenProject before 17.4.0 allows any authenticated user to retrieve the subjects (titles) of work packages they have been explicitly denied access to, bypassing project-level visibility controls. The flaw exists in the GET /api/v3/relations REST API endpoint, where supplying arbitrary work package IDs to the involved, fromId, or toId filter parameters circumvents the Relation.visible scope due to a defective performance optimization in RelationQuery. No public exploit has been identified and the vulnerability is not listed in CISA KEV; however, the attack is trivially executable by any platform user with valid credentials, making it a meaningful risk in deployments handling sensitive or confidential project data.
Authenticated remote code execution affects the official openproject/openproject Docker image, which ships with a hardcoded Rails secret (ENV SECRET_KEY_BASE=OVERWRITE_ME). Because the application uses cookies_serializer = :marshal, any logged-in user who knows this deterministic key can forge a signed cookie containing a malicious Marshal payload that is deserialized when reaching the /my/two_factor_devices cookie reader, yielding code execution on the server (CVSS 9.9, scope-changed). At the time of analysis there is no public exploit identified and the issue is not in CISA KEV, but the predictability of the default key makes exploitation straightforward for anyone running an unmodified image.
Remote code execution in OpenProject before 17.3.3 and 17.4.1 arises from cache store poisoning, allowing an attacker with adjacent-network access and no authentication (CVSS:3.1 AV:A/PR:N) to corrupt cached entries and ultimately execute arbitrary code on the server. The CVSS 9.6 score reflects a scope change (S:C) with full confidentiality, integrity, and availability impact. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Cross-project IDOR in OpenProject's Calendar and Team Planner modules allows an authenticated low-privileged user with management rights in one project to delete public or shared Calendar and Team Planner Query views belonging to entirely separate projects on the same instance. The authorization context is established using :project_id from the URL (Project A), but the targeted Query object is resolved independently by :id through Query.visible(current_user), with no check that the loaded Query belongs to the authorized project - enabling cross-project privilege misuse. Versions prior to 17.3.3 and 17.4.1 are affected; no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
Information disclosure in OpenProject before 17.3.3 and 17.4.1 lets remote attackers read hidden historical field values through the journal diff endpoint, which fails to enforce object- and field-level visibility checks. The flaw (CWE-200) carries a CVSS 7.5 driven entirely by high confidentiality impact, exposing prior values of work-package fields that should be restricted. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV.
Stored XSS in OpenProject's HTML sanitizer allows authenticated project contributors to execute arbitrary Turbo Stream actions - including forced redirects - in every other user's authenticated browser session. The sanitizer's `:data` wildcard for `<macro>` elements permits injection of `data-controller` attributes that Stimulus.js silently mounts, chaining an attacker-uploaded attachment through `renderStreamMessage()` to achieve cross-user session manipulation without victim interaction beyond viewing the work package. Patch-confirmed by vendor GitHub Security Advisory GHSA-q33w-f822-hg8x; no public exploit identified at time of analysis.
Cross-project folder hijacking in OpenProject before 17.3.3 and 17.4.1 lets a project-admin abuse an insecure direct object reference (CWE-639) to take over another project's managed Nextcloud or OneDrive storage folder. By PATCHing the storages_project_storage[project_folder_id] parameter on /projects/<id>/settings/project_storages/<ps_id>, an attacker writes a victim project's folder ID into their own ProjectStorage row, and the next managed-folder sync rewrites the target folder's ACL to the attacker's project member list. CVSS is 9.9 and the issue carries a scope change, but there is no public exploit identified at time of analysis and it is not on CISA KEV.
Cleartext credential disclosure in OpenProject's Storages module (versions prior to 17.3.3 and 17.4.1) writes the userless OneDrive/SharePoint OAuth access_token in plaintext to Rails.cache under the deterministic key storage.<id>.httpx_access_token, refreshed by an hourly cron and every userless-OAuth call. Because none of the supported cache backends (file_store, memcache, redis) encrypts at rest, an attacker who can read the cache backend retrieves the Azure-AD application-tier bearer token via an anonymous memcached/Redis get. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV.
Privilege escalation in OpenProject before 17.3.3 and 17.4.1 lets an attacker forge a cross-site request to /users/:id carrying the POST parameter user[admin], coercing a logged-in privileged user's browser into granting administrator rights to an arbitrary account. The flaw (CWE-352) rates CVSS 8.8 because a successful forgery yields full administrative control over the instance; no public exploit is identified at time of analysis and it is not listed in CISA KEV. Both the 17.3.x and 17.4.x maintenance lines are affected, with fixes shipped in 17.3.3 and 17.4.1.
SQL injection in OpenProject's baseline-comparison (timestamps) functionality lets an authenticated, low-privileged user inject SQL through the timestamps parameter used to request historic work-package attributes, affecting all versions prior to 17.3.3 and 17.4.1. Rated CVSS 9.9 with a changed scope, it can expose or alter database contents beyond the user's normal authorization. No public exploit identified at time of analysis; the issue is fixed in 17.3.3 and 17.4.1.
OpenProject versions prior to 17.3.0 allow authenticated users with manage_agendas permission in any single project to inject malicious agenda items into meetings across all other projects on the instance, including projects to which the attacker has no access. The vulnerability requires only valid project membership with limited permissions and no knowledge of target meetings, enabling an attacker to systematically compromise meeting integrity across an entire OpenProject deployment. No public exploit code has been identified, and the vendor has released patched version 17.3.0 addressing this privilege escalation flaw.
Two-factor authentication bypass in OpenProject before 17.3.0 allows attackers with a known password to brute-force the TOTP code, gaining full account access. No rate limiting or lockout mechanism exists for the 2FA verification endpoint, making it possible to cycle through the 6‑digit code in roughly 11 hours under default settings. The flaw also affects backup code verification, completely negating 2FA protection; publicly available exploit code exists based on SSVC intelligence, though EPSS indicates a low exploitation probability.
SQL injection in OpenProject's reporting module allows authenticated attackers to execute arbitrary database queries via the =n operator. Affects all versions prior to 17.2.3. Attack complexity is low with no user interaction required, enabling authenticated users to escalate privileges, modify data integrity, and potentially compromise availability across scope boundaries. Vendor-released patch confirms fix in version 17.2.3. EPSS score of 0.04% (13th percentile) indicates low probability of mass exploitation, though the CVSS 9.9 critical rating reflects severe potential impact in targeted scenarios. No CISA KEV listing or public exploit code identified at time of analysis.
OpenProject's Repositories module contains a stored cross-site scripting (XSS) vulnerability that occurs when displaying filenames from repository changesets. Attackers with repository push access can inject malicious HTML code via specially crafted filenames, which executes when project members view affected changesets. This affects OpenProject versions prior to 16.6.9, 17.0.6, 17.1.3, and 17.2.1, with a CVSS score of 9.1 indicating critical severity.
OpenProject, a web-based project management platform, contains a critical SQL injection vulnerability in versions prior to 16.6.9, 17.0.6, 17.1.3, and 17.2.1. When custom fields are used in Cost Reports, insufficient input sanitization allows attackers with administrator privileges to execute arbitrary SQL commands. This vulnerability can be chained with a path traversal issue in the Repositories module to achieve remote code execution by injecting malicious Ruby code into the application. No current KEV listing or public POC is documented in available sources.