socket.io 安全策略详解：受支持版本、漏洞报告流程与历史 CVE 的源码级印证

本篇基于仓库根目录的 SECURITY.md 展开，完整覆盖 socket.io 官方安全策略三大板块——受支持版本范围、漏洞负责任披露（responsible disclosure）报告渠道、以及 2012 年至今 socket.io / socket.io-client 两个包的历史安全公告（CVE）清单。在继承原文档全部内容的基础上，本文结合 monorepo 中 socket.io-parser、engine.io 等包的真实源码，逐条印证这些 CVE 对应的防御机制在代码中是如何落地的，帮助维护者和使用者建立「政策—实现」的完整安全认知。

一、受支持的版本（Supported Versions）

SECURITY.md 明确了安全修复的版本覆盖范围：

版本	是否受支持
4.x	✅ 支持
3.x	✅ 支持
2.4.x	✅ 支持
< 2.4.0	❌ 不支持

这意味着：对于 4.x / 3.x / 2.4.x 分支发现的确认漏洞，维护者会提供修复补丁（必要时发布安全版本）；而低于 2.4.0 的版本（如 2.3.x、1.x、0.x）已停止安全维护，使用者必须自行升级到受支持分支。

从当前仓库可确认的版本基线：packages/socket.io/package.json 中服务端包版本为 4.8.3，packages/socket.io-client/package.json 中客户端包版本同样为 4.8.3，二者均属于受支持的 4.x 系列；其运行时依赖 engine.io ~6.6.0、socket.io-parser ~4.2.4（服务端）以及 engine.io-client ~6.6.1、socket.io-parser ~4.2.4（客户端）则对应 engine.io 的 6.6.9 等已合入各 CVE 修复的版本线。

二、漏洞报告渠道：负责任披露流程

SECURITY.md 对报告方式的规定非常明确，原文核心要求如下：

• 报告方式：向维护者 @darrachequesne（地址见其 GitHub 个人主页）发送邮件，邮件需描述漏洞细节及复现方法（reproduction steps）；
• 响应承诺：维护方会尽快回复，并在必要时发布修复版本；
• 关键警告：严禁在仓库的 issue 区公开创建安全漏洞工单，因为公开 issue 可能被攻击者利用抢先实施攻击（drive-by exploitation）——这是负责任披露的核心原则。

README.md 的 Security 一节与之一致：「如果你发现安全漏洞，不要在此仓库创建 issue，而应参照 Security Policy」；仓库的 issues 列表只保留给 bug 报告和功能请求，使用类问题应走文档、Stack Overflow 或 Discussions 渠道。对安全研究者的实操提示是：撰写报告时应包含受影响的包名（socket.io 还是 socket.io-client）、版本范围、最小可复现 payload，这能显著缩短分诊时间。

三、历史安全公告（History）

以下两份清单完整继承自 SECURITY.md 的 History 章节，按包分别列出。

3.1 socket.io 包直接受影响的历史 CVE

日期	描述	CVE 编号	受影响版本	修复版本
2012 年 7 月	不安全随机数（Insecure randomness）	CVE-2017-16031	<= 0.9.6	0.9.7
2021 年 1 月	CORS 配置错误（CORS misconfiguration）	CVE-2020-28481	< 2.4.0	2.4.0
2024 年 6 月	未处理的 'error' 事件（Unhandled 'error' event）	CVE-2024-38355	< 2.5.1；>= 3.0.0, < 4.6.2	2.5.1；4.6.2

3.2 socket.io 包经由传递依赖引入的漏洞

日期	依赖	描述	CVE 编号
2016 年 1 月	ws	Buffer 漏洞	CVE-2016-10518
2016 年 1 月	ws	超大 WebSocket 消息导致 DoS	CVE-2016-10542
2017 年 11 月	ws	Sec-Websocket-Extensions 头解析 DoS	-
2020 年 2 月	engine.io	资源耗尽（Resource exhaustion）	CVE-2020-36048
2021 年 1 月	socket.io-parser	资源耗尽	CVE-2020-36049
2021 年 5 月	ws	Sec-Websocket-Protocol 头 ReDoS	CVE-2021-32640
2022 年 1 月	engine.io	未捕获异常	CVE-2022-21676
2022 年 10 月	socket.io-parser	解码 Socket.IO 数据包时校验不足	CVE-2022-2421
2022 年 11 月	engine.io	未捕获异常	CVE-2022-41940
2023 年 5 月	engine.io	未捕获异常	CVE-2023-31125
2023 年 5 月	socket.io-parser	解码 Socket.IO 数据包时校验不足	CVE-2023-32695
2024 年 6 月	ws	处理含大量 HTTP 头的请求时 DoS	CVE-2024-37890
2026 年 3 月	socket.io-parser	二进制附件数量无上限（Unbounded number of binary attachments）	CVE-2026-33151
2026 年 5 月	ws	未初始化内存泄露（Uninitialized memory disclosure）	CVE-2026-45736
2026 年 6 月	ws	极小分片与数据块导致的内存耗尽 DoS	CVE-2026-48779
2026 年 6 月	engine.io	Engine.IO WebTransport SID DoS	CVE-2026-59724
2026 年 6 月	engine.io	Engine.IO Polling 传输连接耗尽（Connection Exhaustion）	CVE-2026-59725

3.3 socket.io-client 包经由传递依赖引入的漏洞

日期	依赖	描述	CVE 编号
2016 年 1 月	ws	Buffer 漏洞	CVE-2016-10518
2016 年 1 月	ws	超大 WebSocket 消息导致 DoS	CVE-2016-10542
2016 年 10 月	engine.io-client	不安全默认配置允许 TLS 上的 MITM	CVE-2016-10536
2017 年 11 月	ws	Sec-Websocket-Extensions 头解析 DoS	-
2021 年 1 月	socket.io-parser	资源耗尽	CVE-2020-36049
2021 年 5 月	ws	Sec-Websocket-Protocol 头 ReDoS	CVE-2021-32640
2022 年 10 月	socket.io-parser	解码 Socket.IO 数据包时校验不足	CVE-2022-2421
2023 年 5 月	socket.io-parser	解码 Socket.IO 数据包时校验不足	CVE-2023-32695
2024 年 6 月	ws	处理含大量 HTTP 头的请求时 DoS	CVE-2024-37890
2026 年 3 月	socket.io-parser	二进制附件数量无上限	CVE-2026-33151
2026 年 5 月	ws	未初始化内存泄露	CVE-2026-45736
2026 年 6 月	ws	极小分片与数据块导致的内存耗尽 DoS	CVE-2026-48779

从清单中可以读出几条规律：高频受影响的依赖集中在 ws（WebSocket 底层）、engine.io（传输引擎）与 socket.io-parser（协议编解码），漏洞类型以资源耗尽 / DoS 与协议解码校验不足为主——这也决定了下一节源码印证的重点。

四、源码级印证：当前仓库如何防御这些 CVE

以下结论均基于当前仓库的源码与配置，可用于验证「受支持版本已包含对应修复」。

4.1 二进制附件数量上限（对应 CVE-2026-33151）

2026 年 3 月的 socket.io-parser 公告「Unbounded number of binary attachments」针对的是：恶意方在单条报文头中声明海量二进制附件编号，使解码端持续分配/拼接导致资源耗尽。当前代码已引入上限保护，见 packages/socket.io-parser/lib/index.ts：

• DecoderOptions 提供 maxAttachments 选项，默认值为 10；
• 解码器构造函数中以 { reviver: undefined, maxAttachments: 10 } 作为基线配置，允许调用方覆盖；
• 附件重建失败路径会抛出 Illegal attachments 错误（同文件 L240 附近），拒绝非法报文。

配套地，packages/socket.io-parser/lib/binary.ts 在重建树状结构时对不匹配的附件数抛出 illegal attachments。socket.io-parser 的 CHANGELOG 中也留有多条 "add a limit to the number of binary attachments" 与 "reject binary packets with zero attachments" 的修复记录，与本 CVE 时间线吻合。

4.2 请求体大小上限与 413 拒答（对应历史资源耗尽类 CVE）

engine.io 的 maxHttpBufferSize 选项是抵御「超大消息 / 资源耗尽」类攻击的第一道闸门。当前默认值定义在 packages/engine.io/lib/server.ts：maxHttpBufferSize: 1e6（1 MB）。polling 传输中的超限处理逻辑在 packages/engine.io/lib/transports/polling.ts：逐 chunk 累计 contentLength，一旦超过 maxHttpBufferSize 立即 res.writeHead(413).end() 并清理连接，不再继续接收数据；uWebSockets 变体在 packages/engine.io/lib/transports-uws/polling.ts 有等价的 expectedContentLength 校验。相关行为有测试覆盖，例如 packages/engine.io/test/server.js 中 "should not be receiving data when getting a message longer than maxHttpBufferSize when polling" 等用例。

4.3 ws 依赖版本锁定（对应 ws 系列 CVE）

ws 是 engine.io 的 WebSocket 底层，其 2024–2026 年连发多个 CVE（CVE-2024-37890、CVE-2026-45736、CVE-2026-48779）。当前仓库采取双层固定：

• packages/engine.io/package.json 声明 "ws": "~8.21.0"；
• 根 package.json 通过 npm overrides 字段全局强制 "ws": "8.21.0"，防止工作区内其他包间接引入旧版本形成版本漂移。

这种 overrides 做法保证了整个 monorepo（含 devDependencies 与测试依赖树）中的 ws 收敛到同一已修复版本。

4.4 WebTransport 默认关闭（对应 CVE-2026-59724 的攻击面）

2026 年 6 月的 engine.io 公告「WebTransport SID DoS」表明 WebTransport 传输的 SID 处理存在被利用的可能。从源码结构看，当前 packages/engine.io/lib/server.ts 中默认 transports: ["polling", "websocket"]，注释明确写着「WebTransport is disabled by default and must be manually enabled」——即该攻击面在默认部署下不存在，只有显式启用 webtransport 的部署才需要跟进对应修复版本。

4.5 CORS 与 cookie 依赖

2020 年的 CVE-2020-28481（CORS 配置错误）由 2.4.0 修复，而当前服务端与 engine.io 均依赖 cors ~2.8.5、cookie ~0.7.2（见 packages/engine.io/package.json），处于已修复后的版本区间内；socket.io 服务端自身同样依赖 cors ~2.8.5 与 accepts ~1.3.4（见 packages/socket.io/package.json）。

五、给使用者与维护者的实操建议

1. 核对版本：确认生产环境中 socket.io 与 socket.io-client 均为 4.x（本仓库基线为 4.8.3），并保证二者版本一致以避免协议不匹配；若仍停留在 2.x，升级目标不低于 2.4.x，否则已无安全修复保障。
2. 锁定底层依赖：若通过 lockfile 管理依赖，建议关注 ws、engine.io(-client)、socket.io-parser 三个高频 CVE 来源的版本更新，可参考本仓库根 package.json 中 overrides 强制固定 ws 版本的做法。
3. 收紧传输面：非必要不启用 WebTransport（默认即为关闭状态）；对 polling 传输保持默认的 maxHttpBufferSize（1 MB）或按业务调小，超限请求会以 HTTP 413 被快速拒绝。
4. 报告漏洞请走邮件渠道：发现疑似漏洞时，按 SECURITY.md 的要求邮件联系维护者并附复现步骤，不要公开 issue；普通 bug 才提交到仓库 issues。

小结

SECURITY.md 给出的是一份「版本承诺 + 披露流程 + 历史账目」三合一的安全策略：4.x / 3.x / 2.4.x 三个版本线获得持续安全维护，漏洞报告通过邮件负责任披露，2012–2026 年间的全部历史 CVE 逐条归档。结合当前 monorepo 源码可以看到，这些历史教训已沉淀为具体防线——socket.io-parser 的 maxAttachments 上限、engine.io 的 maxHttpBufferSize 413 拒答、ws 的全局版本锁定、WebTransport 的默认关闭——安全策略文档与代码实现形成了闭环。