文章总结： ApacheSkyWalkingBoosterUI存在存储型XSS漏洞CVE-2026-85229，源于iframesandbox同时设置allow-scripts与allow-same-origin导致同源去沙箱，影响10.2.0至10.4.0版本。官方无单独补丁，需迁移至HorizonUI1.0.0根治，并建议通过CSP策略和网络隔离临时缓解。 综合评分： 88 文章分类： 漏洞分析,WEB安全,安全建设

---

SkyWalking 仪表盘存储型XSS：iframe sandbox 同源去沙箱漏洞(CVE-2026-85229)

撅人

2026年9月6日 00:00 广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

🔴 导语 · 修复不完整的代价

使用 Apache SkyWalking Booster UI 的运维团队请注意！⚠️

Apache SkyWalking 是主流的开源 APM 系统，它的仪表盘页面由内置 Web 控制台 Booster UI 渲染，仪表盘配置以 UI 模板形式集中存储在 OAP 服务端，由所有控制台用户共享。这意味着——一个用户注入的恶意配置，所有打开该仪表盘的用户都会中招。

这个漏洞是 CVE-2025-54057 修复不完整的残留风险。之前修复了 URL 校验的部分问题，但 iframe sandbox 同时保留了 allow-scripts 和 allow-same-origin 两个权限——当嵌入内容与控制台同源时，sandbox 限制被完全去除，脚本可以自由执行。

能够向 UI 模板持久化恶意配置的攻击者，可以让浏览该仪表盘的任意用户在浏览器中执行恶意脚本——这是典型的存储型 XSS，危害远大于反射型 XSS。

修复方式比较特殊——Apache 没有为 Booster UI 单独发布补丁，而是通过迁移到全新的 Horizon UI 1.0.0（2026-08-28 发布）来完成修复：新版移除了外部 URL iframe 挂件，并强制 CSP 策略。如果你还在用 Booster UI 10.2.0 ~ 10.4.0，今天就要计划迁移到 Horizon UI。

---

🔍 漏洞速览

| | | | — | — | | 漏洞编号 | CVE-2026-85229 | | 漏洞类型 | 存储型 XSS（CWE-79）· iframe sandbox 绕过 | | CVSS 评级 | Medium （CVSS 5.4 · 低攻击复杂度） | | 影响产品 | Apache SkyWalking Booster UI（apache/skywalking-booster-ui） | | 攻击前提 | 攻击者可向 UI 模板持久化恶意配置（需要模板编辑权限） | | 攻击方式 | 恶意 URL 持久化 → iframe sandbox 同源去沙箱 → 任意用户浏览器执行脚本 | | 受影响版本 | SkyWalking 10.2.0 ~ 10.4.0（Booster UI） | | 修复版本 | 迁移至 Horizon UI 1.0.0（2026-08-28 发布）· 无 Booster UI 单独补丁 | | 核心风险 | 模板共享 → 存储型 XSS → 会话劫持 / 凭证窃取 / 横向移动 | | 相关 CVE | CVE-2025-54057 （前序漏洞 · 本漏洞为其修复不完整的残留风险） |

---

💥 核心危害：iframe sandbox 同源去沙箱攻击链

这个漏洞的杀伤力在于”存储型”——恶意配置一旦持久化，所有浏览仪表盘的用户都会中招，不需要点击任何链接。

攻击链拆解

① 攻击者获得 UI 模板编辑权限，向仪表盘配置中注入恶意挂件 URL

② 恶意 URL 通过 validateAndSanitizeUrl 校验（仅浏览器侧执行，放行 http/https）

③ URL 被渲染进页面 iframe，sandbox 设置了 allow-scripts + allow-same-origin

④ 被嵌入内容与控制台同源 → sandbox 限制被完全去除

⑤ 恶意脚本在控制台源内自由执行 → 会话劫持 / API 调用 / 凭证窃取 💥

为什么”同源 + 双权限”是致命组合？

iframe sandbox 的 allow-scripts 允许嵌入内容执行脚本，allow-same-origin 允许嵌入内容保持其原始源（不被视为 null origin）。这两个权限单独使用都是相对安全的——但组合在一起就是沙箱形同虚设。

// Booster UI 中的 iframe 渲染（简化）

// 如果 src 与控制台同源：

// → iframe 内脚本可访问 parent.document

// → 可读取 cookie / session token

// → 可调用 SkyWalking API / 窃取数据

// → sandbox 形同虚设！

W3C 规范明确警告：当 sandbox 同时设置 allow-scripts 和 allow-same-origin 时，嵌入内容可以去除自身的 sandbox 属性——等于沙箱完全失效。Booster UI 恰好同时设置了这两个权限，再加上同源场景，sandbox 的保护被从内部瓦解。

💬 关于攻击前提的说明： 攻击者需要能向 UI 模板持久化恶意配置——这通常意味着拥有仪表盘编辑权限。在多团队共享 SkyWalking 的场景中，非管理员用户也可能有模板编辑权限。CVSS 5.4 Medium 反映了这个前提——不是任意匿名攻击者可利用，但一旦利用成功，影响面是所有浏览该仪表盘的用户。

---

🧠 漏洞原理（人话版）

理解这个漏洞需要搞清三层：仪表盘模板共享机制、URL 校验的局限性、iframe sandbox 双权限的致命组合。

第 1 层：仪表盘模板共享 = 存储型 XSS 的温床

SkyWalking 的仪表盘配置不是每个用户独立的——它以 UI 模板形式集中存储在 OAP 服务端，由所有控制台用户共享。这意味着：

• 攻击者注入恶意配置 → 持久化在服务端

• 任何用户打开该仪表盘 → 自动加载恶意配置 → 自动触发

• 不需要用户点击任何链接 → 零交互

这就是存储型 XSS 比反射型 XSS 危险得多的原因——一次注入，持续生效，命中所有用户。

第 2 层：validateAndSanitizeUrl 的局限性

Booster UI 有一个 URL 校验函数 validateAndSanitizeUrl，它的逻辑是：

• 放行 http/https 协议的 URL ✅

• 把相对路径改写为同源地址 ✅

问题在于——这个校验只在浏览器侧执行。服务端存储模板配置时不做校验，所以攻击者可以直接通过 API 写入恶意 URL，绕过浏览器侧的校验函数。即使不绕过，http/https 的 URL 本身也是被放行的——攻击者可以用一个看似正常的 https URL 指向恶意页面。

第 3 层：iframe sandbox 双权限 → 同源去沙箱

这是漏洞的核心。iframe 的 sandbox 属性同时设置了 allow-scripts（允许执行脚本）和 allow-same-origin（保持原始源）。

当 iframe 的 src 与控制台同源时（比如通过相对路径或同源 URL），iframe 内的脚本可以：

• 访问 parent.document → 读取控制台 DOM

• 读取 cookie / localStorage 中的 session token

• 调用 SkyWalking 后端 API（携带同源 cookie）

• 甚至移除自身的 sandbox 属性 → 完全去沙箱化

这就是 W3C 规范警告的”allow-scripts + allow-same-origin = sandbox 无效”——两个权限组合后，嵌入内容可以从内部瓦解沙箱保护。

CVE-2025-54057 修复历史

CVE-2025-54057 是前序漏洞，修复了 URL 校验的部分问题——主要是处理了重复 range 导致的内存放大。但修复没有触及 iframe sandbox 双权限这个根因。validateAndSanitizeUrl 虽然加了校验，但 sandbox 的 allow-scripts + allow-same-origin 组合依然保留。CVE-2026-85229 就是这个未修干净的残留风险——堵了 URL 校验的口子，但 sandbox 的后门还开着。

✅ 修复方案做了什么？

这次修复比较特殊——Apache 没有为 Booster UI 单独发布补丁版本，而是通过迁移到全新的 Horizon UI 1.0.0（2026-08-28 发布）来完成修复：

1️⃣ 移除外部 URL iframe 挂件——不再支持在仪表盘中嵌入外部 URL 的 iframe，从根本上消除 iframe sandbox 攻击面

2️⃣ 强制 CSP 策略——每个响应都设置 script-src 'self'（不含 unsafe-inline、unsafe-eval），frame-src 'none'，object-src 'none'

3️⃣ 纵深防御——即使注入了事件属性或存储的脚本链接，CSP 也会阻止其执行，切断存储型 XSS 链路

---

⏱️ 3 秒自查

❌ 受影响版本（红区）

• SkyWalking 10.2.0 ~ 10.4.0（使用 Booster UI）

⚠️ 仅影响使用 Booster UI 的部署；已迁移到 Horizon UI 的不受影响

✅ 安全版本（绿区）

• 迁移至 Horizon UI 1.0.0（2026-08-28 发布）

自查命令：

1. 检查 SkyWalking 版本

在 SkyWalking UI 右下角或关于页面查看版本号

或检查 OAP 服务端启动日志：

grep -i “version” logs/skywalking-oap-server.log | head -5

版本 10.2.0 ~ 10.4.0 → 中招！

已迁移 Horizon UI → 安全

2. 判断 UI 类型（Booster UI vs Horizon UI）

Booster UI: URL 中含 /booster-ui 或页面标题含 “Booster”

Horizon UI: URL 中含 /horizon 或页面标题含 “Horizon”

检查 UI 静态资源目录：

ls webapp/ | grep -iE “booster|horizon”

有 booster-ui → 使用 Booster UI，需迁移

有 horizon → 已迁移，安全

3. 检查仪表盘配置中是否有可疑 URL

通过 SkyWalking GraphQL API 查询仪表盘模板：

curl -s http://localhost:12800/graphql \

-H “Content-Type: application/json” \

-d ‘{“query”:”{ dashboards: listDashboards { name configuration } }”}’ \

| jq ‘.data.dashboards[].configuration’ | grep -i “iframe|url|src”

有可疑外部 URL → 可能已被注入恶意配置

---

🛡️ 修复方案

✅ 方案一：迁移到 Horizon UI 1.0.0（唯一根治方案）

Apache 没有为 Booster UI 发布单独补丁，根治方式是迁移到全新的 Horizon UI：

1. 下载 Horizon UI 1.0.0

https://github.com/apache/skywalking/releases

2. 替换 webapp 目录

cp -r horizon-ui/dist/* webapp/

3. 重启 OAP 服务

bin/oap-service.sh restart

4. 验证 CSP 头

curl -sI http://localhost:8080/ | grep -i content-security-policy

应返回 script-src ‘self’; frame-src ‘none’; object-src ‘none’

⚠️ 迁移后检查仪表盘配置兼容性——Horizon UI 移除了外部 URL iframe 挂件，如有使用该功能的仪表盘需要调整配置。

⚠️ 方案二：网络层隔离（临时缓解）

无法立即迁移时，通过网络层降低风险：

• 限制 SkyWalking UI 访问——仅允许可信网络访问，减少暴露面

• 限制仪表盘模板编辑权限——仅管理员可编辑，降低注入风险

• 在反向代理（nginx）层设置 CSP 头作为额外防护：

nginx 配置示例

add_header Content-Security-Policy \

  “script-src ‘self’; frame-src ‘none’; object-src ‘none'”;

⚠️ 注意：nginx 层 CSP 只对通过 nginx 访问的请求生效，不替代 Horizon UI 的原生 CSP。根治仍需迁移。

🕵️ 排查清单

☐ 确认 SkyWalking 版本是否在 10.2.0 ~ 10.4.0 范围

☐ 确认使用的是 Booster UI 还是 Horizon UI

☐ 检查仪表盘配置中是否有可疑的外部 URL 或 iframe 挂件

☐ 检查模板编辑权限——是否有非管理员拥有编辑权限

☐ 检查 OAP 服务端访问日志——是否有非预期的模板配置写入

☐ 如确认被利用——检查用户会话日志、API 调用日志、轮换凭证

☐ 迁移后验证：CSP 头已生效、iframe 挂件已移除

---

⚠️ 安全提醒

这个漏洞是一个教科书级的”iframe sandbox 双权限 + 同源去沙箱“安全误区案例，也暴露了 CVE 修复完整性的常见陷阱。

关于 iframe sandbox 双权限的教训： sandbox 属性是 HTML5 提供的客户端隔离机制，很多开发者把它当作”万能沙箱”——加了 sandbox 就安全了。但 W3C 规范明确警告：同时设置 allow-scripts 和 allow-same-origin 等于没有沙箱。因为 allow-same-origin 让嵌入内容保持原始源，allow-scripts 让它可以执行脚本——两个权限组合后，嵌入内容可以通过 JavaScript 移除自身的 sandbox 属性，从内部瓦解沙箱。这不是 SkyWalking 独有的问题——任何同时设置这两个权限的 iframe 都存在同样的风险。

关于 CVE 修复完整性的教训： CVE-2025-54057 修复了 URL 校验的部分问题，但没有触及 iframe sandbox 双权限这个根因。validateAndSanitizeUrl 加了校验，但 sandbox 的 allow-scripts + allow-same-origin 组合依然保留。结果就是——堵了 URL 校验的口子，sandbox 的后门还开着，攻击者换条路径照样能 XSS。这提醒我们：修复漏洞时要找根因，而不是只堵当前的攻击路径。URL 校验是治标，移除 iframe 或限制 sandbox 权限才是治本。

关于修复方式的特殊性： Apache 这次没有为 Booster UI 单独发布补丁，而是通过迁移到全新的 Horizon UI 来修复。这说明 Booster UI 的架构问题（iframe 挂件 + 客户端校验 + sandbox 双权限）已经无法通过打补丁修复——必须从架构层面重新设计。Horizon UI 的做法是：移除外部 URL iframe 挂件（消除攻击面）+ 强制 CSP（纵深防御）。这是”消除攻击面 + 纵深防御”的正确组合——即使有新的注入路径，CSP 也能兜底。

如果你在开发 Web 应用中使用 iframe sandbox，记住这条原则：永远不要同时设置 allow-scripts 和 allow-same-origin。如果业务确实需要执行脚本，就不要用 allow-same-origin；如果需要同源访问，就不要用 allow-scripts。两个都设等于没有沙箱。

转发给你们运维、APM 团队和前端安全团队——用 SkyWalking Booster UI 的，尽快迁移到 Horizon UI。

📎 官方参考

• Apache 安全公告：lists.apache.org/thread/oswo0kxr7g2jgdoz3wd923nslo36jsv8

本文仅供安全研究与防御参考，修复请以 Apache SkyWalking 官方公告为准。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：撅人 《SkyWalking 仪表盘存储型XSS：iframe sandbox 同源去沙箱漏洞(CVE-2026-85229)》