OpenProject 16.6.4 安全补丁深度解析CVE-2026-22600 任意文件读取漏洞的成因与防御【免费下载链接】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 16.6.4 是 2026 年 1 月 8 日发布的安全维护版本核心任务是修复一个存在于工作包 PDF 导出功能中的高危漏洞CVE-2026-22600正文标注为 CVE-2026-22605攻击者上传伪装成 PNG 的恶意 SVG 附件即可在 PDF 导出时利用 ImageMagick 的text:coder 读取服务器上应用用户权限范围内的任意本地文件。本文将完整梳理该漏洞的披露信息、攻击链的源码级还原附件 MIME 检测、PDF 图片嵌入与 ImageMagick 委派机制并结合仓库内置的 ImageMagick 安全策略 与 PDF 导出实现代码讲解修复方向与升级建议帮助运维与安全人员快速评估风险并完成防护。版本概览根据 版本发布说明发布版本OpenProject 16.6.4发布日期2026-01-08发布性质安全维护版本包含安全相关的 bug 修复升级建议官方强烈建议所有部署实例尽快升级到最新版本该版本仅包含一条自动生成的修复记录Bugfix: SVG attachments are interpreted as PNG工作包编号 #70349此处为发布说明中引用的官方工单链接文章后续不做展开。这条修复记录与下方 CVE 描述的漏洞根因直接对应理解这一点是把握本次版本的核心。CVE-2026-22600 漏洞详情漏洞类型与影响范围该漏洞被定义为本地文件读取Local File Read, LFR位于OpenProject 16.6.4 的工作包 PDF 导出功能中。漏洞编号在发布说明中同时出现了两种写法标题位置为 CVE-2026-22600正文中则注明 assigned to the CVE CVE-2026-22605官方安全通告以 GitHub AdvisoryGHSA-m8f2-cwpq-vvhh为准实际引用时建议核对公告中的最终编号。攻击路径描述官方发布说明给出的完整攻击链如下攻击者上传一个特制的 SVG 文件但伪装成 PNG作为工作包附件该附件触发后端图片处理引擎ImageMagick参与处理当该工作包被导出为 PDF时后端尝试对图片进行缩放resize缩放过程触发了 ImageMagick 的text:coder委派使攻击者得以读取应用运行用户权限范围内可访问的任意本地文件。可被读取的文件包括但不限于/etc/passwd等系统文件项目配置文件私有项目数据。披露渠道该漏洞通过YesWeHack 平台上的 OpenProject 漏洞赏金项目Bug Bounty Program由安全研究员 syndrome_imposter 负责任地披露该项目由欧盟委员会European Commission赞助。建议安全团队关注 官方安全公告 GHSA-m8f2-cwpq-vvhh 以获取补丁细节与影响版本矩阵。攻击链源码级还原为何伪装成 PNG 的 SVG能绕过检查要理解漏洞为何成立需要沿着 OpenProject 附件从上传、MIME 判定到 PDF 导出的完整代码路径走一遍。以下均为仓库当前代码含修复演进可验证的实现事实。第一步附件 MIME 类型检测OpenProject 在上传时通过系统file命令探测真实 MIME 类型而非信任用户提交的Content-Type。核心实现位于 lib/open_project/content_type_detector.rb调用 FileCommandContentTypeDetector 执行file -b --mime -- path解析出 MIME 与字符集当探测失败或文件不存在时回退到安全默认值application/binary源码注释明确说明其比application/octet-stream更安全最终结果写入附件的content_type字段见 app/models/attachment.rb 中的set_content_type。file命令依赖**魔数magic bytes**识别格式。SVG 是纯文本 XML其内容以?xml或svg开头若攻击者在文件头伪造 PNG 魔数\x89PNG\r\n\x1a\n在 XML 注释中也可写入任意字节file命令就可能将其判定为image/png从而被 OpenProject 记录为 PNG 附件——这正是伪装成 PNG 的 SVG能够进入系统的原因之一。第二步PDF 导出的图片嵌入白名单工作包导出 PDF 时附件图片的嵌入逻辑位于 app/models/exports/pdf/common/attachments.rb核心流程为attachment_image_filepath通过attachment_by_api_content_src解析 markdown 中的图片 src仅接受本实例 API 路径/api/v3/attachments/:id/content或拖拽路径/attachments/:id/filename.ext下的可见附件调用pdf_embeddable?按content_type 白名单过滤白名单仅包含image/jpeg、image/png、image/gif、image/webp见 attachments.rb 第 44-46 行——image/svgxml本身不在白名单内对应的测试用例也验证了这一点见 spec/models/exports/pdf/common/attachments_spec.rb若 content_type 被污染SVG 被记录成 PNG该 SVG 就能通过白名单进入下一步GIF/WebP 会先转换为 PNG最终调用resize_image交由 MiniMagick/ImageMagick 处理。第三步ImageMagick 的 coder 委派是漏洞引爆点resize_image的实现如下attachments.rb 第 34-42 行def resize_image(file_path) tmp_file temp_image_file(File.extname(file_path)) image MiniMagick::Image.open(file_path) image.resize(x800) image.write(tmp_file) tmp_file endMiniMagick是 ImageMagick 命令行的 Ruby 封装见 Gemfile 中 mini_magick 依赖及 attachments.rb 第 31 行 的require mini_magick。ImageMagick 在解码图像时会根据文件内容选择 coder解析器其中text:是 ImageMagick 的内置伪协议text:/etc/passwd会把目标文本文件当作图像读取。当恶意 SVG 以image/png的身份进入MiniMagick::Image.open并执行 resize 时SVG 内部的text:引用会被 coder 委派解析从而把服务器本地文件内容带入图像解码流程最终被导出到 PDF 中——攻击者便拿到了应用用户可读的任意文件内容。仓库内置防御ImageMagick 安全策略解读OpenProject 仓库随附了一份面向 Web 环境的 ImageMagick 安全策略模板 config/imagemagick/policy.xml它是理解本漏洞防护方向的第一手材料。其设计目标正如文件头注释所述在公开访问场景如网站中仅允许 GIF/JPEG/PNG 等 Web 安全格式的读写禁止执行图像滤镜与间接读取。关键策略逐条解读策略含义对应防护policy domaindelegate rightsnone pattern*/禁止一切 delegate外部命令委派执行阻断text:等伪协议背后的外部命令/文件访问委派policy domaincoder rightsnone patternTEXT/显式禁用TEXTcoder直接封堵本漏洞利用的text:读取通道policy domainmodule rightsread \| write pattern{GIF,JPEG,PNG,WEBP}/仅允许 Web 安全格式的模块读写缩小可被 coder 解析的格式面policy domainpath rightsnone pattern/etc/*/禁止读取敏感路径阻止读取/etc/passwd等系统文件policy domainpath rightsnone pattern*/禁止间接读取file语法防 ImageTragick 风格的间接文件读取policy domainpath rightsnone pattern-/禁止读写 stdin/stdout防管道与命令行注入policy domaincoder rightsnone pattern{PDF,EPHEMERAL,URL,HTTPS,MVG,MSL,SHOW,WIN,PLT}/禁用高危 coder覆盖 ImageTragickCVE-2016-3714等历史攻击面policy domainfilter rightsnone pattern*/禁止加载图像滤镜防滤镜相关利用部署前提与限制该文件是仓库提供的策略模板实际生效与否取决于部署方式。Docker 镜像的安装脚本 docker/prod/setup/preinstall-common.sh 会通过 apt 安装imagemagick系统包策略文件是否随容器一并写入取决于 Dockerfile 与配置编排。使用发行版包或自编译 ImageMagick 的实例需要自行确认/etc/ImageMagick-6/policy.xml或对应版本路径已应用上述策略。运维人员可用 ImageMagick 官方提供的策略校验工具验证配置有效性。修复方向为什么 SVG attachments are interpreted as PNG 是根因修复本次 16.6.4 的 bugfix工单 #70349标题为 SVG attachments are interpreted as PNG它直接指向漏洞根因——MIME 类型误判若在上传阶段就纠正 MIME 判定使 SVG 被正确记录为image/svgxml则 PDF 导出白名单pdf_embeddable?会将其拒之门外image/svgxml不在白名单测试用例见 attachments_spec.rb 第 50-54 行恶意文件根本无法进入 ImageMagick 处理流程从源码结构看lib/open_project/content_type_detector.rb 与 lib/open_project/mime_type.rb 中INLINE_IMAGE_TYPES的格式列举修复可发生在file命令结果解析、MIME 归一化或 PDF 导出前的二次校验等多个环节。对于用户而言修复的本质是确保 SVG 附件不再被当作 PNG 解释从而切断整条攻击链的第一步。这也解释了为何官方在发布说明中将该版本定性为包含安全相关 bug 修复并强烈建议更新。升级与防护建议立即升级到 16.6.4 或更高版本这是消除漏洞的根本手段发布说明明确呼吁所有部署实例尽快升级。核对 ImageMagick 安全策略确认运行环境中的policy.xml已禁用TEXTcoder、禁用 delegate、禁止读取/etc/*等敏感路径可参考仓库模板 config/imagemagick/policy.xml 并结合自身环境微调若使用 Docker 部署检查基础镜像中策略文件的落盘位置。关注官方安全公告以 GitHub AdvisoryGHSA-m8f2-cwpq-vvhh为准核对最终 CVE 编号发布说明标题与正文编号写法不一致、受影响版本范围与补丁内容。收紧附件策略如业务允许可在文件上传层面对 SVG/XML 类纯文本格式做额外校验或直接禁用降低同类 MIME 误判风险。参考与延伸阅读版本发布说明docs/release-notes/16/16-6-4/README.mdImageMagick 安全策略模板config/imagemagick/policy.xmlPDF 导出附件处理实现app/models/exports/pdf/common/attachments.rbPDF 附件处理测试spec/models/exports/pdf/common/attachments_spec.rbMIME 检测实现lib/open_project/content_type_detector.rb 与 lib/open_project/file_command_content_type_detector.rb附件模型与 MIME 映射app/models/attachment.rb 与 lib/open_project/mime_type.rbDocker 环境 ImageMagick 安装docker/prod/setup/preinstall-common.sh【免费下载链接】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 16.6.4 安全补丁深度解析：CVE-2026-22600 任意文件读取漏洞的成因与防御
OpenProject 16.6.4 安全补丁深度解析CVE-2026-22600 任意文件读取漏洞的成因与防御【免费下载链接】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 16.6.4 是 2026 年 1 月 8 日发布的安全维护版本核心任务是修复一个存在于工作包 PDF 导出功能中的高危漏洞CVE-2026-22600正文标注为 CVE-2026-22605攻击者上传伪装成 PNG 的恶意 SVG 附件即可在 PDF 导出时利用 ImageMagick 的text:coder 读取服务器上应用用户权限范围内的任意本地文件。本文将完整梳理该漏洞的披露信息、攻击链的源码级还原附件 MIME 检测、PDF 图片嵌入与 ImageMagick 委派机制并结合仓库内置的 ImageMagick 安全策略 与 PDF 导出实现代码讲解修复方向与升级建议帮助运维与安全人员快速评估风险并完成防护。版本概览根据 版本发布说明发布版本OpenProject 16.6.4发布日期2026-01-08发布性质安全维护版本包含安全相关的 bug 修复升级建议官方强烈建议所有部署实例尽快升级到最新版本该版本仅包含一条自动生成的修复记录Bugfix: SVG attachments are interpreted as PNG工作包编号 #70349此处为发布说明中引用的官方工单链接文章后续不做展开。这条修复记录与下方 CVE 描述的漏洞根因直接对应理解这一点是把握本次版本的核心。CVE-2026-22600 漏洞详情漏洞类型与影响范围该漏洞被定义为本地文件读取Local File Read, LFR位于OpenProject 16.6.4 的工作包 PDF 导出功能中。漏洞编号在发布说明中同时出现了两种写法标题位置为 CVE-2026-22600正文中则注明 assigned to the CVE CVE-2026-22605官方安全通告以 GitHub AdvisoryGHSA-m8f2-cwpq-vvhh为准实际引用时建议核对公告中的最终编号。攻击路径描述官方发布说明给出的完整攻击链如下攻击者上传一个特制的 SVG 文件但伪装成 PNG作为工作包附件该附件触发后端图片处理引擎ImageMagick参与处理当该工作包被导出为 PDF时后端尝试对图片进行缩放resize缩放过程触发了 ImageMagick 的text:coder委派使攻击者得以读取应用运行用户权限范围内可访问的任意本地文件。可被读取的文件包括但不限于/etc/passwd等系统文件项目配置文件私有项目数据。披露渠道该漏洞通过YesWeHack 平台上的 OpenProject 漏洞赏金项目Bug Bounty Program由安全研究员 syndrome_imposter 负责任地披露该项目由欧盟委员会European Commission赞助。建议安全团队关注 官方安全公告 GHSA-m8f2-cwpq-vvhh 以获取补丁细节与影响版本矩阵。攻击链源码级还原为何伪装成 PNG 的 SVG能绕过检查要理解漏洞为何成立需要沿着 OpenProject 附件从上传、MIME 判定到 PDF 导出的完整代码路径走一遍。以下均为仓库当前代码含修复演进可验证的实现事实。第一步附件 MIME 类型检测OpenProject 在上传时通过系统file命令探测真实 MIME 类型而非信任用户提交的Content-Type。核心实现位于 lib/open_project/content_type_detector.rb调用 FileCommandContentTypeDetector 执行file -b --mime -- path解析出 MIME 与字符集当探测失败或文件不存在时回退到安全默认值application/binary源码注释明确说明其比application/octet-stream更安全最终结果写入附件的content_type字段见 app/models/attachment.rb 中的set_content_type。file命令依赖**魔数magic bytes**识别格式。SVG 是纯文本 XML其内容以?xml或svg开头若攻击者在文件头伪造 PNG 魔数\x89PNG\r\n\x1a\n在 XML 注释中也可写入任意字节file命令就可能将其判定为image/png从而被 OpenProject 记录为 PNG 附件——这正是伪装成 PNG 的 SVG能够进入系统的原因之一。第二步PDF 导出的图片嵌入白名单工作包导出 PDF 时附件图片的嵌入逻辑位于 app/models/exports/pdf/common/attachments.rb核心流程为attachment_image_filepath通过attachment_by_api_content_src解析 markdown 中的图片 src仅接受本实例 API 路径/api/v3/attachments/:id/content或拖拽路径/attachments/:id/filename.ext下的可见附件调用pdf_embeddable?按content_type 白名单过滤白名单仅包含image/jpeg、image/png、image/gif、image/webp见 attachments.rb 第 44-46 行——image/svgxml本身不在白名单内对应的测试用例也验证了这一点见 spec/models/exports/pdf/common/attachments_spec.rb若 content_type 被污染SVG 被记录成 PNG该 SVG 就能通过白名单进入下一步GIF/WebP 会先转换为 PNG最终调用resize_image交由 MiniMagick/ImageMagick 处理。第三步ImageMagick 的 coder 委派是漏洞引爆点resize_image的实现如下attachments.rb 第 34-42 行def resize_image(file_path) tmp_file temp_image_file(File.extname(file_path)) image MiniMagick::Image.open(file_path) image.resize(x800) image.write(tmp_file) tmp_file endMiniMagick是 ImageMagick 命令行的 Ruby 封装见 Gemfile 中 mini_magick 依赖及 attachments.rb 第 31 行 的require mini_magick。ImageMagick 在解码图像时会根据文件内容选择 coder解析器其中text:是 ImageMagick 的内置伪协议text:/etc/passwd会把目标文本文件当作图像读取。当恶意 SVG 以image/png的身份进入MiniMagick::Image.open并执行 resize 时SVG 内部的text:引用会被 coder 委派解析从而把服务器本地文件内容带入图像解码流程最终被导出到 PDF 中——攻击者便拿到了应用用户可读的任意文件内容。仓库内置防御ImageMagick 安全策略解读OpenProject 仓库随附了一份面向 Web 环境的 ImageMagick 安全策略模板 config/imagemagick/policy.xml它是理解本漏洞防护方向的第一手材料。其设计目标正如文件头注释所述在公开访问场景如网站中仅允许 GIF/JPEG/PNG 等 Web 安全格式的读写禁止执行图像滤镜与间接读取。关键策略逐条解读策略含义对应防护policy domaindelegate rightsnone pattern*/禁止一切 delegate外部命令委派执行阻断text:等伪协议背后的外部命令/文件访问委派policy domaincoder rightsnone patternTEXT/显式禁用TEXTcoder直接封堵本漏洞利用的text:读取通道policy domainmodule rightsread \| write pattern{GIF,JPEG,PNG,WEBP}/仅允许 Web 安全格式的模块读写缩小可被 coder 解析的格式面policy domainpath rightsnone pattern/etc/*/禁止读取敏感路径阻止读取/etc/passwd等系统文件policy domainpath rightsnone pattern*/禁止间接读取file语法防 ImageTragick 风格的间接文件读取policy domainpath rightsnone pattern-/禁止读写 stdin/stdout防管道与命令行注入policy domaincoder rightsnone pattern{PDF,EPHEMERAL,URL,HTTPS,MVG,MSL,SHOW,WIN,PLT}/禁用高危 coder覆盖 ImageTragickCVE-2016-3714等历史攻击面policy domainfilter rightsnone pattern*/禁止加载图像滤镜防滤镜相关利用部署前提与限制该文件是仓库提供的策略模板实际生效与否取决于部署方式。Docker 镜像的安装脚本 docker/prod/setup/preinstall-common.sh 会通过 apt 安装imagemagick系统包策略文件是否随容器一并写入取决于 Dockerfile 与配置编排。使用发行版包或自编译 ImageMagick 的实例需要自行确认/etc/ImageMagick-6/policy.xml或对应版本路径已应用上述策略。运维人员可用 ImageMagick 官方提供的策略校验工具验证配置有效性。修复方向为什么 SVG attachments are interpreted as PNG 是根因修复本次 16.6.4 的 bugfix工单 #70349标题为 SVG attachments are interpreted as PNG它直接指向漏洞根因——MIME 类型误判若在上传阶段就纠正 MIME 判定使 SVG 被正确记录为image/svgxml则 PDF 导出白名单pdf_embeddable?会将其拒之门外image/svgxml不在白名单测试用例见 attachments_spec.rb 第 50-54 行恶意文件根本无法进入 ImageMagick 处理流程从源码结构看lib/open_project/content_type_detector.rb 与 lib/open_project/mime_type.rb 中INLINE_IMAGE_TYPES的格式列举修复可发生在file命令结果解析、MIME 归一化或 PDF 导出前的二次校验等多个环节。对于用户而言修复的本质是确保 SVG 附件不再被当作 PNG 解释从而切断整条攻击链的第一步。这也解释了为何官方在发布说明中将该版本定性为包含安全相关 bug 修复并强烈建议更新。升级与防护建议立即升级到 16.6.4 或更高版本这是消除漏洞的根本手段发布说明明确呼吁所有部署实例尽快升级。核对 ImageMagick 安全策略确认运行环境中的policy.xml已禁用TEXTcoder、禁用 delegate、禁止读取/etc/*等敏感路径可参考仓库模板 config/imagemagick/policy.xml 并结合自身环境微调若使用 Docker 部署检查基础镜像中策略文件的落盘位置。关注官方安全公告以 GitHub AdvisoryGHSA-m8f2-cwpq-vvhh为准核对最终 CVE 编号发布说明标题与正文编号写法不一致、受影响版本范围与补丁内容。收紧附件策略如业务允许可在文件上传层面对 SVG/XML 类纯文本格式做额外校验或直接禁用降低同类 MIME 误判风险。参考与延伸阅读版本发布说明docs/release-notes/16/16-6-4/README.mdImageMagick 安全策略模板config/imagemagick/policy.xmlPDF 导出附件处理实现app/models/exports/pdf/common/attachments.rbPDF 附件处理测试spec/models/exports/pdf/common/attachments_spec.rbMIME 检测实现lib/open_project/content_type_detector.rb 与 lib/open_project/file_command_content_type_detector.rb附件模型与 MIME 映射app/models/attachment.rb 与 lib/open_project/mime_type.rbDocker 环境 ImageMagick 安装docker/prod/setup/preinstall-common.sh【免费下载链接】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），仅供参考