Keras与Skops安全模式漏洞解析：模型序列化中的任意代码执行风险

1. 项目概述：当“安全模式”不再安全

在机器学习项目的日常协作和部署中，模型共享是一个再普通不过的环节。无论是团队内部传递一个训练好的图像分类器，还是在Hugging Face Hub上发布一个开源的大语言模型，我们都需要将模型从内存中的复杂对象，转换成一个可以存储、传输的文件。这个过程，就是序列化与反序列化。长久以来，社区里流传着一种“常识”：使用基于数据的格式（比如JSON、HDF5）来保存模型，比那些基于代码的格式（比如Python的pickle）要安全得多。毕竟，JSON文件里只是一堆文本数据，看起来人畜无害。

基于这种认知，主流框架也推出了相应的“安全”功能。Keras框架的safe_mode和Skops库的“安全持久化”机制，就是其中的典型代表。它们的设计初衷，是试图在保持模型灵活性的同时，为反序列化过程筑起一道安全围墙。许多开发者，包括曾经的我，都曾对这些标志抱有信任，认为只要打开了safe_mode=True，或者使用了Skops格式，从网上下载的模型文件就是相对安全的。

然而，最近一系列深入的安全研究，包括对Keras和Skops核心代码的手动逆向工程，彻底颠覆了这一认知。研究发现，在这两个宣称提供安全加载机制的框架中，存在至少六个零日漏洞（均已获得CVE编号），每一个都可能导致在模型加载阶段执行任意代码。更令人深思的是，这些漏洞的根源并非高深的攻击手法，而恰恰源于安全机制设计本身的缺陷和验证逻辑的不完备。与此同时，像Hugging Face Hub这样集成了安全扫描工具的平台，其检测能力在面对这些新型框架级漏洞时也显得力不从心，出现了明显的漏报和误报。

这篇文章，我将从一个一线开发者和安全研究者的双重角度，深入拆解这些漏洞的原理、框架安全机制的局限性，以及当前模型扫描工具的不足。这不是一篇危言耸听的恐吓文，而是一份基于实际漏洞分析的深度技术复盘。目的是让我们重新审视模型共享过程中的安全假设，理解“安全模式”背后真实的风险边界，并掌握在现有生态下更稳妥的实践策略。

2. 框架安全机制的设计理念与固有局限

在深入漏洞细节之前，我们必须先理解Keras和Skops所宣称的安全机制究竟试图解决什么问题，以及它们的基本设计思路。这有助于我们看清，漏洞为何会产生，以及它们是否意味着整个设计方向的失败。

2.1 数据格式 vs. 代码格式：安全幻觉的源头

传统的Pythonpickle格式之所以危险，是因为它本质上是在序列化代码执行路径。它保存了如何重建一个对象的一系列指令，这些指令在反序列化时会直接映射到Python解释器的底层操作。一个恶意的pickle文件，可以包含调用os.system或eval的指令，从而在加载时执行任意命令。

Keras的.keras格式和Skops的.skops格式，则选择了另一条路：它们序列化的是模型的数据结构。一个Keras模型被保存为一个ZIP压缩包，里面包含用JSON描述的模型架构（config.json）和存储权重的二进制文件。Skops也类似，它使用JSON来定义对象的类型和状态。

这种设计的宣传点是：JSON是数据，不是代码。因此，攻击者无法直接将恶意代码“写”进文件。安全性转而依赖于加载器（loader）在将JSON数据“翻译”回Python对象时所施加的严格限制。例如，Keras的safe_mode会限制只能从受信任的Keras内部模块导入类；Skops则会要求用户明确批准（allowlist）那些非内置的、可能不安全的类型。

这里的核心误区在于：将“文件格式”与“安全属性”直接划等号。实际上，安全与否，完全取决于加载器在解析这些数据时，是否忠实地、无歧义地、且无漏洞地将数据映射回预期的、安全的对象。JSON描述的“layer”: {“class_name”: “Dense”, …}，最终还是要被加载器解释为keras.layers.Dense这个类的实例化过程。如果加载器的验证逻辑有漏洞，攻击者就可以通过精心构造的JSON数据，诱使加载器执行非预期的操作，比如导入subprocess模块并执行run函数。此时，数据格式就成了攻击载荷的载体，其危险性并不亚于直接的代码序列化。

注意：不要被“数据格式”这个词迷惑。任何需要被解释器或加载器动态解析、并用于重建运行时对象的数据格式，其安全性都完全取决于解析器的实现。XML外部实体（XXE）攻击就是数据格式（XML）被滥用的经典案例。

2.2 Kerassafe_mode：白名单机制的理想与现实

Keras的safe_mode（在keras.saving.load_model函数中）是其安全加载的核心。当启用时，它试图实施一个白名单策略。其理想的工作流程是：

1. 解析config.json，找到需要实例化的层或对象的类名（如“Dense”）。
2. 将该类名解析为具体的Python类。在safe_mode下，它只允许从一组受信任的模块（主要是keras自身的模块）中导入。
3. 使用JSON中提供的参数实例化该类。

这个设计的初衷是好的：通过限制类的来源，防止加载器导入并实例化像subprocess.run这样的危险函数。然而，其实现中的验证逻辑却存在多处纰漏，我们发现的漏洞KV.1和KV.2正是利用了这些纰漏。

KV.1的根源：不充分的类名解析验证最初的safe_mode验证存在一个关键盲点。它检查了最终解析到的对象是否是一个“可调用对象”（callable），但却没有足够严格地检查这个可调用对象的类型和来源。攻击者可以构造一个config.json，其中“class_name”指向一个完全合法的Python内置函数，例如“builtins.exec”或“subprocess.run”。由于这些函数本身就是可调用对象，且在某些情况下可能被意外地（或通过其他间接引用）纳入可解析的路径中，旧的验证逻辑会允许它通过。

# 简化版恶意 config.json 结构示意（非完整PoC） { “model”: { “class_name”: “Model”, “config”: { “layers”: [ { “class_name”: “subprocess.run”, // 攻击点：类名指向危险函数 “config”: { “args”: [“/bin/sh”], “shell”: true } } ] } } }

当Keras加载器试图实例化这个“层”时，它实际上会直接调用subprocess.run([“/bin/sh”], shell=True)，导致任意命令执行。这个漏洞（CVE-2025-1550）直接动摇了safe_mode的基础承诺：它未能阻止非Keras代码的执行。

官方修复与KV.2的迂回攻击针对KV.1，Keras 3.9版本进行了修复，强化了验证逻辑，采用了更严格的白名单，基本上只允许导入keras.*下的模块。

然而，KV.2（CVE-2025-9906）展示了在安全机制中常见的“道高一尺，魔高一丈”。攻击者不再直接导入外部模块，而是转向代码重用（Code Reuse）攻击，类似于二进制漏洞利用中的“ROP（Return-Oriented Programming）”链。Keras的Lambda层允许嵌入小的Python函数（以字节码或源码形式）。修复后的safe_mode对Lambda层的内容进行了限制。但攻击者发现，可以利用Lambda层来调用Keras内部的、已加载到内存中的工具函数。

例如，Keras内部有一个用于处理加载逻辑的实用函数。通过精心构造的Lambda层，攻击者可以调用这个内部函数，并传递参数，使其行为类似于exec或eval。更巧妙的是，攻击链中甚至可以包含一个步骤，先调用某个内部函数来动态地将safe_mode标志设置为False，从而完全解除后续的所有限制。这就像是用堡垒内部的钥匙，从里面打开了堡垒的大门。

这个漏洞揭示了一个更深层的问题：在一个庞大、复杂的框架代码库中，很难确保每一个内部函数都是“无害”的。当攻击者可以将这些函数像积木一样组合起来（即利用“gadgets”）时，即使有白名单，也可能构造出意外的执行路径。

2.3 Skops安全持久化：类型验证的边界与逃逸

Skops为scikit-learn模型设计，其安全模型基于类型验证和用户显式批准。它的.skops文件同样包含一个schema.json，用图结构描述对象。其安全核心是get_untrusted_types()和load(trusted)流程：加载时，Skops会检查模型中所有用到的类型，将不在内置可信列表中的类型报告给用户，由用户决定是否批准加载。

SV.1：滥用MethodNode进行对象图遍历MethodNode是Skops中一个强大的特性，它允许通过点号表示法（如obj.attr）访问对象的属性。其设计意图是安全地调用对象的方法。然而，其验证逻辑存在缺陷。攻击者可以这样构造攻击链：

1. 首先，让Skops加载一个看似无害的、用户可能会批准的类型，例如builtins.int（一个整数）。
2. 然后，通过一连串的MethodNode，从这个整数对象开始，遍历Python的对象图。例如：obj -> __class__ -> __base__ -> __subclasses__。这条链可以最终访问到__builtins__模块，从而获得eval或exec函数。
3. 关键漏洞在于，Skops在验证时，只检查了MethodNode中声明的__module__和__class__（即builtins.int），但没有严格验证后续通过func字段指定的属性访问链（如__class__）是否与初始对象的真实属性匹配。攻击者可以在func中写入任何属性名，实现“挂羊头卖狗肉”。

# 简化版恶意 schema.json 片段（SV.1思路） { “__type__”: “MethodNode”, “__module__”: “builtins”, “__class__”: “int”, // 验证时看到的是无害的 int “func”: “__class__”, // 但实际访问的是这个属性，开始了遍历链 “args”: [0], “next”: { // 链式调用下一个 MethodNode “__type__”: “MethodNode”, “__module__”: “builtins”, “__class__”: “type”, “func”: “__subclasses__”, “args”: [] // ... 后续可以连接到 __builtins__.eval } }

这样一来，用户批准加载的只是一个“整数”，但实际执行的却是通过这个整数对象为跳板，最终触发的任意代码执行。

SV.2：OperatorFuncNode的模块验证绕过OperatorFuncNode用于调用Pythonoperator模块中的函数（如operator.add）。其验证逻辑本应检查__module__是否为“operator”。但实现中出现了校验不一致：get_untrusted_types()报告给用户的是完整的__module__.__class__字符串（如“operator.add”），而实际的加载逻辑却忽略了__module__字段，只根据__class__字段的值（如“add”）去operator模块中查找函数。

攻击者可以利用这个不一致，将__module__设置为一个看似无害的、用户容易批准的值（如“numpy”），而将__class__设置为“call”。用户看到“numpy.call”可能会批准（以为是个NumPy函数），但Skops加载时却会执行operator.call。operator.call的功能是调用一个可调用对象，如果攻击者能通过其他节点控制这个对象和参数，就能实现任意函数调用，进而执行代码。

这两个Skops漏洞（CVE-2025-54413, CVE-2025-54412）的共同点在于，它们都利用了验证阶段与执行阶段的信息不对等。展示给用户审批的信息（“这是一个整数类型”）与实际执行时的能力（“通过这个整数访问整个运行时环境”）严重不符，使得用户审批机制形同虚设。

2.4 遗留格式的“静默杀手”：兼容性压倒安全性

无论是Keras对旧版HDF5格式的支持，还是Skops在模型卡片（Card）功能中静默回退到joblib的逻辑，都反映了一个现实问题：对遗留功能的兼容性需求，常常会悄然绕过新建立的安全防线。

KV.3：被忽略的safe_modeKeras的HDF5格式是旧版Keras 2的默认保存格式。当用户使用load_model(…, safe_mode=True)加载一个.h5文件时，他们理所当然地认为安全模式会生效。但事实上，这个safe_mode参数在内部根本没有传递给HDF5格式的加载例程。加载过程会无声无息地以不安全的方式进行。更糟糕的是，HDF5格式对Lambda层的内容没有任何限制，可以直接序列化任意Python字节码。这意味着，攻击者只需将恶意模型保存为.h5格式，就能轻易绕过所有safe_mode的保护，而用户却得不到任何警告。

这个漏洞（CVE-2025-9905）与其说是技术漏洞，不如说是设计缺陷和不良用户体验。它破坏了用户对API行为的信任预期。修复方式不是去“修补”HDF5加载器的安全性（这几乎不可能），而是将safe_mode标志传递给旧加载器，并使其能对Lambda层施加同样的限制，或者在无法保证安全时明确抛出警告。

SV.3：模型卡片的危险回退Skops的Card功能用于生成模型文档。当创建一个Card对象并关联一个模型文件时，Card.get_model()会被调用来加载模型。如果提供的文件是有效的.skopsZIP包，则走安全加载路径。但如果文件不是有效的ZIP包（例如，它是一个伪装成.skops的pickle文件），Skops会静默地回退到使用不安全的joblib.load()来加载它。

这个行为极其危险，因为它依赖于文件的实际内容而非扩展名。攻击者可以将一个恶意pickle文件命名为model.skops。用户和自动化工具看到.skops扩展名，可能认为它是安全的。Skops在尝试用ZIP格式打开失败后，却悄悄用joblib（基于pickle）加载了它，导致任意代码执行。这个漏洞（CVE-2025-54886）的修复方案是在回退到joblib时，要求用户通过显式的allow_pickle=True参数来授权，将风险决策交还给用户。

这两个案例给我们的教训是：任何安全机制，如果存在一条可以绕过它的、默认开启的“兼容性”路径，那么该机制的有效性就大打折扣。框架开发者必须在安全性和向后兼容性之间做出更明确的权衡，至少要通过显式选项和清晰警告来告知用户风险。

3. 模型扫描工具的局限性：并非万能护盾

当框架级别的安全机制失效时，人们自然会将希望寄托于模型共享平台（如Hugging Face Hub）集成的安全扫描工具。这些工具被宣传为在模型上传时提供额外的安全层。然而，我们的评估表明，它们的能力存在显著局限。

3.1 扫描工具的工作原理与固有短板

Hugging Face Hub集成了多个扫描器，主要包括：

1. Picklescan：专门检测Pickle文件中的恶意操作码（opcode）。它对非Pickle格式的文件基本无效。
2. ClamAV：传统反病毒引擎，用于检测已知的恶意软件签名。它对针对ML框架的定制化攻击载荷检测能力很弱。
3. Protect AI Guardian：一个专��于ML模型威胁的扫描器，定义了一系列针对特定框架（如Keras、PyTorch）的威胁规则。
4. JFrog Scanner：提供针对软件供应链的安全扫描，包括对某些模型格式的检查。

这些扫描器本质上属于静态分析工具。它们通过以下方式工作：

• 签名/模式匹配：检查文件内容中是否包含已知的危险字符串、代码模式或文件结构（如Picklescan找特定的opcode，Protect AI匹配其定义的威胁规则）。
• 格式解析与启发式分析：尝试解析模型文件，检查其结构是否异常，是否包含可疑的层或操作。

其局限性是显而易见的：

• 覆盖范围有限：它们通常只针对少数流行的、预先定义好的文件格式和框架威胁。对于Skops（.skops）这种较新的格式，在我们的测试中，没有任何扫描器提供支持。
• 应对新型漏洞乏力：扫描器依赖已知的威胁特征（签名）。对于像KV.1、KV.2、SV.1、SV.2这样的新型框架逻辑漏洞，在漏洞公开、扫描器更新规则之前，它们几乎无法检测。我们的PoC在漏洞公开数周后上传，部分扫描器仍然未能识别。
• 误报与漏报：Protect AI和JFrog Scanner对于包含Lambda层的Keras模型，无论其是否恶意，都倾向于标记为“可疑”或“不安全”。这产生了大量误报，可能导致“警报疲劳”，使用户忽视真正的威胁。同时，对于某些漏洞（如KV.2），扫描器甚至无法完成扫描（状态卡在“排队”）。

3.2 实测结果分析：安全标签的误导性

我们将针对Keras和Skops漏洞的PoC模型上传到Hugging Face Hub，观察扫描结果：

测试模型 (格式)	Picklescan	ClamAV	Protect AI	JFrog	最终标签
KV.1 (.keras)	非pickle	无问题	不安全	无问题	不安全
KV.2 (.keras)	非pickle	无问题	可疑	(卡住)	(卡住)
KV.3 (HDF5)	非pickle	无问题	(无结果)	不安全	不安全
SV.1 (.skops)	非pickle	无问题	无问题	非模型	安全
SV.2 (.skops)	非pickle	无问题	无问题	非模型	安全
SV.3 (pickle)	非pickle	无问题	不安全	不安全	不安全

关键发现：

1. 格式歧视：Picklescan仅对特定扩展名（如.pkl,.pt）的文件进行深度扫描。将恶意pickle文件重命名为.skops或.keras即可轻松绕过。这说明攻击者可以通过简单的文件重命名来规避检测。
2. 对新漏洞的盲区：对于Skops的SV.1和SV.2漏洞，所有扫描器均未报告问题。Protect AI显示“无问题”，JFrog显示“非模型”。由于没有扫描器支持.skops格式，Hugging Face Hub最终给出了**“安全”标签。这是最危险的漏报**，它给用户传递了完全错误的信心。
3. 粗糙的规则与误报：Protect AI对KV.2的检测结果是“可疑”，但其规则似乎是基于“模型包含Lambda层”这一简单特征，而非Lambda层内的具体行为。这导致包含良性Lambda层的模型也会被误报。这种“宁可错杀”的策略虽然谨慎，但降低了工具的可信度。
4. 不一致与不可靠：JFrog扫描器对KV.2的扫描任务一直处于“排队”状态，无法完成。这种不稳定性在实际安全流程中是不可接受的。

最终标签的聚合逻辑：Hugging Face Hub会取所有扫描器结果中最严重的一个作为最终标签。这虽然能弥补单个扫描器的漏报（如KV.1仅被Protect AI检出，但最终标签为“不安全”），但也放大了误报（良性Lambda层模型被标为“不安全”）。更重要的是，当所有扫描器都对某种格式“无结果”或“不支持”时，平台会错误地给出“安全”结论。

3.3 对平台与用户的启示

对于模型共享平台而言，当前的扫描工具生态是碎片化且不成熟的。它们更像是“已知威胁检测器”，而非“模型安全验证器”。平台需要：

• 提高透明度：明确告知用户哪些格式被支持扫描，哪些没有。对于未扫描或无法扫描的模型，应显示“未知风险”或“未扫描”，而非“安全”。
• 推动标准化：需要社区共同努力，建立更统一的模型安全元数据标准和更强大的动态/行为分析工具，而不是仅仅依赖静态签名。

对于用户而言，绝不能将平台的安全标签视为绝对的安全保证。它只是一个参考，尤其是在面对新型、小众或自定义模型格式时。必须建立这样的认知：从不可信来源加载模型，本质上与运行不可信代码同等危险。

4. 实践指南：在脆弱生态中安全地共享与加载模型

既然框架的安全模式和平台的扫描工具都不完全可靠，作为一线开发者，我们应该如何应对？以下是我根据研究和实践经验总结的建议。

4.1 模型提供方的最佳实践

如果你是模型的创建者和分享者，你的目标是最大限度地降低用户的风险，并建立信任。

1. 优先使用约束性更强的交换格式：如果可行，考虑使用ONNX格式导出模型。ONNX定义了一个相对固定、有限的算子集合，其运行时环境通常比完整的Python框架更受限，从设计上减少了攻击面。虽然它可能不支持某些自定义层或最新操作，但对于许多常见的模型，它是一个更安全的选择。
2. 如果使用框架原生格式，请附带完整代码：
   • 对于PyTorch：强烈建议使用torch.save(model.state_dict(), …)仅保存权重，并同时提供用于重建模型架构的源代码文件（.py）。在文档中明确要求用户使用weights_only=True加载权重，然后用自己的代码实例化模型。weights_only模式是PyTorch目前最可靠的“安全”选项，因为它只允许加载张量数据。
   • 对于Keras：类似地，可以保存为.weights.h5（仅权重）或使用model.save(…, save_format=“tf”)（SavedModel格式，相对更复杂但可移植）。避免分享包含自定义Lambda层或复杂自定义对象的.keras或.h5完整模型文件，除非绝对必要。
   • 提供可复现的脚本：提供一个清晰的README.md和一个load_model.py脚本，展示如何安全地加载权重和实例化模型。
3. 详细说明与风险提示：在模型卡片中明确声明：
   • 所使用的框架和版本。
   • 保存的格式（如.keras,.h5,.skops,.pth）。
   • 是否包含自定义层、Lambda层或任何可能触发安全警告的组件。
   • 建议的安全加载步骤。
   • 警告：告知用户从不可信来源加载任何序列化模型都存在潜在风险。

4.2 模型使用方的防御策略

如果你需要加载他人共享的模型，必须采取更谨慎的态度。

1. 建立“零信任”心态：默认任何从互联网下载的模型文件都是潜在的威胁载体。不要盲目信任任何“安全模式”或“安全”标签。
2. 隔离环境加载：
   • 使用沙盒/容器：始终在隔离的环境中首次加载和测试未知模型，例如Docker容器、虚拟机或独立的云实例。确保该环境没有敏感数据、网络权限受到限制。
   • 使用专用的、无特权的用户：在沙盒内，使用一个非root、权限最小的用户来运行加载代码。
3. 代码审查与手动验证：
   • 优先选择“权重+代码”的分享方式：如果提供方给出了权重文件和模型定义代码，这是最安全的方式。仔细审查提供的模型定义代码，确保没有可疑操作。
   • 审查模型结构：如果必须加载完整模型文件，在沙盒中加载后，首先打印并审查模型结构（如model.summary()）。检查是否有来源不明或名称奇怪的层。
   • 警惕Lambda层和自定义对象：对于Keras模型，要特别警惕Lambda层。检查其内容是否被序列化（如果是，则风险极高）。对于Skops模型，仔细查看get_untrusted_types()报告的所有类型，并彻底理解每一个。
4. 版本与格式检���：
   • 更新框架：确保你使用的Keras、Skops等框架是最新版本，已包含已知漏洞的修复。
   • 警惕遗留格式：尽量避免加载旧的.h5（Keras）或纯pickle/joblib文件。如果必须加载，明确知晓风险，并在高度隔离的环境中操作。
5. 利用扫描工具，但不依赖：将Hugging Face等平台的扫描结果作为一个初步的、高误报率的筛选工具。如果模型被标记为“不安全”，需要高度警惕。但如果标记为“安全”，绝不意味着可以放松警惕，尤其是对于.skops等格式。

4.3 给框架与平台开发者的建议

1. 安全设计应默认拒绝：安全机制（如safe_mode）的默认状态应该是“开”，并且其关闭应该需要显式操作和明确的风险确认。对于不安全的遗留路径（如HDF5加载），应给出无法忽略的警告，甚至默认禁用，需要用户通过allow_unsafe_legacy=True这样的参数显式开启。
2. 验证与执行必须一致：像Skops那样让用户审批类型的机制，其展示给用户的信息（“将要加载的类型A”）必须与实际执行时发生的行为（“通过类型A访问了能力B”）完全一致。任何偏差都会导致信任崩塌。
3. 缩小攻击面是根本：鼓励并提供易于使用的“仅权重”导出选项。像PyTorch的weights_only这样的设计方向是正确的，它通过极大地限制可反序列化的类型来从根本上减少风险。
4. 清晰的文档与沟通：在safe_mode等功能的文档中，必须明确说明其局限性：“此模式旨在阻止常见攻击，但不能保证完全安全。加载不受信任的模型始终存在风险。” 避免使用可能产生误导的绝对化词汇。

5. 总结与反思：模型安全是过程，而非特性

回顾Keras和Skops的这系列漏洞，以及扫描工具的现状，我们可以得出几个核心结论：

首先，不存在“绝对安全”的模型序列化格式。无论是数据格式还是代码格式，安全性的重担都落在了加载器的实现上。而复杂的加载器不可避免地会存在漏洞。将安全寄托于某个“安全模式”开关，是一种危险的天真。

其次，安全是一种系统性属性，而非某个孤立特性。它涉及格式设计、加载器实现、用户交互、平台检测等多个环节。当前ML模型共享生态中，这些环节是割裂的：框架提供了有缺陷的“安全”选项，平台提供了不完整的扫描，而用户则被夹在中间，可能获得虚假的安全感。

最后，作为从业者，我们必须提升自身的安全素养。这意味着要理解我们所使用工具的安全模型及其局限，要习惯在隔离环境中工作，要对来自外部的任何代码（包括以模型形式存在的代码）保持审慎。在机器学习工程化日益成熟的今天，模型安全必须成为MLOps流程中不可或缺的一环，而不是事后才考虑的附加项。

这项工作也让我深刻体会到，在追求模型表达力、易用性和向后兼容性的同时，筑牢安全防线是一项持续且艰巨的挑战。它需要框架开发者更严谨的设计，需要安全研究者的持续审计，更需要广大用户建立正确的安全预期和实践。希望这篇深入的分析，能帮助你在下一次保存或加载模型时，做出更明智、更安全的选择。