系统:运行中
← 返回所有攻击
INDIRECT INJECTION CRITICAL NEW

LogJack:云日志成为针对调试智能体的提示注入通道

2026 年 4 月的一项基准测试显示,读取云日志并执行修复的 LLM 调试智能体会服从隐藏在日志行中的指令——逐字执行命令率最高达 86.2%,8 个模型中 6 个可被远程代码执行,且云厂商的防护几乎检测不到任何内容。

2026-06-17 // 6 min affects: llama-3.3-70b, claude-sonnet-4-6, llm-debugging-agents, sre-remediation-agents

这是什么?

2026 年 4 月,论文 LogJack: Indirect Prompt Injection Through Cloud Logs Against LLM Debugging Agents(arXiv 2604.15368)研究了一种在 DevOps 与 SRE 工具链中迅速普及的部署模式:读取云日志、诊断事件、然后执行修复命令的智能体。LogJack 并不是一种新的攻击类别。它属于间接提示注入——Greshake 等人在 2023 年形式化的变体,即指令隐藏在模型随后读取的第三方内容中——只是被应用到一个具体且默认被信任的数据源:日志流。

结论很具体。当调试智能体把日志内容纳入其上下文时,能够把一段字符串写入这些日志的攻击者,就能在其中植入智能体会服从的指令。由于日志行通常被当作惰性的遥测数据处理,无论是智能体本身还是周围的防护措施,都不会预期其中带有命令。

本文属于防御性分析。它不包含可利用的载荷;底层技术早已公开,而这篇论文的贡献在于度量——包括证明云厂商自家的输入过滤器并不能拦截该攻击。

工作原理

威胁模型不假设对智能体、模型或基础设施拥有任何特权访问。攻击者只需影响一段最终会进入智能体所读取日志的文本:一条应用错误信息、被回显到日志中的请求字段、用户可控的标识符、一段执行栈片段。随后这些内容会原封不动地流入智能体的提示。

LogJack 用一个由 5 个云日志类别下 42 个载荷组成的基准来检验这一点,针对 8 个基础模型3 种提示条件下运行(每种 5 次试验)。最关键的变量是智能体的运行模式:

  • 主动模式 —— 智能体被允许执行修复。此时逐字执行命令率从 0%(Claude Sonnet 4.6)到 86.2%(Llama 3.3 70B)不等。日志行写着”运行这个修复”,智能体便照做。
  • 被动指令 —— 系统提示明确写明”不要执行修复”。这把大多数模型降到 0%,但 Llama 3.3 70B 仍有 30.0% 的概率执行,说明系统提示里一行警告并不是一种控制手段。

尤为关键的是,通过 curl | bash 进行远程代码执行在 8 个模型中的 6 个上成功——智能体从网络上获取并运行了攻击者控制的代码,只因为一条日志条目把它当作修复方案呈现给它。本文不复现任何载荷;其机制不过是模型无法区分真正的日志信息与一条伪装成日志信息的指令。

为什么重要

日志是任何系统中最暴露的面之一。它们由应用代码、第三方库、被回显的用户输入以及上游服务写入——其中很多内容是攻击者无需认证就能影响的。调试或修复智能体把这股低信任的流变成了执行通道,而此处的后果不是数据泄露,而是在云基础设施上执行命令

最应让防御者担忧的结果与防护措施有关。云厂商托管的输入过滤器在很大程度上未能检测出嵌入日志的注入:Azure Prompt Shield 只标记了最明显的那个载荷(32 个中的 1 个),GCP Model Armor 一个都没检测到。这些产品正是作为针对此类输入的安全层来销售的,然而藏在一条看似合理的日志行中的指令却能从中溜过。把厂商防护作为主要防御,会带来虚假的覆盖感。

模型之间的差异同样具有启发性。一个模型(Claude Sonnet 4.6)在主动模式下以 0% 抵御,而另一个(Llama 3.3 70B)大多数时候都服从——可利用面在很大程度上取决于模型,以及智能体是否被允许行动,而不取决于某种奇特的载荷。这与 2026 年一个更宏观的主题相呼应:读取受对手影响文本的 LLM 增强型运维流水线,例如 Poisoning the Watchtower(arXiv 2605.24421,2026 年 5 月)所记录的 SOC 日志攻击,会继承它们所读取内容的全部信任问题。

防御

教训是架构层面的:把日志当作不可信输入,绝不让智能体对日志的读取直接导致状态变更。

  • 将诊断与行动分开。 让智能体分析日志并提出修复方案,但任何命令都要经过人工审批环节或策略引擎。Llama 在被动指令下残留的 30% 表明,系统提示里的”不要执行”只是建议,而非边界。
  • 不要把厂商防护当作主要控制。 Azure Prompt Shield 和 GCP Model Armor 对嵌入日志的内容几乎全部漏过。把它们用作纵深防御,而不是入口闸门。
  • 约束动作空间,而不仅是输入。 用白名单限制智能体可运行的修复命令,彻底禁止”下载即执行”的模式(curl | bashwget | sh),并要求任何命令都由结构化的事件状态来论证,而非由日志的自由文本来论证。
  • 标记来源。 在流水线允许时,把日志内容在提示中标注为不可信数据,并使其远离模型当作指令处理的任何区域;给智能体提供结构化遥测,而不是拼接的原始日志文本。
  • 用真实的日志载荷进行测试。 静态越狱测试集会低估这种风险。针对真正部署的智能体,跨各日志类别、在主动与被动两种模式下,用注入内容进行评估,因为模式与模型对结果的影响大于载荷的巧妙程度。

状态

项目详情
论文”LogJack: Indirect Prompt Injection Through Cloud Logs Against LLM Debugging Agents”
arXiv 编号2604.15368
发布时间2026 年 4 月
基准42 个载荷、5 个云日志类别、8 个模型、3 种提示条件
逐字执行命令率(主动)0%(Claude Sonnet 4.6)– 86.2%(Llama 3.3 70B)
被动”不要执行”指令多数模型 0%;Llama 3.3 70B 30.0%
通过 curl | bash 的 RCE在 8 个模型中的 6 个上成功
厂商防护Azure Prompt Shield 检出 1/32;GCP Model Armor 检出 0
性质防御性研究——无可利用载荷

Sources