Prompt泄露风险：抖音集团安全研究团队揭露多租户KV缓存共享漏洞
抖音集团安全研究团队和南方科技大学可信系统安全实验室合作的研究论文揭示了大语言模型安全领域服务框架的侧信道漏洞，利用多租户场景下的KV缓存共享机制精确恢复了用户提示词。本工作成果《I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving》已被安全领域顶级会议NDSS 2025接收。
一、研究背景
大语言模型（LLM）在自然语言处理任务中取得了显著进展，广泛应用于文本生成、翻译、问答等领域，吸引了学术界和工业界的高度关注。这些模型在提供高效、准确的语言处理服务的同时，也面临着由于计算资源需求巨大所带来的性能瓶颈。为了满足不同用户的使用需求，优化资源利用率，大量多租户LLM框架应运而生，通过共享资源和更高效的调度算法，实现性能和成本的有效优化。
在众多多租户LLM的框架中，一个广泛应用的技术就是KV缓存共享（包括SGLang、vLLM等）。KV缓存共享的基本原理是允许不同请求在推理过程中复用已经计算过的KV缓存，但这种共享仅在前序token序列完全相同时才能实现。这种设计保证了不同用户的请求在一定程度上可以复用计算结果，提升了推理效率。目前SGLang提供了SOTA的KV缓存共享策略。具体而言，SGLang使用了一种基于Radix树的结构以便快速索引和访问。此外，SGLang实现了一种优化的调度算法，确保优先处理拥有更长复用匹配的请求，以最大化缓存命中率并减少重复计算。
二、攻击方法
攻击核心：如果攻击者能够观察到自身请求是否触发了KV缓存共享，则可以判断其请求与已处理的请求是否相同或部分相同。攻击者通过每次增加一个token并反复请求，从而逐个token地还原出其他用户的请求内容。
接下来，我们用攻击过程中的一个片段来阐述攻击者如何还原其他用户请求中的一个token。通过反复重复这一操作，攻击者最终可以还原出完整请求。
如下图所示，假设目标语句是“Imagine you are an IT expert”，攻击者已经成功还原出“Imagine you are”，并企图还原出下一个token “an”。
· 本地候选生成：攻击者利用本地LLM来生成可能的token。本地LLM不需要和目标LLM完全相同，只要拥有相同的Tokenizer来确保能够匹配到目标LLM的解析方法即可。在这个例子中，本地LLM可能会生成“a”，“an”，“the”等潜在的候选token。同时，本地LLM也会生成一个最不可能的token作为dummy token，为之后的攻击使用。
· 候选请求发送：在生成本地候选之后， 攻击者会将三批请求依次发送，分别为由dummy token构成的dummy batch，候选token构成的候选batch，和另一批由dummy token构成的dummy batch。这样的设定是为了更容易观测到的侧信道信息。
· 侧信道结果观测：通过观测发送请求的返回顺序作为侧信道信息，攻击者可以判断哪个请求成功触发KV缓存共享，从而确定对应的token。接下来我们对侧信道信息进行具体介绍。
侧信道信息：我们利用调度算法的特性，即与已有KV缓存匹配更长的请求会被优先处理，来实现攻击。成功匹配的请求相比未匹配的请求多一个token匹配，因此更早被处理。我们将请求的返回顺序作为侧信道信息，通过观察哪个请求被优先返回，从而判断其是否触发了缓存共享。
三、实验结果
实验环境：实验环境基于SGLang框架，用户请求设定参考了OpenAI的标准，每3小时发送40次请求，以模拟真实的LLM使用场景。提示数据集包含四类：常规聊天、填空、角色扮演和指令型提示，用于全面评估攻击效果和成本。
下图展示了攻击的最终效果。结果表明，在Llama2-13B模型上，攻击者在知晓提示模版来回复提示输入上成功率达99%，知晓提示输入恢复提示模板成功率为98%，甚至在无任何背景知识恢复全部请求也有95%的成功率。
四、总结与展望
无状态与有状态设计：本工作基于有状态的大语言模型服务框架，即对于用户的共享KV缓存，开展输入窃取攻击，而这种攻击的本质是针对于系统的状态延续所进行的。在大型系统中，用户数据的状态延续往往伴随着潜在的安全风险，所以为了确保安全要尽可能做到单次服务后清除用户状态，如苹果近期提出的Private Computing Cloud。然而，对于延迟要求较高的服务场景，复用缓存等有状态的设计难以避免，但面临着诸如本篇工作的安全挑战。在此基础上，我们已基于本篇工作提出了更安全的KV缓存共享框架，为大语言模型服务提供安全性保障的同时实现了效率的提升。
多租户LLM框架下的资源共享：现有的LLM服务框架会有很多允许多用户/多请求间的共享资源（如KV，memory，Lora adapter），这些共享资源可以很大程度的提高服务性能，但是存在巨大的安全隐患（隐私泄漏，投毒等），所以在设计框架和部署服务的过程中需要谨慎处理基于共享资源的优化。框架设计师和服务提供商需要在保持性能的同时引入足够的隔离机制来保证多租户间的安全性。
KV缓存的安全性考量：KV缓存作为LLM中的独特机制，虽然提升了推理效率，也为LLM的安全性带来了新的攻击面。KV缓存与用户的输入token存在唯一对应关系，这使得一旦出现KV缓存信息泄漏，攻击者便能够通过缓存内容直接推测和重构相应的用户请求，从而导致敏感信息的暴露。本篇工作是第一次注意到了KV缓存所带来的安全风险，希望能够引起广泛的针对这一新属性的安全思考。
抖音集团安全研究团队和南方科技大学可信系统安全实验室合作的研究论文揭示了大语言模型安全领域服务框架的侧信道漏洞，利用多租户场景下的KV缓存共享机制精确恢复了用户提示词。本工作成果《I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving》已被安全领域顶级会议NDSS 2025接收。
一、研究背景
大语言模型（LLM）在自然语言处理任务中取得了显著进展，广泛应用于文本生成、翻译、问答等领域，吸引了学术界和工业界的高度关注。这些模型在提供高效、准确的语言处理服务的同时，也面临着由于计算资源需求巨大所带来的性能瓶颈。为了满足不同用户的使用需求，优化资源利用率，大量多租户LLM框架应运而生，通过共享资源和更高效的调度算法，实现性能和成本的有效优化。
在众多多租户LLM的框架中，一个广泛应用的技术就是KV缓存共享（包括SGLang、vLLM等）。KV缓存共享的基本原理是允许不同请求在推理过程中复用已经计算过的KV缓存，但这种共享仅在前序token序列完全相同时才能实现。这种设计保证了不同用户的请求在一定程度上可以复用计算结果，提升了推理效率。目前SGLang提供了SOTA的KV缓存共享策略。具体而言，SGLang使用了一种基于Radix树的结构以便快速索引和访问。此外，SGLang实现了一种优化的调度算法，确保优先处理拥有更长复用匹配的请求，以最大化缓存命中率并减少重复计算。
二、攻击方法
攻击核心：如果攻击者能够观察到自身请求是否触发了KV缓存共享，则可以判断其请求与已处理的请求是否相同或部分相同。攻击者通过每次增加一个token并反复请求，从而逐个token地还原出其他用户的请求内容。
接下来，我们用攻击过程中的一个片段来阐述攻击者如何还原其他用户请求中的一个token。通过反复重复这一操作，攻击者最终可以还原出完整请求。
如下图所示，假设目标语句是“Imagine you are an IT expert”，攻击者已经成功还原出“Imagine you are”，并企图还原出下一个token “an”。
· 本地候选生成：攻击者利用本地LLM来生成可能的token。本地LLM不需要和目标LLM完全相同，只要拥有相同的Tokenizer来确保能够匹配到目标LLM的解析方法即可。在这个例子中，本地LLM可能会生成“a”，“an”，“the”等潜在的候选token。同时，本地LLM也会生成一个最不可能的token作为dummy token，为之后的攻击使用。
· 候选请求发送：在生成本地候选之后， 攻击者会将三批请求依次发送，分别为由dummy token构成的dummy batch，候选token构成的候选batch，和另一批由dummy token构成的dummy batch。这样的设定是为了更容易观测到的侧信道信息。
· 侧信道结果观测：通过观测发送请求的返回顺序作为侧信道信息，攻击者可以判断哪个请求成功触发KV缓存共享，从而确定对应的token。接下来我们对侧信道信息进行具体介绍。
侧信道信息：我们利用调度算法的特性，即与已有KV缓存匹配更长的请求会被优先处理，来实现攻击。成功匹配的请求相比未匹配的请求多一个token匹配，因此更早被处理。我们将请求的返回顺序作为侧信道信息，通过观察哪个请求被优先返回，从而判断其是否触发了缓存共享。
三、实验结果
实验环境：实验环境基于SGLang框架，用户请求设定参考了OpenAI的标准，每3小时发送40次请求，以模拟真实的LLM使用场景。提示数据集包含四类：常规聊天、填空、角色扮演和指令型提示，用于全面评估攻击效果和成本。
下图展示了攻击的最终效果。结果表明，在Llama2-13B模型上，攻击者在知晓提示模版来回复提示输入上成功率达99%，知晓提示输入恢复提示模板成功率为98%，甚至在无任何背景知识恢复全部请求也有95%的成功率。
四、总结与展望
无状态与有状态设计：本工作基于有状态的大语言模型服务框架，即对于用户的共享KV缓存，开展输入窃取攻击，而这种攻击的本质是针对于系统的状态延续所进行的。在大型系统中，用户数据的状态延续往往伴随着潜在的安全风险，所以为了确保安全要尽可能做到单次服务后清除用户状态，如苹果近期提出的Private Computing Cloud。然而，对于延迟要求较高的服务场景，复用缓存等有状态的设计难以避免，但面临着诸如本篇工作的安全挑战。在此基础上，我们已基于本篇工作提出了更安全的KV缓存共享框架，为大语言模型服务提供安全性保障的同时实现了效率的提升。
多租户LLM框架下的资源共享：现有的LLM服务框架会有很多允许多用户/多请求间的共享资源（如KV，memory，Lora adapter），这些共享资源可以很大程度的提高服务性能，但是存在巨大的安全隐患（隐私泄漏，投毒等），所以在设计框架和部署服务的过程中需要谨慎处理基于共享资源的优化。框架设计师和服务提供商需要在保持性能的同时引入足够的隔离机制来保证多租户间的安全性。
KV缓存的安全性考量：KV缓存作为LLM中的独特机制，虽然提升了推理效率，也为LLM的安全性带来了新的攻击面。KV缓存与用户的输入token存在唯一对应关系，这使得一旦出现KV缓存信息泄漏，攻击者便能够通过缓存内容直接推测和重构相应的用户请求，从而导致敏感信息的暴露。本篇工作是第一次注意到了KV缓存所带来的安全风险，希望能够引起广泛的针对这一新属性的安全思考。
VMware_vCenter 近期漏洞分析
vSphere Client分为UI层、Java服务层、后端层，前端通过RESTful API与基于Spring MVC和OSGI框架的Java服务层进行通信
vCenter可以安装部署至ESXi，也可以导入镜像中的OVA文件部署，漏洞环境的ISO文件可从此处获取。
需要注意的是VCSA的最小部署规格tiny（微型）需要2核10G内存300G硬盘，本文采用的方案是在ESXi的物理机上嵌套安装ESXi虚拟机，并在嵌套安装的ESXi虚拟机中安装VCSA。保持根路由与一级ESXi物理机VLAN为空（或不变/或为4095），将一级ESXi与二级ESXi的虚拟交换机设置为4095（或某个固定值），将二级ESXi中运行的VCSA接入二级虚拟交换机，并同时开启该链路上的各级交换机的混杂模式
由EAM用户运行的服务存在文件读取，Windows上可获取帐号密码。
vSphere Client分为UI层、Java服务层、后端层，前端通过RESTful API与基于Spring MVC和OSGI框架的Java服务层进行通信
vCenter可以安装部署至ESXi，也可以导入镜像中的OVA文件部署，漏洞环境的ISO文件可从此处获取。
需要注意的是VCSA的最小部署规格tiny（微型）需要2核10G内存300G硬盘，本文采用的方案是在ESXi的物理机上嵌套安装ESXi虚拟机，并在嵌套安装的ESXi虚拟机中安装VCSA。保持根路由与一级ESXi物理机VLAN为空（或不变/或为4095），将一级ESXi与二级ESXi的虚拟交换机设置为4095（或某个固定值），将二级ESXi中运行的VCSA接入二级虚拟交换机，并同时开启该链路上的各级交换机的混杂模式
由EAM用户运行的服务存在文件读取，Windows上可获取帐号密码。
This media is not supported in your browser
VIEW IN TELEGRAM
Chrome Ext 3CL XSS
为 CobaltStrike TeamServer 加上谷歌二次验证
CobaltStrike TeamServer 在认证的时候，是没有类似验证码的功能的，这就为蓝队爆破 TeamServer 密码提供了可能。
再加上攻防演练当中出现的「红队钓鱼事件」，团队中不乏有新鲜血液，稍有不慎就会让用户家目录下的 .aggressor.prop 文件被他人窃取，令团队成果付之东流。
那么如何规避这种情况呢？我们有如下几个方案考虑：
方案一: 直接反编译 CobaltStrike JAR 包，修改逻辑之后重打包。
该方案的好处是可控性强，可以改的面目全非，甚至可以把配置文件中的密码保存改成加密的形式。
缺点也显而易见：
· 首先CS反编译之后重打包挺让人抓狂的，不好弄。
· 其次必须要用专有的 cobaltstrike 去连接，后续如果拿到新的版本，工作量是比较大的
· 团队成员机器如果被控，攻击者完全可以偷走专有的工具和配置文件进行连接
所以该方案 Pass
方案二：网络层动手脚
TeamServer 监听在 127.0.0.1 接口上，通过 SSH 等其它方式建立 Socks5隧道或者 VPN，团队成员在接入 TeamServer 时，先进入到专网当中，再连接。
好处是成本低，无任何额外工作量，TeamServer 监听的端口也不会被 fofa zoomeye 这些网络空间搜索引擎扫描到。
缺点是团队成员机器被控后，攻击者完全可以该成员机器作为跳板，通过专网连接。
所以该方案也 Pass
生成 TOTP SecretKey
java -cp CSTOTP.jar com.maxwell.Main
不要奇怪包名为啥叫麦斯威尔，我自己随便写的
3、掏出你的手机，下载 Google Authenticator (有些叫 谷歌身份验证器)，或者随便找一个支持 2FA 的 APP 就行。然后扫描上面的二维码，或者是手动把 SecretKey 添加进去就行。
这玩意儿请务必保存好，这再被人偷了就只能活该了。攻防演练前生成好，让团队成员扫描这个二维码即可
4、生成 SecretKey 之后，根据最后一行提示，把最后一行的内容添加到 teamserver 这个文件里
红线上的内容之前是没有的，之后我们保存
5、你之前是怎么运行 teamserver 的，现在还是怎么运行
CobaltStrike TeamServer 在认证的时候，是没有类似验证码的功能的，这就为蓝队爆破 TeamServer 密码提供了可能。
再加上攻防演练当中出现的「红队钓鱼事件」，团队中不乏有新鲜血液，稍有不慎就会让用户家目录下的 .aggressor.prop 文件被他人窃取，令团队成果付之东流。
那么如何规避这种情况呢？我们有如下几个方案考虑：
方案一: 直接反编译 CobaltStrike JAR 包，修改逻辑之后重打包。
该方案的好处是可控性强，可以改的面目全非，甚至可以把配置文件中的密码保存改成加密的形式。
缺点也显而易见：
· 首先CS反编译之后重打包挺让人抓狂的，不好弄。
· 其次必须要用专有的 cobaltstrike 去连接，后续如果拿到新的版本，工作量是比较大的
· 团队成员机器如果被控，攻击者完全可以偷走专有的工具和配置文件进行连接
所以该方案 Pass
方案二：网络层动手脚
TeamServer 监听在 127.0.0.1 接口上，通过 SSH 等其它方式建立 Socks5隧道或者 VPN，团队成员在接入 TeamServer 时，先进入到专网当中，再连接。
好处是成本低，无任何额外工作量，TeamServer 监听的端口也不会被 fofa zoomeye 这些网络空间搜索引擎扫描到。
缺点是团队成员机器被控后，攻击者完全可以该成员机器作为跳板，通过专网连接。
所以该方案也 Pass
生成 TOTP SecretKey
java -cp CSTOTP.jar com.maxwell.Main
不要奇怪包名为啥叫麦斯威尔，我自己随便写的
3、掏出你的手机，下载 Google Authenticator (有些叫 谷歌身份验证器)，或者随便找一个支持 2FA 的 APP 就行。然后扫描上面的二维码，或者是手动把 SecretKey 添加进去就行。
这玩意儿请务必保存好，这再被人偷了就只能活该了。攻防演练前生成好，让团队成员扫描这个二维码即可
4、生成 SecretKey 之后，根据最后一行提示，把最后一行的内容添加到 teamserver 这个文件里
红线上的内容之前是没有的，之后我们保存
5、你之前是怎么运行 teamserver 的，现在还是怎么运行
您能破解文档吗？
对于这个挑战，我们提供了一个名为“CrackDoc.doc”的文件，当我们打开它时，我们会看到一个“UsersForm1”提示，要求输入“Key”值。
输入错误的键会显示一条消息“你能做到。再努力一点...”，并附上一张可爱的狗狗图片。
对于这个挑战，我们提供了一个名为“CrackDoc.doc”的文件，当我们打开它时，我们会看到一个“UsersForm1”提示，要求输入“Key”值。
输入错误的键会显示一条消息“你能做到。再努力一点...”，并附上一张可爱的狗狗图片。
忘记密码？以 Kaminsky 风格接管用户账户
总结
在分析了 146 个 Web 应用程序的 DNS 名称解析漏洞后，Timo Longin（SEC Consult Vienna）发现，一些 Web 应用程序至今仍存在漏洞。Kaminsky 以及 IP 碎片攻击可能允许通过“忘记密码？”功能接管这些 Web 应用程序的用户帐户。为了识别存在漏洞的 Web 应用程序，提供了DNS 重置检查器。
这个攻击媒介会影响我吗？
我该如何保护自己？
我应该警惕这个攻击媒介吗？
问答部分涵盖了这些问题以及更多问题。
忘记密码？
很难想象登录表单没有这个问题。
指定电子邮件地址
接收密码重置 URL
更改密码
简单！但是“忘记密码？”功能与 DNS 漏洞有何关系？
以下场景更接近这一点：
假设攻击者可以将任意 DNS 记录注入 Web 应用程序使用的 DNS 解析器的缓存中（DNS 缓存中毒），那么他就可以操纵电子邮件域名到 IP 地址的映射。因此，“gmail.com”的 DNS 名称解析不再必然指向 Google 电子邮件服务器的 IP 地址，而是指向攻击者电子邮件服务器的 IP 地址。
这样，攻击者就可以收到所有发往“gmail.com”的电子邮件。包括密码重置电子邮件。
图说明了这一点：因此，如果攻击者可以操纵 Web 应用程序的 DNS 名称解析，则“忘记密码？”功能可能会被滥用来接管用户帐户。
Dan Kaminsky 早在 2008 年的 Black Hat 大会上就展示了这种攻击媒介[1]。Timo Longin 在毕业论文《Web 应用程序中的 DNS 漏洞》[14] 中对 146 个 Web 应用程序进行了以下分析，结果表明，这种攻击媒介至今仍然存在。
总结
在分析了 146 个 Web 应用程序的 DNS 名称解析漏洞后，Timo Longin（SEC Consult Vienna）发现，一些 Web 应用程序至今仍存在漏洞。Kaminsky 以及 IP 碎片攻击可能允许通过“忘记密码？”功能接管这些 Web 应用程序的用户帐户。为了识别存在漏洞的 Web 应用程序，提供了DNS 重置检查器。
这个攻击媒介会影响我吗？
我该如何保护自己？
我应该警惕这个攻击媒介吗？
问答部分涵盖了这些问题以及更多问题。
忘记密码？
很难想象登录表单没有这个问题。
指定电子邮件地址
接收密码重置 URL
更改密码
简单！但是“忘记密码？”功能与 DNS 漏洞有何关系？
以下场景更接近这一点：
假设攻击者可以将任意 DNS 记录注入 Web 应用程序使用的 DNS 解析器的缓存中（DNS 缓存中毒），那么他就可以操纵电子邮件域名到 IP 地址的映射。因此，“gmail.com”的 DNS 名称解析不再必然指向 Google 电子邮件服务器的 IP 地址，而是指向攻击者电子邮件服务器的 IP 地址。
这样，攻击者就可以收到所有发往“gmail.com”的电子邮件。包括密码重置电子邮件。
图说明了这一点：因此，如果攻击者可以操纵 Web 应用程序的 DNS 名称解析，则“忘记密码？”功能可能会被滥用来接管用户帐户。
Dan Kaminsky 早在 2008 年的 Black Hat 大会上就展示了这种攻击媒介[1]。Timo Longin 在毕业论文《Web 应用程序中的 DNS 漏洞》[14] 中对 146 个 Web 应用程序进行了以下分析，结果表明，这种攻击媒介至今仍然存在。
攻防启示：Chromium组件风险剖析与收敛
数月前我们在攻防两个方向经历了一场“真枪实弹”的考验，期间团队的目光曾一度聚焦到Chromium组件上。
其实，早在 Microsoft 2018年宣布 Windows的新浏览器Microsoft Edge将基于Chromium内核进行构建之前，伴随互联网发展至今的浏览器之争其实早就已经有了定论，Chromium已然成为现代浏览器的事实标准，市场占有率也一骑绝尘。在服务端、桌面还是移动端，甚至据传SpaceX火箭亦搭载了基于Chromium开发的控制面板。
Chromium主要包含两大核心组成部分：渲染引擎和浏览器内核。
2.1.1 渲染引擎
Chromium目前使用Blink作为渲染引擎，它是基于webkit定制而来的，核心逻辑位于项目仓库的third_party/blink/目录下。渲染引擎做的事情主要有：
1) 解析并构建DOM树。Blink引擎会把DOM树转化成C++表示的结构，以供V8操作。
2) 调用V8引擎处理JavaScript和Web Assembly代码，并对HTML文档做特定操作。
3) 处理HTML文档定义的CSS样式
4) 调用Chrome Compositor，将HTML对应的元素绘制出来。这个阶段会调用OpenGL，未来还会支持Vulkan。在Windows平台上，该阶段还会调用DirectX库处理；在处理过程中，OpenGL还会调用到Skia，DirectX还会调用到ANGLE。
数月前我们在攻防两个方向经历了一场“真枪实弹”的考验，期间团队的目光曾一度聚焦到Chromium组件上。
其实，早在 Microsoft 2018年宣布 Windows的新浏览器Microsoft Edge将基于Chromium内核进行构建之前，伴随互联网发展至今的浏览器之争其实早就已经有了定论，Chromium已然成为现代浏览器的事实标准，市场占有率也一骑绝尘。在服务端、桌面还是移动端，甚至据传SpaceX火箭亦搭载了基于Chromium开发的控制面板。
Chromium主要包含两大核心组成部分：渲染引擎和浏览器内核。
2.1.1 渲染引擎
Chromium目前使用Blink作为渲染引擎，它是基于webkit定制而来的，核心逻辑位于项目仓库的third_party/blink/目录下。渲染引擎做的事情主要有：
1) 解析并构建DOM树。Blink引擎会把DOM树转化成C++表示的结构，以供V8操作。
2) 调用V8引擎处理JavaScript和Web Assembly代码，并对HTML文档做特定操作。
3) 处理HTML文档定义的CSS样式
4) 调用Chrome Compositor，将HTML对应的元素绘制出来。这个阶段会调用OpenGL，未来还会支持Vulkan。在Windows平台上，该阶段还会调用DirectX库处理；在处理过程中，OpenGL还会调用到Skia，DirectX还会调用到ANGLE。