Next.js 安全修补不仅仅是升级版本号那么简单
makedream2026年5月14日
0
Computing/SoftwareRelated Video
16:03NextJS 彻底完了…… 13 个新增安全漏洞
Better Stack
Comments (0)
Log in to leave a comment
No posts yet
makedream16:03makedream16:03Better Stack
Log in to leave a comment
No posts yet
对于没有专业安全人员的团队来说，听到 Next.js 漏洞的消息往往会感到茫然。服务不能立即停止，但推迟补丁又让人心生不安。仅仅运行 npm update 并不能解决所有问题。你必须亲自找出并堵住隐藏在代码某处的漏洞。本文整理了在确保发布后服务不崩溃的前提下，兼顾安全的实务应对方法。
当你安装的库所使用的“子包（child package）”出现漏洞时，情况会变得很棘手。等待上游库更新实在太冒险了。在这种情况下，必须干预依赖树，强制插入指定版本。
首先在终端执行 npm list <漏洞软件包名>。你需要亲眼确认该软件包是通过什么路径引入的。找到原因后，在 package.json 中添加 overrides (npm) 或 resolutions (yarn) 字段。在这里明确写下已修复安全问题的版本，包管理器就会扫描子依赖并将其替换为该版本。最后还需打开 package-lock.json 确认版本是否真的发生了变化，这样才能放心。
在 Next.js Server Actions 或 API Routes 中获取外部数据时，很容易暴露在 SSRF 攻击之下。如果攻击者在 URL 参数中加入像 169.254.169.254 这样的云端元数据地址，服务器就会天真地读取并交出内部凭据。更改基础设施配置很麻烦，因此应在代码层面收紧入口。
不要直接使用标准 fetch，而应加入检查 IP 范围的逻辑。通过 dns.lookup 将主机名转换为 IP 后，检查该地址是否属于私有网络范围（如 10.0.0.0/8、192.168.0.0/16 等）。编写一个自定义函数，如果是内网地址则立即拦截请求，并将其应用于所有服务器端调用。这是无需依赖基础设施团队即可防止数据泄露事故最可靠的方法。
CVE-2025-29927 漏洞利用中间件路径处理逻辑的漏洞来绕过身份验证。特别是在使用多语言设置时，如果在 URL 中混入奇怪的特殊字符，匹配逻辑可能会出现混乱。
在 middleware.ts 中，所有进入的路径都必须经过正规化处理。删除重复的斜杠，并采用与允许的语言代码（如 ko、en 等）列表进行对比的白名单方式。对于不在列表中的请求，直接返回 400 错误。此外，应设置在反向代理阶段删除从外部流入的 x-middleware-subrequest 等内部专用 Header。这样可以在不改动业务逻辑的情况下，挡住权限绕过攻击。
React 19 中使用的数据传输方式非常复杂。像 CVE-2026-23869 那样，攻击者可能发送包含循环引用的数据，导致服务器 CPU 飙升至 100%。在修改代码之前，应先在服务器入口处设置物理限制。
在 Nginx 等反向代理中，将 client_max_body_size 大幅缩小至 128k 左右。对于一般的 API 请求，这已经足够了。特别是带有 Content-Type: text/x-component Header 的请求，需要更严格地限制速率。为了防止服务器因读取异常数据而拖延时间，建议将超时时间缩短至 30 秒以内。
如果发布了安全补丁，结果却导致支付页面无法打开，那就麻烦了。补丁发布后，必须使用测试代码模拟真实攻击者的行为。使用 Playwright 会很方便。
编写一些场景，例如尝试在没有授权的情况下访问管理员页面，或者在 API 参数中输入 localhost 地址。此时添加断言（assertion），确认系统返回的是 403 或 400 响应，而不是 200 OK。将此测试放入 CI/CD 流水线中，可以防止在下次更新时误删安全逻辑。虽然没有完美的安全，但养成逐一封闭代码入口的习惯，会比专业安全团队构建更强大的防线。