Pion WebRTC 库一夜爆出 6 个安全漏洞：AI 扫描器找到了人肉审计 4 年没找到的问题

10 月 16 日，Pion 维护者 JoTurk 在 Hacker News 发了一个不起眼的帖子（发帖时几乎没有热度），内容却是 Go 实时通信生态近两年最重的一次安全披露：把 Pion DTLS 加入 Anthropic 的 OSS Scanner 之后，一觉醒来收到 36 个 bug 的报告，其中 6 个是安全漏洞——2 个严重、3 个高危、1 个中危，4 个影响 WebRTC。这些漏洞有些在代码库里存在了 4 年以上，扛过了多年的测试和社区安全扫描。

对用 Pion 做 SFU 媒体服务器、浏览器实时通信、设备互联的开发者，这篇文章回答三个问题：漏洞具体是什么、为什么这么多年没被发现、现在该怎么处理。

六个漏洞：两个认证绕过，三个资源耗尽，一个签名混淆

先说结论性的版本事实：DTLS v3 的问题在 3.1.13 和 3.1.14 两个补丁版本里修复；DTLS v2（2.2.12 及以下）的修复情况要按官方公告确认，两个严重漏洞的 v2 条目写的是 Patched versions: None——用 v2 的项目不能假设已经安全，要么升 v3，要么逐条核对公告。维护者在 HN 帖里说明这些漏洞全部早于 ChatGPT 出现，不是 AI 写出来的代码。

两个严重级漏洞都出在 DTLS 1.2 会话恢复机制上。第一个（GHSA-hhpj-h56m-9f2p，CVSS 9.1）：Pion DTLS 在客户端证书校验完成之前就把会话写进了 SessionStore。攻击者可以故意发一个不完整的握手——省略 Certificate 消息、发完 ClientKeyExchange 就走人。因为攻击者参与了密钥交换，它知道产生的 master secret；之后它开新连接恢复这个缓存的会话， abbreviated 握手只验证持有该密钥，不再强制执行原来的客户端证书要求。前提条件是服务端启用了 SessionStore、协商了基于证书的密码套件、并通过 RequireAnyClientCert 或 RequireAndVerifyClientCert 要求客户端证书。公告特别注明：这不影响纯 WebRTC 用户。

第二个严重漏洞（GHSA-7c2r-jhm9-43vf）是握手签名方案混淆，允许对端冒充：验证逻辑没有正确区分签名方案，攻击者可借签名混淆完成对端伪造，CVSS 向量为网络攻击、低复杂度、无需权限，机密性和完整性都是高影响，CWE-347（不当验证的密码签名）。

第三个认证绕过是高危级（GHSA-cqhp-ggp7-58qj）：Pion DTLS 不区分会话是客户端创建还是服务端创建。如果应用把同一个 SessionStore 同时用于出站连接和监听器，一个曾被应用主动连接过的恶意服务器，可以用它保有的出站会话密钥选中客户端缓存的那条会话、完成握手，绕过监听器的 PSK 回调或客户端证书校验。换句话说，你连过的服务器可以反向打你的监听端口——前提是它能 reachable 你的 listener。同样不影响纯 WebRTC 用户。

剩下三个是资源耗尽类。握手缓存无上限（GHSA-jm57-r6vj-mwg9，高危）：缓存只追加、不去重、无内存预算，握手完成后还能继续插入条目，攻击者用合适的 DTLS 流量就能把应用内存吃穿。超大 RSA 密钥（GHSA-jp25-wc3w-p9xp，高危）：对端证书里的 RSA 公钥在签名验证前没有模数上限，一张带超大模数和无效签名的证书就足以触发昂贵的验证运算——攻击者不需要生成对应私钥。修复方式照抄 crypto/tls：拒绝超过 8192 位的对端 RSA 公钥。这个漏洞影响 WebRTC 应用：攻击者只要能触达 DTLS 握手并让 RSA 验证路径执行即可，本端用 ECDSA 证书挡不住对端出示 RSA 证书。最后一个中危（GHSA-qpgj-64qg-5m4r）：服务端在等待客户端 Finished 消息期间会重复处理客户端证书 flight，恶意客户端扣住 Finished、持续发握手流量，就能让同一次握手反复跑证书验证和密码学运算。

为什么 4 年没被发现

这个案子里最有信息量的不是漏洞本身，而是发现路径。Pion 是 Go 生态 WebRTC 的安全关键依赖，go-libp2p、LiveKit、mediamtx、go2rtc 这些实时通信和媒体服务器项目都在用，OpenAI 内部也在用（维护者提到他们请 OpenAI 审过一个新 DTLS API）。10 月 9 日维护者把 pion/dtls 登记进 Anthropic 的 OSS Scanner（一个开源项目安全扫描计划，维护者提交 project.yaml 并通过项目构建与测试校验后加入），10 月 10 日 carlini 合并登记 PR，一周内扫描报告落地：36 个 bug，其中 6 个安全漏洞。修复提交（pion/dtls PR #1236）在 10 月 16 日当天由维护者合并，同一天 6 份 GitHub Security Advisory 发布。

更扎心的对比是：OpenAI 的内部代码评审曾经审过同一个新 API，没有报出任何 bug；这次扫描器找到的三个问题里包括一个认证问题、一个死锁、一个 TLS KeyUpdate 阻塞写入的 bug。维护者原文的原话是"OpenAI missed these issues when they reviewed the API"。这三个问题出在尚未发布的 DetachedConn API 上，所以不发 CVE、直接在合并前修掉——这对使用方是好消息：还没出厂就堵上了。

维护者在 HN 帖里还提了一个行业痛点：他们的收件箱常年被 AI 生成的安全报告轰炸，绝大多数标记的问题毫无价值；但这次 36 个 bug 里躺在代码库里 4 年多的真漏洞，正是被这类自动化扫描挖出来的。人工评审（哪怕是一线 AI 公司的评审）盯着 API 语义看，会漏掉跨状态的时序问题——比如"会话在认证完成前被缓存"这种缺陷，需要的是把状态机每个写入点和校验点对齐的机械性排查，这恰好是扫描器的舒适区。

影响面分层与处置建议

判断自己是否受影响，先看用法再谈版本。纯 WebRTC 场景（用 pion/webrtc 建点对点连接）对两个严重级的会话恢复漏洞免疫，但仍然暴露在三个资源耗尽类漏洞下，其中超大 RSA 密钥那条明确影响 WebRTC 应用。自建 DTLS 服务端、启用了 SessionStore 和客户端证书校验的场景受全部 6 个漏洞影响，是最高优先级。

具体动作按顺序做四件事。第一，升级 DTLS v3 到 3.1.14 或更高（认证绕过类在 3.1.14 修复，资源耗尽类在 3.1.13 修复，取高版本一步到位）。第二，还在 v2 的项目逐条核对官方公告：GHSA 页面显示 v2 到 2.2.12 全部受影响且 Patched 一栏为 None，是否已有 backport 要以 pion/dtls 仓库和公告更新为准，公告之外不要做安全假设。第三，暂时不能升级的，评估缓解项：不共享 SessionStore（堵第三个绕过）、不对公网暴露 DTLS 监听、对端证书链显式限制 RSA 密钥长度。第四，蓝队侧把"DTLS 握手流量异常放大、同源反复发起未完成握手"加入监控视野——三个 DoS 类漏洞的攻击面都是握手阶段的流量模式。

还有一个工程视角值得留下：这 6 个漏洞全部有 GHSA 编号、修复 commit 和 CVSS 向量，但没有分配 CVE（公告 CVE ID 一栏为 No known CVE）。做依赖风险台账的团队，只盯 CVE 数据源会把这批问题全部漏掉——Go 生态的安全披露走 GHSA + govulncheck 通道，扫描配置里应当包含它。

本文面向授权安全研究与防御建设，未经授权对任何系统实施文中技术属违法行为。