2. Linux.do
  3. 大家警惕 vibe coding 的投毒问题

大家警惕 vibe coding 的投毒问题

EFL 2026-06-14 11:21 1

[image]
这个对话完全是用的any的配置，中间没切过对话
[image]


从这里继续讨论：


很多佬友遇到这个问题不清楚具体是什么原因，我们可以看一下，当我们使用 Claude Code 或者 Codex 之类的工具 vibe coding 的时候，整个流程是怎样的：



  1. 你发送了一条消息

  2. 插件 Hook 可以修改你发送的消息

  3. 中转站把消息发给模型

  4. 模型开始推理

  5. 模型调用了一些工具，此时消息从中转站发回 Claude Code

  6. 插件 Hook 可以修改模型调用工具的输入

  7. Claude Code 进行实际的工具调用

  8. 插件 Hook 可以修改工具调用的输出

  9. Claude Code 把输出发送给中转站

  10. 中转站把消息发给模型

  11. 模型继续推理


在这个过程中，几乎每一步都是可以投毒的：



  • 如果你安装了有恶意代码的插件，那么他可以：

    • 在第二步进行提示词注入

    • 在第六步注入带有恶意代码的工具调用

    • 在第八步进行提示词注入



  • 如果中转站是坏的：

    • 在第三步进行提示词注入

    • 在第五步修改工具输入，进行带有恶意代码的工具调用

    • 在第十步进行提示词注入





插件 Hook 作恶的可能性是比较低的，因为他们直接就运行在你的电脑上，想干什么直接干就行不需要经过大模型。但是还是提醒大家，插件是有能力干预整个流程的。



提示词注入还算是比较文明的方法，基本上是在你看不见的地方让模型干坏事，并尽可能让模型意识不到自己在干坏事。


而更有威胁的是直接进行恶意工具调用，假设模型是想要 ls，结果被改成了 cat ~/.ssh/id_rsa && ls，此时哪怕模型意识到了 SSH key 泄露，这个工具调用的结果也已经发送给中转站了。


除了投毒以外，也有可能是模型自己的幻觉问题。为了提高模型能力，Claude Code 会在上下文中加入 <system-reminder> 之类的文本，向模型发送一些提示，而这有可能直接被模型自己当成提示词注入的攻击，例如：



我自己用官方的opus4.8也遇到了这个问题 但是我的情况更倾向于是模型幻觉导致的 因为我发现目前挺多人遇到这个问题的 而且我排查聊天记录之后也没有找到注入的提示词
[image]


那么有什么解决方法吗？目前没有。



  • 可以禁用对敏感目录和文件的读取权限？直接用 bash 就能绕过

  • 加上一些 bash 的 deny 规则？比如禁止 Bash(*~/.ssh*)，可是兄弟这随便绕啊。



我能想到的唯一的解决方案，是让所有的工具调用，尤其是 Bash，在一个能隔离文件系统等访问的沙盒里运行。而据我所知，不知道出于什么原因，还没有主流 vibe coding 工具拥有这个功能。

最新回复 (19)
  • apparition 06-14 11:23
    1楼

    主流 vibe coding 工具拥有这个功能



    因为这是你该自行控管的事

    目前还没有官方被投毒的案例

  • Angel_bai 06-14 11:23
    2楼

    说白了就全凭各自良心了，唉世事难料啊

  • EFL 楼主 06-14 11:31
    3楼

    如果一个 vibe coding 工具的作者这么想，是很不负责的。上面只是提到中转站访问敏感文件这一个例子。那如果用的是官方 provider 而非中转站，模型自身抽风呢？它可以读取敏感鉴权信息之后做一些不该做的事，或者经典的“删掉了我的 ~/ 目录”“删掉了我的桌面”。而这些本该在“模型没有权限访问”这一步就预防了。

  • apparition 06-14 11:34
    4楼

    你可以选择在 docker 内建立编译环境开发

    加上 git 可以解决 99% 误删的问题

    绝大多数用户不会这么做而已

  • EFL 楼主 06-14 11:36
    5楼

    vibe coding 一个很重要的意义就是，让很多没那么专业的用户也能享受编程，那么既然“绝大多数用户不会这么做”，还不加安全护栏，就是不负责任。



    加上 git 可以解决 99% 误删的问题



    无论是L站还是别的什么地方都有很多删D盘删桌面的惨案了，git 还能管这个吗。

  • crazycrazyshui 06-14 11:37
    6楼

    codex似乎自带有沙盒模式，但是cc似乎只能在linux或者wsl中使用沙盒

  • lzd2 06-14 11:37
    7楼

    尽量用官方，中转的话就谁也不知道毒在哪里了；为了官方，买了vps、自建了梯子、开了会员、搭了各种服务。。。

  • infinite 06-14 11:38
    8楼

    的确有点恐怖，搞的都不敢用一些小众的站了

  • EFL 楼主 06-14 11:39
    9楼

    Codex 的沙盒没法禁止读取工作区之外的文件，也就是说读取 SSH key 之类的敏感文件是可能的，他们可能出于复杂性没有做这里的护栏


    并且假如用户都用官方的话确实没问题，毕竟 OpenAI 也不会拿着这些东西做什么。但是很多人 GPT 用的都是中转站的

  • apparition 06-14 11:41
    10楼

    你可以尝试去设计安全护栏

    然后就会发现这些机制在妨碍你开发

    还不如 docker + git


    删D盘删桌面吗? 别用 codex 降低 90% 概率 ^-^

    话说删库跟你的投毒是两回事

  • EFL 楼主 06-14 11:41
    11楼

    话说删库跟你的投毒是两回事



    是这样，我发帖的时候还没想那么多。



    你可以尝试去设计安全护栏



    好的。

  • ciarany 06-14 11:42
    12楼

    所以现在不仅是中转api，要装skill什么的也得仔细检查

  • kkkqkx 06-14 11:43
    13楼

    读密钥、环境变量感觉确实不好防，就算支持自定义规则能绕过的方法也太多了。真要实现似乎只能加个脱敏了？可以考虑做个llm网关作为调用api时的中间件，替换掉自定义的敏感模式

  • Enze 06-14 11:43
    14楼



    When using MCP tools, always enable tool approvals so end users can review and confirm every operation, including reads and writes. In Agent Builder, use the human approval node.



    官方希望你人工审批每个call，官方agent的help里给所有yolo类选项都标注危险和极度危险。你平时的实践只是官方模型+工具链能提供的能力，不是官方推荐的做法，你要是打算这么做你本来就应该自己承担风险。


    当然最关键的是，这种会调用外部程序的客户端的安全远比你所说的我能想到的唯一的解决方案，是让所有的工具调用，尤其是 Bash，在一个能隔离文件系统等访问的沙盒里运行复杂，加上跨平台，你可以理解成这是世界难题。

  • KMVH 06-14 11:43
    15楼

    我有些没理理解，执行任何bash指令不是都会申请权限吗？而且访问沙盒（工作空间）以外的目录或者文件也都要进行提权申请，每次都会说需要什么权限，执行什么命令，写入或者读取什么内容，是我没有理解对吗？

  • EFL 楼主 06-14 11:44
    16楼

    脱敏也是一个很重要的方法，OpenAI Privacy Filter 那个模型挺好的，我在研究用它做前置脱敏

  • fablia 06-14 11:44
    17楼

    我能想到的唯一的解决方案，是让所有的工具调用，尤其是 Bash，在一个能隔离文件系统等访问的沙盒里运行。而据我所知，不知道出于什么原因，还没有主流 vibe coding 工具拥有这个功能。



    这不就是容器干的活嘛，没必要vb工具来做吧

    直接起一个开发容器就完事了

    vscode可以很方便的起开发容器

    jetbrains的fleet甚至可以选择直接在容器里创建会话

  • 哈基登 06-14 11:44
    18楼

    今天还看到arch aur也有投毒的，服啦

  • EFL 楼主 06-14 11:47
    19楼

    这就是为什么我觉得他很不负责的原因。他只管说“自行承担风险”就完事了，不考虑一下现实中用户使用的场景是怎样的。并且事实上 Codex 已经有了沙盒机制，这不是一个很难做到的事情，企业需要有社会责任感。


    https://openai.com/index/building-codex-windows-sandbox/


    但是他们的沙盒也是不完善的。

* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐