xiaohack's Blog - AI框架安全
type: channel
link: https://blog.xiaohack.org/tag/ai-28bc75/
items: 深度实例分析：攻防视角下的AI框架组件中的注入漏洞

深度实例分析：攻防视角下的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…

深度实例分析：攻防视角下的AI框架组件中的注入漏洞
type: item
date: 2026-01-16T08:59:16+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指令，即可绕过数据分析的初衷，直接在宿主机上执行任意系统命令。importpandasaspd importos fromtypingimport Any defexecute_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被恶意提示词引导进入“代码编写模式”，它所产生的代码将直接在服务器后端运行。importsubprocess importshlex …

深度实例分析：攻防视角下的AI框架组件中的注入漏洞
type: item
date: 2026-01-14T09:48:04+08:00
description: 在从事了一段时间对AI框架组件的安全审计研究后，也挖掘到了很多相似的注入漏洞，对于目前的AI框架组件（PandasAI，LlamaIndx，Langchain...）对于该类型漏洞的通病结合实战实例以及学术界的研究做了系统性的归纳，站在AI框架的顶层角度对该类AI框架组件中的注入漏洞进行研究分析，供师傅们交流指点...深度实例分析：攻防视角下的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框架集成应用执行流如下： 1. 用户通过自然语言接口（如Web聊天框或API端点）提交查询提示（Prompt），这个提示通常封装为一个结构化的输入 2. 框架（如LangChain、LlamaIndex或PandasAI）接收此输入后，会在系统提示（System Prompt）指导下调用LLM模型（如OpenAI的GPT系列），系统提示旨在强化安全边界，例如“仅生成安全的Pandas代码，不要执行系统命令”。LLM基于其训练数据和概率分布，生成一个中间输出——通常是伪代码或自然语言描述的代码片段 3. 框架的解析器（Parser）将此输出转化为可执行的Python代码字符串 4. 最后在执行阶段，框架依赖动态解释器（如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指令，即可绕过数据分析的初衷，直接在宿主机上执行任意系统命令。 ```python 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 验证文件内容 ``…