安全专家在JFrog我发现了一个“即时劫持”威胁，它利用了人工智能系统使用MCP(模型上下文协议)相互通信的弱点。
商业领袖希望通过直接使用公司数据和工具。但是，像这样连接人工智能也带来了新的安全风险，不是在人工智能本身，而是在它是如何连接的。这意味着首席信息官和首席信息官需要考虑一个新的问题:保持供给人工智能的数据流安全，就像他们保护人工智能本身一样。
为什么针对MCP等协议的人工智能攻击如此危险
人工智能模型——无论它们是在谷歌、亚马逊上，还是在本地设备上运行——都有一个基本问题:它们不知道眼下正在发生什么。他们只知道他们受过什么训练。他们不知道程序员在编写什么代码，也不知道计算机上的文件里有什么。
的科学家们人类的创建了主控制程序来解决这个问题。MCP是AI连接到现实世界的一种方式，让它安全地使用本地数据和在线服务。当你指向一段代码并要求它重做时，它能让像Claude这样的助手理解这意味着什么。
然而，JFrog的研究表明，MCP的某种使用方式存在一个提示劫持弱点，可以将这个梦想中的AI工具变成一个噩梦般的安全问题。
想象一下，一个程序员要求一个人工智能助手推荐一个标准的Python工具来处理图像。人工智能应该建议枕头，这是一个很好的受欢迎的选择。但是，因为一个瑕疵(CVE-2025-6515)在oatpp-mcp系统，有人可以潜入用户的会话。他们可以发送自己的假请求，服务器会将其视为来自真实用户。
因此，程序员从人工智能助手那里得到了一个糟糕的建议，推荐了一个名为最佳图像处理包。这是对软件供应链的严重攻击。有人可以利用这种提示劫持来注入坏代码、窃取数据或运行命令，而所有这些看起来都像是程序员工具箱中有用的一部分。
这种MCP即时劫持攻击是如何工作的
这种即时劫持攻击扰乱了系统使用MCP进行通信的方式，而不是AI本身的安全性。具体的弱点是在Oat++ C++系统的MCP设置中发现的，它将程序连接到MCP标准。
问题在于系统如何使用服务器发送的事件(SSE)处理连接。当真正的用户连接时，服务器会给他们一个会话ID。然而，有缺陷的函数使用计算机的会话内存地址作为会话ID。这违背了协议的规则，即会话id应该是唯一的和密码安全的。
这是一个糟糕的设计，因为计算机经常重复使用内存地址来节省资源。攻击者可以利用这一点，通过快速创建和关闭大量会话来记录这些可预测的会话id。稍后，当真正的用户连接时，他们可能会获得攻击者已经拥有的这些回收id中的一个。
一旦攻击者拥有有效的会话id，他们就可以向服务器发送自己的请求。服务器无法区分攻击者和真实用户，因此它将恶意响应发送回真实用户的连接。
即使一些程序只接受某些响应，攻击者也可以通过发送大量带有公共事件号的消息来绕过这一点，直到其中一个被接受。这使得攻击者可以在不改变AI模型本身的情况下扰乱模型的行为。任何公司使用oatpp-mcp如果在网络上启用了HTTP SSE，攻击者可以访问的网络将面临风险。
AI安全负责人应该怎么做？
这次MCP prompt劫持攻击的发现，对于所有正在构建或使用AI助手的技术领导者，尤其是CISOs和CTO来说，是一个严重的警告。随着人工智能越来越成为我们的工作流程通过像MCP这样的协议，它也获得了新的风险。保持人工智能周围地区的安全是现在的首要任务。
尽管这种特定的CVE影响一个系统，但迅速劫持的想法是普遍的。为了防范这种和类似的攻击，领导者需要为他们的人工智能系统制定新的规则。
首先，确保所有的人工智能服务使用安全的会话管理。开发团队需要确保服务器使用强大的随机生成器创建会话id。这应该是任何人工智能程序的安全清单上的必备内容。使用像内存地址这样的可预测标识符是不行的。
第二，加强用户端的防御。客户端程序应该被设计为拒绝任何与预期的id和类型不匹配的事件。简单的，递增的事件id有被喷射攻击的风险，需要用不冲突的不可预知的标识符替换。
最后，对人工智能协议使用零信任原则。安全团队需要检查整个人工智能设置，从基本模型到连接数据的协议和中间件。这些通道需要强大的会话分离和过期，就像web应用程序中使用的会话管理一样。
这个MCP提示劫持攻击是一个完美的例子，说明了一个已知的web应用程序问题，即会话劫持，是如何在AI中以一种新的危险方式出现的。保护这些新的人工智能工具意味着应用这些强大的安全基础来阻止协议级别的攻击。
