以下文章来源于：云鼎实验室

腾讯云鼎实验室官方微信公众号

一、 引言：当AI基础设施成为攻击目标

随着大语言模型（LLM）的爆发式发展，AI 训练和推理框架已成为支撑整个行业的关键基础设施。NVIDIA Megatron-LM 作为分布式训练框架的翘楚，在 GitHub 上斩获超过15K Stars，被广泛应用于 GPT、DeepSeek、GLM 等主流大模型的训练过程。而 NVIDIA Model Optimizer 则是模型部署优化的核心工具，负责将训练好的模型量化压缩，适配TensorRT-LLM、vLLM 等推理引擎。

而近年来，Megatron-LM、vLLM、Model Optimizer等主流框架频繁披露安全漏洞，这些被视为"AI时代操作系统"的基础设施，其安全水位可能偏低，暴露了模型加载、推理服务等关键环节的安全缺陷。一旦这些漏洞被攻击者利用，其背后价值数亿美元的高性能算力资源将面临劫持风险，核心模型资产亦可能遭到窃取。腾讯安全云鼎实验室借助自研漏洞挖掘智能体VulnAgent，对这些主流AI框架进行深度安全审计，连续发现三个高危反序列化漏洞：CVE-2025-33248、CVE-2025-33247（Megatron-LM）以及 CVE-2026-24141（Model Optimizer），均获得 NVIDIA 官方致谢。

本文将以这三个漏洞为切入点，重点分析AI基础设施中因反序列化导致的安全漏洞，剖析AI基础设施面临的系统性安全风险。

二、 反序列化漏洞：AI框架中普遍存在的安全问题

2.1 什么是反序列化漏洞？

反序列化漏洞是 Python 生态中最为危险的漏洞类型之一。当程序使用 pickle、torch.load()、numpy.load()等函数加载数据时，如果数据源被攻击者控制，便可触发任意代码执行。

在AI训练场景中，模型文件、数据集文件、量化校准数据等都需要频繁序列化/反序列化，这为攻击者提供了大量的攻击面。

2.2 为何AI框架频发此类漏洞？

可能原因：

1. 功能优先导向：AI 框架设计历史上优先考虑训练效率，安全功能滞后。PyTorch 在 2025 年发布的 2.6 版本才默认启用 weights_only=True，此前近9年（2016-2025）允许加载任意对象

2. 生态依赖复杂：PyTorch 2.6 之前版本、 NumPy 1.16.3 之前版本、Yaml 5.3.1 之前版本及 Pickle 等底层库默认允许反序列化任意对象，缺乏安全边界

3. 使用场景特殊：模型文件体积庞大（GB级别），安全校验成本高，开发者习惯直接加载，缺乏校验机制

2.3 典型案例

以下是近年来AI基础设施中已公开的反序列化相关漏洞：

可以看到，不安全的反序列化问题贯穿了从底层框架（PyTorch、Keras）到训练框架（Megatron-LM）、模型管理（MLflow）及推理服务（vLLM）的整个AI技术栈。而本文发现的三个NVIDIA CVE进一步印证了这一趋势。

三、 漏洞详解：从不安全反序列化到任意代码执行

⚠️ 重要说明：本文涉及的漏洞均已通过 CNVD 和 NVDB 提交，并获得 NVIDIA 官方确认，官方已发布修复方案。请相关用户及时更新至最新版本以修复相关漏洞，避免因版本滞后导致运行环境暴露于安全风险之中。

3.1 Megatron-LM 反序列化漏洞

CVE-2025-33248

漏洞原理

Megatron-LM的hybrid_conversion.py 模块用于处理混合 Mamba-Transformer 架构模型在不同并行配置间的转换。这是 Megatron-LM 支持新兴架构的关键组件，直接影响模型的灵活部署能力。漏洞产生的根本原因：在加载模型文件时直接调用 torch.load()，未设置 weights_only=True 参数：

# get the latest iteration
tracker_filename = os.path.join(args.load_dir,'latest_checkpointed_iteration.txt')
withopen(tracker_filename,'r')as f:
    metastring = f.read().strip()
try:
        iteration =int(metastring)
except ValueError:
raise Exception("Invalid iteration found in latest_checkpointed_iteration.txt!")
out_iteration = iteration ifnot args.reset_iterations else0
# get model directory and model parallel ranks
input_model_dir = os.path.join(args.load_dir,'iter_{:07d}'.format(iteration))
input_sub_models = os.listdir(input_model_dir)
# load one of the model parallel ranks to get arguments
sample_model_file = os.path.join(input_model_dir, input_sub_models[0],"model_optim_rng.pt")
# 危险：直接执行恶意代码
sample_model = torch.load(sample_model_file)# 默认 weights_only=False

在 PyTorch 2.6 之前，torch.load()的默认行为允许加载任意 Python 对象，攻击者可借此执行任意代码。这意味着，一旦用户加载恶意 checkpoint 文件，攻击者精心编造的任意代码就会在目标机器上执行。

官方修复方案

CVE-2025-33248 漏洞披露后，Megatron-LM官方修复方案是强制设置 torch 版本为2.6+，从而保证 torch.load() 的参数 weights_only 默认为 True。

dependencies = ["torch>=2.6.0", "numpy", "packaging>=24.2"] 

CVE-2025-33247

漏洞原理

Megatron-LM的pretrain_gpt.py 模块用于 GPT 模型预训练和 SFT（监督微调）。漏洞产生的根本原因：在于其量化配置（Quantization Recipe）加载流程中直接调用yaml.load(Loader=yaml.FullLoader), 而非使用yaml.SafeLoader。

def from_yaml_file(recipe_yaml_path:str)->"RecipeConfig":
"""Loads recipe from yaml configuration."""
ifnot HAVE_YAML:
raise ImportError("yaml is not installed. Please install it with `pip install pyyaml`.")
withopen(recipe_yaml_path,"r")as f:
# 危险：直接执行恶意代码
        config = yaml.load(f, Loader=yaml.FullLoader)#
return RecipeConfig.from_config_dict(config)

yaml.FullLoader 支持 Python 对象构造标签，攻击者构造恶意 YAML 文件即可在加载时执行任意代码。这意味着，一旦用户加载恶意 YAML 文件，攻击者精心编造的任意代码就会在目标机器上执行。

官方修复方案

CVE-2025-33247 漏洞披露后，Megatron-LM 官方修复方案是强制设置 yaml.load() 的参数 Loader 为 SafeLoader。

withopen(recipe_yaml_path,"r")as f:
    config = yaml.load(f, Loader=yaml.SafeLoader)

3.2 Model Optimizer 反序列化漏洞（CVE-2026-24141）

漏洞原理

Model Optimizer 的 ONNX 量化模块（modelopt.onnx.quantization）是模型部署前压缩的关键步骤，用于将 FP32 模型量化为 INT8，大幅降低推理成本。漏洞产生的根本原因：在加载量化校准数据时，使用了numpy.load(allow_pickle=True)：

# 不安全的实现
calibration_data = np.load(args.calibration_data_path, allow_pickle=True)

NumPy的allow_pickle参数在True时，可加载包含任意Python对象的.npy文件，与pickle模块存在相同的安全风险。这意味着，一旦用户加载恶意文件，攻击者精心编造的任意代码就会在目标机器上执行。

官方修复方案

CVE-2026-24141漏洞披露后，Model Optimizer官方修复方案是在加载量化校准数据时采用用户的输入参数trust_calibration_data，默认值False：

calibration_data = np.load(
    args.calibration_data_path, allow_pickle=args.trust_calibration_data
)

四、 AI基础设施面临的三重风险

4.1 算力资产劫持风险

算力即金钱。现代 GPU 集群的算力价值远超传统服务器：

• 单卡价值高昂：NVIDIA H100单卡售价约2.5～3万美元，一个千卡训练集群的硬件价值可达数千万美元

• 训练成本惊人：据公开报道估算，GPT-4的训练成本超过1亿美元；Meta 训练 Llama 3 使用了 16,000 张 H100，消耗超过 2,000万 GPU 小时攻击者通过反序列化漏洞获得服务器控制权后，可：

• 挖矿牟利：部署加密货币挖矿程序，持续消耗高价 GPU 算力

• 算力盗用：私自运行模型训练任务，窃取企业算力资源

• 资源转售：将算力挂到黑市二次租赁，非法牟利

4.2 模型资产窃取风险

大模型训练成本动辄数百上千万美元，模型权重是企业的核心资产：

• 直接窃取：下载模型文件（数十GB至数百GB）

• 数据泄露：窃取训练数据集，可能包含敏感信息

4.3 供应链污染风险

AI模型供应链呈现**“中心化+长链条”**特征：

攻击者只需在任一环节注入恶意代码：

• 预训练模型投毒：在 Hugging Face 等平台上传含恶意 pickle 的模型文件，用户加载后即触发代码执行

• 量化数据投毒：构造恶意量化校准数据（.npy文件），在模型量化环节触发代码执行

• 训练配置投毒：发布恶意训练配置，加载时触发代码执行

此次发现的三个CVE正是典型的供应链攻击节点：

• Megatron-LM 负责训练阶段（源头） 

• Model Optimizer 负责部署阶段（出口）

一旦被利用，可实现对整个AI生产链的渗透。

五、 安全缓解措施

5.1 安全编码规范

• 禁用不安全的反序列化调用：在代码中严格避免使用 torch.load() 的默认参数，强制设置 weights_only=True；使用 yaml.SafeLoader 替代 yaml.FullLoader；禁止 numpy.load(allow_pickle=True) 加载不可信数据

• 升级依赖版本：将 PyTorch 升级至 2.6+ 版本（默认启用 weights_only=True）；将 PyYAML 升级至 6.0+ 版本；定期使用 SCA 工具扫描第三方依赖的已知漏洞

• 使用安全数据格式：优先采用 Safetensors 格式替代传统的 .pt/.pkl 模型文件，从根本上杜绝反序列化攻击面；量化校准数据使用 JSON、CSV 等纯数据格式替代 .npy（pickle模式）

• 代码安全审查：使用 SAST 工具自动化扫描 pickle.load()、torch.load()、yaml.load(FullLoader)、numpy.load(allow_pickle=True) 等危险调用模式，将安全检查纳入 CI/CD 流程

5.2 模型文件与数据完整性校验

• 来源验证：仅从官方渠道或可信源获取模型文件和预训练权重，避免使用来路不明的 checkpoint 文件

• 哈希校验：对模型文件、量化校准数据、训练配置文件进行 SHA-256 哈希校验，确保文件未被篡改

• 模型扫描：在加载前使用安全工具（如 Hugging Face 的 picklescan）扫描模型文件中是否包含恶意序列化对象

5.3 运行环境隔离

• 最小权限原则：AI 训练和推理服务以非 root 用户运行，限制文件系统和网络访问权限

• 容器化部署：使用容器隔离训练/推理环境，限制容器的系统调用能力（如通过 seccomp、AppArmor 策略）

• 网络隔离：训练集群与外部网络严格隔离，仅开放必要的数据传输通道，防止攻击者在获取代码执行权限后进行横向移动或数据外传

注：腾讯安全产品已全线支持上述漏洞的检测。

六、 结语

此次针对 NVIDIA Megatron-LM 与 Model Optimizer 的安全研究表明，反序列化风险已成为AI基础设施中不可忽视的系统性安全短板：

1. 漏洞普遍性：三个高危漏洞分布在预训练和后训练两个关键环节，涵盖模型文件加载、量化配置解析、校准数据加载等核心流程

2. 影响严重性：可导致算力劫持、模型窃取、供应链污染，直接威胁价值数亿美元的GPU集群和核心模型资产

3. 生态脆弱性：在供应链场景下，从代码缺陷到攻击实现的路径清晰且利用门槛低，攻击者仅需构造恶意模型文件或配置文件即可触发远程代码执行

附录：

「AI开源组件安全风险」系列一：配置缺陷，让你的 GPU 沦为矿机

关注云鼎实验室，获取更多安全情报

跳转微信打开

AI开源组件的 Web 安全水位可能偏低，而其背后的高性能算力资源却成为黑产眼中的"香饽饽"。

随着生成式AI技术的快速发展，ComfyUI、Stable Diffusion WebUI 等AI开源组件已成为 AI 应用开发的基础设施。然而，在这些组件快速迭代的背后，一个容易被忽视的安全问题正在浮现：AI开源组件的 Web 安全水位可能偏低，而其背后的高性能算力资源却成为黑产眼中的"香饽饽"。

腾讯安全云鼎实验室长期聚焦于 AI 组件生态的安全风险研究，对主流AI开源组件进行了系统性的安全分析，发现了多类普遍存在的安全隐患。本文是「AI开源组件安全风险分析」系列的第一篇，将重点分析AI开源组件中因配置缺陷导致的安全漏洞——包括组件自身的设计缺陷，以及用户部署时的配置失误，并结合真实云上攻击案例进行深度剖析。后续我们将持续披露更多研究成果（如供应链安全，AI Infra安全等），敬请关注。

近年来，多个主流 AI 开源组件被披露存在因配置缺陷导致的高危问题。这类问题往往具有共同特点：组件为了易用性/可扩展性，提供了“可远程触发的高权限能力”；而默认配置、暴露面判断或配套鉴权措施不足时，就会被攻击者利用。

典型案例（公开披露）

这些漏洞揭示了AI开源组件在安全设计上的共性问题：为了追求功能的灵活性和易用性，可能忽视了安全边界的控制。

在对 AI 组件生态进行横向观察时，我们发现 Stable Diffusion WebUI（下称 SD WebUI）同样存在典型的“配置缺陷”风险。更值得关注的是：即便某些保护机制已在项目侧引入，仍会因为“反向代理暴露、端口转发、多用户共享、升级滞后”等现实部署场景，导致公网中持续存在大量高风险实例。

⚠️ 重要说明：此漏洞于2023年被披露，属于已知的Nday漏洞（CNVD-2023-81119）。官方已提供有效修复方案——通过 disable_extension_access 参数默认禁止公网环境下的远程扩展安装。请所有用户立即检查并更新至最新版本，并参照本文末尾「安全配置建议」进行安全加固，避免因配置不当或版本滞后导致实例暴露于风险之中。

3.1 漏洞原理

漏洞的原理非常直接：攻击者可以远程安装恶意扩展插件，从而实现任意代码执行。 在SD WebUI的代码中，扩展安装流程会直接执行插件目录下的install.py脚本：

# SD WebUI 扩展安装代码（简化）
def run_extension_installer(extension_dir):
    path_installer = os.path.join(extension_dir, "install.py")
ifnot os.path.isfile(path_installer):
return


try:
        env = os.environ.copy()
        env['PYTHONPATH'] = f"{script_path}{os.pathsep}{env.get('PYTHONPATH', '')}"


        # 危险：直接执行远程扩展的install.py脚本
stdout = run(f'"{python}""{path_installer}"', 
                    errdesc=f"Error running install.py for extension {extension_dir}")
        if stdout:
            print(stdout)
    except Exception as e:
        errors.report(str(e))

这意味着，一旦用户安装了恶意扩展，攻击者编写的任意Python代码就会在目标机器上执行。

3.2 官方修复方案

CNVD-2023-81119漏洞披露后，SD WebUI官方的修复方案是在安装远程插件之前增加了检查机制：

# 安装前的安全检查（官方修复）
if disable_extension_access == True:
return  # 禁止远程安装扩展

关键参数：disable_extension_access

这个参数是官方修复的核心，其值由多个启动配置共同决定：

# disable_extension_access 的判断逻辑
is_exposed_to_internet = any([
    cmd_opts.share,        # --share: 使用Gradio公共分享链接
    cmd_opts.listen,       # --listen: 监听0.0.0.0允许外部访问
    cmd_opts.ngrok,        # --ngrok: 使用ngrok隧道
    cmd_opts.server_name   # --server-name: 指定非默认服务器名称
])


disable_extension_access = is_exposed_to_internet andnot cmd_opts.enable_insecure_extension_access

官方修复后的安全逻辑解析：

3.3 为什么公网仍存在大量可攻击实例

虽然官方已经默认对开到公网的服务加了限制，但我们实际发现外网的机器多数都开启了扩展安装功能，可被此漏洞攻击。

可能的原因：

• 服务开启在本地，通过反向代理或端口转发暴露到公网：用户在本地启动SD WebUI（此时扩展安装默认开启），然后通过Nginx反向代理、frp、ngrok、Cloudflare Tunnel等方式将服务暴露到公网。由于SD WebUI检测不到公网暴露，安全限制不会生效。

• 主动开启了 --enable-insecure-extension-access：部分用户为了便利性，在启动命令中添加了此参数，强制允许远程安装扩展。

• 使用的 Stable Diffusion WebUI 版本很老：2023年修复前的旧版本（<=1.6.0）完全没有 disable_extension_access 安全检查，任何公网可访问的实例都可被直接攻击。

通过腾讯云主机安全和网络入侵等产品的安全感知能力，我们捕获到多起真实的云上 SD WebUI 失陷事件，以其中一次真实入侵事件为例，还原了攻击者从初始入侵到挖矿牟利的完整攻击链路。

整个攻击过程分为以下四个阶段：

• 阶段一：初始入侵。受害主机以 --listen 模式启动 SD WebUI，扩展安装 API 暴露于公网。攻击者远程安装了恶意扩展，安装后即为攻击者提供了一个持久化的 Web Shell。

• 阶段二：信息收集。攻击者通过 Web Shell 执行了 whoami、ps aux、lscpu、uname -a、nvidia-smi 等命令，快速确认当前用户权限、运行环境和 GPU 算力情况，评估主机的利用价值。

• 阶段三：持久化。攻击者下载并安装了 sshx 远程终端工具，随后执行 sshx -q > /var/tmp/sshx_link.txt 生成远程访问链接。sshx 是一个开源工具，被攻击者滥用为反向隧道后门，通过浏览器即可获得完整 Shell 权限，属于无文件持久化技术，更难被检测。

• 阶段四：目标达成。攻击者下载 XMRig v6.22.2 挖矿程序，将其重命名为 rdxr 以规避进程名检测，连接矿池。最终通过 nohup + trap + while true 无限循环实现持久化挖矿，确保进程被杀死后自动重启。

5.1 传统Web应用 vs AI开源组件

5.2 黑产的新目标：高性能GPU算力

AI开源组件的典型硬件配置：

• 消费级：RTX 4090（24GB显存）

• 专业级：NVIDIA A10（24GB显存）

• 企业级：A100（40GB/80GB显存）

这些GPU的算力价值：

• 挖矿收益：单张4090每日可产生5-10美元的挖矿收益

• AI算力租赁：A100的云端租赁价格高达每小时2-4美元

• 规模化攻击：批量控制100台机器，月收益可达数万美元

5.3 为什么AI开源组件安全水位偏低？

技术栈侧重不同

• AI 组件开发者通常更专注于模型算法与推理效果，Web 安全并非其核心关注领域

• 这与传统 Web 开发团队长期积累的安全经验形成了客观差异

快速发展阶段的共性挑战

• AI 开源生态正处于高速发展期，功能迭代速度快，安全审查机制尚在完善中 

• 第三方扩展生态蓬勃发展的同时，统一的安全规范和准入标准仍在建立过程中

部署场景的复杂性

• 部分组件在设计时主要面向本地或可信环境使用

• 但实际部署中，公网暴露、反向代理转发、多用户共享等场景较为普遍，超出了原始设计预期

依赖管理的混乱

• Python等语言生态的依赖问题

• 扩展插件权限过高

面对AI开源组件的安全威胁，需要从网络边界到主机层面构建纵深防御体系。

6.1 腾讯云安全产品方案

腾讯云NDR 腾讯云容器安全入侵防御模块支持对漏洞的后利用恶意行为的检测

6.2 安全配置建议

• 优先本地访问：默认仅监听本地地址，避免直接暴露公网

• 启用认证：如需远程访问，务必配置访问认证

• 反向代理加固：如通过Nginx反向代理，可以在配置时添加基础认证

本文作为「AI开源组件安全风险分析」系列的第一篇，重点分析了因配置缺陷导致的安全漏洞。从ComfyUI-Manager到Stable Diffusion WebUI，我们看到：

• AI开源组件的扩展安装机制普遍缺乏安全控制

• 配置参数的复杂性增加了用户出错的概率

• 公网中仍存在大量可被攻击的脆弱实例

关注云鼎实验室，获取更多安全情报

跳转微信打开

以下文章来源于：云鼎实验室

腾讯云鼎实验室官方微信公众号

三、OpenCode 远程代码执行漏洞

五、Gradio SSRF 服务器端请求伪造漏洞

腾讯云安全近期监测到关于Gradio的风险公告，漏洞编号：TVD-2026-8173（CVE编号：CVE-2026-28416，CNNVD编号：CNNVD-202602-4619）。成功利用此漏洞的攻击者，最终可实现服务器端请求伪造，访问内部资源并窃取敏感信息。

Gradio是一款开源的Python库，专为快速构建机器学习模型演示和原型应用而设计。它允许开发者通过几行代码就能为AI模型创建交互式Web界面，支持各种输入输出组件，如文本、图像、音频、视频等。Gradio因其简单易用的特性，被广泛应用于机器学习研究、模型展示和AI应用开发领域。其中`gr.load()`功能允许用户加载托管在Hugging Face Spaces或其他平台上的Gradio应用，方便用户复用和集成现有的AI模型和应用，促进了AI社区的协作与共享。

ope

据描述，该漏洞源于Gradio在处理`gr.load()`加载外部Space时存在安全缺陷。当受害者应用使用`gr.load()`加载攻击者控制的恶意Space时，配置中的恶意`proxy_url`会被信任并添加到允许列表中，使攻击者能够通过受害者的基础设施访问内部服务、云元数据端点和私有网络资源。

注：任何使用 gr.load() 加载外部或不可信 Spaces 的 Gradio 应用程序均受该漏洞影响。

漏洞状态：

风险等级：

Gradio <= 6.5.1

1.官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，建议升级至最新版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://github.com/gradio-app/gradio/releases

2.临时缓解措施：

- 避免使用`gr.load()`加载不受信任的外部Space

- 配置防火墙或网络规则，限制服务器对内部网络和云元数据端点的访问

- 如无必要，避免开放至公网

七、Apache Camel 反序列化远程代码执行漏洞

腾讯云安全近期监测到关于Apache Camel 组件的风险公告，漏洞编号：TVD-2026-7326（CVE编号：CVE-2026-25747，CNNVD编号：CNNVD-202602-3925）。成功利用此漏洞的攻击者，最终可远程执行任意代码。

Apache Camel是Apache软件基金会开发的一款开源企业级集成框架，基于企业集成模式(EIP)设计，为开发者提供了丰富的组件和连接器，用于实现不同系统之间的数据交换和集成。Camel支持超过300种协议和数据格式，广泛应用于企业服务总线(ESB)、微服务架构和消息驱动应用中。LevelDB组件是Camel的聚合存储库实现之一，使用Google的LevelDB键值存储引擎来持久化聚合过程中的中间消息，确保消息在系统重启后不会丢失，为高可用性和容错性提供支持。

据描述，该漏洞源于Apache Camel的LevelDB组件中DefaultLevelDBSerializer类在反序列化数据时存在安全缺陷。该类使用java.io.ObjectInputStream反序列化从LevelDB聚合存储库读取的数据，但未应用任何ObjectInputFilter或类加载限制。攻击者若能够写入Camel应用程序使用的LevelDB数据库文件，可注入恶意构造的序列化Java对象，在正常聚合存储库操作期间触发反序列化，最终实现任意代码执行。

漏洞状态：

风险等级：

3.0.0 <= Apache Camel < 4.10.9

4.11.0 <= Apache Camel < 4.14.5

4.15.0 <= Apache Camel < 4.18.0

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，及时更新漏洞补丁

https://camel.apache.org/download/

2. 临时缓解措施：

- 配置防火墙或网络规则，仅允许特定IP地址或IP段访问

- 如无必要，避免开放至公网

八、Gogs 远程代码执行漏洞

腾讯云安全近期监测到关于Gogs的风险公告，漏洞编号：TVD-2025-47166（CVE编号：CVE-2025-64111，CNNVD编号：CNNVD-202602-995）。成功利用此漏洞的攻击者，最终可远程执行任意代码。

Gogs是一款开源的轻量级自托管Git服务，采用Go语言编写，以其极低的资源占用和简单的部署方式而著称。Gogs提供了类似于GitHub的Web界面，支持仓库管理、问题追踪、Wiki、代码审查等功能，适合个人开发者和小型团队使用。它支持多种数据库后端，包括SQLite、MySQL、PostgreSQL等，可以在各种操作系统上运行，包括Windows、Linux、macOS和ARM架构设备。Gogs的设计目标是成为一个易于安装、运行和维护的Git托管解决方案，让用户能够快速搭建私有的代码托管平台。

据描述，由于针对 Gogs 远程代码执行漏洞（CVE-2024-56731）的补丁修复不完整，在 internal/route/api/v1/repo/contents.go 文件的UpdateRepoFile 函数调用路径中，安全校验逻辑仍存在遗漏，攻击者仍可通过 API 接口，利用仓库中的符号链接文件（如指向 .git/config 的链接），以 Base64 编码的方式提交恶意配置内容，从而篡改 Git 配置的 sshCommand 等关键参数，最终在服务器端执行任意系统命令。

漏洞状态：

风险等级：

Gogs <= 0.13.3

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。https://github.com/gogs/gogs/releases

2. 临时缓解方案：

- 建议在 app.ini 中关闭 Gogs 用户注册功能，防止攻击者注册账号进行登录利用（修改后需重启 Gogs 服务）：

[auth]

DISABLE_REGISTRATION = true

九、n8n 沙箱逃逸漏洞

腾讯云安全近期监测到关于n8n的风险公告，漏洞编号：TVD-2026-7841（CVE编号：CVE-2026-27577，CNNVD编号：CNNVD-202602-4190）。成功利用此漏洞的攻击者，可通过表达式注入绕过沙箱限制，在宿主机上执行任意系统命令。

n8n是一款开源的工作流自动化平台，专为技术人员和企业设计，用于连接各种应用程序和服务以实现业务流程自动化。它提供了直观的可视化界面，支持超过400个应用程序集成，包括常见的SaaS服务、数据库、API等。n8n的核心优势在于其灵活性和可扩展性，用户可以通过拖拽方式创建复杂的自动化工作流，也可以使用JavaScript编写自定义逻辑。n8n支持自托管部署，让企业能够完全控制自己的数据和工作流，广泛应用于数据同步、通知推送、报表生成等自动化场景。

据描述，该漏洞是CVE-2025-68613的后续漏洞，源于n8n在表达式求值机制中存在额外的安全缺陷。经过身份验证且具有工作流创建或修改权限的用户，可以在工作流参数中构造恶意表达式，绕过沙箱限制，在运行n8n的宿主机上触发非预期的系统命令执行，最终实现沙箱逃逸和远程代码执行。

漏洞状态：

风险等级：

n8n < 1.123.22

2.0.0 <= n8n < 2.9.3

2.10.0 <= n8n < 2.10.1

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://github.com/n8n-io/n8n/releases

2. 临时缓解方案：

- 将工作流的创建和编辑权限限制在完全可信的用户范围内，避免不可信用户利用该漏洞

- 将 n8n 部署在强化后的环境中，限制其操作系统权限和网络访问范围，以降低漏洞被成功利用后可能造成的危害

跳转微信打开

以下文章来源于：云鼎实验室

腾讯云鼎实验室官方微信公众号

三、n8n 未授权文件访问漏洞

五、Apache Struts2 XWork XML外部实体注入漏洞

腾讯云安全近期监测到关于Apache Struts的风险公告，漏洞编号：TVD-2025-45593(CVE编号：CVE-2025-68493，CNNVD编号：CNNVD-202601-1787)。成功利用此漏洞的攻击者，最终可读取系统敏感文件或导致拒绝服务。

Apache Struts是一个用于开发Java EE网络应用程序的开源Web应用框架，它简化了基于MVC设计模式的Web应用程序的开发过程。Struts通过提供一系列标签库、拦截器和配置文件，帮助开发者更高效地构建动态网页和处理用户输入。该框架广泛应用于企业级应用中，因其灵活性和扩展性而受到开发者的青睐。

据官方描述，该漏洞源于Apache Struts2的XWork组件在处理XML配置文件时存在安全缺陷，其XML解析器在解析过程中未能以安全的方式验证 XML输入，未禁用或限制对外部实体的加载。攻击者可构造并发送一个包含指向本地文件或远程资源外部实体声明的特制 XML 请求。当该请求被 XWork 组件解析时，解析器会加载并处理这些外部实体，导致将服务器上的文件内容或内网服务响应嵌入至应用响应中返回给攻击者，或引发解析过程中的资源耗尽等。

漏洞状态：

风险等级：

2.0.0 <=Apache Struts <= 2.3.37

2.5.0 <= Apache Struts <= 2.5.33

6.0.0 <= Apache Struts<= 6.1.0

1.官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，建议升级至最新版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://struts.apache.org/download.cgi

2. 临时缓解措施：

(1) 自定义 XML 解析器：通过设置系统属性 xwork.saxParserFactory，指定一个自定义的 SAXParserFactory 类，该类需在默认配置中禁用外部实体解析。

(2) 或配置 JVM 全局设置：通过 JVM 启动参数，配置默认 XML 解析器以禁用所有外部资源的访问，具体参考以下配置，将值设为空字符串来阻断所有协议：

-Djavax.xml.accessExternalDTD=""

-Djavax.xml.accessExternalSchema=""

-Djavax.xml.accessExternalStylesheet=""

六、Crawl4AI远程代码执行漏洞

腾讯云安全近期监测到关于Crawl4AI的风险公告，漏洞编号：TVD-2026-3804。成功利用此漏洞的攻击者，最终可远程执行任意代码。

Crawl4AI 是一款专为大型语言模型和 AI 应用设计的开源网络爬虫与数据提取框架，其核心目标是解决传统爬虫工具在支持 AI 工作流（如 RAG、模型微调、AI代理）时面临的数据适配问题。它通过智能化的内容处理管道，能够将网页内容高效转换为 AI 友好的格式（如结构清晰的 Markdown 或 JSON），并在此过程中自动过滤广告、导航栏等噪声内容，显著提升数据质量。

据描述，当使用Docker API部署Crawl4AI时，其/crawl端点存在严重安全缺陷。该端点接收的hooks参数中包含的Python代码，会通过不安全的exec()函数执行，以支持用户自定义钩子功能，但执行代码时的安全沙箱配置将__import__这个内置函数保留在了允许使用的内置函数列表中，这使得攻击者可以在hooks 参数中导入os等任意模块，最终远程执行任意代码。

漏洞状态：

风险等级：

Crawl4AI < 0.8.0

1.官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】：建议您在升级前做好数据备份工作，避免出现意外。

https://github.com/unclecode/crawl4ai/releases/tag/

注：更新指南可参考以下官方链接：

https://github.com/unclecode/crawl4ai/blob/release/v0.8.0/docs/migration/v0.8.0-upgrade-guide.md

2.临时缓解措施：

- 停止并禁用此 Docker API 服务容器。

- 在网络层面（如防火墙）阻断对 /crawl 端点的访问。

- 为该 API 服务添加强身份验证。

七、GNU InetUtils telnetd 远程身份认证绕过漏洞

腾讯云安全近期监测到关于GNU Inetutils的风险公告，漏洞编号：TVD-2026-4039（CVE编号：CVE-2026-24061，CNNVD编号：CNNVD-202601-3437）。成功利用此漏洞的攻击者，最终可绕过身份验证，以root权限登录。

GNU Inetutils 是一个由 GNU 项目开发和维护的开源软件套件，它集成了一套传统的、用于网络管理和运维的基础命令行工具，包括常见的客户端和服务器端程序，例如 ftp、telnet、ping 等。GNU InetUtils telnetd 是 GNU InetUtils 软件套件中的一个组件，它是一个实现了 Telnet 协议的服务器端守护进程，其主要功能是监听 TCP 23 端口，为客户端提供基于明文的远程终端登录服务，在认证环节通常会调用系统的 /usr/bin/login程序来完成用户身份验证。

据官方描述，在 GNU InetUtils 1.9.3 至 2.7 版本的 telnetd 服务端中，由于服务端在处理来自客户端的 USER 环境变量值时，未对其内容进行任何验证或净化，便直接将此值作为参数传递给 /usr/bin/login 程序。当攻击者通过客户端指定 USER='-f root' 并向服务端发送时，该值最终会作为命令的一部分执行，从而直接以 root 用户身份登录，完全绕过正常的认证流程。

注：在主流 Linux 发行版（如 Debian、RHEL）的软件仓库中，telnet 服务器功能通常由多个独立的上游项目实现提供。其中，来自 netkit 或 xinetd 项目的实现是默认的、首选的软件包（如 telnetd 或 telnet-server）。而来自 GNU 项目的 inetutils-telnetd，则作为另一个可选的、备选的实现存在于同一仓库中。截止目前，受该漏洞影响设备主要以 NAS 设备为主。

漏洞状态：

风险等级：

1.9.3 <= GNU InetUtils <= 2.7

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，及时更新漏洞补丁

https://codeberg.org/inetutils/inetutils/commit/fd702c02497b2f398e739e3119bed0b23dd7aa7b

https://codeberg.org/inetutils/inetutils/commit/ccba9f748aa8d50a38d7748e2e60362edd6a32cc

2. 临时缓解措施：

- 禁用 telnetd 服务器。

- 使用定制的 login 程序：修改 telnetd 配置，使其调用一个经过修改的、移除了 -f 参数的自定义 login 程序，这样可以阻断该漏洞的直接利用路径。

八、SmarterMail 身份认证绕过漏洞

腾讯云安全近期监测到关于SmarterMail的风险公告，漏洞编号：TVD-2026-4115（CVE编号：CVE-2026-23760，CNNVD编号：CNNVD-202601-3816）。成功利用此漏洞的攻击者，可接管管理员用户，最终远程执行任意代码。

SmarterMail 是由美国 SmarterTools 公司开发的一款企业级邮件服务器软件，它被广泛视为 Microsoft Exchange 的经济型替代方案。它不仅提供安全的企业邮件服务，还集成了共享日历、联系人、任务管理、即时通讯和文件存储等完整的团队协作功能。其核心优势在于原生支持关键的 MAPI/Exchange 协议以实现与 Microsoft Outlook 的无缝集成，同时具备跨平台能力（支持 Windows 和 Linux 服务器，甚至 Docker 部署）、更低的总体拥有成本、开箱即用的企业级垃圾邮件与防病毒保护，以及可通过“应用市场”扩展功能的灵活性，使其成为从中小型企业到互联网服务提供商（ISP）及托管服务商等多种场景的理想选择。

据描述，该漏洞源于SmarterMail的密码重置接口/force-reset-password未验证系统管理员OldPassword字段的有效性，未授权的攻击者可直接向该接口发送特制请求重置管理员密码，随后利用内置的Volume Mounts功能远程执行任意代码。

漏洞状态：

风险等级：

SmarterMail < Build 9511

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://www.smartertools.com/smartermail/release-notes/current

2. 临时缓解方案：

- 如无必要，避免开放至公网

- 配置防火墙或网络规则，仅允许特定IP地址或IP段访问

九、SmarterMail ConnectToHub 远程代码执行漏洞

腾讯云安全近期监测到关于SmarterTools SmarterMail的风险公告，漏洞编号：TVD-2026-4422(CVE编号：CVE-2026-24423，CNNVD编号：CNNVD-202601-3955)。成功利用此漏洞的攻击者，最终可远程执行任意代码。

据描述，该漏洞由于SmarterMail的ConnectToHub API接口缺乏对访问源的有效身份验证和鉴权，并且设计上允许从外部服务器获取并执行指令，远程攻击者可以构造一个包含恶意操作系统命令的响应，并架设一个恶意 HTTP 服务器。当攻击者诱导存在漏洞的 SmarterMail 服务器向该恶意服务器发起 ConnectToHub 请求时，SmarterMail 会接收并直接执行来自恶意响应的操作系统命令，从而在服务器上实现远程代码执行。

漏洞状态：

风险等级：

SmarterMail < Build 9511

1. 官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，酌情升级至安全版本。

【备注】建议您在升级前做好数据备份工作，避免出现意外。

https://www.smartertools.com/smartermail/downloads

2. 临时缓解方案：

- 如无必要，避免开放至公网

- 配置防火墙或网络规则，仅允许特定IP地址或IP段访问

十、OpenCode 远程代码执行漏洞

腾讯云安全近期监测到关于OpenCode的风险公告，漏洞编号：TVD-2026-3345(CVE编号：CVE-2026-22813，CNNVD编号：CNNVD-202601-1874)。成功利用此漏洞的攻击者，最终可远程执行任意代码。