😭 求助！我的CC中毒了？疑似 'data' 字符串被中转站全局劫持的离谱操作
- 内容介绍
- 文章标签
- 相关推荐
麻烦各位佬友看看下面的情况是怎么个事，感觉相当诡异
现象描述
我的CC一直接入的是某中转站（后面简称中转A）的API，在今天用CC opus 4.6读取文件内容进行分析的过程中，突然出现了奇怪的疑似“路径劫持”的现象 。（由于路径涉及个人信息，对相应的同字符串打了马赛克作脱敏处理，后文简称abcdefg，应该很难出现雷同)
- 读取的目标文件绝对路径为/data/home/abcdefg/…/data/…，但是可以看到cc读取的对象路径不仅从绝对路径变成了相对路径模式，而且最关键的是子目录“data”被直接替换成了“data/home/abcdefg”
这样替换以后的文件路径结局当然是无法读取到的，因此有了前两次报错。同时模型也意识到了整个"qwen-vl-finetune/data/home/abcdefg/“相对路径中的”/data/home/abcdefg/"这一段应该是不存在的，在回复的末尾，模型直接指出了这个问题
- 还有一个值得关注的点是模型返回的回复中9号字段的字段名"datacomp_caption",同样有"data"这个单词
88211931dc94b7053b96f1c4b9ab687f2078×1366 316 KB
接续上一张图：
01490c0c8044181ccbbb589c5eceefaf1920×1200 439 KB
如图所示，在回复中，模型表示一共发生了两处替换：1. 在Prompt发送的文本中路径子目录"data"被替换为"data/home/abcdefg"。2. 所读取到的实际文件中（也就是图1的第九号字段"datacomp_caption"在模型看来也是"data/home/abcdefgcomp_caption"，和1中描述的是相同的替换。
但是其实图1中我们收到的第九号字段的内容是正常显示的，因此这里模型的第一段回复“关于路径显示的说明”后半句针对文件内容的陈述有点问题。于是我又继续截图了他第一次回复内容的那个表格并进行追问，得到了在模型侧看来他读取到的文件里第九号字段实际上是"data/home/abcdefgcomp_caption"的现象。
image2098×1094 278 KB
为了排除单次模型幻觉，我重新开了3个窗口，使用不同的Prompt要求读取相同路径的txt文件，都遇到了如上的1. 绝对路径直接读取发生错误，（后使用search pattern之类的Tool才读取到文件），"…/data/…“被意外地替换为”…/data/home/abcdefg/…“2. 读取文件时其内容中的"datacomp_caption"字段疑似也被替换为"data/home/abcdefgcomp_caption”。
补充说明 ： 该中转A在实际写代码的时候，如图from dataclasses import dataclass, field这样的代码也会写成from data/home/abcdefgclasses import data/home/abcdefgclass,field，因此可以排除“模型声称”的幻觉的因素，这实在是太离奇了
为什么怀疑是中转服务的问题呢？因为在将API_KEY替换为我持有的另外两家中转（简称B，C）的API_KEY以后，复现对话，并没有出现离谱的路径读取错误或者文件内容读取错误，如下图
b68c12f12a2f0a7813f20856ad3c56d72678×828 261 KB
并且返回的绝对路径内容也是正确的。
归纳总结
对此，我感到非常困惑，以下是我的几个疑问，不知道各位佬友有何看法
- 理论上讲/data/home/abcdefg是涉及本人个人信息的特异化的字符串，为什么会出现Prompt和读取文件中的“data”同时被替换为“/data/home/abcdefg”的现象？
- 如果只是检测到“data”就进行粗暴的替换处理，那“/data/home/abcdefg”中同样含有data这个子字符串 为啥没有递归替换？
- 这个现象究竟是不是中转A读取用户请求然后进行全局劫持导致的？
发这个贴也是想问问有没有佬友遇到过类似的情况，之前用的一直都很正常，就这几天出的问题，主要是写代码的时候任何data子字符串也会被全局替换 实在是太影响体验了，完全没法正常使用了，求助求助
网友解答：--【壹】--：
有些中转站是有注入一个初始路径来进行声明, 让cc那边看上去是同一个user的使用, 避免cc的一些检测, 不确定佬友是不是也是这种情况
--【贰】--：
我当时运行CC的具体的工作目录是/data/home/echominkki/myceph_cq/qwenvl_training，一开始其实并不是帖子里所说的让CC读取文件，其实是他写代码的时候就已经发生了把所有’data’字符串写作了data/home/echominkki/myceph_cq，比如from dataclasses import dataclass,field就直接写成了from data/home/echominkki/myceph_cqclasses import data/home/echominkki/myceph_cqclass,field（这段代码的位置是在/data/home/echominkki/myceph_cq/qwenvl_training/downstream_task/_common.py中，另外所有在当前session里新写的代码都出现了data被替换的情况，然后我才用以下原始Prompt进行了测试：
data/home/echominkki/myceph_cq/qwenvl_training/qwen-vl-finetune/data/demo/BLIP-Kale.txt读取这个文件内容，复述这个文件中有哪些字段（不允许修改内容，不允许省略）
然后我之前基本一直都是在这个目录使用的，而且我的所有工作目录都以/data/home/echominkki/myceph_cq为前缀，不知道为什么突然就出问题了
--【叁】--：
明显用了cc-gateway了，还把user prompt里的路径都替换了
--【肆】--：
这个里面的内容就比较复杂了，感觉过断时间就要找个靠谱的模型全局扫一下所有的上下文和使用痕迹。CC不是更新的新版本，加入了一些校验吗？我暂时用的codex，没用CC
--【伍】--：
问题没有解决,既然这个问题现在还在有,说明他们没重视或根本无法解决.
我就订阅了1个月,到期后直接转官方订阅了.
--【陆】--：
收到，我们测试一下，是在linux/mac系统下吗？
--【柒】--：
我在CC 2.1.97和2.1.101新开了三四个对话都遇到了这个问题，上面也说了换了两家别的中转API以后，就没有这个问题了，切换API只单独修改了.settings.json里面的相应字段，其他mcp,skills都没有改，所以感觉不是CC本体的问题？
--【捌】--：
我以前用某Yes的中转,会在我的C:\Users 创建莫名其妙的用户名和路径.导致很多文件读取错误.
--【玖】--：
不清楚具体情况
但是前段时间是有相关文章对免费/付费中转站做检查 很多会偷token的 偷信息的
虽然那篇文章作者似乎也有些事情 但是无论如何至少能证明这些中转站肯定有不干净的地方
所以不只是幻觉问题 确实可以怀疑一下中转站本身是不是有篡改信息
--【拾】--：
不过我比较好奇的是，开伪装的话不应该是把包含个人信息的特异化字符串替换成看起来比较通用的字符串吗，为什么在我观察到的现象看起来是反向地把通用的字符串替换成了特异化字符串？ 另外上游是咋定位到哪些字符串可能涉及特殊信息需要来替换伪装的嘞
--【拾壹】--：
可以尝试换个目录试试，其实出错率不高。另外因为我们都是本地抓包自己环境或者通过用户反馈修正，测试样例覆盖不全，所以会出现这种情况，佬可以说说你具体目录，系统环境我们看能不能复现，能复现就好修复了。
--【拾贰】--：
cc-gateway是啥嘞，这种情况有解吗
--【拾叁】--：
我用的就是yes,佬友后来有解决这个问题吗 还是直接换了？
--【拾肆】--：
先别怀疑本地中毒，八成是中转A做了路径重写/替换。直接拿同一段prompt去直连官方/另一个中转对比，再抓一下请求响应原文，重点看是不是返回里把data全局替换了。
--【拾伍】--：
感谢亲自回复，那想请问一下这种情况有解决办法吗？ 如果只是读取侧也就算了，主要现在写代码的情境下也会出现’data’字符串被全局替换成特异化字符串的现象，这种就太影响使用了，可以说完全用不了了（ 这个是恢复以后才开始采取的新策略吗？以前没有这个现象。
--【拾陆】--：
是的，我这边是在Linux系统下，辛苦~
--【拾柒】--：
但感觉根据我观察的现象似乎是把"data"替换成了含有我个人信息的特异化字符串，如果是为了伪装看上去是同一个user的话不应该反向替换嘛？
--【拾捌】--：
上游开了伪装，让所有会话看上去像同一个用户。。。。没辙
--【拾玖】--：
sry佬，因为通用字符串出现频次高，重写出错概率更高，所以我们用了比较unique的目标字符串，但难以避免让模型不跑错，做这么多只为了防封；策略很简单，就是把所有用户的ENV重写成同一个发给A社，再返回时再根据unique的目标字符串映射回去。定位很简单，cc注入的初始环境信息就在system prompt的 #Environment 里。
麻烦各位佬友看看下面的情况是怎么个事，感觉相当诡异
现象描述
我的CC一直接入的是某中转站（后面简称中转A）的API，在今天用CC opus 4.6读取文件内容进行分析的过程中，突然出现了奇怪的疑似“路径劫持”的现象 。（由于路径涉及个人信息，对相应的同字符串打了马赛克作脱敏处理，后文简称abcdefg，应该很难出现雷同)
- 读取的目标文件绝对路径为/data/home/abcdefg/…/data/…，但是可以看到cc读取的对象路径不仅从绝对路径变成了相对路径模式，而且最关键的是子目录“data”被直接替换成了“data/home/abcdefg”
这样替换以后的文件路径结局当然是无法读取到的，因此有了前两次报错。同时模型也意识到了整个"qwen-vl-finetune/data/home/abcdefg/“相对路径中的”/data/home/abcdefg/"这一段应该是不存在的，在回复的末尾，模型直接指出了这个问题
- 还有一个值得关注的点是模型返回的回复中9号字段的字段名"datacomp_caption",同样有"data"这个单词
88211931dc94b7053b96f1c4b9ab687f2078×1366 316 KB
接续上一张图：
01490c0c8044181ccbbb589c5eceefaf1920×1200 439 KB
如图所示，在回复中，模型表示一共发生了两处替换：1. 在Prompt发送的文本中路径子目录"data"被替换为"data/home/abcdefg"。2. 所读取到的实际文件中（也就是图1的第九号字段"datacomp_caption"在模型看来也是"data/home/abcdefgcomp_caption"，和1中描述的是相同的替换。
但是其实图1中我们收到的第九号字段的内容是正常显示的，因此这里模型的第一段回复“关于路径显示的说明”后半句针对文件内容的陈述有点问题。于是我又继续截图了他第一次回复内容的那个表格并进行追问，得到了在模型侧看来他读取到的文件里第九号字段实际上是"data/home/abcdefgcomp_caption"的现象。
image2098×1094 278 KB
为了排除单次模型幻觉，我重新开了3个窗口，使用不同的Prompt要求读取相同路径的txt文件，都遇到了如上的1. 绝对路径直接读取发生错误，（后使用search pattern之类的Tool才读取到文件），"…/data/…“被意外地替换为”…/data/home/abcdefg/…“2. 读取文件时其内容中的"datacomp_caption"字段疑似也被替换为"data/home/abcdefgcomp_caption”。
补充说明 ： 该中转A在实际写代码的时候，如图from dataclasses import dataclass, field这样的代码也会写成from data/home/abcdefgclasses import data/home/abcdefgclass,field，因此可以排除“模型声称”的幻觉的因素，这实在是太离奇了
为什么怀疑是中转服务的问题呢？因为在将API_KEY替换为我持有的另外两家中转（简称B，C）的API_KEY以后，复现对话，并没有出现离谱的路径读取错误或者文件内容读取错误，如下图
b68c12f12a2f0a7813f20856ad3c56d72678×828 261 KB
并且返回的绝对路径内容也是正确的。
归纳总结
对此，我感到非常困惑，以下是我的几个疑问，不知道各位佬友有何看法
- 理论上讲/data/home/abcdefg是涉及本人个人信息的特异化的字符串，为什么会出现Prompt和读取文件中的“data”同时被替换为“/data/home/abcdefg”的现象？
- 如果只是检测到“data”就进行粗暴的替换处理，那“/data/home/abcdefg”中同样含有data这个子字符串 为啥没有递归替换？
- 这个现象究竟是不是中转A读取用户请求然后进行全局劫持导致的？
发这个贴也是想问问有没有佬友遇到过类似的情况，之前用的一直都很正常，就这几天出的问题，主要是写代码的时候任何data子字符串也会被全局替换 实在是太影响体验了，完全没法正常使用了，求助求助
网友解答：--【壹】--：
有些中转站是有注入一个初始路径来进行声明, 让cc那边看上去是同一个user的使用, 避免cc的一些检测, 不确定佬友是不是也是这种情况
--【贰】--：
我当时运行CC的具体的工作目录是/data/home/echominkki/myceph_cq/qwenvl_training，一开始其实并不是帖子里所说的让CC读取文件，其实是他写代码的时候就已经发生了把所有’data’字符串写作了data/home/echominkki/myceph_cq，比如from dataclasses import dataclass,field就直接写成了from data/home/echominkki/myceph_cqclasses import data/home/echominkki/myceph_cqclass,field（这段代码的位置是在/data/home/echominkki/myceph_cq/qwenvl_training/downstream_task/_common.py中，另外所有在当前session里新写的代码都出现了data被替换的情况，然后我才用以下原始Prompt进行了测试：
data/home/echominkki/myceph_cq/qwenvl_training/qwen-vl-finetune/data/demo/BLIP-Kale.txt读取这个文件内容，复述这个文件中有哪些字段（不允许修改内容，不允许省略）
然后我之前基本一直都是在这个目录使用的，而且我的所有工作目录都以/data/home/echominkki/myceph_cq为前缀，不知道为什么突然就出问题了
--【叁】--：
明显用了cc-gateway了，还把user prompt里的路径都替换了
--【肆】--：
这个里面的内容就比较复杂了，感觉过断时间就要找个靠谱的模型全局扫一下所有的上下文和使用痕迹。CC不是更新的新版本，加入了一些校验吗？我暂时用的codex，没用CC
--【伍】--：
问题没有解决,既然这个问题现在还在有,说明他们没重视或根本无法解决.
我就订阅了1个月,到期后直接转官方订阅了.
--【陆】--：
收到，我们测试一下，是在linux/mac系统下吗？
--【柒】--：
我在CC 2.1.97和2.1.101新开了三四个对话都遇到了这个问题，上面也说了换了两家别的中转API以后，就没有这个问题了，切换API只单独修改了.settings.json里面的相应字段，其他mcp,skills都没有改，所以感觉不是CC本体的问题？
--【捌】--：
我以前用某Yes的中转,会在我的C:\Users 创建莫名其妙的用户名和路径.导致很多文件读取错误.
--【玖】--：
不清楚具体情况
但是前段时间是有相关文章对免费/付费中转站做检查 很多会偷token的 偷信息的
虽然那篇文章作者似乎也有些事情 但是无论如何至少能证明这些中转站肯定有不干净的地方
所以不只是幻觉问题 确实可以怀疑一下中转站本身是不是有篡改信息
--【拾】--：
不过我比较好奇的是，开伪装的话不应该是把包含个人信息的特异化字符串替换成看起来比较通用的字符串吗，为什么在我观察到的现象看起来是反向地把通用的字符串替换成了特异化字符串？ 另外上游是咋定位到哪些字符串可能涉及特殊信息需要来替换伪装的嘞
--【拾壹】--：
可以尝试换个目录试试，其实出错率不高。另外因为我们都是本地抓包自己环境或者通过用户反馈修正，测试样例覆盖不全，所以会出现这种情况，佬可以说说你具体目录，系统环境我们看能不能复现，能复现就好修复了。
--【拾贰】--：
cc-gateway是啥嘞，这种情况有解吗
--【拾叁】--：
我用的就是yes,佬友后来有解决这个问题吗 还是直接换了？
--【拾肆】--：
先别怀疑本地中毒，八成是中转A做了路径重写/替换。直接拿同一段prompt去直连官方/另一个中转对比，再抓一下请求响应原文，重点看是不是返回里把data全局替换了。
--【拾伍】--：
感谢亲自回复，那想请问一下这种情况有解决办法吗？ 如果只是读取侧也就算了，主要现在写代码的情境下也会出现’data’字符串被全局替换成特异化字符串的现象，这种就太影响使用了，可以说完全用不了了（ 这个是恢复以后才开始采取的新策略吗？以前没有这个现象。
--【拾陆】--：
是的，我这边是在Linux系统下，辛苦~
--【拾柒】--：
但感觉根据我观察的现象似乎是把"data"替换成了含有我个人信息的特异化字符串，如果是为了伪装看上去是同一个user的话不应该反向替换嘛？
--【拾捌】--：
上游开了伪装，让所有会话看上去像同一个用户。。。。没辙
--【拾玖】--：
sry佬，因为通用字符串出现频次高，重写出错概率更高，所以我们用了比较unique的目标字符串，但难以避免让模型不跑错，做这么多只为了防封；策略很简单，就是把所有用户的ENV重写成同一个发给A社，再返回时再根据unique的目标字符串映射回去。定位很简单，cc注入的初始环境信息就在system prompt的 #Environment 里。