涉黄审核漏洞背后：大模型内容安全的四道裂缝

一、事件复盘：漏洞不只是“模型不行”

近期，某开源大模型的对话应用被曝存在涉黄内容审核漏洞。舆论的第一反应往往指向模型本身，训练数据不干净、对齐没做好、越狱提示词太狡猾。但当研究者完整复盘攻击路径后，一个更值得警惕的事实浮出水面：绕过审核的关键动作，多数发生在模型之外。

被披露的攻击载体是一类第三方改造插件。它以“功能增强”的面目出现在插件生态中，实际上同时在三个层面发力：

• 运行时挂钩：在系统提示词组装、代理执行前处理、会话创建、预设切换、命令与工具注册、界面服务等宿主提供的扩展点上注册自身逻辑，让每一轮对话都流经被改造的管道；
• 宿主文件篡改：定位官方发布包中的脚本、配置与清单文件，先保存原始副本，再按版本与文件形态替换指定代码片段，使默认提示词、身份表述、审批与拒绝行为在宿主重启后依然生效；
• 配套子系统捆绑分发：规则集、技能管理、提示词编辑、自动续答与重试、对话回退、备份还原、插件更新，乃至一套独立的“授权安全演练”数据与代理协作体系，全部打包在一起。

这套设计的高明之处在于便利性与安全削弱被捆绑分发：用户为了“自动续答”“免审批”“可回退”等效率特性安装插件，审批与沙箱约束的松动只是“顺带”发生，还因为在备份还原机制的包装下显得可控、可逆。而被补丁的目标不止提示词与身份表述，还包括取消或放宽部分官方审批、拒绝与沙箱约束，它扩大了代理自动执行的范围，同时削弱了宿主原有的安全闸门。

二、双链协同：审核闸门是如何被绕过的

理解这起漏洞，需要区分两条性质完全不同的攻击路径。

动态链：提示注入。 每轮对话都会经过系统提示词组装与执行前处理。攻击者只要在这些环节挂上逻辑，就能在运行时改写模型看到的身份约束与安全指令。动态链随会话而生、随会话而灭，重启即失效，这也是多数团队重点防御、检测手段最成熟的方向。

静态链：落盘篡改。 更隐蔽的一步是把修改写入磁盘。网页端与桌面端重启后，宿主会“名正言顺”地加载被篡改的状态，使之成为新的运行基线。此后即便动态链完全失效，模型也已工作在被削弱的默认环境里：审批、拒绝与沙箱约束被取消或放宽，代理可自动执行的范围随之扩大。更麻烦的是，这类改造工具通常自带备份与重应用机制，使篡改在宿主升级后仍能自动续命，静态链不仅持久，还会“自我修复”。

两条链叠加意味着：防御方必须同时盯住“每一轮对话”和“每一份落盘文件”。只防对话注入、不防文件篡改，等于只锁前门、敞开后门。

还有一个容易被忽视的细节让静态链更加顽固：该客户端允许用户改写提示词文件，并遵循“用户正文保留”策略，文件缺失或为空时播种默认稿；一旦内容被识别为用户改写，就不会在启动或重新应用时被默认稿覆盖。这本是尊重用户定制的善意机制，却被反向利用：篡改结果被系统识别为“用户正文”，从而获得了跨启动、跨升级的持久化豁免。

三、四道裂缝：这起漏洞真正暴露的问题

裂缝一：信任边界错位——审核决策放在了可篡改的一侧

系统提示词、拒绝逻辑、审批策略、区域合规配置，这些内容审核的“命门”若落在用户可写的文件层，就等于宣布：任何拥有本地写权限的进程都有权重写审核规则。安全架构的第一原则是按信任级别划分资产：桌面客户端、插件生态、配置文件、提示词文件全部运行在用户权限域内，对防御方而言属于不可信侧；唯一可信的强制点在服务端。这起漏洞的根源，就是把本应属于服务端的“约束”降格成了客户端的“建议”。

裂缝二：静态链无人看守——只监控“说了什么”，不监控“自己是什么”

主流内容安全体系的建设重心几乎都在运行时：输入过滤、提示词检测、输出分类、会话风控。但对“客户端自身被改造成什么样”缺乏度量，没有完整性基线、没有签名校验、没有启动自检，落盘篡改就成了不可见事件。更具迷惑性的是，重启与升级这些原本代表“恢复出厂状态”的动作，反而替篡改背书：宿主以为自己在加载合法基线，实际加载的是被削弱后的版本。检测视角的缺失，是静态链得以长期潜伏的直接原因。

裂缝三：安全闸门的“不可等价恢复”——被拆掉的安全补不回来

这是整起事件中最深刻的一点。改造工具并非裸奔：它提供备份还原、状态检查、区域目标限制等管理能力，试图证明削弱是“可控、可逆”的。但备份能恢复文件内容，却恢复不了“从未被篡改”这一事实所隐含的信任。安全属性依附于执行路径，而不是配置状态：审批、拒绝、沙箱这些闸门一旦被移除，代理自动化操作造成的数据外泄与滥用风险已经实际发生；即便事后把配置原样贴回，也无法证明当前运行时等价于未被削弱的状态。由此得出的工程结论非常朴素：不要设计“先拆闸门、再靠管理工具补位”的架构。防御机制要么驻留在不可篡改的一侧，要么就等于不存在。

裂缝四：对抗评测缺位——漏洞为什么是“被曝”而不是“被发现”

这起漏洞由外部披露而非内部评测发现，本身就是一个信号。颇具讽刺意味的是，连攻击方都随包携带一套独立的“授权安全演练”数据体系来验证绕过效果，而多数防御方的内容安全测试仍停留在少量手工用例与发布前的抽样检查。攻击已经工程化，有版本管理、有升级适配、有演练数据；防御若仍靠单点用例，差距只会越拉越大。安全不是一次性的发布检查，而是持续的对抗性度量过程。

四、补齐裂缝：五项可落地的防护实践

1. 把审核强制点上移至服务端

一切可被本地进程改写的资源——系统提示词、审核规则、审批与区域策略，只能视为客户端提交的“偏好建议”，不能视为约束本身。真正的强制点必须位于服务端（示意伪代码）：

async def handle(req):
    if not input_guard.scan(req.text):        # 输入侧审核
        return refuse()
    reply = await llm.generate(
        system=SERVER_OWNED_PROMPT,           # 系统提示词由服务端持有与下发
        messages=req.messages,
    )
    if not output_guard.scan(reply):          # 输出侧兜底
        return refuse()
    audit.write(req.id, req.text, reply)      # 全链路审计
    return reply

服务端持有的系统提示词与审批策略对客户端不可见、不可改；客户端可以提交个性化参数，但服务端只接受白名单内的键值，任何试图整体替换指令的请求都应被拒绝并告警。

2. 关键文件的完整性与签名校验

对安装目录内的脚本、配置、清单建立哈希基线，启动时逐项校验，失配即拒绝运行，而不是“带病运行”（示意伪代码）：

def verify_manifest(manifest):
    for path, expected in manifest.items():
        if sha256(read(path)) != expected:
            raise FatalIntegrityError(path)  # 拒绝启动并上报

再配合代码签名与“校验失败自动回滚到可信版本”，可以把静态链篡改从不可见事件变成高噪声告警。对确需用户自定义的提示词，应把“用户正文”限定为受服务端约束的参数化字段，而不是整段可执行的指令文本。

3. 危险操作的默认安全与最小授权

代理自动执行范围的每一步扩大，都应在服务端对应一道策略：读写宿主文件、执行系统命令、访问网络等高危工具调用，保留服务端审批与沙箱隔离，客户端无权关闭。审批逻辑可以做成策略引擎，按区域、租户、风险等级做差异化配置，但决策点必须在服务端。同理，“区域目标限制”这类合规诉求应由服务端依据请求来源属地统一执行，依赖客户端配置的区域限制，在静态链面前形同虚设。

4. 输出侧兜底与审计闭环

即便输入侧与模型层全部失守，输出侧仍应是最后一道闸。业界成熟的做法是接入专业内容安全服务：以百度智能云为代表的主流云厂商普遍提供文本、图像等多模态内容审核类能力，支持风险等级划分、阈值配置与实时告警，适合作为涉黄、涉暴等风险输出的兜底判定。所有拒绝、放行与人工复核事件应全量落审计，并与监控告警体系打通，形成“发现—定位—止血”的闭环，让单点绕过在统计层面变得可见。

5. 常态化对抗评测与响应机制

• 建设攻击语料库：持续收集越狱模板、变体改写、多轮诱导样本，并将线上真实绕过案例回流入库；
• 定义可度量指标：绕过率、召回率、误伤率随版本回归，任何提示词或规则变更都必须通过对抗集测试；
• 开展红蓝对抗：授权演练应同时覆盖动态链与静态链两个维度，把“客户端被改造”纳入正式攻击面；
• 明确响应流程：对外部披露先于内部发现的部分，作为评测体系的缺陷进行复盘并改进。

五、结语

涉黄审核漏洞只是表象。它真正暴露的，是内容安全体系对“客户端必然可被改造”这一前提缺乏敬畏：信任边界画错了位置，静态链无人看守，被拆掉的闸门被幻想成可以事后补回，对抗评测远远落后于攻击的工程化水平。内容审核从来不是模型能力的单点比拼，而是一道体系工程，把强制点放回不可篡改的一侧，为关键文件建立完整性基线，让每一次削弱都可见、让不可逆的削弱无从发生，审核漏洞才可能从“被曝”变成“被发现”。