尧图网页设计 
OpenProject 17.2.1 发布解析修复自定义字段 SQL 注入 → 远程代码执行攻击链与仓库文件 CSP 绕过漏洞【免费下载链接】openprojectOpenProject is the leading open source project management software for product, project and portfolio management. A powerful Jira alternative with agile planning, issue tracking, roadmaps, Gantt charts, time tracking, collaboration features, and more. Available on premises or in the cloud. ⭐ Star us on GitHub项目地址: https://gitcode.com/GitHub_Trending/op/openproject本文基于 OpenProject 官方发布说明docs/release-notes/17-2-1/README.md发布日期 2026-03-16撰写完整解读 OpenProject 17.2.1 版本中的两项安全修复CVE-2026-32698 与 CVE-2026-32703及其攻击原理并结合仓库源码展示修复后的关键实现同时给出该版本的全部缺陷修复清单。读完后你将理解这两条漏洞链是如何形成的、官方在哪个环节切断了攻击路径以及自托管 OpenProject 时为何必须升级到最新版本。版本概览OpenProject 17.2.1 是一个安全修复版本。官方明确建议所有部署实例更新到该版本因为它包含两项高危安全修复以及若干缺陷修复。从发布说明的结构看本版本没有新增功能核心内容集中在Security fixes两个 CVE 级别的漏洞修复涉及 SQL 注入、任意路径写入、CSPContent Security Policy内容安全策略绕过与持久化 XSSBug fixes and changes5 项具体缺陷修复覆盖 CKEditor、Jira 导入、Nextcloud 存储、SMTP/TLS 邮件测试以及 Docker slim 镜像等场景。由于 17.2.1 紧跟 17.2.0 发布发布说明中即修复了17.2.0 中 slim 镜像被移除 curl的回归问题对于停留在 17.2.0 的实例而言升级到 17.2.1 属于强烈建议的安全操作。安全修复一CVE-2026-32698——自定义字段名 SQL 注入可链式升级为远程代码执行漏洞原理两个独立缺陷组成的攻击链根据发布说明CVE-2026-32698 并非单点漏洞而是一条由两个缺陷串联而成的攻击链第一环Cost Report 中的 SQL 注入。当攻击者控制的自定义字段被用于 Cost Report成本报表时该自定义字段的名称未经适当净化即被注入 SQL 查询使得攻击者能够在生成成本报表时执行任意 SQL 命令。值得注意的是发布说明指出自定义字段只能由拥有完整管理员权限的用户创建因此该注入点的攻击面相对受限——但正如其与第二环的联动所示管理员级权限的写入操作一旦被注入语句驱动后果远超常规 SQL 注入。第二环Repositories 模块的任意路径 checkout。发布说明描述Repositories代码仓库模块存在一个独立缺陷模块使用项目标识符project identifier生成 git 仓库在服务器文件系统上的 checkout 路径时未对该标识符做净化。攻击者可借此让应用把某个 git 仓库 checkout 到服务器上任意选定的路径。升级为 RCE 的关键一步。如果恶意 checkout 的落点恰好位于 OpenProject 应用内部的某些路径那么在下一次应用重启时checkout 出的文件会被应用当作自身代码/资产加载攻击者因此可以向应用中注入 Ruby 代码实现远程代码执行RCE。两环如何串联。发布说明特别说明项目标识符无法通过常规界面手动改成包含点号、斜杠等特殊字符的任意字符串因此第二环本身难以直接触发——必须借助第一环的 SQL 注入去篡改数据库中的项目标识符才能构造出能驱动任意路径 checkout 的输入。这正是该漏洞被定级为严重可链式 RCE的原因。仓库源码中的对应实现在当前的 17.2.1 代码库中Repositories 模块入口位于 app/controllers/repositories_controller.rb。其中find_repository方法负责所有仓库页面请求前的准备工作包括准备 checkout 说明信息约 repositories_controller.rb#L302-L328def find_repository repository project.repository unless repository render_404 return false end # Prepare checkout instructions # available on all pages (even empty!) path params[:repo_path] || instructions ::SCM::CheckoutInstructionsService.new(repository, path: path) # Asserts repository availability, or renders an appropriate error repository.scm.check_availability! ... end可以看到 checkout 路径由params[:repo_path]传入并经SCM::CheckoutInstructionsService处理这与发布说明中使用项目标识符生成 checkout 路径的描述对应。由于本仓库为修复后的版本具体净化逻辑分散在 SCM 层从源码结构看修复重点在于路径生成与落盘前的合法性校验而非在控制器层简单拼串。Cost Report 相关实现位于modules/costs模块其服务层目录结构见 modules/costs/app/services/报表相关的自定义字段属性组装逻辑集中在该模块的报表/属性处理代码中。发布说明明确指出注入发生在自定义字段名称拼入 SQL 的环节修复即对该名称做了参数化处理。该漏洞由用户 sam91281 在 YesWeHack.com 的 OpenProject Bug Bounty 项目欧洲委员会赞助中报告官方安全公告编号为 GHSA-jqhf-rf9x-9rhx。安全修复二CVE-2026-32703——仓库原始文件按文件名 MIME 类型下发导致 CSP 绕过漏洞原理raw 文件 URL 变成了合法 JS 分发点当项目启用了 Repositories 模块时用户此前可以通过形如/projects/{project}/repository/revisions/{commit_id}/raw/{file}.js.raw的 URL 在浏览器中直接访问仓库内文件的原始内容。漏洞在于这些文件的 MIME 类型是按文件扩展名检测得出的。也就是说仓库里一个名为x.js或x.css的文件会以与主应用同一域名、且携带正确的 active content MIME 类型如text/javascript下发。从浏览器与 CSP 的视角看同一域下带正确 JS/CSS MIME 类型的资源是可信可执行的——攻击者可利用这一点绕过应用的 Content Security Policy。发布说明进一步指出配合其他未净化 HTML 被下发的环节这允许构造持久化 XSS 攻击。官方此次的修复策略是移除针对仓库文件的 MIME 类型检测一律以application/octet-stream下发从而让 CSP 直接阻断其执行。仓库源码中的修复实现修复后的实现可以在 app/controllers/repositories_controller.rb 中找到核心是send_raw与raw_or_to_large_or_non_text两个方法约 repositories_controller.rb#L443-L455def raw_or_to_large_or_non_text(content, path) params[:format] raw || (content.size content.size Setting.file_max_size_displayed.to_i.kilobyte) || !entry_text_data?(content, path) end def send_raw(content, path) # Force the download as binary to prevent CSP bypass send_data content, filename: filename_for_content_disposition(path.split(/).last), type: application/octet-stream, disposition: :attachment end代码中的注释Force the download as binary to prevent CSP bypass强制以二进制方式下载以防止 CSP 绕过直接点明了修复意图无论文件扩展名是什么一律type: application/octet-stream且disposition: :attachment浏览器因此只能将其作为附件下载而不会按 JS/CSS 执行——这正是发布说明中以application/octet-stream下发的源码级印证。同时raw_or_to_large_or_non_text给出了走 raw 下发的三个条件URL 显式请求raw格式、内容超过Setting.file_max_size_displayed以 KB 计的显示上限配置配置值、或内容判定为非文本数据。同源漏洞一并修复的两处 XSS 注入点发布说明指出利用该 MIME 缺陷的两个具体滥用点也已被修复仓库文件名的 HTML 注入。Repositories 模块此前未正确转义从仓库中显示的文件名。拥有 push 权限的攻击者可以提交包含 HTML 代码的文件名当该文件在某个 changeset 中被删除、相关页面展示该 changeset 时恶意 HTML 未经净化即被注入页面对项目内所有访问仓库页面的成员构成持久化 XSS。工作包名称在活动流中的 HTML 注入。当工作包名称包含 HTML 内容、且该工作包被附加到某个 meeting会议时其名称会在 activities活动信息流中未经适当净化地渲染出来。这些漏洞同样由 sam91281 在同一 Bug Bounty 项目中报告官方安全公告编号为 GHSA-p423-72h4-fjvp。其他缺陷修复清单发布说明的自动化变更区Bug fixes and changes列出了 17.2.1 的 5 项缺陷修复对应官方 issue 编号如下修复内容说明Issue截图与 CKEditor 工具栏重叠滚动页面时截图遮挡 CKEditor 工具栏的显示问题#72678Jira 导入类型冲突报错导入类型与 OpenProject 中已有类型相同且带必填自定义字段时的导入报错#72854Nextcloud AMPF 文件夹创建失败连带影响创建 AMPF 文件夹失败时其他文件夹也一并无法创建#72940SMTP TLS 测试邮件失败使用 SMTP 且启用 TLS 时发送测试邮件失败#73099slim 镜像缺失 curl17.2.0 中openproject/openproject:17-slim镜像意外移除了 curl本版恢复#73142其中slim 镜像被移除 curl一项值得运维注意使用 Docker slim 镜像部署 OpenProject 的实例在 17.2.0 中如果依赖容器内的curl做健康检查或调试脚本会受到影响17.2.1 已将其恢复。升级建议与适用前提升级优先级本版本包含可链式 RCE 的 SQL 注入CVE-2026-32698与 CSP 绕过 持久化 XSSCVE-2026-32703凡运行 17.2.0 或更早版本的自托管/云实例均应升级到 17.2.1 或更新版本。攻击前提回顾CVE-2026-32698 的完整利用链需要能创建自定义字段的管理员级上下文 篡改项目标识符 触发特定路径 checkout 应用重启条件苛刻但后果严重CVE-2026-32703 的 XSS 则需要对目标仓库拥有 push 权限或对会议/工作包数据的写入能力。即使认为自身不满足这些前提官方仍建议直接更新。验证方式升级后如需确认修复生效可在启用 Repositories 模块的项目中通过上述raw/...js.raw形式 URL 访问仓库内 JS 文件确认响应被强制为附件下载而非可执行的text/javascript相关实现即 send_raw。本版本发布说明同时向社区贡献者致谢特别感谢 Martin Pfister 在本轮缺陷报告中的贡献。发布说明原文见 docs/release-notes/17-2-1/README.md。【免费下载链接】openprojectOpenProject is the leading open source project management software for product, project and portfolio management. A powerful Jira alternative with agile planning, issue tracking, roadmaps, Gantt charts, time tracking, collaboration features, and more. Available on premises or in the cloud. ⭐ Star us on GitHub项目地址: https://gitcode.com/GitHub_Trending/op/openproject创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenProject 17.2.1 发布解析：修复“自定义字段 SQL 注入 → 远程代码执行“攻击链与仓库文件 CSP 绕过漏洞
OpenProject 17.2.1 发布解析修复自定义字段 SQL 注入 → 远程代码执行攻击链与仓库文件 CSP 绕过漏洞【免费下载链接】openprojectOpenProject is the leading open source project management software for product, project and portfolio management. A powerful Jira alternative with agile planning, issue tracking, roadmaps, Gantt charts, time tracking, collaboration features, and more. Available on premises or in the cloud. ⭐ Star us on GitHub项目地址: https://gitcode.com/GitHub_Trending/op/openproject本文基于 OpenProject 官方发布说明docs/release-notes/17-2-1/README.md发布日期 2026-03-16撰写完整解读 OpenProject 17.2.1 版本中的两项安全修复CVE-2026-32698 与 CVE-2026-32703及其攻击原理并结合仓库源码展示修复后的关键实现同时给出该版本的全部缺陷修复清单。读完后你将理解这两条漏洞链是如何形成的、官方在哪个环节切断了攻击路径以及自托管 OpenProject 时为何必须升级到最新版本。版本概览OpenProject 17.2.1 是一个安全修复版本。官方明确建议所有部署实例更新到该版本因为它包含两项高危安全修复以及若干缺陷修复。从发布说明的结构看本版本没有新增功能核心内容集中在Security fixes两个 CVE 级别的漏洞修复涉及 SQL 注入、任意路径写入、CSPContent Security Policy内容安全策略绕过与持久化 XSSBug fixes and changes5 项具体缺陷修复覆盖 CKEditor、Jira 导入、Nextcloud 存储、SMTP/TLS 邮件测试以及 Docker slim 镜像等场景。由于 17.2.1 紧跟 17.2.0 发布发布说明中即修复了17.2.0 中 slim 镜像被移除 curl的回归问题对于停留在 17.2.0 的实例而言升级到 17.2.1 属于强烈建议的安全操作。安全修复一CVE-2026-32698——自定义字段名 SQL 注入可链式升级为远程代码执行漏洞原理两个独立缺陷组成的攻击链根据发布说明CVE-2026-32698 并非单点漏洞而是一条由两个缺陷串联而成的攻击链第一环Cost Report 中的 SQL 注入。当攻击者控制的自定义字段被用于 Cost Report成本报表时该自定义字段的名称未经适当净化即被注入 SQL 查询使得攻击者能够在生成成本报表时执行任意 SQL 命令。值得注意的是发布说明指出自定义字段只能由拥有完整管理员权限的用户创建因此该注入点的攻击面相对受限——但正如其与第二环的联动所示管理员级权限的写入操作一旦被注入语句驱动后果远超常规 SQL 注入。第二环Repositories 模块的任意路径 checkout。发布说明描述Repositories代码仓库模块存在一个独立缺陷模块使用项目标识符project identifier生成 git 仓库在服务器文件系统上的 checkout 路径时未对该标识符做净化。攻击者可借此让应用把某个 git 仓库 checkout 到服务器上任意选定的路径。升级为 RCE 的关键一步。如果恶意 checkout 的落点恰好位于 OpenProject 应用内部的某些路径那么在下一次应用重启时checkout 出的文件会被应用当作自身代码/资产加载攻击者因此可以向应用中注入 Ruby 代码实现远程代码执行RCE。两环如何串联。发布说明特别说明项目标识符无法通过常规界面手动改成包含点号、斜杠等特殊字符的任意字符串因此第二环本身难以直接触发——必须借助第一环的 SQL 注入去篡改数据库中的项目标识符才能构造出能驱动任意路径 checkout 的输入。这正是该漏洞被定级为严重可链式 RCE的原因。仓库源码中的对应实现在当前的 17.2.1 代码库中Repositories 模块入口位于 app/controllers/repositories_controller.rb。其中find_repository方法负责所有仓库页面请求前的准备工作包括准备 checkout 说明信息约 repositories_controller.rb#L302-L328def find_repository repository project.repository unless repository render_404 return false end # Prepare checkout instructions # available on all pages (even empty!) path params[:repo_path] || instructions ::SCM::CheckoutInstructionsService.new(repository, path: path) # Asserts repository availability, or renders an appropriate error repository.scm.check_availability! ... end可以看到 checkout 路径由params[:repo_path]传入并经SCM::CheckoutInstructionsService处理这与发布说明中使用项目标识符生成 checkout 路径的描述对应。由于本仓库为修复后的版本具体净化逻辑分散在 SCM 层从源码结构看修复重点在于路径生成与落盘前的合法性校验而非在控制器层简单拼串。Cost Report 相关实现位于modules/costs模块其服务层目录结构见 modules/costs/app/services/报表相关的自定义字段属性组装逻辑集中在该模块的报表/属性处理代码中。发布说明明确指出注入发生在自定义字段名称拼入 SQL 的环节修复即对该名称做了参数化处理。该漏洞由用户 sam91281 在 YesWeHack.com 的 OpenProject Bug Bounty 项目欧洲委员会赞助中报告官方安全公告编号为 GHSA-jqhf-rf9x-9rhx。安全修复二CVE-2026-32703——仓库原始文件按文件名 MIME 类型下发导致 CSP 绕过漏洞原理raw 文件 URL 变成了合法 JS 分发点当项目启用了 Repositories 模块时用户此前可以通过形如/projects/{project}/repository/revisions/{commit_id}/raw/{file}.js.raw的 URL 在浏览器中直接访问仓库内文件的原始内容。漏洞在于这些文件的 MIME 类型是按文件扩展名检测得出的。也就是说仓库里一个名为x.js或x.css的文件会以与主应用同一域名、且携带正确的 active content MIME 类型如text/javascript下发。从浏览器与 CSP 的视角看同一域下带正确 JS/CSS MIME 类型的资源是可信可执行的——攻击者可利用这一点绕过应用的 Content Security Policy。发布说明进一步指出配合其他未净化 HTML 被下发的环节这允许构造持久化 XSS 攻击。官方此次的修复策略是移除针对仓库文件的 MIME 类型检测一律以application/octet-stream下发从而让 CSP 直接阻断其执行。仓库源码中的修复实现修复后的实现可以在 app/controllers/repositories_controller.rb 中找到核心是send_raw与raw_or_to_large_or_non_text两个方法约 repositories_controller.rb#L443-L455def raw_or_to_large_or_non_text(content, path) params[:format] raw || (content.size content.size Setting.file_max_size_displayed.to_i.kilobyte) || !entry_text_data?(content, path) end def send_raw(content, path) # Force the download as binary to prevent CSP bypass send_data content, filename: filename_for_content_disposition(path.split(/).last), type: application/octet-stream, disposition: :attachment end代码中的注释Force the download as binary to prevent CSP bypass强制以二进制方式下载以防止 CSP 绕过直接点明了修复意图无论文件扩展名是什么一律type: application/octet-stream且disposition: :attachment浏览器因此只能将其作为附件下载而不会按 JS/CSS 执行——这正是发布说明中以application/octet-stream下发的源码级印证。同时raw_or_to_large_or_non_text给出了走 raw 下发的三个条件URL 显式请求raw格式、内容超过Setting.file_max_size_displayed以 KB 计的显示上限配置配置值、或内容判定为非文本数据。同源漏洞一并修复的两处 XSS 注入点发布说明指出利用该 MIME 缺陷的两个具体滥用点也已被修复仓库文件名的 HTML 注入。Repositories 模块此前未正确转义从仓库中显示的文件名。拥有 push 权限的攻击者可以提交包含 HTML 代码的文件名当该文件在某个 changeset 中被删除、相关页面展示该 changeset 时恶意 HTML 未经净化即被注入页面对项目内所有访问仓库页面的成员构成持久化 XSS。工作包名称在活动流中的 HTML 注入。当工作包名称包含 HTML 内容、且该工作包被附加到某个 meeting会议时其名称会在 activities活动信息流中未经适当净化地渲染出来。这些漏洞同样由 sam91281 在同一 Bug Bounty 项目中报告官方安全公告编号为 GHSA-p423-72h4-fjvp。其他缺陷修复清单发布说明的自动化变更区Bug fixes and changes列出了 17.2.1 的 5 项缺陷修复对应官方 issue 编号如下修复内容说明Issue截图与 CKEditor 工具栏重叠滚动页面时截图遮挡 CKEditor 工具栏的显示问题#72678Jira 导入类型冲突报错导入类型与 OpenProject 中已有类型相同且带必填自定义字段时的导入报错#72854Nextcloud AMPF 文件夹创建失败连带影响创建 AMPF 文件夹失败时其他文件夹也一并无法创建#72940SMTP TLS 测试邮件失败使用 SMTP 且启用 TLS 时发送测试邮件失败#73099slim 镜像缺失 curl17.2.0 中openproject/openproject:17-slim镜像意外移除了 curl本版恢复#73142其中slim 镜像被移除 curl一项值得运维注意使用 Docker slim 镜像部署 OpenProject 的实例在 17.2.0 中如果依赖容器内的curl做健康检查或调试脚本会受到影响17.2.1 已将其恢复。升级建议与适用前提升级优先级本版本包含可链式 RCE 的 SQL 注入CVE-2026-32698与 CSP 绕过 持久化 XSSCVE-2026-32703凡运行 17.2.0 或更早版本的自托管/云实例均应升级到 17.2.1 或更新版本。攻击前提回顾CVE-2026-32698 的完整利用链需要能创建自定义字段的管理员级上下文 篡改项目标识符 触发特定路径 checkout 应用重启条件苛刻但后果严重CVE-2026-32703 的 XSS 则需要对目标仓库拥有 push 权限或对会议/工作包数据的写入能力。即使认为自身不满足这些前提官方仍建议直接更新。验证方式升级后如需确认修复生效可在启用 Repositories 模块的项目中通过上述raw/...js.raw形式 URL 访问仓库内 JS 文件确认响应被强制为附件下载而非可执行的text/javascript相关实现即 send_raw。本版本发布说明同时向社区贡献者致谢特别感谢 Martin Pfister 在本轮缺陷报告中的贡献。发布说明原文见 docs/release-notes/17-2-1/README.md。【免费下载链接】openprojectOpenProject is the leading open source project management software for product, project and portfolio management. A powerful Jira alternative with agile planning, issue tracking, roadmaps, Gantt charts, time tracking, collaboration features, and more. Available on premises or in the cloud. ⭐ Star us on GitHub项目地址: https://gitcode.com/GitHub_Trending/op/openproject创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考