作者 akihi（白帽攻防录讲师），某甲方网络安全工程师，合合 SRC 年度第一、腾讯 SRC 连续三年前十，单漏洞赏金 4w+，擅长 Web/App/PC 客户端漏洞挖掘。专注前端安全、React 应用安全、XSS 漏洞分析。本文基于公开 CVE 信息与技术原理深度复盘，供安全研究与防护参考。
一、漏洞时间线
2026 年 9 月，TanStack 发布了安全更新，修复了一个 CVSS 9.3 的严重漏洞 CVE-2026-102989。这个漏洞让攻击者能通过一个精心构造的 URL，让 TanStack Start 应用从自己的源返回攻击者控制的 HTML，在受害者浏览器里执行任意 JavaScript 脚本。
| 时间 | 事件 | 影响版本 |
|---|---|---|
| 2026-09-30 | TanStack 发布安全公告 | 修复版本已发布 |
| 2026-10-01 | 各大安全媒体公开技术分析 | ------ |
| 2026-10-04 | 韩国安全媒体发布详情 | ------ |
| 2026-10-07 | Netlify 等平台发布防护规则 | ------ |
这个漏洞最可怕的地方在于：它是一个反射型 XSS------但和传统的反射型 XSS 不一样。传统 XSS 是在搜索框、参数里注入脚本，而这个漏洞是在服务器函数的响应处理里------攻击者构造一个 URL，应用服务器就会把攻击者控制的 HTML 直接返回给浏览器，而且是在应用自己的源里执行。这意味着攻击者能窃取用户的会话 Cookie、篡改页面内容、进行钓鱼攻击。
二、攻击链全景
让我们先用一张流程图还原完整的攻击路径：
攻击者发现目标用了 TanStack Start 框架
│
▼
第一步：环境探测
│ 攻击者分析目标：
│ - 用了 TanStack Start
│ - 版本有漏洞
│ - 部署在 Netlify 等平台
│
│ 怎么识别？
│ - 看页面源码特征
│ - 看服务器函数端点
│ - 看响应头
▼
第二步：构造恶意 URL
│ 攻击者构造一个恶意 URL：
│ - 指向服务器函数端点
│ - 参数里有恶意内容
│ - 能让应用返回攻击者控制的 HTML
│
│ 什么是服务器函数？
│ - TanStack Start 的服务器端函数
│ - 类似 Next.js 的 Server Actions
│ - 前端调用后端函数
│
│ 问题在哪里？
│ - 服务器函数处理请求时
│ - 把攻击者控制的内容
│ - 直接放到响应里
│ - 没有正确转义
▼
第三步：诱导受害者点击
│ 攻击者把恶意 URL 发给受害者：
│ - 邮件钓鱼
│ - 社交媒体
│ - 评论区
│
│ 受害者看到什么？
│ - 一个看起来正常的链接
│ - 比如 "你的订单有更新"
│ - 受害者点击了
▼
第四步：服务器返回恶意 HTML
│ 受害者浏览器访问恶意 URL
│
│ TanStack Start 服务器函数：
│ - 收到请求
│ - 处理参数
│ - 生成响应
│ - 把攻击者控制的内容
│ - 直接放到 HTML 里
│
│ 为什么能这样？
│ - 响应处理逻辑有缺陷
│ - 没有正确转义特殊字符
│ - 攻击者的 HTML 被原样返回
▼
第五步：恶意脚本执行
│ 浏览器收到响应
│ - 是应用自己的源
│ - 浏览器信任它
│ - 执行里面的恶意脚本
│
│ 恶意脚本做什么？
│ - 窃取会话 Cookie
│ - 篡改页面内容
│ - 钓鱼表单
│ - 强制跳转
▼
攻击者完全控制用户的浏览器会话
│
├─ 窃取会话 Cookie
├─ 劫持用户账号
├─ 篡改页面内容
└─ 传播给更多用户**关键结论：**这个漏洞的本质是"服务器函数响应处理不当"------服务器函数把攻击者控制的内容直接放到响应 HTML 里，没有正确转义。在前端框架安全中，服务器函数是一个新的攻击面：传统的 XSS 是在渲染用户输入时出问题，而服务器函数是在处理请求响应时出问题。理解服务器函数安全、响应转义、CSP 防护，是做现代 Web 安全的基本功。
三、TanStack Start 与服务器函数原理
3.1 什么是 TanStack Start
TanStack Start 是一个 React 元框架：
| 组件 | 功能 |
|---|---|
| TanStack Start | React 全栈框架 |
| 服务器函数 | 前端调用后端函数的机制 |
| 路由系统 | 文件系统路由 |
| 数据加载 | 服务器端数据获取 |
| 部署平台 | Netlify、Vercel 等 |
3.2 什么是服务器函数
服务器函数是现代前端框架的核心概念：
// 服务器函数是干什么的？
// 传统前端架构：
// - 前端是纯静态页面
// - 后端是独立的 API
// - 前端通过 fetch 调用 API
//
// 现代全栈框架：
// - Next.js Server Actions
// - TanStack Start Server Functions
// - Remix Actions
//
// 服务器函数是什么？
// - 写在前端代码里的后端函数
// - 前端直接 import 调用
// - 框架自动在服务器执行
//
// 为什么要这样？
// - 减少样板代码
// - 类型安全
// - 更好的开发体验
//
// 安全问题在哪里？
// - 服务器函数处理用户输入
// - 生成响应
// - 如果处理不好
// - 就会有 XSS 漏洞3.3 什么是反射型 XSS
反射型 XSS 是最经典的 Web 漏洞：
// 反射型 XSS 是什么？
// 正常 Web 应用：
// - 用户访问 URL
// - 服务器根据参数生成页面
// - 参数显示在页面上
//
// 比如：
// - URL: /search?q=hello
// - 页面显示 "搜索结果：hello"
//
// 攻击方式：
// - URL: /search?q=<script>steal()</script>
// - 页面显示 "搜索结果：<script>steal()</script>"
// - 浏览器执行脚本
//
// 为什么危险？
// - 脚本在应用的源执行
// - 能访问用户的 Cookie
// - 能篡改页面
// - 能做任何用户能做的事四、漏洞深度分析
4.1 漏洞根因：响应处理不当
根据 TanStack 官方公告，漏洞的根本原因是服务器函数响应处理不当：
// 有缺陷的逻辑（伪代码）
// TanStack Start 处理服务器函数请求：
// 1. 收到服务器函数请求
// 2. 拿到请求参数
// 3. 调用对应的服务器函数
// 4. 把函数返回值放到响应 HTML 里
// 5. 返回给浏览器
// 问题在哪里？
//
// 步骤 4 应该：
// - 转义返回值里的 HTML 特殊字符
// - 不允许插入任意 HTML
// - 只显示纯文本
//
// 但实际代码：
// - 直接把返回值放到 HTML 里
// - 不转义特殊字符
// - 攻击者传什么就显示什么
//
// 修复方式：
// - 正确转义响应内容
// - 或者用安全的渲染方式
// - 不允许插入原始 HTML4.2 为什么是反射型 XSS
这个漏洞是反射型 XSS：
// 为什么是反射型 XSS？
// 什么是反射型？
// - 攻击者构造恶意 URL
// - 受害者点击后
// - 服务器把恶意内容"反射"回浏览器
// - 浏览器执行脚本
//
// 和存储型 XSS 的区别：
// - 存储型：恶意内容存在服务器上
// - 反射型：恶意内容在 URL 里
// - 每次都要受害者点击
//
// 这个漏洞属于哪种？
// - 恶意内容在 URL 参数里
// - 服务器函数处理后返回
// - 是反射型
//
// 为什么严重？
// - CVSS 9.3
// - 不需要存储
// - 只要诱导点击就行
// - 影响所有用 TanStack Start 的应用4.3 完整攻击链
从构造 URL 到完全控制会话：
// 完整攻击步骤
// 前置条件：
// - 目标用了有漏洞的 TanStack Start
// - 部署在 Netlify 等平台
// - 有公开的服务器函数端点
// 第一步：信息收集
// - 分析目标应用
// - 确认用了 TanStack Start
// - 找到服务器函数端点
// - 确认版本有漏洞
// 第二步：构造恶意 URL
// - 研究服务器函数参数
// - 找到能注入 HTML 的参数
// - 写恶意的 HTML payload
// 第三步：诱导受害者
// - 发钓鱼邮件
// - 发社交媒体消息
// - 评论区放链接
// - 受害者点击
// 第四步：服务器返回恶意 HTML
// - 浏览器访问恶意 URL
// - TanStack Start 服务器函数处理
// - 把攻击者控制的 HTML 放到响应里
// - 返回给浏览器
// 第五步：恶意脚本执行
// - 浏览器收到响应
// - 在应用的源执行脚本
// - 窃取 Cookie、篡改页面
// 第六步：横向移动
// - 用窃取的 Cookie
// - 访问用户的其他数据
// - 进一步渗透4.4 影响范围
| 项目 | 详情 |
|---|---|
| CVE 编号 | CVE-2026-102989 |
| 漏洞类型 | 反射型 XSS |
| 影响产品 | TanStack Start |
| 影响版本 | 修复版本之前的所有版本 |
| 发现者 | TanStack 安全团队 |
| 利用条件 | 受害者点击恶意链接 |
| 用户交互 | 需要受害者点击 |
| CVSS 评分 | 9.3（严重） |
| 影响 | 会话劫持、数据窃取、页面篡改 |
| 部署平台 | Netlify、Vercel 等 |
五、修复方案分析
TanStack 在 2026 年 9 月修复了这个问题：
| 修复项 | 修复方式 |
|---|---|
| 响应转义 | 正确转义服务器函数响应内容 |
| 输入验证 | 严格验证服务器函数参数 |
| 安全渲染 | 用安全的方式渲染响应 |
| CSP 防护 | 建议配置 Content-Security-Policy |
5.1 前端框架安全设计原则
// 前端框架安全设计原则
// 1. 默认转义
// 所有用户输入默认转义
// 不要让开发者不小心写出 XSS
// 2. 服务器函数安全
// 服务器函数处理输入要验证
// 生成响应要转义
// 3. CSP 防护
// 配置 Content-Security-Policy
// 减少 XSS 的影响
// 4. Cookie 安全
// Cookie 设置 HttpOnly
// 即使有 XSS 也偷不到
// 5. 依赖更新
// 及时更新前端框架
// 不要用有漏洞的版本5.2 Web 应用安全最佳实践
// Web 应用安全检查清单
// 1. XSS 防护
// 所有用户输入都要转义
// 不要直接渲染用户输入
// 2. CSP 配置
// 配置 Content-Security-Policy
// 限制脚本执行源
// 3. Cookie 安全
// Cookie 设置 HttpOnly、Secure、SameSite
// 4. 依赖审计
// 定期审计前端依赖
// 及时更新有漏洞的包
// 5. 安全测试
// 定期做 XSS 安全测试
// 自动化扫描 + 手动测试六、SRC 审计启示录
6.1 前端应用安全审计清单
在 SRC 挖洞过程中，针对现代前端框架的审计清单：
| # | 检查项 | 检测方法 |
|---|---|---|
| 1 | 服务器函数有没有 XSS | 测试服务器函数参数有没有反射 XSS |
| 2 | 用户输入有没有转义 | 测试用户输入会不会原样显示在页面上 |
| 3 | CSP 配置严不严格 | 检查 CSP 头有没有限制脚本源 |
| 4 | Cookie 有没有 HttpOnly | 检查会话 Cookie 能不能被 JS 读取 |
| 5 | 前端依赖有没有漏洞 | 审计前端依赖包有没有已知漏洞 |
6.2 常见前端框架漏洞类型
// 常见的前端框架漏洞
// 1. 反射型 XSS
// 用户输入反射到页面上
// 执行恶意脚本
// 2. 存储型 XSS
// 用户输入存到服务器
// 其他用户看到时执行
// 3. 服务器函数注入
// 服务器函数处理输入不当
// 注入恶意内容
// 4. 原型链污染
// 前端库处理对象不当
// 污染原型链
// 5. 依赖漏洞
// 前端 npm 包有漏洞
// 被攻击利用6.3 暴露面分级
| 暴露级别 | 情况 | 风险 |
|---|---|---|
| 严重 | XSS 能窃取会话 Cookie | 账号被完全接管 |
| 高 | XSS 能篡改页面内容 | 钓鱼攻击、数据篡改 |
| 中 | 信息泄露辅助攻击 | 降低攻击成本 |
| 低 | 日志不完善 | 攻击难追踪 |
七、防护建议
- 及时更新：升级到 TanStack Start 最新修复版本
- 响应转义：所有服务器函数响应都要正确转义 HTML 特殊字符
- CSP 配置：配置严格的 Content-Security-Policy，限制脚本执行源
- Cookie 安全：会话 Cookie 设置 HttpOnly、Secure、SameSite
- 依赖审计：定期审计前端依赖，及时更新有漏洞的包
- 安全测试：定期做 XSS 安全测试，包括自动化扫描和手动测试
八、总结
CVE-2026-102989 是现代前端框架安全的一个经典案例：一个传统的反射型 XSS 漏洞，在新的全栈框架架构下找到了新的攻击面。随着越来越多的企业用 React、Next.js、TanStack Start 等现代前端框架，前端安全会成为一个越来越重要的领域。在 Web 安全领域，服务器函数是一个新的攻击面------传统的 XSS 是在渲染用户输入时出问题，而服务器函数是在处理请求响应时出问题。在 SRC 挖洞实践中，现代前端框架安全是一个新兴方向------一个服务器函数 XSS 漏洞，对企业来说价值极高。
