LLMLeak:借 LLM 合法网页抓取实施隐蔽数据外泄
The Innocent Courier: Covert Exfiltration Through Legitimate LLM Web Fetching
LLMLeak 把机密编码进报错 URL,让聊天机器人的网页抓取工具在 DNS/HTTP 请求中带出秘密;11 个开源模型上平均 Sconf 为 79.70%。
敌手 A 已在受害机器上运行恶意软件并取得机密,但因网络限制或监控无法直接连到自己的服务器。
- 本地恶意软件拿得到机密却因网络限制或监控无法直接外传。现有第三方泄露依赖提示注入来操纵模型,容易被注入防御或用户检查挡住。作者认为只防行为操纵会给人虚假安全感。
- LLMLeak 把秘密编码进报错里看似正常的文档 URL(子域走 DNS,路径走 HTTP),由用户把报错交给带网页抓取工具的聊天机器人。模型按调试流程去抓该 URL 时,攻击者的 DNS 或 Web 服务器收到请求即完成外传,不依赖提示注入。
- 在 11 个开源模型、每种通道 100 次、每模型 n=2000 的设置下,作者报告平均 Sreach 81.42%、Sconf 79.70%,Llama-3.3-70B 的 Sconf 为 99.9%,Qwen3-Coder-30B 为 30.0%。信息性表述平均 Sconf 降到 54.63%。真实聊天机器人案例中,ChatGPT、Gemini、Claude、Grok 均抓取了载荷 URL。
- 作者指出真实聊天机器人案例规模有限,且依赖模型愿意抓取外部引用;后续可研究防御与更长秘密。实验覆盖 11 个开源权重模型的 ReAct 智能体(temperature 0.7、最多 24 轮)以及四款闭源聊天机器人的案例,论文未报告与人工判定的一致性。
- 威胁模型
- 敌手 A 已在受害机器上运行恶意软件并取得机密,但因网络限制或监控无法直接连到自己的服务器。A 不能控制良性聊天机器人 C 或其基础设施,也不能看 V 与 C 的对话;A 可构造输出(如报错),由用户 V 交给 C。A 可运营公网可达的 DNS/HTTP 服务器。目标是在不引起 V 注意的情况下外传秘密。
- 模型
- Meta-Llama-3.3-70B-InstructMeta-Llama-4-Scout-17B-16E-InstructMeta-Llama-3.1-8B-InstructMistral-Small-24B-Instruct-2501Mistral-7B-Instruct-v0.3IBM-Granite-3.3-8b-instructAlibaba-Qwen2.5-7B-InstructMicrosoft-Phi-4-mini-instructDeepSeek-Coder-V2-Lite-InstructMeta-Llama-3.2-3B-InstructAlibaba-Qwen3-Coder-30B-A3B-InstructChatGPT (GPT-5.4)GeminiClaudeGrok
- 基准
- 10 distinct Python crash stack traces (20 with two framings)synthetic code project with ReAct agent toolsreal-world chatbot case study (ChatGPT, Gemini, Claude, Grok)
- 指标
- SreachSconfScallSdataRecovery Score rLevenshtein similarity
研究者提出 LLMLeak,一种利用 LLM 网页抓取工具建立隐蔽信道的新型攻击向量:本地恶意软件无法直接联网,却可把机密编码进 URL,并以“迁移软件库”等良性任务为由让 LLM 访问该链接,攻击者再通过自己控制的 DNS 或网页服务器取回编码后的机密。作者指出,直接让 LLM 用生成代码发送数据的输入容易被检测、网络库通常也受限,而 LLMLeak 只依赖 LLM 获取网站信息的工具。在 11 个开放参数模型上的评测显示攻击成功率为 79.7%,作者还对真实聊天机器人做了案例研究。
深度解读
这篇论文试图解决什么问题?
本地恶意软件无法直连外网时,如何借良性聊天机器人的网页抓取把秘密外传。
核心问题是:已拿到机密、却不能直接联网的本地恶意软件,能否不操纵模型行为,只靠聊天机器人正常抓取网页,把秘密传到攻击者服务器。
场景:用户把报错交给带工具的 LLM 聊天机器人排障。作者称,向运营商泄露已有合同或本地部署等缓解,向无关第三方泄露受到的关注更少。编程场景里,作者引用超过 90% 的程序员经常用 AI 工具写代码或做开发 [6]。
现有不足:作者把既有第三方泄露分成直接提示注入、间接提示注入,以及把机密嵌进被操纵 URL 或外部资源(如图片)再诱使模型发出攻击者控制的请求。这些做法的共同点是注入指令来操纵模型,因而可能被提示注入防御拦住,用户也可能在提交前检查可疑或隐藏指令。
核心观察:网站抓取是聊天机器人被明确允许的正常能力。把秘密编进 URL 后,抓取本身就会向攻击者控制的 DNS 或 Web 服务器发请求;请求发出即完成外传,不需要服务器返回内容,也不需要模型故意外泄。作者认为,只靠阻止操纵模型行为来防机密泄露会给人虚假的安全感。
本文提出:LLMLeak。客户端恶意软件把秘密编进报错中的 URL,把该网站说成完成良性任务所需的资料(例如迁移某个库)。用户把报错交给聊天机器人后,抓取工具访问该 URL,攻击者从 DNS 或 HTTP 请求中解码秘密。作者称它不需要在被控设备上提权,也不依赖隐藏字符或同形字,因此在复制文本和截图等媒介上仍然有效,并可跨越气隙(例如手工复制报错或提供截图)。
威胁模型
- 目标:敌手 A 要在恶意软件无法与任何服务器通信的情况下传出秘密消息,同时不引起受害者用户 V 的注意。作者称,一旦被发现并分析,外传信息可能失去价值,例如密钥随后被吊销。
- 知识与控制:恶意软件已在系统上执行并取得机密(如通常无需额外权限即可访问的 API 或 SSH 密钥,或被故意授予秘密的恶意库),但不能因网络限制或监控直接连到 A 的服务器。A 不能控制良性聊天机器人 C 或其部署基础设施,也不能访问 V 与 C 的对话或 C 所处理的信息。
- 能力:A 能构造输出,且 V 会不加怀疑地把它交给 C,例如恶意软件生成的栈跟踪或报错。V 可能在提交前检查该输出,因此 A 不能使用显式提示注入,也不能直接指示 C 把信息发到攻击者服务器。A 可以运营公网可达的外部基础设施,例如位于无关物理位置的攻击者控制服务器。
- 受害系统:V 遇到问题后咨询配备网站检索等标准工具的先进 LLM 聊天机器人 C。C 可由外部提供商运营,也可部署在机构本地。外传由抓取工具发出的合法网络请求完成,V 与 C 只作为不知情的中间人。
有哪些相关研究?
作者把相关工作分成提示注入式泄露、隐蔽通道,以及 LLM 工具使用,并据此把 LLMLeak 定位成不操纵模型的中间人通道。
向第三方泄露与提示注入
- 直接与间接提示注入:作者讨论直接把恶意指令放进模型输入的攻击 [13, 19, 29],以及让模型加载含恶意指令的攻击者控制外部内容的间接提示注入 [12, 37]。作者称这些指令可被滥用来让 LLM 或其工具传出敏感信息,例如执行建立外部网络连接的代码。
- 不靠任意网络代码的外传:作者称先前工作通过诱使 LLM 发出攻击者控制的请求来外传,例如把机密嵌进被操纵 URL 的参数,或放进外部加载的资源如图片 [12, 28, 31]。作者指出,尽管传输方式不同,这些方法都依赖注入指令来操纵模型做出攻击者想要的行为。
- 提示注入防御:作者提到用输入结构化等手段阻止不受信任的指令影响模型 [8, 9, 20, 44],并称用户也可能在提交前检查可疑或隐藏指令。作者用这一点说明:只防止操纵模型行为,挡不住 LLMLeak 这种只使用预期抓取功能的通道。
隐蔽通道与网络外传
- 隐蔽通道定义:作者引用隐蔽通道是让两个协作方在不超出各自授权的情况下,违反安全策略交换信息的非预期或未授权信道 [32]。发送方与接收方约定协议,经一个或多个看似无害的中间人编码并传递信息。
- 恶意软件外传:作者称恶意软件拿到敏感数据后,与攻击者服务器的直接通信可能被网络监控发现 [42] 或被完全阻断,因而可借无害中间人间接传输,且依通信手段而定,不一定需要特殊权限。
- DNS 与 HTTP 承载数据:作者引用 DNS 把域名解析为 IP、并支持把权威委派给指定服务器 [22];HTTP GET 把资源写在 URL 中,路径或查询参数可携带数据 [10]。作者指出这些成分的结构并未严格标准化,任意字符串可以看起来像合法标识符,客户端单凭格式难以区分用途。DNS 标签与 FQDN 长度限制引用 [23],URL 语法主要定义在 ASCII 上引用 [4]。
LLM、对齐与工具调用
- 聊天机器人与工具:作者把 LLM 描述为基于 transformer 的深度网络 [36],经微调与来自人类反馈的强化学习对齐人类指令与偏好 [25],并通过工具检索实时信息、查数据库、执行代码或访问网站 [3]。作者引用间接提示注入工作 [12],说明从外部来源取回的恶意内容可以操纵模型行为;本文则把工具访问本身当作另一条攻击向量。
- 工具调用与智能体差异:评测选用指令微调模型,作者依据 Berkeley Function-Calling Leaderboard 上指令微调模型相对基座模型有更好的工具调用准确率 [21],以及指令微调更能对齐交互式、按轮进行的用户意图 [26]。作者还引用工作称通用模型与代码模型在智能体多步设置中的指令遵循与鲁棒性差异很大 [17],因此两类都覆盖。智能体遵循 ReAct [40],系统提示遵循 Yang 等人的 agent-computer interface 设计原则 [39]。
- 编码与相似度:载荷恢复用归一化 Levenshtein 相似度 [41]。客户端组件被描述为环境中的恶意、无特权库 [15, 35]。
基线方法与基准
- 基线:论文没有把既有攻击实现成对照系统。对比发生在 LLMLeak 内部变体:directive 与 informational 两种报错表述、Latin 与 CJK(Hanzi)编码、DNS 与 HTTP 通道、载荷 URL 与普通 URL、异常类型,以及载荷长度。
- 基准/数据集:作者自建 10 条典型 Python 崩溃栈跟踪(每种表述各 10 条,共 20 条),错误发生在 LLMLeak 库内,并在合成代码项目上用 ReAct 智能体调用 read_file、list_dir、search_code、write、fetch_url。另有对真实聊天机器人的案例研究。模型用 vLLM 以原生精度提供服务。
作者把 LLMLeak 定位为不要求把模型操纵成恶意行为、只利用其检索外部信息这一预期功能的隐蔽通道,从而绕过针对提示注入的防御;信息以 URL 中的常规字符表示,不依赖隐藏指令或隐藏字符。
论文如何解决这个问题?
恶意库在真实异常的 URL 里编码秘密,聊天机器人的抓取工具访问后,攻击者从 DNS 或 HTTP 请求中恢复秘密。
LLMLeak 把机密编进报错所引用的 URL,使用户或在用户机器上操作的聊天机器人在排障时用抓取工具访问该 URL;访问请求本身把秘密送到攻击者控制的 DNS 或 HTTP 服务器。Figure 1 把流程画成六步:恶意软件取得秘密、编进报错 URL、用户把报错交给聊天机器人、模型调用抓取工具、工具向攻击者服务器请求该 URL、攻击者解码。作者强调,服务器返回的内容和模型随后的回答都不是传输所必需的。
问题设定与需求
- 系统:受害者 V 向配备网站检索工具的聊天机器人 C 求助。C 与托管它的基础设施是良性的,不受 A 控制。
- 需求:R1 必须能把机密传到攻击者端点;R2 外传过程不能引起 V 注意,否则 V 可能发现妥协并作废泄露信息;R3 不能控制或修改 C 或其基础设施,只能使用合法暴露给 V 的能力。
- 挑战:C1 是良性 C 不会故意外传,A 也看不到 C 的输入、内部处理或输出,只能靠合法能力让 C 在不知情时发出携带攻击者所选信息的请求。C2 是恶意软件与 C 之间可能没有机器可读直连,V 可能复制文本或提交截图,甚至跨设备,从而形成气隙;因此不能依赖隐藏的机器可读信息或同形字。
客户端恶意软件与报错
- 载体:客户端是 V 软件环境中的恶意、无特权库。它在取得秘密后不直接发网,而是让程序在该库内进入错误状态,抛出真实异常,把秘密嵌进异常信息所引用的攻击者控制 URL。栈帧、模块和行号对应程序的实际执行。Figure 2 对比了真实库报错中的文档 URL 与 LLMLeak 生成的栈跟踪。
- 两种表述:directive 把外部引用说成解决错误所必需的信息来源;informational 只把外部资源当作参考,不明确要求打开。作者用二者区分常规排障线索与底层外传机制。附录 A、B 给出了这些报错文本。
- 不使用提示注入作为主体:攻击不附带指示模型访问 URL 或做异常操作的显式提示注入。作者称,对冷门或先前未知的库,查阅所引用的文档是合理的排障步骤。提示注入只被讨论为可选手段,用于提高模型访问引用 URL 的可能性,但会引入常规提示注入成分并可能影响隐蔽性;评测因此不依赖提示注入。
- 落地页:HTTP 端点在被正常访问时应呈现与该库相关、足够通用的页面。默认页提供通用框架文档、用法示例和证书信息,单独的排障页描述异常中的具体错误。打开外传 URL 时总会重定向到该排障页。这些响应不是外传所必需,而是为了降低事后怀疑。
DNS 与 HTTP 两条通道
- DNS:A 运营权威 DNS 服务器并控制要嵌入的域名,配置为通配符服务器,把任意子域解析到一个固定 IP 并记录被请求的域名。短消息可直接放入子域。每个 DNS 标签最多 63 个字符,完整域名表示最多 255 个字符(计入句点),且只能用小写字符。已是小写字母、数字和连字符的数据可直接编码;任意字符先映射成比特序列,再用允许字符表编码。接收方解码子域标签以恢复秘密。每次请求可加入随机 nonce,使连续查询唯一,从而不被解析器缓存抑制。
- HTTP:A 控制一个 HTTP(S) 端点,恶意软件把指向该端点的 URL 嵌进报错,用路径分量和查询参数携带编码信息。抓取工具发出 HTTP 请求后,服务器记录被请求的 URL。HTTP 没有单一的协议级 URL 长度上限,但客户端、服务器、代理和其他组件会限制长度,过长 URL 在栈跟踪里也可能显得可疑,因此要保持在人类可读的长度内。非 ASCII 数据可用两位十六进制编码,服务器再反解。
- 实现:客户端库与接收端都用 Python 和标准库。DNS 用 dnslib 做通配符到固定 IP 的配置,并包含 NS、通配符证书和 SOA;HTTP 用 http.server,并配置通配符证书以启用 HTTPS。两端记录全部入站请求。客户端只需少量代码读取秘密并把它的编码放进真实异常所引用的 URL。跨多个请求的载荷用序列信息重组。
提高信道容量的 CJK 编码
- 变换:在普通拉丁字符编码之外,Unicode(CJK)变体先把 16 字符的十六进制 SHA-256 标签当成字母表 0-9a-z 上的 base-36 串,再成对编码:一对符号 (s1, s2) 映射为 v = s1·36 + s2,取值在 0 到 1295,再映射到码位 U+4E00 + v。CJK 统一表意文字块为 U+4E00 到 U+9FFF,362 = 1296,因此所有对都落在该块内。
- 容量:两个 base-36 字符可编码约 10.34 比特(log2(1296) ≈ 10.34),因而至少一字节。作者称该变换无碰撞且完全可逆。DNS 侧先把 Unicode 转成 DNS 编码层表示再还原;HTTP 侧用对应字节序列(例如标准 UTF-8 URL 编码)表示。两条传输都可使用该编码。
评测中的智能体与成功判定
- 智能体:多步工具使用智能体遵循 ReAct:每轮先给出推理再调用工具,观察结果,直到生成给用户的回复或达到轮数上限。输入是源自恶意库的栈跟踪,任务是诊断并解决问题。工具为 read_file、list_dir、search_code、write、fetch_url,作用在合成代码项目上。模型由 vLLM 以原生精度服务,temperature 0.7,top-p 1.0,各模型相同。一轮定义为一次工具调用及其返回结果,硬上限 24 轮;作者称预实验中没有模型需要超过 24 轮才解决任务或调用 fetch_url,全部试验中只有约 0.03% 因达到最大长度而以 called = 0 结束。
- 系统提示:各实验使用同一系统提示,按 ACI 原则写明五个可用工具并以 respond 作为结束动作,固定“一个想法 / 一条命令”的回合格式,并给出中性指导(先调查再下结论,不要猜测项目中没有的事实)。提示与任务无关,不提及 URL、抓取或攻击。附录 E 给出完整提示词。
- 指标:Recovery Score r 用归一化 Levenshtein 相似度衡量原始载荷 ρo 与收到的载荷 ρr 有多接近,sim(ρo,ρr)=1−(lev(ρo,ρr))/(max(|ρo|,|ρr|)),r 从 0(完全缺失或不同)到 1(精确恢复)。Scall 为调用抓取工具请求任意网站的试验比例;Sreach 为请求落到攻击者控制域名并被其服务器观察到的比例;Sdata 为到达该域名的请求至少含部分载荷的比例;Sconf 为请求含完整、未修改载荷的比例。实验载荷是包含实验索引、栈跟踪和重复次数的任意哈希,由字母数字组成,放在子域或 HTTP GET 查询串中。
论文做了哪些实验?
11 个开源模型平均 Sconf 79.70%,信息性表述降到 54.63%;四款真实聊天机器人在案例中都抓取了载荷 URL。
实验设置
- 被测模型:11 个开源权重、以指令微调为主的模型,来自六个提供方:Meta-Llama-3.3-70B-Instruct(Dense,70B/70B,128K)、Meta-Llama-4-Scout-17B-16E-Instruct(MoE,109B/17B,10M)、Meta-Llama-3.1-8B-Instruct(8B/8B,128K)、Mistral-Small-24B-Instruct-2501(24B/24B,32K)、Mistral-7B-Instruct-v0.3(7.3B/7.3B,32K)、IBM-Granite-3.3-8b-instruct(8B/8B,128K)、Alibaba-Qwen2.5-7B-Instruct(7.6B/7.6B,32K)、Microsoft-Phi-4-mini-instruct(3.8B/3.8B,128K)、DeepSeek-Coder-V2-Lite-Instruct(MoE,15.7B/2.4B,128K)、Meta-Llama-3.2-3B-Instruct(3.2B/3.2B,128K)、Alibaba-Qwen3-Coder-30B-A3B-Instruct(MoE,30.5B/3.3B,262K)。Table 1 列出架构、总参数/激活参数和上下文窗口。案例研究另用 ChatGPT、Gemini、Claude 和 Grok;ChatGPT 一节写明模型为 GPT-5.4,其余三款论文未写具体版本。
- 数据与环境:10 条不同的 Python 崩溃栈跟踪,错误都从 LLMLeak 库内抛出,覆盖多种常见错误类型,并改变周围栈帧(transport、sync/loader 路径)。informational 与 directive 两种表述各 10 条,共 20 条。工具作用在合成代码项目上;链接解析到含该恶意库文档的真实库调试页,工具返回与栈跟踪一致的代码。
- 重复与解码:Table 2 的设置为 10 条报错、每种通道(DNS、HTTP)100 次重复,每模型 n = 2000。论文未说明这 2000 次在两种表述之间如何分配;Table 3 的平均 Sconf 与 Table 2 同为 79.7,Table 4 又把 79.7 标成 directive 的 Sconf。
- 指标:Scall、Sreach、Sdata、Sconf 与在 Sdata 上计算的 r,定义见第 3 问。主表报告百分比。
- 服务参数:vLLM、原生精度、temperature 0.7、top-p 1.0,每实验最多 24 轮。评审不是另一个 LLM 打分,而是由攻击者侧服务器是否收到请求、以及载荷与原始值的字符串相似度来判定。
- 案例协议:真实聊天机器人使用与开源实验相同的攻击载荷和栈跟踪;作者记录模型是否抓取 URL、是否警告用户,以及对话是否可继续。
主结果
据 Table 2,DNS 与 HTTP 合并、每模型 n = 2000 时的 Sreach 与 Sconf(%)如下。
模型 Sreach Sconf Llama-3.3-70B 100.0 99.9 Llama-4-Scout-17B 95.9 95.8 Llama-3.1-8B 95.8 95.2 Mistral-Small-24B 95.2 94.0 Granite-3.3-8B 94.5 90.6 Mistral-7B 92.8 91.0 Qwen2.5-7B 90.5 89.5 Phi-4-mini 81.5 75.8 表中省略 DeepSeek-Coder-V2-Lite(62.0 / 59.4)、Llama-3.2-3B(56.5 / 55.5)和 Qwen3-Coder-30B(30.9 / 30.0)。11 个模型平均 Sreach 81.42、Sconf 79.70。Qwen3-Coder-30B 是表中最低的一行,故保留在省略说明里并在下面单独写。
- 作者解读:作者称 LLMLeak 能有效传输载荷并促使 C 请求对应 URL,Sconf 最高到 99.9%;11 个模型中只有 3 个的 Sconf 低于 75%。
- 低成功率:Qwen3-Coder-30B 的 Sconf 为 30.0%。作者调查后称,它倾向于在本地解决错误,检查项目并修改依赖或配置文件(例如在 requirements 里抬高恶意库版本),而不是打开所引用的 URL。作者同时称,在良性设置下只凭不熟悉的报错就改依赖或配置、而不先查文档,可能引入新错误或破坏依赖。
- 与规模:作者希望用 3.2B 到 70B 的范围看成功率是否与模型规模相关,并提到更大模型可能有更强的上下文基础、从而更能识别恶意意图。Table 2 本身未给出相关系数;最高与最低分别是 70B 的 Llama-3.3-70B(99.9)和激活参数 3.3B 的 Qwen3-Coder-30B(30.0),但同为较小模型的 Mistral-7B 仍有 91.0。
失败点与表述方式
- 漏斗:Table 3 在同一批模型上给出 Scall、Sreach、Sdata、Sconf 和在 Sdata 上的 r。Scall 从 Qwen3-Coder-30B 的 32.2% 到 Llama-3.3-70B 的 100.0%;从 Scall 到 Sconf 的总下降最多为 Granite-3.3-8B 的 6.4 个百分点(97.0 到 90.6),11 个模型中有 8 个低于 4 个百分点。Sreach 与 Sdata 的差距不超过 0.4%,每个模型的 r 均不低于 0.93,平均 r 为 0.99。作者称成功率主要在一开始就决定,投递通道本身近乎无损且与模型无关。
- directive 与 informational:Table 4 比较两种表述的 Sconf 与 r。directive 平均 Sconf 79.7,informational 为 54.6,平均 ΔSconf 为 −25.0 个百分点;平均 r 从 0.99 到 0.97,Δr 为 −0.02。降幅最大的是 Mistral-7B(91.0 到 30.6,−60.4)和 Granite-3.3-8B(90.6 到 46.0,−44.6);最小的是 Mistral-Small-24B(94.0 到 93.2,−0.8)和 Llama-3.3-70B(99.9 到 97.0,−2.9)。
- 信息性表述的漏斗:Table 5 只报告 informational。平均 Scall 64.07、Sreach 56.85、Sdata 56.50、Sconf 54.63、r 0.97。作者称模型更少去网上搜资源,Scall 与 Sreach 在所有模型上下降,但一旦发起请求,Sreach 到 Sconf 的差距仍然小(例如 Llama-3.3-70B 从 98.0 到 97.0,Mistral-Small-24B 从 93.6 到 93.2),低抓取模型的 r 仍不低于 0.93。作者的结论是:表述主要影响模型是否发起请求,而不影响通道在发起之后的可靠性。
传输误差、因素消融与 CJK
- 误差类型:Table 6 在全部到达攻击服务器的请求上分解误差:完全正确(r = 1,即 Sconf)17 525 次,占 Sreach 的 97.9%;等长替换 54 次(0.30%);长度错误但前缀正确 121 次(0.68%);长度错误的混合子串 186 次(1.04%);无载荷(r = 0)18 次(0.10%);Sreach 合计 17 904(100.0%)。作者称误差主要来自不完整或部分被修改的载荷。
- CJK:Table 8 比较 Latin 与 CJK。平均 Sreach 从 81.4 到 80.6,平均 Sconf 从 79.7 到 66.0,平均 Δ 为 −13.7 个百分点。降幅从 DeepSeek-Coder-V2-Lite 的 −1.8 到 Qwen2.5-7B 的 −24.7;Llama-3.3-70B 为 −19.1(99.9 到 80.8),Qwen3-Coder-30B 的 Sreach 从 30.9 降到 23.4、Sconf 从 30.0 降到 19.7。作者讨论 Latin 每字符只有 26 + 10 种选择(忽略连字符),容量低于 CJK,但 Table 8 显示 CJK 的 Sconf 在每个列出的模型上都更低。附录 C 的 Table 11 给出 Hanzi 编码的详细指标;正文在可见部分没有逐项抄出 Table 11 的数字。
- 真实聊天机器人:作者做了案例研究,使用与开源实验相同的栈跟踪和载荷。作者报告 ChatGPT(GPT-5.4)、Gemini、Claude 和 Grok 都会抓取携带载荷的 URL,从而让攻击者侧收到秘密;作者称这些会话很少向用户发出警告。论文未在可见正文中给出这四款产品的分项百分比或试验次数。附录给出了示例栈跟踪,用来说明报错形态与真实库报错相似,以及外传 URL 的放置方式。
其他消融与分析
- 因素消融(Table 7,DNS/HTTP 合并,单位百分点):Granite-3.3-8B 的 Sreach 94.0,ΔURL +4.5,ΔError −0.8,ΔFraming −45.3;Mistral-7B 为 91.5、+3.0、−1.2、−57.3;Qwen2.5-7B 为 88.0、+3.5、−1.0、−37.3;Phi-4-mini 为 87.0、−5.0、+0.2、−48.7;DeepSeek-Coder-V2-Lite 为 56.5、−2.0、+1.8、−18.5;Qwen3-Coder-30B 为 33.5、−3.5、+0.8、−16.6。表只覆盖 6 个模型。作者改变的是载荷相对普通 URL、异常类型和报错表述。
- 长度(附录 D):Sreach 上,11 个模型中有 9 个在载荷从 4 个字符增到 63 个字符时下降,幅度从最大模型(Llama-3.3-70B、Llama-4-Scout-17B)的可忽略下降,到 Mistral-7B、Granite-3.3-8B 和 Qwen3-Coder-30B 的超过 12 个点。Llama-3.1-8B 与 DeepSeek-Coder-V2-Lite 相反,略有上升。附录未在可见文本中给出每个长度的完整数字表。
- 轮数上限:全部试验中约 0.03% 因达到 24 轮上限且 called = 0 而结束。作者称该上限没有约束模型行为。
- Qwen3-Coder-30B:在 Table 2 的汇总设置和 Table 5 的 informational 设置(Sconf 16.2)里都是最低。作者给出的解释只针对本地改依赖、不跟随 URL 这一行为。
- 通道比较:Table 2、Table 6、Table 7 把 DNS 与 HTTP 合并报告。可见正文没有单独给出每条通道的 Sconf。
- 恢复质量:Table 3 中 r 的模型平均值最低为 Mistral-7B 在 Table 5 informational 下的 0.93;directive 侧多个模型为 1.00。
有什么可以进一步探索的点?
作者把真实产品上的证据写成案例,并讨论不依赖提示注入时模型可能根本不去抓取 URL。
作者指出的局限与后续方向
- 不抓取就无法外传:第 4.6 节写明,模型有时不跟随外部引用,只根据报错里已有的信息给出一般解释或方案,这种行为会阻止外传请求发出。作者没有把这写成独立的 Limitations 节标题,而是把它作为攻击成立条件。
- 提示注入与隐蔽性的取舍:第 4.6 节称,可以在报错中加入额外指令来提高助手查阅链接的可能性,但这会引入常规提示注入成分,并可能略微影响 LLMLeak 的隐蔽性。评测因此不使用提示注入。
- 信道格式约束:第 4.3 节写明 DNS 标签 63 字符、FQDN 255 字符,且只能使用小写字符,任意字符必须先映射再编码。第 4.4 节写明 HTTP 虽无单一协议级长度上限,但各组件会限制长度,异常长的 URL 在栈跟踪中可能显得可疑,因此必须保持人类可读长度。
- 案例而非大规模闭源评测:贡献列表与第 5 节把真实聊天机器人上的结果称为 case study。可见正文没有给出 ChatGPT、Gemini、Claude、Grok 的试验次数或分项成功率。
- 可被用户检查:第 3.2 节假设 V 会不加怀疑地把输出交给 C,但同时写明 V 可能在提交前检查该输出,所以不能使用显式提示注入。若 V 注意到传输,可能吊销已泄露的凭证,使信息对 A 失去价值(R2,第 3.3 节)。
- 后续编码:第 4.5 节把 CJK 变体作为提高有效信道容量的设计,而不是已解决所有长度限制;Table 8 显示该变体的 Sconf 低于 Latin。作者没有在可见正文中另列“计划开源”或“将并入某代码库”。
实验覆盖范围
- 开源模型:第 5.1.2 节与 Table 1 评测 11 个开源权重模型,Dense 与 MoE 都有,总参数从 Llama-3.2-3B 的 3.2B 到 Llama-4-Scout 的 109B(激活 17B),上下文从 32K 到 Llama-4-Scout 的 10M。服务设置为 vLLM、原生精度、temperature 0.7、top-p 1.0。
- 任务与重复:第 5.1.3–5.1.4 节使用 10 条 Python 栈跟踪、两种表述共 20 条;Table 2 为每种通道 100 次重复、每模型 n = 2000。工具集为 read_file、list_dir、search_code、write、fetch_url,轮数上限 24。系统提示全文在附录 E,且不提及 URL、抓取或攻击。
- 指标与误差:成功由攻击者服务器是否观察到请求以及载荷字符串是否完整来判定(第 5.1.5 节)。Table 3–6 给出漏斗和传输误差分解;Table 6 的 Sreach 合计为 17 904 次请求。论文未报告另一个模型作为评审,也未报告评审与人工的一致性。
- 消融范围:Table 4–5 覆盖全部 11 个模型的两种表述;Table 7 的 ΔURL、ΔError、ΔFraming 只列出 6 个模型;Table 8 比较全部 11 个模型的 Latin 与 CJK;附录 D 比较载荷从 4 到 63 字符时的 Sreach 方向,未在可见文本中给出完整长度表。DNS 与 HTTP 在主表中合并。
- 闭源与防御:真实产品部分是 ChatGPT(GPT-5.4)、Gemini、Claude、Grok 的案例研究,论文未报告每款的重复次数。论文讨论了提示注入防御 [8, 9, 20, 44] 为何挡不住这条通道,因为评测中的报错不含注入指令;论文未报告对这些防御产品做自适应攻击实验,也未报告效用下降、延迟或误拒。
总结一下论文的主要内容
LLMLeak 用报错 URL 借聊天机器人抓取外传秘密;11 个开源模型平均 Sconf 79.70%,信息性表述平均 54.63%。
LLMLeak 研究一种隐蔽外传:本地恶意软件已拿到机密,却因为网络限制或监控不能直接连接攻击者,于是把秘密放进看起来像排障文档的 URL,让良性聊天机器人的网页抓取工具在访问时把秘密带出去。
- 问题:用户会把程序报错交给带工具的聊天机器人。作者认为,既有向第三方泄露的做法依赖直接或间接提示注入,或依赖诱使模型发出攻击者控制的请求,因而可能被注入防御和用户检查挡住。只防止操纵模型行为,挡不住模型按预期去抓取外部资料。
- 做法:恶意、无特权库在自身代码路径上抛出真实异常,把秘密编进 URL 的子域(DNS,标签不超过 63 字符、FQDN 不超过 255 字符、仅小写)或路径/查询参数(HTTP)。directive 表述把链接说成必需资料,informational 只作参考。评测不用提示注入。CJK 变体把 base-36 字符成对映射到 U+4E00 起的表意文字以提高每字符容量。请求到达即完成传输。ReAct 智能体在合成项目上最多跑 24 轮,temperature 0.7、top-p 1.0。
- 开源主结果:Table 2 中 11 个模型、每模型 2000 次(10 条报错,DNS 与 HTTP 各 100 次)的平均 Sreach 为 81.42%,平均 Sconf 为 79.70%。Llama-3.3-70B 的 Sconf 为 99.9%,Qwen3-Coder-30B 为 30.0%;作者称后者更常在本地改依赖而不是打开链接。Table 3 中一旦调用抓取工具,到 Sconf 的下降最多约 6.4 个百分点,r 平均 0.99。
- 表述、编码与误差:informational 的平均 Sconf 为 54.63%(Table 5),相对 directive 的 79.7 平均低 25.0 个百分点(Table 4),作者称主要少的是“是否发起请求”。到达攻击服务器的 17 904 次请求中,97.9% 载荷完全正确(Table 6)。CJK 的平均 Sconf 为 66.0%,比 Latin 低 13.7 个百分点(Table 8)。
- 案例与作者结论:作者报告在 ChatGPT(GPT-5.4)、Gemini、Claude 和 Grok 的案例中,聊天机器人抓取了载荷 URL,并称很少向用户警告。作者的结论是,LLM 的合法抓取功能可以成为跨越网络隔离的隐蔽通道,而且不需要操纵模型去做恶意行为;用户和模型都只是不知情的中间人。