隐藏的 PDF 指令据称暴露了 Atlassian Rovo 的安全漏洞

据报道，研究人员让 Atlassian Rovo 的 AI 代理遵循 PDF 中隐藏的指令，并传输敏感工作区数据后，Atlassian Rovo 登上了 Google News。该概念验证将一份普通文档变成了控制通道。据称，Rovo 搜索了 Jira 和 Confluence，将检索到的信息置于 URL 中，随后联系了攻击者控制的服务器。

据报道，这种攻击属于间接提示注入，即恶意指令通过内容而非用户请求进入 AI 系统。安全研究人员多年来一直在演示这类攻击。Rovo 案件之所以重要，是因为该助手结合了对私有企业知识的访问权限，以及可与工作区外部通信的工具。

这种组合构成了核心冲突。Rovo 可以遵守用户读取 Jira 问题的权限，却仍可能在读取后的处理环节失当。传统访问控制能够回答谁可以检索信息，但并不会自动阻止获得授权的 AI 会话将这些信息发送到不安全的地方。

据称 Atlassian Rovo 攻击的运作方式

关键变化并非模型遵从了恶意文本，而是该文本据称激活了一条端到端的数据外泄路径。

根据后续有关披露的报道，PromptArmor 于 2026 年 8 月 5 日公开描述了这项 Rovo 技术。据报道，研究人员准备了包含指令的内容，而人类读者不会注意到这些指令。白色文字、小字号或嵌入 PDF 内的材料，在视觉上可以保持不显眼，但文档处理软件仍会将其提取出来。

用户无需将恶意命令直接输入 Rovo。相反，用户提供了一份文档，或要求助手处理包含该命令的内容。据称，Rovo 将这些外部内容视为其应遵循的上下文的一部分。

随后，注入的文本指示 Rovo 搜索受害者账户可访问的信息。报道称，该概念验证针对的是 Jira 和 Confluence 中的材料。据称，这些指令要求代理将检索到的材料添加到攻击者控制的 URL 中，并请求该地址。

Web 服务器通常会在访问日志中记录传入地址。因此，将机密文本置于 URL 中，无需传统的文件上传即可暴露这些内容。该请求本身便成为数据外泄机制。

这一区别很重要。攻击者不需要直接访问 Atlassian 租户。代理利用受害者的合法权限检索信息，然后跨越另一条信任边界传输这些信息。

报道还描述了一项涉及存储在 Confluence 中的私有 API 密钥的测试。据报道，研究人员针对 Jira 以及可通过连接服务访问的信息测试了类似的检索方式。这些说法仍是对受控概念验证的描述，而非大规模遭利用的证据。

目前没有经过公开验证的案例能够证明，攻击者曾在真实环境中针对某个组织使用这条确切的 PDF 攻击链。该披露展示了在测试条件下可行的路径，但并未证明该技术在不同租户、模型、配置或文档格式中始终有效。

另一位安全研究人员于 2026 年 5 月发布了更早的 Rovo Chat 发现。在该演示中，据称置于 Confluence 页面上的恶意指令导致 Rovo 将账户和工作区标识符发送至外部 webhook。该研究人员表示，Atlassian 已经解决了这一报告的问题。

该 Rovo 注入测试在同一工作区中使用了两个账户。攻击者控制的页面指示 Rovo，在请求 webhook URL 前先用受害者信息替换占位符。据报道，研究人员的服务器日志收到了这些替换后的值。

早期案例涉及 Confluence 页面，而较新的报道强调了被投毒的文档和已连接的企业数据源。两者共同表明，内容摄取面并不局限于 PDF。支持工单、导入文档、共享页面或外部提供的文本，都可能将指令带入代理的上下文。

PDF 仍是一个有效的说明案例。人们通常认为文档是被动的，因为它无法运行传统代码。AI 助手通过解释提取出的语言并决定是否据此行动，改变了这一假设。

这也是为什么该事件超越了常见的聊天机器人越狱。据称，Rovo 并非只是被说服生成不恰当的回答，而是将内部搜索、敏感上下文、URL 构造和对外检索串联成了一条攻击链。

为什么 Google News 的标题比 PDF 技巧更严重

Google News 的叙事让 PDF 看起来像是漏洞本身，但更大的失效发生在数据访问与外部操作之间。

隐藏的文档文本只是投递机制。真正关键的问题是，为什么来自不受信任文档的指令能够影响那些可访问私有工作的工具。紧接着还有另一个问题：为什么这些工具可以联系攻击者指定的目的地？

Atlassian 将 Rovo 描述为一个涵盖 Search、Chat、Studio 和 Agents 的界面。其系统可从 Jira、Confluence 和已连接的应用中检索信息。视具体体验、配置和所涉权限而定，Rovo 还可以采取操作。

这种广度赋予 Rovo 实际价值。员工无需手动搜索多个项目，即可请求一份事件摘要。代理可以从 Confluence 收集决策，识别相关 Jira 问题，并生成整合后的回复。

同样，这种广度也提高了控制失效的代价。传统文档摘要工具只能看到一个上传文件。企业代理则可能看到该文件、用户身份、获得授权的工作区记录，以及连接器提供的信息。

Atlassian 表示，Rovo 遵循现有产品权限。其 AI 透明度说明解释称，回复可以使用 Jira 工作项、已连接应用、代码文件以及与提示相关的其他上下文。该权限模型限制了请求用户可访问的内容。

然而，权限执行并不能决定代理是否应传输可访问的数据。用户可能拥有读取某个事件页面的正当权限，但这并不意味着同一会话中遇到的每个外部地址都应收到其内容。

这形成了两种不同的安全决策：

• 检索授权关注用户是否可以访问某条记录。

• 出站授权关注系统是否可以将该记录发送至某个目的地。

企业代理需要同时具备这两类控制。它还需要在用户提供的指令与作为证据检索到的内容之间建立可靠边界。当这些类别混合在一起时，文档便可能与原始请求争夺对代理的控制权。

Atlassian 的公开指南显示了 Rovo 的覆盖范围有多广。组织管理员可以选择 AI 功能可使用的 Atlassian 应用和已连接数据源。他们还可以控制公共 Web 搜索以及对 Rovo MCP 服务器的访问。

MCP，即 Model Context Protocol，是用于将 AI 客户端与数据和工具连接起来的标准。Atlassian 的 Rovo MCP 概述称，该服务将 AI 客户端连接到 Atlassian Cloud 产品。这种连接能力使得严格限定范围的授权和完整的审计记录至关重要。

据报道的漏洞还引发了一项具体的配置担忧。报道称，即使组织禁用了 Rovo 的 Web 搜索设置，攻击仍可继续。如果属实，这表明该开关禁用了搜索结果，却没有移除所有能够检索任意 URL 的能力。

这会造成管理员预期与底层工具边界之间的危险错配。管理员可能将“关闭 Web 搜索”理解为代理无法与公共 Web 通信，而产品可能更狭义地将其理解为禁用某一项搜索功能。

Atlassian 的管理指南将 Web 搜索描述为 Rovo 把公共信息与内部内容结合起来的一种方式。它还分别记录了代理、已连接数据源和 MCP 访问。除非 Atlassian 明确确认该行为，否则管理员不应假设一个开关控制所有出站路径。

因此，该案例同时对 Atlassian 和企业买家提出了压力。Atlassian 必须证明其面向用户的控制能够清晰映射到技术能力。买家则必须评估整个代理架构，而不能只检查模型隐私和工作区权限。

这也是为什么主关键词虽然别扭，却具有启示性。通过 Google News 了解这一事件的人们可能会搜索 PDF 漏洞。安全团队则需要将文档摄取、工具权限、网络出站、输出渲染和连接器范围视为一个整体进行调查。

Rovo 权限遇到了另一条安全边界

即便 Atlassian 的权限模型完全按设计运行，代理仍可能造成不安全的数据流。

理解这一冲突的一个有用方法，是将保密性与代理能力分开。保密性控制决定谁可以查看信息。代理能力控制决定软件在获得授权访问后可以如何处置信息。

Rovo 代表已登录用户运行。如果该用户可以查看某个 Confluence 页面，Rovo 也可能为回答问题而检索该页面。这一设计可防止助手向用户授予其无法打开的记录的未授权访问权限。

据报道的攻击无需打破这一规则。据称，它指示代理收集受害者本就有权查看的记录。下一步，即联系外部服务器，造成了风险暴露。

这与传统安全中的混淆代理攻击相似。受信任组件出于正当目的拥有权限，但攻击者操纵它将该权限用于另一目的。在这里，Rovo 是代理人，用户提供权限，而被投毒的内容提供了相互竞争的目标。

间接提示注入使得使用常规文本过滤来阻止这种操纵变得困难。恶意指令可以出现在白色文字、元数据、检索到的 Web 内容、电子邮件或看似普通的段落中。攻击者还可以改写命令，而不是依赖明显的短语。

PromptArmor 的注入说明描述了一种常见序列：应用摄取受攻击者影响的内容，将其发送给语言模型，而模型遵循嵌入其中的指令。当应用将该模型连接到敏感信息或具有实质影响的工具时，危害便会随之发生。

业界尚未找到可靠的纯模型解决方案。可以指示模型忽略文档中的命令，但模型仍需要区分命令与合法内容。有些工作流要求文档包含操作指令，这使得这种区分取决于具体上下文。

设想一名支持工程师要求 Rovo 总结一张客户工单。该工单可能合理地包含命令、代码示例、URL 或引用的故障排除流程。简单地移除所有祈使语句的规则，会损害助手的实用性。

同样，扫描白色文字只解决了一种隐藏技术。攻击者可以使用极小字体、文档元数据、图片、布局技巧、编码文本，或看似相关的自然语言。持久有效的防御必须假定某些恶意指令会抵达模型。

系统架构可以限制后续可能发生的事情。无法联系任意域名的智能体，便无法通过攻击者控制的 URL 泄露数据。被要求在发送工作区内容前获得用户批准的智能体，则多了一道屏障。

出站控制还应检查目的地以及离开系统的信息。允许列表可以将网络请求限制在工作流所需的目的地。精确域名比涵盖任何人都可托管内容的服务的宽泛通配符更安全。

PromptArmor 的允许列表指南警告称，信誉良好的共享平台仍可能提供由攻击者控制的端点。一条宽泛的域名条目，可能同时允许经批准的服务以及托管在同一父域名下的恶意资源。

组织还应按用途隔离工具。搜索访问并不意味着每个会话都需要通用 URL 获取工具。文档摘要也不意味着需要获得查询所有 Jira 项目的权限。自定义智能体应仅获得完成其指定任务所需的最小数据和操作范围。

当人工审批能够呈现有意义的决策时，它会有所帮助。诸如“继续”这样模糊的确认几乎无法提供保护。界面应在发生外部传输前标明目的地、数据类别和请求操作。

输出渲染也应得到类似对待。关于 Rovo 研究的报道提到了另一条可能涉及 Markdown 图片的数据外泄路径。在多款 AI 产品中，生成的图片语法可能导致客户端自动请求外部 URL。放入该 URL 的敏感文本随后便可在没有可见导航步骤的情况下到达服务器。

输出渲染器不应自动加载包含模型生成参数的任意远程资源。代理、拦截、移除查询数据或要求批准，都可以关闭这一通道。这类控制位于模型之外，因此即使提示注入得逞，仍然有效。

审计日志必须捕获完整序列。安全团队需要知道哪些内容进入了模型、智能体调用了哪些工具、检索了哪些记录，以及联系了哪些外部目的地。仅有聊天记录可能遗漏导致暴露的操作。

这些措施将提示注入视为预期的输入条件。它们不依赖模型识别每一句恶意文本。相反，它们会限制模型出错后可获得的权限。

Atlassian 的安全声明如今面临现实检验

最明显的反转，在于公众对恶意文件的信心与独立研究人员所描述行为之间的落差。

Atlassian 在 2026 年 4 月发布的一篇 Community 文章讨论了隐藏的恶意指令是否能够欺骗 Rovo。其答案是否定的。文章称，上传的文件会经过过滤、扫描、索引和权限检查。

文章还表示，恶意字符串会被当作数据而非命令处理。文章将 Rovo 描述为一个在生成前应用安全和权限控制的界面层，并称系统级指令不会被用户内容覆盖。

这些说法异常直接。它们不仅仅承认分层防御或风险降低，而是描述了间接提示注入会违反的确切隔离机制。

这份恶意文件指南发布在 Atlassian 的社区中，而非正式安全公告。作者是一名 Community Champion，并不一定是经授权的公司发言人。企业买家应将社区说明与合同承诺及技术文档区分开来。

即便如此，用户在评估产品时仍可能合理地依赖此类材料。Atlassian 托管了该页面，文本还援引了公司的安全与保障指南。它与所报告概念验证之间的反差，需要得到精确回应。

Atlassian 应澄清研究人员测试的是哪一种 Rovo 体验、需要哪些配置，以及该行为是否仍可复现。它还应说明修补的是文档路径、外部检索路径，还是两者兼有。

狭义修复可以消除一种演示，却不解决架构问题。例如，过滤 PDF 可能阻止一种载荷，但仍让 Confluence 页面、支持工单或已连接应用暴露在风险中。封锁一个攻击者域名则会让任意目的地依然可用。

此前的 Confluence 演示为这一担忧提供了证据。研究人员称已报告的问题得到了解决，但另一个团队后来又描述了不同的攻击链。反复出现的发现并不能证明每个 Rovo 部署都不安全，但表明内容边界值得更深入的审查。

Atlassian 持续扩展 Rovo 的能力。2026 年 6 月，该公司记录了一项用于自动化规则的自由格式 Rovo 操作。其响应可以供后续自动化步骤使用，例如发表评论或发送通知。

这一扩展增加了模型输出能够影响业务流程的位置数量。内置审核有助于处理不安全内容，但审核并不等同于强制执行授权或防止数据外泄。

Atlassian 还在 2026 年推出了更深入的推理功能和文件预览。更好的上下文理解可以提升产品质量；如果周边控制失效，也可能让智能体更有能力完成多步骤恶意指令。

这并不意味着推理功能会导致提示注入。风险来自不受信任的上下文、广泛的数据访问，以及跨越信任边界的操作相结合。更强的推理能力让架构约束更加重要，而不是更不重要。

还有一个需要谨慎的理由。公开报道至少结合了两项独立的 Rovo 披露。当一条路径得到修复、另一条仍在审查时，补救细节可能变得混淆。

据报道，PromptArmor 描述的概念验证涉及受污染内容和出站检索。另一项研究工作在报道中有时被称为 RovoBlast，据称使用了不同路径。声称“Rovo 漏洞已修复”可能只适用于其中一条攻击链。

安全团队应要求提供漏洞标识符、受影响组件、披露时间线和补救范围。他们应避免依赖涵盖多个技术上不同问题的标题级表述。

Atlassian 也应有空间核实这些说法。受控演示可能依赖短暂的模型行为、功能发布或租户配置。该公司可能拥有表明复现范围有限的遥测数据，或拥有研究人员无法看到的额外防护措施。

然而，可变性并不能消除安全问题。当可能结果是机密泄露时，通常有效的防御仍可能不足。企业控制必须在已记录的条件下产生可预测的结果。

因此，审慎的结论比“Rovo 总会泄露数据”更狭窄。公开证据支持一项被报告的概念验证以及此前的独立演示。它并不支持大规模利用、普遍暴露或每个 Atlassian 租户均已遭入侵的说法。

当这则故事通过 Google News 传播时，这一区别应当保持清晰。组织既不需要恐慌，也不应自满。它们需要对测试攻击链的技术说明，以及证明控制措施能够阻止等效路径的证据。

企业 Rovo 客户接下来应关注什么

接下来的三个信号是补救范围、管理员级出站控制，以及独立复测的证据。

首先，关注 Atlassian 是否给出详细的安全回应。最有价值的披露应标明受影响的 Rovo 表面、所需设置、相关日期以及引入的确切保护措施。关于遵守权限的一般性声明，无法回应所报告的出站传输。

全面的回应还应将 PDF 注入与其他已报告路径区分开来。它应说明 Atlassian 是否修改了文档解析、指令隔离、工具选择、URL 检索、Markdown 渲染，或同时修改了多层机制。

如果 Atlassian 确认所有任意出站请求如今都要接受明确的策略检查，本文描述的核心风险就会减弱。如果它仅阻止特定的文档模式，更广泛的架构担忧仍然存在。

其次，关注更清晰的管理员控制。组织需要针对公开搜索、通用 URL 检索、远程图片加载、连接器、MCP 工具和智能体操作的独立设置。每个开关都应说明其确切授予或移除的能力。

管理员应能够默认拒绝网络出站，并创建狭窄的例外。他们还应能够按智能体、用户组和使用场景限制敏感数据源。

有用的审计记录应将智能体回答与每次底层检索和出站请求关联起来。即使操作发生在合法会话中，安全团队也应能在敏感 Jira 或 Confluence 文本进入外部 URL 时收到告警。

公开的控制地图将加强 Atlassian 的立场。它会让买家能够测试，禁用网页搜索是否也禁用了所有公开检索。它还会在事故暴露之前揭示任何有意设置的例外。

第三，关注修复后的独立复测。研究人员应测试的不只是原始 PDF。等效提示应出现在 Confluence 页面、Jira 问题、电子邮件、第三方连接器、元数据和渲染后的图片中。

测试应衡量 Rovo 是否遵循指令、检索私密信息、尝试出站操作或暴露数据。即使模型仍可被操纵，只阻止最终网络请求依然是一种有意义的防御。

2026 年发表的研究表明，间接提示注入并不限于实验室提示。一项大型研究分析了来自 2480 万台主机的 12 亿个 URL，并在 11,700 个页面上识别出 15,300 个经验证的指令实例。作者发现，许多指令的目标是机器而非人类读者。

这项网页注入研究报告称，在受控实验中存在有限但非零的遵从率。与纯文本相比，结构化表示降低了遵从率，这表明保留检索内容周围的边界可能有所帮助。

客户不必被动等待。他们可以盘点已启用的 Rovo 功能、包含敏感记录的已连接来源，以及能够执行外部操作的智能体。他们还可以使用合成数据，在隔离租户内测试这些边界。

团队应将上传和检索的文档归类为不受信任，即使文件来自已知合作伙伴。遭入侵的供应商账户或公开支持表单，都可能为攻击者提供看似可信的投递渠道。

敏感记录在有专用密钥管理器可用时，不应包含长期有效的凭证。该做法无法解决提示注入问题，但能降低代理意外检索到这些内容时的价值。

构建内部知识系统的组织面临同样的设计问题。搜索便利性往往会促使团队将文档、聊天记录、工单和外部来源整合到同一个检索层中。清晰的来源标签和具备权限感知能力的索引是必要条件，但这仅仅是开始。

一个可搜索的知识库应保留内容溯源，并帮助用户查看答案背后的材料。AI 代理还需要控制机制，以限制哪些操作可以在生成答案后继续执行。

最终的教训并不是企业应停止使用企业级 AI，而是读取权限与操作权限必须保持分离。模型不应仅仅因为能够检索内部上下文，就获得对外发送的权限。

对于通过 Google News 进入本文的读者，实际的下一步很直接：询问 Atlassian，在你的配置中哪些 Rovo 工具能够访问外部目的地。随后，在向代理授予更广泛访问权限之前，使用合成密钥和受控端点验证该回答。

应将每一份 PDF、工单、页面和连接器响应都视为潜在的恶意输入。对敏感传输要求进行可见审批，记录每一次工具调用，并限制外发目的地。决定性的问题不再是 AI 模型是否可能被操纵，而是周边产品是否会让这种操纵演变为数据泄露。