Node.js 2021年10月安全发布全解析HTTP 请求走私漏洞 CVE-2021-22959 / CVE-2021-22960 的成因、影响与修复【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org2021 年 10 月 12 日Node.js 项目针对 v12.x、v14.x、v16.x 三条发布线发布了安全更新版本一次性修复了两个中危的HTTP Request SmugglingHRSHTTP 请求走私漏洞CVE-2021-22959 与 CVE-2021-22960。这两个漏洞均源自 Node.js 内置 HTTP 解析器llhttp对畸形请求的宽松解析可被攻击者利用来绕过前端代理的校验、实施缓存投毒或会话劫持。阅读本文你将掌握这两个漏洞的精确成因与触发条件、受影响版本范围、llhttp 修复版本与回归测试策略以及 nodejs.org 站点是如何组织、展示和检索这些安全公告与漏洞数据的。发布总览一次覆盖三条发布线的安全更新本次安全发布对应公告文档 oct-2021-security-releases.md于 2021 年 10 月 12 日周二当天或稍后发布共修复两个中危Medium问题涉及的发布线与对应版本如下发布线版本状态修复漏洞v12.xv12.22.7LTSCVE-2021-22959、CVE-2021-22960v14.xv14.18.1LTSCVE-2021-22959、CVE-2021-22960v16.xv16.11.1CurrentCVE-2021-22959、CVE-2021-22960三条发布线全部受影响、且修复版本在同一天齐发的模式在 Node.js 安全实践中非常典型说明漏洞位于所有发布线共享的底层依赖llhttp HTTP 解析器中而非某一发布线特有的新特性代码。CVE-2021-22959Header 名后冒号前允许空格导致请求走私中危漏洞成因CVE-2021-22959 的根因在公告中被精确定位为HTTP 解析器接受头部名称之后、冒号之前紧跟一个空格SPSpace的请求。在严格的 HTTP 协议语义中头部行的格式应当是Header-Name: value冒号前不允许出现空白字符。但存在缺陷的 llhttp 版本会容忍Header-Name : value这种写法。前端代理如 Nginx、HAProxy、各类 WAF与后端 Node.js 服务器对该畸形格式的解析结果不一致时就产生了请求走私HRS攻击面——攻击者可以向同一个代理-后端连接塞入两份语义不同的请求从而污染共享连接、绕过访问控制或投毒缓存。影响范围与修复公告明确指出该漏洞影响 16.x、14.x、12.x 发布线的所有版本。修复被包含在llhttp v2.1.4 与 v6.0.6中v2.1.4 服务于 v12.x/v14.x 等使用旧版 llhttp 2.x 的发布线v6.0.6 服务于 v16.x 等使用 llhttp 6.x 的发布线。漏洞由 Mattias Grenfeldt 与 Asta Olofsson 报告。源码层面的修复证据仓库中的各发布线 release 公告完整记录了这次修复的具体提交。以 v14.18.1 发布说明为例其 Notable changes 与 Commits 部分显示deps: update llhttp to 2.1.4将 llhttp 依赖升级到包含修复的 2.1.4 版本http: add regression test for smuggling content length新增针对 Content-Length 走私场景的回归测试防止此类解析缺陷在未来被重新引入。v16.11.1 发布说明则对应记录了deps: update llhttp to 6.0.4以及两条同样面向走私场景的回归测试提交。这组依赖升级 回归测试的组合是 Node.js 处理安全依赖缺陷的标准修复范式不仅要升级还要用测试把漏洞形态固化下来。CVE-2021-22960解析分块请求体时忽略 chunk 扩展导致请求走私中危漏洞成因CVE-2021-22960 的根因在于解析分块传输编码chunked transfer encoding请求体时解析器忽略了 chunk 扩展chunk extensions。HTTP 分块编码的每个数据块格式为chunk-size[;chunk-extensions]CRLF chunk-data CRLF其中 chunk 扩展如;namevalue属于合法语法但不同的解析器对其处理方式不同。当 Node.js 的解析器在特定条件下忽略 chunk 扩展而前端代理按扩展语义例如把扩展名解释为元数据、改变后续分块解释处理时双方对请求边界的判定就会产生分歧从而形成走私条件。公告用词是under certain conditions特定条件下即该漏洞并非所有分块请求都会触发而是需要精确构造畸形/边界输入。影响范围与修复与 CVE-2021-22959 完全一致影响 16.x、14.x、12.x 发布线的所有版本修复同样包含在llhttp v2.1.4 与 v6.0.6中同样由 Mattias Grenfeldt 与 Asta Olofsson 报告。源码层面的修复证据v14.18.1 发布说明与 v16.11.1 发布说明中的 Commits 均记录了http: add regression test for chunked smuggling——这是专门针对分块编码走私chunked smuggling形态的回归测试提交与 CVE-2021-22960 的成因一一对应验证了修复确实覆盖了 chunk 扩展被忽略这一具体解析路径。漏洞为什么都指向 llhttp将两个漏洞放在一起看模式非常清晰根因全部位于 Node.js 内置的 HTTP 解析器 llhttp 中。llhttp 是一个用 C 编写的、面向 Node.js http 模块的增量式 HTTP 解析器负责对进入的请求/响应做逐字节解析解析器的职责之一是严格判定请求边界Header 结束、Body 长度、分块结束而请求走私的本质就是不同解析器对同一条请求的边界判定不一致本次两个漏洞分别出在头部行解析冒号前空格与分块体解析chunk 扩展两条路径上恰好覆盖了 HTTP 报文中最容易产生歧义的两类语法。这也解释了为什么 v12/v14/v16 三条发布线需要同时打补丁它们共享同一套 llhttp 解析逻辑只是 llhttp 大版本不同2.x 与 6.x因此修复需要分别落到 v2.1.4 与 v6.0.6 两个版本上。升级路径与影响评估影响范围自查v16.x 发布线所有版本均受两个中危问题影响v14.x 发布线所有版本均受两个中危问题影响v12.x 发布线所有版本均受两个中危问题影响。升级建议运行在上述任意发布线、且版本号低于本次修复版本的 Node.js 实例尤其是直接对外暴露 HTTP 服务、或位于反向代理/负载均衡/WAF 之后的实例都建议尽快升级v12.x → v12.22.7 (LTS)v14.x → v14.18.1 (LTS)v16.x → v16.11.1 (Current)各 release 公告中除漏洞修复说明外还完整列出了当次发布的分发产物清单Windows/macOS/Linux 各架构的安装包与二进制、源码包以及经 PGP 签名的 SHASUMS 校验文件可用于升级后的完整性校验。安全公告在 nodejs.org 站内的组织与呈现理解这份公告如何被站点消化有助于你在 nodejs.org 上快速检索历史安全信息。从仓库源码结构可以清晰看到一条完整的数据链路1. 漏洞原始数据源站点并不硬编码漏洞数据而是从 Node.js Security Working Group 维护的漏洞清单实时拉取。数据源 URL 定义在 next.constants.mjs 的VULNERABILITIES_URL常量中指向 security-wg 仓库的vuln/core/index.json。2. 数据生成与按主版本分组next-data/generators/vulnerabilities.mjs 是核心生成器它fetchWithRetry拉取上述 JSON将每条漏洞记录的vulnerable字段形如12.x、6.0.0 6.2.0、0.10.x等通过正则解析RANGE_REGEX、V0_REGEX、VER_REGEX拆解最终按主版本号分组输出。这意味着 CVE-2021-22959 这类影响 12.x/14.x/16.x 全部版本的漏洞会被自动归入 12、14、16 三个分组供各版本页面展示。对应的分组逻辑由 vulnerabilities.test.mjs 中的多组单测覆盖如12.x || 13.x双版本分组、 5降序展开、 5仅含指定主版本等边界用例。3. 数据结构与严重程度分级漏洞的数据模型定义在 types/vulnerabilities.ts 中每条记录包含cve编号数组、vulnerable/patched版本表达式、description、overview、affectedEnvironments与severity字段。其中Severity被严格限定为unknown | low | medium | high | critical五级——本次公告中的两个问题即为medium中危。4. 界面呈现在站点的 EOLEnd-of-Life页面中EOLReleaseTable/TableBody.tsx 会为每个已停止维护的版本展示对应的漏洞标签点击详情后EOLModal.tsx 会按SEVERITY_ORDER对漏洞排序并分已知严重程度/未知严重程度两个区块展示VulnerabilitiesTable.tsx 则把每条漏洞渲染为CVE 编号、严重程度标签、概览、详情链接四列表格其中严重程度标签由 VulnerabilityChip 依据SEVERITY_KIND_MAP映射为对应的 Badge 样式。5. 公告的分类归档本公告所在的 vulnerability 分类与 release/announcements 等分类共同构成了博客体系。博客数据的分类与分页逻辑位于 util/blog.tsmapBlogCategoryToPreviewType将vulnerability直接映射为同名的预览类型getBlogPosts与paginateBlogPosts负责按分类筛选并按页切分保证你在安全公告列表页可以按时间顺序翻看所有历史漏洞通告。安全披露流程与后续更新渠道公告同时给出了安全研究者的后续参与路径报告漏洞Node.js 项目维护有明确的安全披露策略Security Policy安全研究人员应遵循该流程提交漏洞报告而不是直接在公开 Issue 中透露细节订阅公告项目提供低流量、仅发公告的 nodejs-sec 邮件列表订阅后可第一时间获取 Node.js 及其关联项目nodejs GitHub 组织下维护的项目的安全漏洞与安全发布通知。结语CVE-2021-22959 与 CVE-2021-22960 是一次教科书式的 HTTP 解析器安全事件两个中危漏洞、共享同一根因组件llhttp、同时波及三条发布线、并在同一天以依赖升级 回归测试的组合完成修复。对开发者而言本公告的启示有三点其一HTTP 边界解析是走私攻击的高发区任何自定义的代理/网关/解析逻辑都应警惕与后端解析器之间的语义差异其二运行中的 Node.js 服务应始终跟进 LTS 发布线的安全补丁其三像 nodejs.org 这样将安全公告、漏洞数据、版本影响面系统化组织起来的做法正是可观测、可检索的安全运维基础设施。【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Node.js 2021年10月安全发布全解析：HTTP 请求走私漏洞 CVE-2021-22959 / CVE-2021-22960 的成因、影响与修复
Node.js 2021年10月安全发布全解析HTTP 请求走私漏洞 CVE-2021-22959 / CVE-2021-22960 的成因、影响与修复【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org2021 年 10 月 12 日Node.js 项目针对 v12.x、v14.x、v16.x 三条发布线发布了安全更新版本一次性修复了两个中危的HTTP Request SmugglingHRSHTTP 请求走私漏洞CVE-2021-22959 与 CVE-2021-22960。这两个漏洞均源自 Node.js 内置 HTTP 解析器llhttp对畸形请求的宽松解析可被攻击者利用来绕过前端代理的校验、实施缓存投毒或会话劫持。阅读本文你将掌握这两个漏洞的精确成因与触发条件、受影响版本范围、llhttp 修复版本与回归测试策略以及 nodejs.org 站点是如何组织、展示和检索这些安全公告与漏洞数据的。发布总览一次覆盖三条发布线的安全更新本次安全发布对应公告文档 oct-2021-security-releases.md于 2021 年 10 月 12 日周二当天或稍后发布共修复两个中危Medium问题涉及的发布线与对应版本如下发布线版本状态修复漏洞v12.xv12.22.7LTSCVE-2021-22959、CVE-2021-22960v14.xv14.18.1LTSCVE-2021-22959、CVE-2021-22960v16.xv16.11.1CurrentCVE-2021-22959、CVE-2021-22960三条发布线全部受影响、且修复版本在同一天齐发的模式在 Node.js 安全实践中非常典型说明漏洞位于所有发布线共享的底层依赖llhttp HTTP 解析器中而非某一发布线特有的新特性代码。CVE-2021-22959Header 名后冒号前允许空格导致请求走私中危漏洞成因CVE-2021-22959 的根因在公告中被精确定位为HTTP 解析器接受头部名称之后、冒号之前紧跟一个空格SPSpace的请求。在严格的 HTTP 协议语义中头部行的格式应当是Header-Name: value冒号前不允许出现空白字符。但存在缺陷的 llhttp 版本会容忍Header-Name : value这种写法。前端代理如 Nginx、HAProxy、各类 WAF与后端 Node.js 服务器对该畸形格式的解析结果不一致时就产生了请求走私HRS攻击面——攻击者可以向同一个代理-后端连接塞入两份语义不同的请求从而污染共享连接、绕过访问控制或投毒缓存。影响范围与修复公告明确指出该漏洞影响 16.x、14.x、12.x 发布线的所有版本。修复被包含在llhttp v2.1.4 与 v6.0.6中v2.1.4 服务于 v12.x/v14.x 等使用旧版 llhttp 2.x 的发布线v6.0.6 服务于 v16.x 等使用 llhttp 6.x 的发布线。漏洞由 Mattias Grenfeldt 与 Asta Olofsson 报告。源码层面的修复证据仓库中的各发布线 release 公告完整记录了这次修复的具体提交。以 v14.18.1 发布说明为例其 Notable changes 与 Commits 部分显示deps: update llhttp to 2.1.4将 llhttp 依赖升级到包含修复的 2.1.4 版本http: add regression test for smuggling content length新增针对 Content-Length 走私场景的回归测试防止此类解析缺陷在未来被重新引入。v16.11.1 发布说明则对应记录了deps: update llhttp to 6.0.4以及两条同样面向走私场景的回归测试提交。这组依赖升级 回归测试的组合是 Node.js 处理安全依赖缺陷的标准修复范式不仅要升级还要用测试把漏洞形态固化下来。CVE-2021-22960解析分块请求体时忽略 chunk 扩展导致请求走私中危漏洞成因CVE-2021-22960 的根因在于解析分块传输编码chunked transfer encoding请求体时解析器忽略了 chunk 扩展chunk extensions。HTTP 分块编码的每个数据块格式为chunk-size[;chunk-extensions]CRLF chunk-data CRLF其中 chunk 扩展如;namevalue属于合法语法但不同的解析器对其处理方式不同。当 Node.js 的解析器在特定条件下忽略 chunk 扩展而前端代理按扩展语义例如把扩展名解释为元数据、改变后续分块解释处理时双方对请求边界的判定就会产生分歧从而形成走私条件。公告用词是under certain conditions特定条件下即该漏洞并非所有分块请求都会触发而是需要精确构造畸形/边界输入。影响范围与修复与 CVE-2021-22959 完全一致影响 16.x、14.x、12.x 发布线的所有版本修复同样包含在llhttp v2.1.4 与 v6.0.6中同样由 Mattias Grenfeldt 与 Asta Olofsson 报告。源码层面的修复证据v14.18.1 发布说明与 v16.11.1 发布说明中的 Commits 均记录了http: add regression test for chunked smuggling——这是专门针对分块编码走私chunked smuggling形态的回归测试提交与 CVE-2021-22960 的成因一一对应验证了修复确实覆盖了 chunk 扩展被忽略这一具体解析路径。漏洞为什么都指向 llhttp将两个漏洞放在一起看模式非常清晰根因全部位于 Node.js 内置的 HTTP 解析器 llhttp 中。llhttp 是一个用 C 编写的、面向 Node.js http 模块的增量式 HTTP 解析器负责对进入的请求/响应做逐字节解析解析器的职责之一是严格判定请求边界Header 结束、Body 长度、分块结束而请求走私的本质就是不同解析器对同一条请求的边界判定不一致本次两个漏洞分别出在头部行解析冒号前空格与分块体解析chunk 扩展两条路径上恰好覆盖了 HTTP 报文中最容易产生歧义的两类语法。这也解释了为什么 v12/v14/v16 三条发布线需要同时打补丁它们共享同一套 llhttp 解析逻辑只是 llhttp 大版本不同2.x 与 6.x因此修复需要分别落到 v2.1.4 与 v6.0.6 两个版本上。升级路径与影响评估影响范围自查v16.x 发布线所有版本均受两个中危问题影响v14.x 发布线所有版本均受两个中危问题影响v12.x 发布线所有版本均受两个中危问题影响。升级建议运行在上述任意发布线、且版本号低于本次修复版本的 Node.js 实例尤其是直接对外暴露 HTTP 服务、或位于反向代理/负载均衡/WAF 之后的实例都建议尽快升级v12.x → v12.22.7 (LTS)v14.x → v14.18.1 (LTS)v16.x → v16.11.1 (Current)各 release 公告中除漏洞修复说明外还完整列出了当次发布的分发产物清单Windows/macOS/Linux 各架构的安装包与二进制、源码包以及经 PGP 签名的 SHASUMS 校验文件可用于升级后的完整性校验。安全公告在 nodejs.org 站内的组织与呈现理解这份公告如何被站点消化有助于你在 nodejs.org 上快速检索历史安全信息。从仓库源码结构可以清晰看到一条完整的数据链路1. 漏洞原始数据源站点并不硬编码漏洞数据而是从 Node.js Security Working Group 维护的漏洞清单实时拉取。数据源 URL 定义在 next.constants.mjs 的VULNERABILITIES_URL常量中指向 security-wg 仓库的vuln/core/index.json。2. 数据生成与按主版本分组next-data/generators/vulnerabilities.mjs 是核心生成器它fetchWithRetry拉取上述 JSON将每条漏洞记录的vulnerable字段形如12.x、6.0.0 6.2.0、0.10.x等通过正则解析RANGE_REGEX、V0_REGEX、VER_REGEX拆解最终按主版本号分组输出。这意味着 CVE-2021-22959 这类影响 12.x/14.x/16.x 全部版本的漏洞会被自动归入 12、14、16 三个分组供各版本页面展示。对应的分组逻辑由 vulnerabilities.test.mjs 中的多组单测覆盖如12.x || 13.x双版本分组、 5降序展开、 5仅含指定主版本等边界用例。3. 数据结构与严重程度分级漏洞的数据模型定义在 types/vulnerabilities.ts 中每条记录包含cve编号数组、vulnerable/patched版本表达式、description、overview、affectedEnvironments与severity字段。其中Severity被严格限定为unknown | low | medium | high | critical五级——本次公告中的两个问题即为medium中危。4. 界面呈现在站点的 EOLEnd-of-Life页面中EOLReleaseTable/TableBody.tsx 会为每个已停止维护的版本展示对应的漏洞标签点击详情后EOLModal.tsx 会按SEVERITY_ORDER对漏洞排序并分已知严重程度/未知严重程度两个区块展示VulnerabilitiesTable.tsx 则把每条漏洞渲染为CVE 编号、严重程度标签、概览、详情链接四列表格其中严重程度标签由 VulnerabilityChip 依据SEVERITY_KIND_MAP映射为对应的 Badge 样式。5. 公告的分类归档本公告所在的 vulnerability 分类与 release/announcements 等分类共同构成了博客体系。博客数据的分类与分页逻辑位于 util/blog.tsmapBlogCategoryToPreviewType将vulnerability直接映射为同名的预览类型getBlogPosts与paginateBlogPosts负责按分类筛选并按页切分保证你在安全公告列表页可以按时间顺序翻看所有历史漏洞通告。安全披露流程与后续更新渠道公告同时给出了安全研究者的后续参与路径报告漏洞Node.js 项目维护有明确的安全披露策略Security Policy安全研究人员应遵循该流程提交漏洞报告而不是直接在公开 Issue 中透露细节订阅公告项目提供低流量、仅发公告的 nodejs-sec 邮件列表订阅后可第一时间获取 Node.js 及其关联项目nodejs GitHub 组织下维护的项目的安全漏洞与安全发布通知。结语CVE-2021-22959 与 CVE-2021-22960 是一次教科书式的 HTTP 解析器安全事件两个中危漏洞、共享同一根因组件llhttp、同时波及三条发布线、并在同一天以依赖升级 回归测试的组合完成修复。对开发者而言本公告的启示有三点其一HTTP 边界解析是走私攻击的高发区任何自定义的代理/网关/解析逻辑都应警惕与后端解析器之间的语义差异其二运行中的 Node.js 服务应始终跟进 LTS 发布线的安全补丁其三像 nodejs.org 这样将安全公告、漏洞数据、版本影响面系统化组织起来的做法正是可观测、可检索的安全运维基础设施。【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考