传统漏洞的演变

lally.2026-01-09 10:28

文章目录

前言

刚入门安全的web朋友可能会遇到一个问题，就是学习xss，sql注入这些传统漏洞到底有什么意义，比如sql注入，我们直觉上一个参数化查询就可以彻底杀死，这样的漏洞在当下的真实环境里真的还存在吗，如果存在他是什么样的，跟网上看到的多如牛毛的传统漏洞分析有什么区别，有了这个想法就去寻找答案，发现目前没有人愿意花精力来回答，于是花了点时间ai了一篇关于2025年cve的文章，作为对这个问题的解答

关于sql注入

在 CVE-2025-21628（Chatwoot） 中，问题出在会话/联系人筛选接口对 query_operator 参数没有做严格约束，后端直接把用户给的"运算符"拼进 ORM/SQL 过滤条件里，导致攻击者可以构造恒真条件或追加任意子句实现 SQL 注入；因为这是一个"看起来只是过滤条件"的业务参数，且需要已登录账号，很多 WAF 对这类已认证 API 放行较宽，又未对 query_operator 做语义级解析，所以很容易绕过基于关键字/正则的浅层规则。GitHub+1
CVE-2025-1094（PostgreSQL psql） 则更典型地说明了"WAF 完全管不着"的一类：漏洞来源于 libpq/psql 在处理无效 UTF-8 字节串时的转义逻辑错误，攻击者利用特殊多字节前缀（例如以 0xC0 开头的非法 UTF-8）骗过转义函数，再配合 psql 的 ! 元命令将 SQL 注入链升级为本地命令执行；整个链条发生在数据库客户端/后端通道上，与 HTTP 边界无关，再强的 Web WAF 也拦不住，只能靠端点加固和版本升级来解决。SOC Prime+1
CVE-2025-49002（DataEase） 属于"补丁绕过"：前一洞（CVE-2025-32966）修补思路是禁止 H2 数据库的 INIT / RUNSCRIPT 参数以阻止通过连接字符串执行任意 SQL/命令，但实现时按大小写敏感做了字符串黑名单，攻击者只要用大小写变体（如全小写、混合大小写）就能重新启用 H2 的初始化脚本能力，通过 SQL 注入构造恶意连接串达到远程代码执行；这既绕过了产品自己的"虚拟补丁"，也证明任何 WAF / 网关如果只匹配固定大小写关键字，同样会被轻松躲开。nvd.nist.gov+2GitHub+2
CVE-2025-57870（Esri ArcGIS Server） 是 ArcGIS Feature Service 某个操作中的 SQL 注入，攻击点藏在空间/属性查询参数里，攻击者可以在特定 POST/JSON 请求体字段中塞入恶意表达式，让后台拼接出任意 SQL 对企业地理数据库执行查询或修改；这里一方面是"完全未授权 + 业务 API 专用格式"，另一方面 payload 和正常查询语句非常相似，如果 WAF 不理解 ArcGIS 的 Feature Service 协议、只做通用关键字匹配，就很难在不产生巨量误报的前提下准确拦截。nvd.nist.gov+2jvndb.jvn.jp+2
CVE-2025-57819（FreePBX） 则是 AUTHZ 绕过叠加 SQL 注入的典型组合链：未认证攻击者可以先利用认证绕过缺陷进入管理平面，再通过 /admin/ajax.php 中未正确净化的 brand 参数注入 SQL，将恶意任务写入 cron_jobs 表，从而定时生成 Base64 编码的 PHP WebShell 或执行任意命令，实现持久化 RCE；这一链条对 WAF 的绕过点在于：请求看上去只是访问后台 AJAX 接口、brand 字段本身是业务字段，而且注入语句可以非常短小、嵌入在合法 SQL 模板中（例如只往某个字段追加一小段 payload），如果没有针对 /admin/ajax.php + brand 的精细规则，依赖通用"UNION SELECT / OR 1=1" 这类签名往往检测不到，因此现在已经有专门的 AppSec 规则集只盯这个端点和参数来做"虚拟补丁"。app.crowdsec.net+4nvd.nist.gov+4IoT OT Security News+4

2025 年的 SQL 注入并没有"消失"，而是明显向"复杂业务参数 + 客户端/中间件链路 + 补丁绕过/大小写绕过 + 数据库自带脚本能力"集中，WAF 如果停留在 URL 级关键字匹配，基本只能当心理安慰。

老一代 WAF 的防御模型：

以 URL 关键字匹配为主，主要针对经典 id=1 and 1=1 样式的注入；

新一代高危 SQLi：

  • 更偏向「复杂业务 API + 内部组件链」；
  • 利用了编码、数据库特性（大小写不敏感、特殊参数）、多字节字符集等细节；
  • 很多攻击压根不在单纯 URL 这一层出现，天然绕过"只盯 URL 的 WAF"。

为什么参数化查询无效

CVE-2025-21628参数化（prepared statement）只能绑定"数据"，不能绑定"代码结构"：

  • 你可以写 WHERE status = ?，把 ? 换成用户输入；
  • 但不能写 WHERE cond1 ? cond2，让 ? 去当 AND / OR，DB 根本不认。

也就是说，这个洞是因为把"操作符/片段"交给用户控制，这东西是没法 parameterize 的。

参数化查询是现代防 SQL 注入的必要条件 ，但在 2025 年这批高危 CVE 里已经明显不再是充分条件：

关于xss

先说结论版一句话：2025 年的高危 XSS 也没有"消失"，而是从简单表单注入，转移到了「重前端业务、日志/调试面板、可视化引擎、DevSecOps 平台、网络准入/管理平面」上，很多攻击点根本不在传统 WAF 视野里。

CVE-2025-49553（Adobe Connect, DOM XSS / Critical）

Adobe Connect 12.9 及之前版本存在 DOM 型 XSS：前端在 DOM 中拼接/处理不可信数据时没有正确转义，攻击者可以通过特制页面（或 URL）让受害者浏览，进而在浏览器中执行任意脚本，官方评为 CVSS 9.3 的 Critical，明确提到可实现会话接管、提高机密性和完整性影响等级。国家漏洞数据库+2安全下一步+2

这里的关键点在于：漏洞完全发生在客户端 DOM 逻辑里 ，HTTP 请求看起来只是"正常参数 + 一点编码过的内容"，WAF 即使做了基本的 <script>/事件属性匹配，也很难在不理解前端 JS 的前提下判断"这段数据后续会被 innerHTML / document.write / eval-like 使用"。加上 Connect 常被部署在内网协作环境，前面还可能有反向代理或 VPN 网关，很多团队实际上不会在这些内部协作系统前再专门挂一层强规则的 WAF，这类 DOM XSS 就天然处于防御盲区。

CVE-2025-0183（binary-husky/gpt_academic, Stored XSS in Latex Proof-Reading 模块）

开源项目 gpt_academic 的 Latex Proof-Reading 模块在生成 debug_log.html 调试报告时，会把用户提交的 Latex 内容原样写入 HTML，而没有对其中的 < / > / 事件属性等做输出编码，导致攻击者可以通过构造恶意 Latex，把脚本注入到调试页面中；当管理员或开发者打开这个 debug_log.html 进行故障排查时，脚本被执行，实现典型的 stored XSS。国家漏洞数据库

这类 XSS 有几个典型的"现代特征"：

  • 触发点在调试/日志面板，而不是用户可见的"正常业务页面"，平时安全测试和 WAF 规则都很少关注这些路径；
  • debug_log.html 很可能是离线文件（本地打开、通过文件协议或 IDE 内嵌浏览器打开），这条链压根经过不了 Web WAF；
  • 同时它与 LLM 工具高度耦合------调试页面里往往还包含 prompt、模型输出、token 日志等敏感信息，一旦 XSS 成功，不只是"弹个窗"，更容易变成针对攻防研究者/管理员的钓鱼与信息窃取载体。

CVE-2025-9222 / CVE-2025-13761（GitLab, Markdown 占位符 + Web IDE XSS）

GitLab 2026-01-07 的补丁中修了两条高危 XSS：

  • CVE-2025-9222 ：GitLab Flavored Markdown 的"占位符"处理存在 stored XSS，认证用户可以在 Issue/合并请求等 Markdown 内容中构造特殊占位符，让渲染管线把恶意内容当作 HTML/脚本输出，CVSS 8.7（S:C / C:H / I:H）。about.gitlab.com
  • CVE-2025-13761 ：Web IDE 中的 XSS，可让未认证攻击者通过构造恶意页面，引导已登录 GitLab 的开发者访问，从而在其浏览器环境下执行脚本，CVSS 8.0。about.gitlab.com

这类 XSS 对传统 WAF 的"压制力"非常有限：

  • Markdown 占位符是在服务端深层渲染（GFM → HTML）时才被解释，HTTP 请求里看起来只是普通文本 ，只有理解 GitLab 自己的 Markdown 方言和占位符语义，才能知道哪些组合会变成 <script>/危险属性；
  • Web IDE XSS 则跨站触发：恶意页面不一定托管在 GitLab 上，甚至可以是完全独立的域，WAF 守在 GitLab 前面时根本看不到这一步交互；
  • 更微妙的是，这两类 XSS 的"受害者"往往不是普通终端用户，而是开发者 / DevOps / 安全团队本身，一旦被打，后续可以借助 GitLab 的 Token、CI/CD、Runner 去做更深的供应链打击。

CVE-2025-68385（Kibana Vega, 补丁绕过型 Stored XSS）

这是 Kibana 中 Vega 可视化引擎的一条高危 XSS：早前 Vega 曾经修过 XSS，增加了一些过滤/限制，但 2025 年又披露了一条新的漏洞------攻击者仍可通过 Vega 相关配置，将恶意脚本嵌入到最终渲染给浏览器的内容中，从而实现 stored XSS。官方描述里明确指出：该漏洞绕过了之前的 Vega XSS 缓解措施 。红帽缺陷跟踪系统

这和你前面提到的 DataEase/H2 SQL 注入绕过有明显类比关系：

  • 防御方（这里是 Kibana/Vega）在上一轮补丁中基于"已知 Payload 形态"做了一套过滤；
  • 攻击者在语法/配置空间里找到新的表达方式，复用 Vega 的合法特性，在"看起来合法"的图表配置中继续注入脚本；
  • 很多"虚拟补丁"/WAF 规则是按照旧版 PoC / 关键词写的（比如检查某些字段里是否出现 <script>、javascript:、特定 Vega 字段组合），于是一次性被绕过------这说明单纯依赖静态规则，而不做系统性"语义约束"（例如对 Vega 允许的表达式、信任边界做白名单化），很难跟得上这种补丁博弈。

CVE-2025-37122（HPE Aruba ClearPass, NAC 管理面的未认证 Reflected XSS）

这条漏洞发生在 HPE Aruba ClearPass Policy Manager 等网络准入控制（NAC）产品的 Web 管理界面：未认证的远程攻击者通过构造特定 URL，即可在管理员访问时触发反射型 XSS，在该管理界面的域上下文中执行任意 JavaScript。CNA 给出的 CVSS 3.1 评分为 6.1（AV:N / PR:N / UI:R / S:C / C:L / I:L / A:N）。国家漏洞数据库+1

这种漏洞的"危险性"和 CVSS 分数不完全成正比，原因在于：

  • ClearPass 属于典型的网络入口/访问控制中枢------一旦通过 XSS 劫持管理员会话，就有机会进一步下发错误策略、导出设备凭据甚至植入恶意 RADIUS/802.1X 配置；
  • 管理界面通常部署在内网，前面顶多是反向代理，很少会再放一台"严格审计内部请求"的 WAF，大家默认"内网管理员自己不会攻击自己"；
  • 实际上这条 XSS 是一个典型的"钓管理员"场景：攻击者通过邮件/聊天下发带有管理 URL 的恶意链接，管理员在浏览器中点开就中招，这条链路和你在 SQLi 那部分提到的"psql/客户端侧注入"类似------攻击面不再是开放的公网 Web 业务，而是"人机耦合"的运维平面。

XSS 的整体趋势

2025 年的 XSS 并没有"消失"，而是明显向「复杂前端框架 + 内部可视化/控制面 + 日志/调试 UI + 补丁绕过」集中：

  • 从攻击面看：
    • DOM XSS / SPA XSS（Adobe Connect 等）更多出现在重前端协作/会议系统里，核心逻辑在浏览器端，HTTP 流量看上去就是"正常参数" ；国家漏洞数据库+1
    • 日志/调试视图 XSS（gpt_academic 的 debug_log.html）则藏在"只给管理员看"的 HTML 报告中，既不在普通用户路径，也不一定走 Web 服务器 ；国家漏洞数据库
    • DevOps/AI 平台（GitLab Markdown 占位符 + Web IDE、AI 辅助功能周边）成为新的富攻击面，XSS 可以直接打到 CI/CD、Runner、Token 等"供应链中枢"；about.gitlab.com
    • 运维/安全管理面（Kibana、ClearPass、Cisco UICM、QRadar 等）仍然大量爆出 XSS，且往往位于**"内网 + 管理员 + 高价值"**的组合位置。国家漏洞数据库+1
  • 从技术特征看：
    • 大量 XSS 不再是简单的"把用户输入直接拼进 HTML 字符串"，而是混在模板语法、Markdown 占位符、可视化 DSL（Vega）、Latex 等**"高级内容格式"**里，需要理解这些格式的语义才能做有效检测；about.gitlab.com+1
    • 出现更多"补丁绕过型"XSS：厂商先基于旧 PoC 做了一轮黑名单/过滤，随后研究者通过改变编码方式、利用新的字段/语法重新打通（Kibana/Vega 就是典型）。红帽缺陷跟踪系统
    • 攻击目标越来越偏向"高权限少数人"（管理员、DevOps、研究员），而不是传统 Web 站点里所有访客，这也意味着传统基于流量统计/告警量的检测思路更难奏效。

老一代 XSS 防御模型（很多传统 WAF / 旧代码库的思路）：

  • 把 XSS 理解为"在 HTML 里注入 <script> 或事件属性（onerror 等）"；
  • WAF 主要做 URL / 表单字段中的关键字匹配，偶尔附带一点正则规则；
  • 服务器端模板里做简单的 strip_tags / 黑名单过滤；
  • 很少区分输出上下文（HTML 文本、属性、URL、JS 字符串、JSON 等），更谈不上对 DOM/前端框架的语义理解。

新一代高危 XSS 的现实：

  • 攻击载体混在 Markdown、Latex、JSON、可视化 DSL、日志文本 等复杂格式里，需要做深度解析才能判断其中哪些片段最终会进入 HTML/DOM；
  • 很多攻击链条压根不经过"公网业务入口" ：
  • 一部分 XSS 是**"补丁/规则绕过进化版"**，专门针对之前的防护逻辑（如 Vega 旧版缓解）做变形，而不是"从 0 到 1"的新洞。红帽缺陷跟踪系统

结果就是：如果防御还停留在"URL 级关键字匹配 + 简单 strip_tags"，它的价值更多是审计合规和心理安慰，而不是实质性防护。

为什么"只靠 WAF / 简单过滤 + 一点 CSP"不够？

统一的输出编码 + 合理 CSP，是防 XSS 的必要条件，但在 2025 这批高危 XSS 里远远不够成为充分条件。

具体可以类比拆一下：

  1. 输出编码只能解决"数据 → HTML"的那一段
    • 你可以保证所有用户输入经过 htmlEscape 后再放进模板，但DOM XSS 常常发生在后续 JS 操作中（例如把原本安全的文本再 innerHTML 回 DOM，或者从 data-* 属性里取出再拼成 HTML），这一步 WAF / 后端编码是看不到的。OffSeq Threat Radar
  2. CSP 只是在浏览器执行阶段"兜底"，挡不住所有现代用法
    • 很多企业应用为了兼容旧代码或第三方插件，CSP 仍然会放行 unsafe-inline、广泛的 script-src 域名等，导致 XSS 有足够活动空间；
    • 像 GitLab Web IDE 这种场景，XSS 利用的就是"在既有 JS 环境中调用已有 API"，即便不能加载外部脚本，也足够完成 CSRF、数据窃取等行为。about.gitlab.com
  3. 对复杂内容格式/DSL 不做"语义级约束"，等于给攻击者留了巨大的攻击面
    • Vega、Markdown 占位符、Latex 这些都是"小语言"，只做字符串黑名单远远不够，需要考虑"白名单化语法 + 禁用脚本能力 + 上下文隔离"，否则就会一步步走向像 CVE-2025-68385 那样的补丁绕过。红帽缺陷跟踪系统+2about.gitlab.com+2
  4. 内网/管理面的"信任假设"在 XSS 时代已经不成立
    • 管理员也是人，也会点钓鱼链接；ClearPass、Cisco UICM 这种管理接口一旦被 XSS 打穿，后果远比普通前端页面严重，但这些界面往往既缺 WAF，又缺系统性前端安全审计 。国家漏洞数据库+1

关于文件上传

CVE-2025-0520（ShowDoc）------典型"小而全"的自建工具 RCE

ShowDoc 是很多团队自建的接口文档 / 说明书平台，默认就带上传功能。

CVE-2025-0520 属于经典的 扩展名校验不足 ：上传接口只做了"文件扩展名"检查，但实现不严谨，导致可以上传带有 PHP 代码的文件并被 Web 服务器当作脚本执行，从而 RCE。肯尼亚教育网络

WAF 绕过点：

  • ShowDoc 通常部署在内网或运维自搭环境，前面根本没有 WAF，更多靠"没人知道地址"；
  • 就算挂了 WAF，它只看见一个正常的 multipart/form-data 上传；真正的问题是后台怎样判扩展名、怎么把文件落到可执行目录，这些业务细节 WAF 完全不可见。

CVE-2025-34085（WordPress Simple File List）------多步骤逻辑导致的"后置执行"绕过

Simple File List 是一个帮 WordPress 站点做文件列表 / 上传的小插件。

CVE-2025-34085 的关键不是"上传时没校验"，而是 上传 + 重命名是分两步实现的：

  • 第一步：ee-upload-engine.php 限制上传扩展名，看起来只能传 .png 等安全类型；
  • 第二步：ee-file-engine.php 提供"重命名"功能，但重命名时不再检查扩展名 。
    攻击者先上传一个伪装成 .png 的 PHP webshell，再调用重命名接口改成 .php，就绕过了第一步的白名单，最终能在服务器上直接执行。cvedetails.com

WAF 绕过点：

  • WAF 看单个请求时，只看到：
    1）一次"正常的图片上传"；
    2）一次"重命名文件"的 API 调用，没有任何 SQL / eval 关键字；
  • 这类 跨请求链路（upload → rename → execute）如果没有对插件语义做精细建模，很难靠通用规则拦下来。

CVE-2025-52691（SmarterMail）------"任意路径"上传的基础设施级 RCE

SmarterMail 是企业常用的邮件服务器软件。

CVE-2025-52691 被评为最高危，原因是：未认证攻击者可以将任意文件上传到邮件服务器上的任意路径 ，然后通过 Web 服务器或其他服务加载这些文件，实现 RCE。NVD 的说明就直接写了 attackers can upload arbitrary files to any location on the mail server, potentially enabling remote code execution。TechRadar

WAF 绕过点：

  • 很多组织把邮件系统直接暴露在公网（HTTPS + 自带认证），并不会再叠一层 Web WAF；
  • 就算有 WAF，问题在于：
    • 危险的是"路径可控 + 文件类型可控"，而不是上传内容里的某个特征字符串；
    • 请求本身可以长得非常"干净"，比如 JSON/表单里只是一个 path=/var/www/.../shell.aspx。

CVE-2025-20188（Cisco IOS XE WLC）------硬编码 JWT + AP 镜像上传端点

在 Cisco IOS XE Wireless Controller（无线控制器）里，有两个用于上传 AP 镜像 / 频谱记录的端点：/aparchive/upload 与 /ap_spec_rec/upload/。

Horizon3 的分析指出，这些端点通过 Lua 脚本 ewlc_jwt_verify.lua + ewlc_jwt_upload_files.lua 做访问控制和文件保存 ，验证 JWT 的密钥从 /tmp/nginx_jwt_key 读取；如果文件不存在，就用固定字符串 "notfound" 当密钥，这相当于硬编码了一个通用 JWT secret。攻击者只要用这个已知 secret 签出合法 JWT，就能在无需认证的情况下上传任意文件到 /bootflash/ 或 /harddisk/ap_spectral_recording/ 等目录。Horizon3.ai

WAF 绕过点：

  • 这些上传端点挂在设备管理面上，往往在 专用管理网段，产品本身又内置 Nginx / OpenResty，大多数环境不会额外加 WAF；
  • Nginx 配置里已经加了 X-Content-Type-Options: nosniff 等头，但真正的问题是 认证层（JWT 验证）和目标路径都被逻辑错误"掏空"，WAF 即使在，也很难识别"这是一个带伪造 JWT 的合法 POST 文件上传"。

CVE-2025-8450（Fortra FileCatalyst）------"安全文件传输"平台自身的未认证上传

FileCatalyst 是 Fortra 的托管文件传输（MFT）产品，用来做大文件安全传输。

FI-2025-010 对应的 CVE-2025-8450 描述为：在 Workflow 组件的"订单表单页面"上存在 Improper Access Control ，允许未认证用户通过该表单上传任意文件。官方给出的 CWE 是 CWE-434（危险类型文件不受限制上传）+ CWE-306（缺少认证保护关键功能）。fortra.com

WAF 绕过点：

  • 对外宣传是"安全文件传输网关"，很多组织反而信任它是安全边界的一部分，不会再在前面叠安全设备；
  • 攻击流量长得就像普通客户提交订单 / 表单，Content-Type 合法、扩展名可以伪装，WAF 很难在不大量误报的前提下对某个"订单上传"接口做极端严格的规则。

顺带：CVE-2025-20282（Cisco ISE）与 CVE-2025-42910（SAP SRM）

  • CVE-2025-20282（Cisco ISE） ：ZDI 报告 ISE 的 handleFilesUpload 方法缺少严格校验，导致未认证任意文件上传，可在 iseadminportal 用户上下文执行任意代码。zerodayinitiative.com
  • CVE-2025-42910（SAP Supplier Relationship Management） ：被 TechRadar 点名为"unrestricted file upload"，作为一组 SAP NetWeaver / SRM 高危漏洞的一部分，攻击面直接在采购/供应链业务模块。TechRadar

这两类都说明：关键后台系统里的上传接口一旦缺少认证或类型控制，后果基本都是"未授权 RCE"。

整体趋势

对比一下上面这批 CVE，可以看到文件上传的几个明显趋势：

  1. 从"博客头像上传" → "基础设施 / 供应链上传"

    • WordPress 插件仍然是主战场之一（Simple File List、King Addons 等都有未认证任意上传）。TechRadar+1
    • 但更多高分 CVE 出现在 邮件服务器、无线控制器、身份认证网关、SAP 采购系统、MFT 平台 等"企业基础设施"组件上（SmarterMail、Cisco WLC、Cisco ISE、FileCatalyst、SAP SRM）。zerodayinitiative.com+4TechRadar+4Horizon3.ai+4

  2. 访问控制缺失比"文件内容本身"更致命

    很多 CVE 的核心是：

    • 上传接口本来就应该"强认证 + 授权 "，结果却变成 未认证可调 （CVE-2025-52691、CVE-2025-8450、CVE-2025-20282、CVE-2025-34085 等）；cvedetails.com+3TechRadar+3fortra.com+3
    • 甚至连"上传到哪里"都可由用户指定或间接控制，使得攻击者可以直达执行路径。

  3. 多步骤 / 多接口组合，让"单点扫描"失效

    • WordPress Simple File List：上传时过滤，重命名时不过滤；
    • 典型业务系统：
      • 第一个接口负责上传原始"材料"；
      • 后续接口负责"转换格式 / 解压 / 打包 / 下发配置"，真正的执行点在第二步。

    简单对某一个 /upload 路径做规则已经不够，你得理解整个业务流。

  4. WAF 覆盖不到的面越来越多

    • 邮件服务器、无线控制器、身份认证网关、MFT 平台等常常自带 HTTPS 入口，部门会觉得"这就是一个封闭的专用系统"，不会另外加 WAF；
    • 即便有 WAF，上传数据可以是二进制、压缩包、图片伪装，很难在网关层做精细解析。

老一代模型（很多框架/项目仍停在这一步）：

  1. 按扩展名白名单：endswith( .jpg / .png / .pdf )；
  2. 查一下 MIME / Content-Type；
  3. 上传到"非 Web 根目录"或者关掉执行权限；
  4. WAF 上对 filename=*.php、multipart/form-data 做一些关键字匹配。

在 2025 这批 CVE 面前的问题：

  • 扩展名只检查一次 ：
    • Simple File List 说明"上传时查扩展名"不够，rename / move / import 时也得重新检查。cvedetails.com
  • 访问控制是空的 ：
    • SmarterMail / FileCatalyst / Cisco ISE 都是 未认证 文件上传，哪怕你把扩展名检查写得再完美，别人连登录都不用就能往任意目录扔文件 。TechRadar+2fortra.com+2
  • 业务逻辑绕过安全假设 ：
    • Cisco WLC 的 JWT 验证看似"有认证"，实际因为硬编码 secret "notfound"，整个认证形同虚设；Horizon3.ai
    • SAP SRM 中的上传本身是为业务附件设计，攻击者却能利用它作为进入企业核心 ERP 的入口。TechRadar

文件上传世界里什么已经不够用了？

文件上传里也有一套"老三件"：

  1. 扩展名白名单 （.jpg/.png/.pdf 之类）；
  2. 上传到非可执行目录；
  3. 开一点 WAF / 杀毒扫描。

在 2025 这几类高危 CVE 里，这些已经明显不再是充分条件：

  • 如果 上传接口不需要强认证/授权，那它本质上就是一个匿名写文件原语，任何小失误都可能变成 RCE；
  • 如果你只在"第一步上传"做检查，而在重命名、移动、导入模板、解压等后续步骤放松了约束，攻击者就会把 payload 安排在后半场触发；
  • 如果你把"文件合法性"外包给 WAF 或杀毒（尤其是只看文件头/拓展名），那只要攻击者玩一点格式伪装、polyglot 或业务场景（比如"订单资料""频谱数据"），就能轻松穿过去。

更现实的做法应该是：

  • 把"上传接口"当成 和登录 / 支付同等级别的安全敏感点，默认关掉匿名上传；
  • 对"路径、重命名、导入处理"等所有与文件相关的接口统一做 安全 SDK / 中间件 封装，不能让业务自己随便拼路径；
  • 对每一步（上传、重命名、移动、解析）都做 独立的类型检查和权限检查，而不是只在入口做一次"扩展名过滤"就完事；
  • 对于设备 / 网关类产品，要把管理端口纳入统一资产暴露治理，不要因为"这是黑盒设备"就把它排除在 WAF / 资产盘点之外。

关于反序列化

先上结论：2025 年的反序列化漏洞已经从"老牌 Java Web + PHP unserialize"扩展成「AI/ML 服务框架 + 前端新架构（React Server Components）+ SAP/Cisco 这类企业中枢 + OT/工业平台 + DevSecOps 工具」的组合拳，很多攻击根本不在传统 Web WAF 的视野里。

CVE-2025-55182（React Server Components / Next.js，简称 React2Shell）

问题出在 React 19 生态中 RSC"Flight"协议对服务器函数请求的二进制 payload 反序列化 ：服务端把来自客户端的 Flight 数据当成可信结构直接解析，还允许其中携带要调用的 Server Function、参数等高敏信息，结果导致未认证远程攻击者可以构造恶意 Flight payload，实现服务器端任意代码执行（CVSS 10.0）。这个洞影响原生 React Server Components 以及 Next.js 等实现 RSC 的框架，且已被多家厂商证实有大规模在野利用。TechRadar+5Akamai+5react.dev+5

为什么它"天然绕过"传统 WAF：

  • Flight 不是普通 JSON，而是一种 RSC 自定义的二进制/分块协议；
  • HTTP 上看就是一串看不出含义的字节流，WAF 不理解协议语义，很难在不大量误报的前提下做规则；
  • payload 里真正危险的是"对象图 + 函数引用 + 服务器内部标识"，而不是 <script>、eval、__wakeup 这种关键字；
  • 很多 RSC 应用部署在自家主域名下，WAF 更不可能只对"/react"这类路径做极端限制。

CVE-2025-27520（BentoML，Python AI 服务框架）

BentoML 是一个非常常用的 Python 模型服务框架。这个 CVE 直接写明：在 serde.py 中存在不安全反序列化，未认证用户就能触发远程代码执行 ，影响 v1.4.2，1.4.3 修复。国家漏洞数据库

典型模式大致是：为了方便在 RPC / HTTP 层传输复杂 Python 对象，框架内部用了一类"通用序列化"（pickle / cloudpickle / 自定义），但反序列化时直接吃客户端传来的 blob ，没有做类型白名单或隔离环境。

WAF 看到的只是一个看着很正常的 POST 请求 + 一坨 base64 / 二进制数据；真正危险的 gadget 链存在于 BentoML 自身以及部署者安装的各种第三方依赖里------这些都不在 WAF 的分析能力范围内。

CVE-2025-5662（H2O-3 REST API + JDBC 组合链）

H2O-3 是广泛使用的开源机器学习平台。该 CVE 指出：在 REST API 的 POST /99/ImportSQLTable 接口中，使用 Key-Value 模式传递 JDBC 连接参数时，存在反序列化漏洞 ，可被未认证攻击者远程代码执行。问题根源是：H2O-3 在处理这些参数时，依赖 MySQL JDBC 驱动（8.0.19）与特定 JDK 版本（8u112）的一段不安全反序列化逻辑，H2O-3 本身又没对参数做足够验证；修复版本为 3.46.0.8。CISA+3国家漏洞数据库+3OSV+3

这里的"隐蔽点"在于：你以为自己只是写了一个"导入 SQL 表"的 API，实际攻击链跨越了 REST → H2O-3 → JDBC 驱动 → JDK 反序列化 四层；只要其中任意一层用过"把字节流还原成对象"的 API，就有可能被搭起 gadget 链。WAF 站在最外层，只看到"导入表"的业务请求和看起来正常的 Key/Value 数据，很难意识到这会在 JVM 里触发反序列化。

CVE-2025-42944（SAP NetWeaver RMI-P4，Java 反序列化 RCE）

SAP 2025 年 9 月补丁日的"头号大雷"，CVSS 10 分：

SAP NetWeaver AS Java 的 RMI-P4 模块里存在不安全 Java 对象反序列化 ，远程未认证攻击者可以往暴露在公网/内网的 RMI 端口发恶意 payload，从而在底层操作系统上执行任意命令。TechRadar+3SAP支持门户+3SAP支持门户+3

和 SQL 注入类似，这种洞完全不在 HTTP 边界：

  • 攻击面是 RMI 协议端口，很多环境只用防火墙简单放行，不会挂 Web WAF；
  • payload 也不是 SQL / JSON，而是 Java 自带的序列化格式流；
  • 只要业务里有符合条件的 gadget（比如某些常见库的 readObject() 里有命令执行），攻击者就能"一包流量、一发 RCE"。

CVE-2025-20124 / CVE-2025-20125（Cisco ISE 不安全 Java 反序列化 + 授权问题）

Cisco Identity Services Engine（ISE）是 NAC/零信任里很核心的一块。2025 年 2 月 Cisco 公告中提到：ISE 中存在不安全 Java 反序列化漏洞 ，结合授权缺陷可以让低权限用户在系统上下文执行任意代码（CVSS 基础分 9.9）。cisco.com+1

攻击面同样不在传统 Web App"登录页""管理后台"这些地方，而在 ISE 内部某些服务接口上------只要能从管理网段打到那个端口，会一点 Java gadget 利用，就能直接拿 NAC 这块关键基础设施的系统级权限。

CVE-2025-54923（Schneider EcoStruxure Power Monitoring Expert）

Schneider 披露：EcoStruxure Power Monitoring Expert（PME）中某个网络暴露的服务 对已认证用户发来的数据做了不安全反序列化，导致认证用户可以构造数据包实现远程代码执行（CWE-502）。国家漏洞数据库+1

这类 OT/电力监控产品的典型特点是：

  • 运行在工业网络 / 数据中心内部，很少有 WAF 之类 Web 安全设备；
  • 通信协议多是自定义二进制或基于消息总线的"黑盒"，安全团队也不会在流量层做深度解析；
  • 一旦被打穿，后面挂的是大量工控设备与电力/能耗相关资产。

CVE-2025-5086（DELMIA Apriso，制造执行系统 MES）

达索系的 DELMIA Apriso 从 2020～2025 各版本中，都存在"反序列化不可信数据"漏洞，官方明确写成"可能导致远程代码执行"。Dassault Systèmes

和 Schneider 那类 OT 产品类似，这是直接打到产线核心 MES 平台上的 gadget 链：攻击面通常是某种内部接口 / 自定义协议，而不是公开的 Web API，因此传统 Web WAF 几乎帮不上忙。

CVE-2025-63950（Twittodon PHP，典型 unserialize() 对象注入）

这个例子则是"经典 PHP 流派"：

Twittodon 的 download.php 把 obj 参数当作 base64 字符串解码后，直接丢进 unserialize()，没有任何校验；结果远程未认证攻击者可以传入任意构造好的 PHP 对象图，至少能造成 DoS，若项目或依赖中存在合适的魔术方法，还可能进一步走到代码执行。国家漏洞数据库

值得注意的是，HTTP 层面看起来仍然是一条很普通的下载链接请求，参数只是一个经过 base64 的 blob，WAF 很难仅凭关键字判断这里会在 PHP 里触发反序列化。

CVE-2025-53690（Sitecore ViewState 反序列化 Zero-Day）

Sitecore 的若干产品被披露存在 ViewState 反序列化漏洞：在某些配置下，攻击者可以通过构造恶意 ViewState，利用不安全反序列化实现远程代码执行。Google Cloud 与 Sitecore 均披露了这一点，并指出该漏洞已在野被利用，用来对互联网上暴露的 Sitecore 站点做初始入侵。Google Cloud+2Sitecore 支持+2

和历史上的 ASP.NET ViewState 链一样，这里的问题不是"开发者在业务代码里手写了反序列化"，而是底层框架自带的一项"状态管理特性"默认就依赖对象反序列化，一旦验证/密钥配置不当，就变成攻击入口。

CVE-2025-2180（Checkov------IaC 安全扫描工具的本地反序列化）

Prisma Cloud 报告：Checkov 在解析 Terraform 文件时存在不安全反序列化，精心构造的 Terraform 配置可以在本地执行任意代码。这个漏洞攻击向量是 LOCAL，但不需要额外权限，用户只要"被动地"扫描恶意 IaC 文件就会中招。Palo Alto Networks Security

这说明反序列化不再只是在"服务端"危险：本地开发/CI 上跑的安全工具本身也可能因反序列化而被接管，形成供应链风险。

整体趋势

综合上面这些 CVE，可以看到 2025 年反序列化的几个明显集中点：

  1. AI / ML / LLM 基础设施成了重灾区
    • BentoML、H2O-3 等都是"模型服务 / 数据科学平台"，为了传输复杂对象，天然依赖各种序列化协议，一旦把输入视作"半可信"，就非常容易出现不安全反序列化 RCE。GitHub+3国家漏洞数据库+3国家漏洞数据库+3
    • 这些组件经常部署在内部数据科学集群前端，安全团队习惯把它当"内网工具"而不是高危互联网服务。
  2. 前端新架构（React Server Components / Server Functions）把反序列化"藏"到了协议里
    • RSC Flight 协议、Server Functions 的实现，本质就是"客户端把一坨描述 UI/调用的结构化数据序列化后发给服务端解析"；
    • React2Shell（CVE-2025-55182）表明，只要协议设计没把"哪些字段可以被用户控制、哪些字段可以控制执行路径"划清楚，就会把整个对象图暴露给攻击者玩。TechRadar+4Akamai+4react.dev+4
  3. 企业中枢/OT 系统：SAP / Cisco / Schneider / Dassault 等继续贡献高危 CWE-502
  4. 老问题从未消失：PHP unserialize、.NET ViewState、Java Gadget 链依然活跃
  5. MITRE 的 CWE Top 25 里，CWE-502 仍然是榜单常客
    2025 年 MITRE 公布的 CWE Top 25 中，信任不可信数据的反序列化（CWE-502）仍被列为最危险的弱点之一，和注入、认证缺失等并列，可见其在真实漏洞中的"热度"并没有下降。ITmedia+1

老一代的思路大概是：

  • "我们业务里不用 unserialize() 就安全了"；
  • Java 里"禁止 application/x-java-serialized-object 这种 Content-Type"；
  • ASP.NET 把 ViewStateMac 开起来、换个 key；
  • 再加一点 WAF / RASP 规则去拦典型 gadget 链（Commons-Collections 之类）。

但 2025 这批漏洞暴露的问题是：

  1. 反序列化早就不只发生在"业务代码那几行"里了
    • React RSC、H2O-3、JDBC 驱动、Sitecore ViewState、Checkov 等，都是"框架 / 库 / 工具"在底层偷偷帮你做了反序列化；
    • 你在业务层说"我不用反序列化，只用 JSON"，并不能阻止这些组件在内部对攻击者可控数据做 readObject() / pickle.loads() / BinaryFormatter.Deserialize()。
  2. 协议与对象图高度耦合，只靠"屏蔽几个危险类"挡不住
    • React2Shell 中 Flight payload 设计得足够灵活，可以携带各种组件/函数引用；除非对整个协议做语义白名单，否则"挡 gadget 类"只是在做猫抓老鼠 ；wiz.io+2react.dev+2
    • H2O-3 / JDBC 的问题则在于"底层驱动把参数当对象反序列化"，H2O 自己如果不在上层加强类型约束，就会暴露出 driver 层的弱点。国家漏洞数据库+2OSV+2
  3. 很多攻击面根本不经过 Web WAF / API 网关
    • SAP RMI-P4、Cisco ISE 内部服务、Schneider / DELMIA 工业协议、本地 Checkov 扫描、Sitecore ViewState 等，都绕开了"HTTP 入口 + Web WAF"这套假设；Google Cloud+6SAP支持门户+6Arctic Wolf+6
    • 即便有 WAF，它也只看到"正常的业务字段 + 一坨看不懂的二进制"，完全不具备构建 gadget 链的语义能力。

JSON的局限性

在 SQL 注入那部分我们说过：参数化查询是必要条件，但远远不够。反序列化世界里也有一个类似的误区：

很多团队会说："我们统一用 JSON / Protobuf，不再用 Java/PHP 的原生序列化，就没反序列化问题了。"

从 2025 这些 CVE 看，这句话至多是必要但远非充分，原因主要有三点：

  1. 你控制不了所有组件的实现细节
    • React 19 的 RSC Flight、Sitecore 的 ViewState、JDBC 驱动、BentoML/H2O-3 等，都在"你不知道的地方"引入了对象反序列化；国家漏洞数据库+3react.dev+3国家漏洞数据库+3
    • 只要你使用它们，哪怕你自己从不调用 unserialize() / readObject()，攻击者也能通过公共入口（HTTP/RMI/REST）把 payload 喂到那一层。
  2. "不用反序列化"这件事本身很难形式化和验证
    • 现实中项目往往会引入各种三方库，谁能保证其中没有某个 helper 在特定分支里对用户输入做了反序列化？
    • 更别提像 Checkov 这种场景：你"只是"让它解析一个 Terraform 文件，但内部为了性能和功能需要，确实用到了 Python 的对象反序列化。Palo Alto Networks Security
  3. 就算你在新代码里彻底弃用反序列化，老组件和部署环境也会留下"历史债务"
    • Sitecore/ASP.NET 的 ViewState、SAP NetWeaver 的 RMI-P4 等都属于"架构级设计遗留"，不是一两行代码能换掉的；Sitecore 支持+3SAP支持门户+3SAP支持门户+3
    • 对这些系统而言，更现实的是：
      • 把接收 serialized 数据的端口/接口暴露面缩到最小；
      • 为这些接口专门做流量监控与强访问控制；
      • 在服务器侧引入类型白名单 / 沙箱反序列化，而不是指望"所有人都不用反序列化"。

关于命令注入

直接说结论：2025 年的命令注入，已经明显集中在「安全基础设施 + 网络/VPN 边界 + 监控/HA 平台」上，而且大量是 *pre-auth / 低权限* 的 OS Command Injection，常见 WAF 规则和"黑名单过滤 ;&|"基本挡不住。

CVE-2025-54948 / CVE-2025-54987（Trend Micro Apex One 管理控制台）------"终端防护自己被 RCE"

Apex One 是企业端点防护产品，CVE-2025-54948 / 54987 是其 本地管理控制台里的 OS 命令注入漏洞 ，CVSS 9.4，已被 CISA 列入 KEV，确认有在野利用。趋势科技成功中心+2国家漏洞数据库+2

  • 漏洞属于 CWE-78（OS Command Injection）：管理控制台对某些输入没有正确净化，最终拼进底层系统命令，导致远程代码执行；
  • Tenable 分析指出：未认证攻击者只要能访问管理控制台，就能上传任意文件并通过命令注入实现 RCE，两条 CVE 分别对应不同 CPU 架构。Tenable®
  • JPCERT 和厂商公告都强调：漏洞正在被利用，临时 Mitigation 包括禁用部分远程安装功能，随后通过补丁修复。安全下一步+2日本漏洞信息+2

WAF 绕过点：

  • 这是"安全产品自己的 Web 控制面"，很多部署直接暴露在管理网/甚至公网，运营上反而不会再单独加一层 WAF；
  • HTTP 请求看起来只是访问管理页面、提交配置/任务，payload 嵌在 JSON/表单字段里，不一定显眼地带 ;wget 之类关键字，为了避免误报，通用 WAF 很难对这类"安全产品控制台"用极端严格规则。

CVE-2025-25256（Fortinet FortiSIEM）------"监控一切的 SIEM，被 pre-auth 命令注入"

FortiSIEM 是安全事件管理/监控平台。CVE-2025-25256 是一个 远程未认证 OS 命令注入漏洞 ，官方 CVSS 9.8，Fortinet 和多家 CSIRT 都明确说明：已经有实用 Exploit 在野流通。国家漏洞数据库+2安全下一步+2

  • 根本问题仍是 CWE-78：CLI 处理输入时对特殊字符中和不当，攻击者可以构造特制请求在系统上执行任意命令；国家漏洞数据库+1
  • watchTowr 的分析直接标题就是"pre-auth command injection in FortiSIEM，让你一包请求吃掉整个 SIEM"，并指出利用代码几乎不留日志痕迹------很符合"打监控先干掉监控"的现实打法。watchTowr Labs+1

WAF 绕过点：

  • FortiSIEM 通常部署在安全管理网段 ，入口多为专用 Web/CLI 接口，前面基本不会再挂第三方 WAF；
  • 漏洞利用的是 CLI/后端接口，对外表现可能是非常普通的 HTTP/JSON 或自定义请求，payload 是看似合法的参数值，很难靠通用规则识别"这会被拼成系统命令"。

CVE-2025-58034（Fortinet FortiWeb WAF）------WAF 自己被 OS Command Injection 打穿

FortiWeb 是 Fortinet 的 Web 应用防火墙。CVE-2025-58034 是 FortiWeb 自身的 OS Command Injection 漏洞 ，影响 7.0--8.0 一长串版本，被 NVD 归为 CWE-78，允许通过特制 HTTP 请求或 CLI 输入在设备上执行未授权的系统命令。国家漏洞数据库

  • 多个 CERT/国家级通报确认：该漏洞已经被在野积极利用，用来在 WAF 上拿系统权限、植入后门、横向移动。NHS England Digital+1

WAF 绕过点：

  • 这里比较魔幻：你指望 FortiWeb 来挡别人的命令注入，结果 FortiWeb 本机的管理 API/CLI 自己就有命令注入；
  • 攻击入口是 WAF 自己的管理接口（HTTP/CLI），任何"在 WAF 前面再加一个 WAF"都几乎不存在，真正的控制点只能是资产暴露面和补丁管理。

CVE-2025-20334（Cisco IOS XE HTTP API）------路由/交换控制面的 root 命令注入

CVE-2025-20334 是 Cisco IOS XE 软件 HTTP API 子系统的命令注入漏洞。Cisco 公告指出：由于输入校验不足，攻击者只要拥有设备管理员权限，就可以通过 HTTP API 发起特制调用，在底层操作系统以 root 权限执行任意命令。CVSS 8.8。cisco.com+2国家漏洞数据库+2

  • 这是"控制平面"层面的命令注入：攻击流量是对 /restconf / 某些管理 API 的合法调用，但内部会把某些字段拼进系统命令或脚本；
  • 安全媒体报道中提到，相关漏洞和同批次的认证绕过等一起，被研究者和攻击者广泛关注，已有 Nessus 等插件用于检测。安全下一步+1

WAF 绕过点：

  • 绝大多数组织不会在 路由/交换管理接口 前再放一个 HTTP WAF；
  • 即便有 HTTP 安全设备，payload 看起来只是某个 API 参数（例如命令字符串、路径、模板名），不像传统 Web 表单那样可以简单扫 ;|&，否则会把正常管理操作全打死。

CVE-2025-7850 / CVE-2025-6542（TP-Link Omada/Festa VPN 路由）------WireGuard 配置里的命令注入 + 补丁变体

在 TP-Link Omada 网关和 Festa VPN 路由中，研究者发现了多起命令注入漏洞：

  • CVE-2025-7850 ：在 WireGuard VPN 设置中存在 OS Command Injection，攻击者如果拿到 Web 管理端管理员账号，就能通过配置页面注入命令，CVSS 9.3。Forescout+2The Hacker News+2
  • CVE-2025-6542 ：另一处命令注入甚至不需要认证，直接通过 Omada Web 接口触发，同样是 9.3 分，被认为特别危险。TechRadar

研究报告指出，这些路由大量部署在 工业/能源场景 （太阳能逆变器、PLC 前面挂的 VPN/边界路由），而且是对先前漏洞（CVE-2024-21827）修复不彻底的变体：旧补丁留下调试功能和危险路径，导致"漏洞变体挖掘"一下子把新的命令注入点揪出来。Forescout+2Industrial Cyber+2

WAF 绕过点：

  • 这些是 VPN/网关设备本身，正常部署方式就是直接暴露其管理接口，基本不会再前置独立 WAF；
  • 命令注入点藏在 VPN 配置字段里（如 WireGuard 的 endpoint / script 字段），payload 很难和"正常配置"用简单规则区分，WAF 即使用在外层也很难在不大量误报的前提下防住。

CVE-2025-66644（ArrayOS AG VPN 网关）------长期在野利用 + WebShell 种植

Array Networks 的 ArrayOS AG（VPN/应用网关）在 9.4.5.9 之前版本存在命令注入漏洞，CVE-2025-66644。NVD 和 CISA 均指出：该漏洞在 2025 年 8--12 月被积极利用，用来植入 WebShell。CISA+3国家漏洞数据库+3国家漏洞数据库+3

  • JPCERT/IPA 的通报中明确写到：攻击者利用 DesktopDirect 功能中的命令注入，在设备 Web 管理面上落 WebShell，进一步横向。jpcert.or.jp+1
  • 厂商在 2025 年 5 月就发布修复版本，但大量设备未及时升级，导致后面几个月内出现多起成功入侵案例------这是标准的"打 VPN 设备拿企业内网"的攻击链。

WAF 绕过点：

  • 和前面的 FortiWeb/FortiSIEM 类似：被打的是安全/远程接入设备本身，部署结构上很少给它再加一层 Web WAF；
  • 命令注入点在一个"看起来正常"的管理功能（DesktopDirect），payload 包在 HTTP 参数里，与合法请求几乎同形。

CVE-2025-66399（Cacti SNMP Command Injection）------从 SNMP 社区串一路绕到命令执行

Cacti 是常见的开源网络监控/性能管理平台。CVE-2025-66399 是发生在 SNMP 设备配置功能中的命令注入：

  • 在 host.php?action=save 里，snmp_community 字段用于保存 SNMP 社区字符串；
  • 1.2.28 及之前版本允许认证用户提交包含控制字符（包括换行）的社区字符串，这些字符串被原样存进数据库，之后在 backend SNMP 操作中拼进命令行；
  • 当下游 SNMP 工具把这些控制字符解释为命令分隔符时，就会导致攻击者控制的命令被执行，从而在 Cacti 所在主机上实现 RCE。dbugs+3国家漏洞数据库+3GitHub+3

安全新闻和 Check Point 等厂商都强调：这是认证用户才能利用的漏洞，但一旦被用来接管监控平台，就等于拿到了整个网络拓扑和大量凭据，影响极大。IoT OT Security News+2Check Point Software+2

WAF 绕过点：

  • 从 HTTP 视角看，这只是一个"配置 SNMP 社区串"的普通表单字段，值是 base64/ASCII 字符串，里面即便混了换行/奇怪字符，WAF 很难基于关键字判断这会变成 shell 命令；
  • 真正的命令注入发生在后端调用 snmpwalk/snmpget 等工具那一步，是"HTTP → PHP → shell → SNMP 工具"的链式注入。

CVE-2025-11546（NEC EXPRESSCLUSTER X）------高可用集群协议里的命令注入

NEC 的 EXPRESSCLUSTER X 是做服务器/应用高可用的集群软件。NEC 安全公告 NV25-006 指出：该产品存在 OS Command Injection 漏洞 ，攻击者只需向指定端口发送特制网络数据包，即可在目标系统上以软件权限执行任意命令，无需认证。NEC

这里比较典型的是：攻击面不在 HTTP，而在集群自己的通信协议/管理端口上------你连是 TCP 还是 UDP、payload 格式长啥样，WAF 都看不懂。这类"基础设施中间件"如果暴露在大网里，风险非常难在流量层通过通用安全设备缓解。

整体趋势

从上面这些例子，可以看出 2025 年命令注入的几个明显集中方向：

  1. 安全基础设施本身成了高危靶子

    • 终端防护（Trend Micro Apex One）、SIEM（FortiSIEM）、WAF（FortiWeb）、VPN/应用网关（ArrayOS AG、TP-Link Omada）、网络设备 OS（Cisco IOS XE）都在这一年曝出严重命令注入，且多起被列入 CISA KEV、确认在野利用。TechRadar+8国家漏洞数据库+8趋势科技成功中心+8
    • 打安全产品 = 打"安全摄像头"：一旦成功，后续横向、日志清洗、持久化都会非常舒服。

  2. 命令注入越来越多发生在"控制/管理平面"与"专有协议"上

    • Cisco IOS XE HTTP API、FortiSIEM CLI、FortiWeb API/CLI、ExpressCluster 的集群协议、TP-Link 的 WireGuard 配置、Cacti 的 SNMP 设备管理等，入口不再是"用户业务页面"，而是系统管理接口和运维管道 。国家漏洞数据库+5国家漏洞数据库+5国家漏洞数据库+5
    • 很多协议是自定义的、二进制的或半结构化的，传统 Web WAF 根本没法理解，更谈不上写精细规则。

  3. pre-auth / 低权限命令注入比例显著上升

    • FortiSIEM（CVE-2025-25256）是远程未认证 RCE；ArrayOS AG（CVE-2025-66644）确认被大规模利用；TP-Link Omada 的某些漏洞甚至无需认证即可命令注入；Trend Micro Apex One 则是"控制台可达即可打"。CISA+4国家漏洞数据库+4国家漏洞数据库+4
    • 这意味着只要资产暴露在互联网上，端口开放 + 小小一处输入校验缺陷，就能变成一发 RCE。

  4. "配置字段 → 下游工具"的链式注入越来越多

    这类场景下，HTTP 入口看起来只是"写配置"，真正的命令注入是在后端"调用工具/脚本"那一步发生的。

  5. CWE-77/78 仍在各类"Top 漏洞榜单"里常年占位

    • 从 MITRE CWE 定义和 2025 年各家统计来看，"命令注入/OS Command Injection"依然是最危险的通用弱点之一，被 CISA KEV 列入的命令注入案例也明显增多。TechRadar+5CWE+5国家漏洞数据库+5

老一代常见做法是：

  1. 后端调用命令时，把用户输入做一遍简单过滤/替换，禁止出现 ; | & \ $ ( )` 等；
  2. WAF 上写几条规则，看到 ;cat /etc/passwd、&&wget、id;uname 就拦；
  3. 觉得"我不用 system()，改用 subprocess.run(..., shell=False) 就安全了"。

但 2025 这批 CVE 暴露出的问题是：

  1. 命令注入往往发生在"你代码看不到的地方"
    • 你以为自己只是填了 SNMP 社区串（Cacti）、VPN 配置（TP-Link）、HTTP API 参数（Cisco IOS XE / FortiWeb / FortiSIEM），真正把这些值拼成命令的是"下面那一层产品"；国家漏洞数据库+4GitHub+4Forescout+4
    • 对业务开发来说，这和"我写 SQL 用参数化，但 ORM 或驱动在某些路径仍然字符串拼 SQL"非常像------你以为安全边界在自己这层，实际上不止这一层。
  2. 黑名单过滤在复杂协议和工具链前面完全不够看
    • Cacti 的利用点是控制字符（特别是换行），不是典型 ;、&&；国家漏洞数据库+1
    • FortiSIEM/FortiWeb/Cisco IOS XE 中的命令注入点多在内部"构造 shell 命令"的代码里，攻击面可能是 JSON 字段、CLI 参数、API body，简单丢掉几种符号并不能消除所有 shell 元字符/边界情况；
    • TP-Link/ArrayOS 这类设备还会混合脚本语言、环境变量、配置文件解析，黑名单几乎无从下手。Forescout+2国家漏洞数据库+2
  3. WAF 覆盖面的真实边界，比想象中小得多
    • 很多被打的是 安全产品、VPN/路由、HA 集群、监控平台 ，它们的管理接口根本没有挂在 WAF 后面（反而有时自己就是"WAF"）；GitHub+4国家漏洞数据库+4国家漏洞数据库+4
    • 即便经过 Web WAF，payload 也常常是一坨完全合理的配置/管理参数，要做到"不漏报又不把管理员日常操作全拦掉"几乎不可能。

不用 system() / shell=True

"我们统一不用 system() / shell=True，都用 subprocess.run([...])，再加一层 escape，所以没有命令注入问题。"

从 2025 这些案例看，这同样只是必要但远非充分：

  1. 你控制不了所有命令执行的地方：
  2. 很多命令并不直接可见为"shell"，而是"外部工具/脚本/协议栈"的一部分：
    • Cacti 是"SNMP 社区串 → 下游 SNMP 工具命令"；
    • ExpressCluster 是"集群协议包 → 节点命令"；
    • Apex One/FortiSIEM 等是"Web/CLI 请求 → 后端脚本/agent 调用"。国家漏洞数据库+3dbugs+3NEC+3
  3. 就算你这层完全不用 shell，下游组件也可能"帮你"用：
    • 和"我这层用了参数化查询，但驱动/ORM 在别处仍然拼 SQL"一模一样------你可以限制自己不用 system()，但很难要求所有依赖都不用命令行。

更现实的做法应该是：

  • 把"任何能触发系统命令/脚本执行的接口"（管理 API、CLI、配置导入、SNMP/SSH 代理等）当成 RCE 级别资产 管理：强认证、暴露面收紧、日志和检测拉满；
  • 在实现层面尽量避免"字符串拼命令"，用严格参数化的底层调用（不经 shell 的 exec / 专用库），同时对所有参数做 白名单型约束（枚举允许的子命令、选项、路径模式）；
  • 对安全产品/网络设备这类"别人信任你做安全边界"的组件，不要迷信"我们是安全厂商就自己安全"，要把自己的管理面当成优先级最高的攻击面来做 SDL 和动态测试。

关于csrf

在 CVE-2025-24358（gorilla/csrf 中间件） 中，问题直接出在"防御库本身"：

gorilla/csrf 声称会基于 Origin / Referer 做跨站校验，但实现里只在认为"请求走 TLS"时才检查 Referer，而它是通过 r.URL.Scheme 判断是否为 HTTPS ------Go 规范里这个字段对服务端请求默认是空的，于是检查逻辑根本不会跑 。再加上没有对 Origin 做白名单校验，结果就是：只要攻击者已经在同一顶级域或子域拿到 XSS，就可以在那个子域里发起跨站表单提交，成功绕过本该保护应用的 gorilla/csrf 中间件。国家漏洞数据库

这里的绕过点完全在"框架/中间件层"，业务代码哪怕每个表单都乖乖用了 CSRF token，也挡不住。

CVE-2025-11990（GitLab EE） 体现的是"CSRF token 被间接泄露"：

GitLab 修了一个缺陷：在某些仓库引用（repository ref）的输入校验 + 重定向处理上存在组合问题，允许低权限认证用户通过构造特殊 ref + 跳转链条，获取本不属于自己的 CSRF token 。一旦拿到别人的 token，后面所有"检查 token 是否匹配"的防护就等于失效，可以在目标用户会话上下文里发起本不该由自己发起的状态变更操作。国家漏洞数据库

这个洞说明：CSRF 不是"有没有 token"的问题，而是"token 有没有被安全绑定（不泄露、不混用）"的问题。

CVE-2025-41254（Spring Framework STOMP over WebSocket） 是"协议换了，但 CSRF 思维还停在 HTTP"：

Spring 的 spring-websocket 模块里，STOMP over WebSocket 存在安全校验缺口：攻击者可以在未正常完成预期的会话创建/握手流程 的情况下，向应用端发送未经授权的 STOMP 消息，也就是绕过了原本应该做的"谁有资格发这条消息"的检查。Home

很多团队会在 HTTP 层严格做 CSRF 防护（token + SameSite cookie），但 WebSocket / STOMP 这一侧只当"内部通道"用，缺乏同等强度的来源校验和会话绑定，于是出现了"WebSocket 版 CSRF"：只要能诱导浏览器与目标建立 WS 连接，就能在后续消息层面假借用户身份发指令。

CVE-2025-14546（fastapi-sso） 是经典的 OAuth state 绑定失败 → 登录 CSRF / 账号绑定劫持 ：
fastapi-sso 这个库里，get_login_url 虽然可以生成 state 参数，但并不会把生成的 state 持久化到会话中；回调处理函数 verify_and_process 又直接相信回调 URL 里带回来的 state，从不与本地可信值对比 。漏洞信息和修复指南

结果就是：攻击者先自己走一遍 OAuth 流程拿到合法的 state + code，再通过钓鱼等方式让受害者在已登录状态下访问伪造回调 URL，服务器就会在受害者会话里把"攻击者的外部账号"绑定进来，形成一种 SSO 级别的 CSRF / 账号混绑，后续可以用外部身份直接操作受害者在站内的账户。

CVE-2025-60156（AR For WordPress 插件） 、CVE-2025-52835（WING WordPress Migrator） 则是"CSRF + 高危后台功能 = 直接 RCE"的插件代表：

  • 在 CVE-2025-60156 里，AR For WordPress 插件某些后台操作缺少 nonce/CSRF 校验，未认证攻击者只要诱骗管理员访问自己控制的页面，就能构造后台请求，让管理员浏览器在登录态下调用"上传 AR 资源"之类的接口，最终实现向服务器上传任意 WebShell。国家漏洞数据库+2OffSeq Threat Radar+2
  • CVE-2025-52835 中，WING WordPress Migrator 迁移插件同样因为 CSRF 缺失，导致攻击者可以借管理员之手通过"迁移/导入"功能上传恶意文件，拿到 WebShell，CVSS 直接打到 9.6。国家漏洞数据库

这类洞乍一看只是"插件 CSRF"，但因为后台功能本身就具备"上传文件、改配置、安装插件"这些高权限能力，一旦被 CSRF 利用，攻防上本质就是一条轻量级的 RCE 链。

CVE-2025-20326（Cisco Unified Communications Manager 管理面） 是"传统大厂设备管理口 + CSRF"的老问题新案例：

Cisco UCM / SME 的 Web 管理界面在 CSRF 防护上存在缺陷：对敏感操作缺少有效 token 校验和来源检查，攻击者只要让登录了管理界面的管理员点击一条恶意链接，就能在对方浏览器里，以管理员权限对语音/呼叫路由配置执行任意操作 。国家漏洞数据库+1

这类设备往往被认为"只暴露在内网/VPN 后面"，安全团队不会给管理口再加额外网关/浏览器隔离，结果一旦管理员被钓鱼，CSRF 就成了打穿语音基础设施的捷径。

整体趋势

把这些 CVE 摆在一起，会发现 2025 年的 CSRF 也和 SQL 注入一样，在往"更深的链路和更复杂的业务"里钻，而不是停留在简单的表单提交上：

  • 重灾区一：后台插件 & 管理面功能
    • WordPress 插件（迁移、地图、AR、预约等）通过 CSRF 直接走到 WebShell / 插件安装 / 设置篡改。国家漏洞数据库+2国家漏洞数据库+2
    • 网络设备 / UC 管理界面一旦被 CSRF，影响的是整条语音或网络平面。
  • 重灾区二：SSO / OAuth / 身份绑定流程
    • fastapi-sso 的 state 不绑定会话，等于是给了攻击者一个"替他人完成登录/绑定"的入口。漏洞信息和修复指南
    • GitLab 的 token 泄露问题属于"CSRF 防护资产本身被旁路或窃取"，是更高一层的逻辑缺陷。
  • 重灾区三：框架 & 中间件级防护失效
    • gorilla/csrf 判断 HTTPS 的逻辑错误，导致 Referer 检查在真实部署里几乎形同虚设。国家漏洞数据库
    • Spring STOMP over WebSocket 放行了未经完整会话建立的消息，相当于在"协议适配层"打了洞。Home

传统意义上那种"纯表单 + 没有 token 的 CSRF"当然还在，但 高危链条越来越多是：CSRF 只是入口，后面接的是插件安装、任意文件上传、账号劫持、配置篡改甚至 RCE。

老一代对 CSRF 的理解

很多系统的防御模型大概是这样的：

  • CSRF = "用户被钓鱼点击一个带 cookie 的链接"；
  • 防御 = 表单里加一个隐藏字段 token，提交时对比一下；
  • 补充措施 = 偶尔检查 Referer，一些地方加 SameSite=Lax。

在这种模型里，只要"我表单里有 CSRF token"，大家就感觉相对安心。

2025 高危 CSRF 的现实

从上面这些 CVE 看，现在的问题已经明显不止于"有没有 token"：

  • token 逻辑没绑好
    • GitLab：token 可以通过不相关的 ref + redirect 链条被低权用户收集。国家漏洞数据库
    • fastapi-sso：OAuth state 没有持久化，也没有和当前会话绑定，导致"谁发起的登录"和"谁完成了回调"可以是两个人。漏洞信息和修复指南
  • 防护库 / 框架自身的实现漏洞
    • gorilla/csrf 完全没有实质性检查跨源请求的 HTTPS Referer，Origin 又没白名单，结果任何分享同一主域的 XSS 都能借你的中间件当跳板。国家漏洞数据库
    • Spring STOMP 这种"非 HTTP、但依然基于浏览器会话"的协议，如果没有专门做来源/会话验证，HTTP 那边做得再严也没用。Home
  • 高危后台能力暴露给前端，缺少二次确认
    • WordPress 插件让一个简单的 POST 就能上传文件/安装插件，而这个 POST 又没有 nonce/CSRF 校验，于是"管理员随便点个链接 → 站点被种马"。国家漏洞数据库+2国家漏洞数据库+2
    • 设备管理界面同样如此，任何配置变更只依赖 cookie 会话，没有额外确认步骤或 out-of-band 校验。国家漏洞数据库+1
  • CSRF 目标已经不只是"改密码/改邮箱"，而是整个控制平面
    • 通过 CSRF 上传 WebShell、本地持久化、安装恶意插件，这些都让 CSRF 成了 RCE 链的第一环，而不再是"中危逻辑漏洞"。

那还应该怎么想 CSRF 防护？

基于这些 2025 年的案例，更合理的防御思路可以总结成几条（对应上面每类问题）：

  1. 把 CSRF token/State 当成"安全资产"来设计，而不是一个装饰字段
    • 必须绑定到会话/设备/用户，不能简单"谁带着 token 来我就信谁"。
    • SSO / OAuth 必须正确使用 state（或 PKCE 等）并做严格匹配。
  2. 对框架/中间件的 CSRF 防护保持怀疑态度
    • 认真看它到底在检查 Origin 还是 Referer、对哪些方法/路径生效；
    • 对像 gorilla/csrf 这种库，要跟进官方安全公告和补丁，而不是"一次接入终身放心"。国家漏洞数据库
  3. 把 WebSocket / STOMP / SSE 等"非传统 HTTP 通道"纳入 CSRF 威胁模型
    • 把"谁能打开连接"和"谁能发消息"分开考虑；
    • 对消息级别加上应用层身份/来源验证，而不是只依赖握手时的一次 cookie 检查。Home
  4. 对后台高危操作做额外交互或 out-of-band 校验
    • 安装插件、上传可执行文件、变更管理员权限这些操作，最好有二次确认 / 管理员 PIN / 短期 one-time token，而不是"一次 CSRF token 校验走天下"；
    • 对管理界面尽量限制可被互联网直接访问的面，配合浏览器隔离、专用管理浏览器等手段，降低"被钓鱼后带 cookie 点链接"的概率。国家漏洞数据库+2cisco.com+2

关于ssrf

先上结论：2025 年的 SSRF 明显已经不是"image_url=""简单拉个图"那个时代了，而是：

  • 深度绑在 云控制平面 / 观察性 / 备份与安全产品 / LLM Actions 上；
  • 甚至连叫 nossrf / ssrfcheck 这种"防 SSRF 库"本身都在被打；
  • 典型"只在 WAF 上 ban 掉 127.0.0.1 / 169.254.169.254"的模型，基本等于心理安慰。

CVE-2025-54122（Manager.io / Manager 会计软件）

  • 本质问题 ：Manager Desktop / Server 版的 proxy handler 组件存在 未认证的 full-read SSRF ，攻击者可以在完全未登录的情况下，通过该代理功能让服务端主动对任意目标发起 HTTP 请求并回显响应内容。国家漏洞数据库
  • 为何难防 ：
    • 这是应用内置的"对外 HTTP 代理"能力，本身就是为了跨网络访问其他服务设计的------WAF 看见的只是一条普通对 /proxy 之类路径的请求；
    • SSRF 的目标往往是 内网服务 / 云元数据，走的是服务器 → 内网的出站通道，完全在 WAF 可视边界之外；
    • "full-read" 意味着不仅能探测端口，还能直接读配置、状态等敏感信息，为后续横向移动打底。

CVE-2025-29972（Microsoft Azure Storage Resource Provider）

  • 本质问题 ：Azure Storage Resource Provider（控制平面的一部分）中存在 SSRF，授权攻击者可以滥用该组件向任意端点发起请求，CVSS 直接给到了 9.9。国家漏洞数据库
  • 攻击链特点 （来自 CODE BLUE 2025 公开技术细节）：
    • 以一个"传统 SSRF"起手，通过 Storage Resource Provider 的 HTTP 请求能力打通内部边界；
    • 引入新型 DNS rebinding 技术 "Spray&Pray4Bind" 来 绕过云平台新一代缓存/防重绑定防御；
    • 最终劫持 ID metadata 获取流程，窃取任意租户的 AAD 令牌，实现跨租户横向移动和存储劫持。クラスメソッド発「やってみた」系技術メディア | DevelopersIO
  • 为什么 WAF 不管用 ：
    • 整个链条发生在 云控制平面内部服务之间，根本不是你的 Web 应用在发请求，WAF 连封包都见不到；
    • 防御必须是 云侧修复 + 客户侧最小权限 / 条件访问 / 审计，而不是"在入口 Web 服务上加几条 URL 规则"。

CVE-2025-6454（GitLab Webhook SSRF） & Typebot Webhook SSRF（无 CVE，GitHub Advisory）

  • GitLab CVE-2025-6454 ：
    • 影响 GitLab CE/EE 16.11 之后至 18.x 某些版本，漏洞点在 Webhook 的 自定义 Header 功能。
    • 认证用户可以构造特殊 header 序列，经由 GitLab 配置的 HTTP 代理发往内部地址，形成 SSRF；官方描述为"通过 proxy 环境发起非预期内部请求"。国家漏洞数据库+1
    • CVSS 8.5，典型场景就是拿 GitLab 当成 企业代理+CI 中枢 ，打内部管理接口。IoT OT Security News+1
  • Typebot Webhook SSRF（AWS EKS 凭据泄露） ：
    • Typebot 的 HTTP Request 组件（webhook block）允许已认证用户发起任意 HTTP 请求；
    • 研究人员发现可以通过 自定义 Header 注入 绕过 IMDSv2 的防护，从容器节点访问 AWS Instance Metadata Service，窃取 EKS 节点角色的临时 IAM 凭据，从而直接控整集群 & 关联 AWS 资源 。GitHub

这两例说明：

  • SSRF 越来越多出现在 "集成 / Webhook / Actions / 机器人" 这种"帮你去请求别的服务"的功能里；
  • 利用重点已经不只是读内网端口，而是直接拿到 云凭据 / 访问令牌 ，跟 2025 年 JumpCloud 对 SSRF 风险的总结高度一致。JumpCloud

CVE-2025-25012 & CVE-2025-37734（Elastic Kibana）

  • CVE-2025-25012：Open Redirect → SSRF
    • Kibana 的 URL 重定向校验不严格，导致攻击者可以构造恶意 URL，把用户重定向到任意站点，同时在某些部署形态下还能借此伪造服务端请求（SSRF）。SentinelOne
    • 这是典型的"Open Redirect + SSRF 绑在一起"，在多层代理/反向代理环境里尤其难察觉。
  • CVE-2025-37734：AI Assistant Origin 校验缺陷
    • 出在 Kibana Observability AI Assistant 功能的 Origin 验证错误，导致远程攻击者可以构造请求，让 Kibana 向攻击者指定的内部或外部地址发起 SSRF。IoT OT Security News
    • 影响多个 8.x、9.x 版本，且 AI Assistant 打通了观测、日志和后端服务，对攻击者的情报价值极高。

两个洞加在一起，你可以把 Kibana 看成：

  • 一端连着 开发/运维操作台 + LLM 分析助手，
  • 一端连着 日志存储 / ES 集群 / 内部 API，
  • SSRF 就变成了一条非常舒适的"从前端到后端、从人到数据"的高速公路。

CVE-2025-54249（Adobe Experience Manager, AEM）

  • CrowdSec 观测到针对该洞的大规模利用流量：AEM 的某接口允许攻击者控制请求目标，让服务器替其向任意地址发起请求，典型 SSRF。CrowdSec
  • AEM 常常部署在企业门户、内容管理中枢位置，对内部服务有非常广的访问权限，因此一旦被用作 SSRF 代理，就很容易扫遍内部 API、配置中心、版本仓库等。

CVE-2025-23082（Veeam Backup for Microsoft Azure）

  • 影响 Veeam Backup for Azure 7.1.0.22 及之前版本，漏洞允许远程攻击者利用 SSRF 从备份系统对任意目标发起请求，从而进行 内部网络枚举或为其他攻击铺路 。Veeam Software
  • 备份/灾备系统本身往往对生产 VNet 拥有广泛访问权限，又经常被认为是"纯内部服务"，很少配专门的 WAF/网关；SSRF 一旦打通，这类系统就是完美的内部 pivot。

CVE-2025-2691（nossrf） & CVE-2025-8267（ssrfcheck）------"防 SSRF 库"本身被打

  • nossrf（CVE-2025-2691） ：
    • 一个用于 Node.js 的 SSRF 防护包 nossrf 在 1.0.4 之前版本存在 SSRF 漏洞：攻击者只要提供一个解析到本地或保留地址空间的 hostname，就可以 绕过其保护逻辑 ，完成 SSRF。国家漏洞数据库
  • ssrfcheck / "SSRF Check"（CVE-2025-8267） ：
    • 这个 npm 包的设计目标也是"检查 URL 是否 SSRF 安全"，但 <1.2.0 版本由于 IP denylist 不完整 ，没有把 224.0.0.0/4 组播地址段视为保留地址，结果可以借此构造指向组播地址的请求，绕开过滤。国家漏洞数据库+1

这两例非常直观地说明：

  • "我已经用了某某 SSRF 安全库" ≠ 安全；
  • 否则连安全组件本身都不会连续出现在 CISA 周报和 NVD 里作为 SSRF 高危案例。CISA

CVE-2025-8084（WordPress AI Engine 插件） & CVE-2025-69222（LibreChat）------绑定 LLM / AI 的 SSRF

  • CVE-2025-8084：AI Engine for WordPress
    • 在 3.1.8 (含) 之前，rest_helpers_create_images 功能中存在 SSRF，Editor 及以上权限的用户可以让站点向任意 URL 发起请求，访问内网服务；
    • 在云托管场景下，这个 SSRF 还能访问云元数据，窃取实例凭据。GitHub+2dbugs+2
  • CVE-2025-69222：LibreChat（ChatGPT 类开源项目）
    • LibreChat 0.8.1-rc2/0.8.2-rc2 的 Actions 功能 默认配置缺少对目标 URL 的严格限制，导致用户可以配置"Agent 动作"去请求任意地址，形成高危 SSRF（CVSS 9.1）。安全警报+2漏洞数据库+2
    • Actions 支持 OpenAPI 说明、多 HTTP 方法和自定义 Header，本来是为了扩展 LLM 能力，现在则被研究者演示为"LLM 带你扫内网"的载体。

这一组和前面的 Kibana AI Assistant 一起，基本宣告：

  • AI/Agent/Actions 已经成为 SSRF 的一线战场，而不是"顺带"的小问题。

2025 年 SSRF 的整体趋势

结合上面这些 CVE，可以看到几个非常明显的方向：

  1. 攻击面从"下载图片"转向"集成 & 控制平面 & AI"

    • Webhook、HTTP Request 组件、Observability / Logging 平台（Kibana）、备份系统（Veeam）、内容管理（AEM）、LLM Actions（LibreChat / AI Engine / Typebot）等，都在做一件事：

      让服务器"代表你"去访问别的服务。

    • 这天然就是 SSRF 的温床，且每一个点后面都挂着大量内网/云资源。

  2. 利用目标从"扫内网端口"升级为"窃取云凭据 / 控多租户"

  3. "安全组件 / 安全库"自身成为 SSRF 攻击目标

  4. WAF / URL 关键字规则越来越边缘化

    • 大量攻击发生在 二次/三次请求（服务端 → 内部服务），WAF 根本看不到；
    • 即使在入口处要拦，也必须理解具体协议/JSON 结构/业务语义（例如 GitLab Webhook Header、Kibana 的重定向参数、LibreChat Actions 配置），不是简单 http://169.254. 这种正则能搞定的。

为什么"简单 URL 检查 / 阻断 127.0.0.1 和 169.254.*"远远不够

类比你前面对 SQL 注入的结论（"参数化是必要条件但不是充分条件"），对 SSRF 可以这样总结：

"使用某个 SSRF 安全库 + 在 WAF 里 ban 掉几段 IP" 是必要条件，但已经明显不再是充分条件。

主要有几层原因：

  1. 检查点太"字符串化"
    • 许多库只检查 字面量 IP/域名 ，忽略解析结果、重定向、DNS rebinding 甚至组播/链路本地段（ssrfcheck 忽略 224.0.0.0/4 就是教科书级案例）。国家漏洞数据库+1
  2. 缺少"上下文"和"调用者意图"
    • GitLab / Typebot / LibreChat 这些场景，需要根据 调用者是谁、功能本身允许访问什么 来判断，而不是在一个全局 hook 里凭字符串黑名单拍脑袋。
  3. 缺少统一的"出站网关"
    • 很多产品（Manager, Kibana, Veeam, AEM）自己就能直接出网，绕过了你可能在主业务 API 前面的所有网关/WAF/Service Mesh 控制；
    • 如果没有统一 egress 代理 + 网络层 ACL，再聪明的应用侧过滤都可能被"某个被遗忘的组件"绕过。
  4. 云环境中 SSRF ≈ 凭据窃取漏洞
    • 一旦 SSRF 能够触达云元数据 / 控制平面，就基本等价于"黑进 CI/CD 或 IAM"的后果：
      • 短期 Token 一旦泄露，就可以用来创建新资源、读写存储、横向到别的服务；
      • SSRF 不再是"信息泄露"，而是完整的 初始入侵 + 横向移动 + 权限升级链路 的第一步。日本专利局+1

如果你后面要在报告里做"传统漏洞 2025 趋势"那张大表，可以把 SSRF 这一列总结成类似：

  • 攻击面迁移 ：
    从传统的 image_url / PDF 抓取 → Webhook / AI Actions / Observability / 备份&云管产品 / 安全组件本身。
  • 利用目标升级 ：
    从简单内网端口扫描 → 云元数据 & 凭据窃取 → 跨租户云控制平面入侵。
  • 防御共性 ：
    • 必须有 统一 egress 控制 （网络层/Service Mesh）+ 严格的域名白名单 & 解析后 IP 校验；
    • 把所有"帮你发请求"的功能（Webhook、LLM Actions、备份探测等）当成高危面做模型化，而不是当成普通业务参数随便放；
    • SSRF 安全库 / WAF 规则只作为"最后一道保险"，而不是第一也是唯一的防线。

关于ssti

在 2025 年这波 SSTI 里，明显能看到一个趋势：
不再是"简单模板没 escape 一下"，而是"复杂模板 + 沙箱绕过 + LLM/Docs/配置链路"在一起炸，而且很多场景根本不在传统 Web 边界内，WAF 几乎没存在感。

CVE-2025-23211（Tandoor Recipes，Jinja2 SSTI → RCE） OffSec

  • 开源菜单/菜谱管理系统，后端用 Jinja2 渲染菜谱内容。
  • 漏洞点在于：菜谱说明（instructions）字段直接当 Jinja2 模板渲染，而不是"纯文本"，且没有做任何模板级过滤。
  • 低权限登录用户只要能创建/编辑菜谱，就能在说明里塞 payload，例如典型的 Jinja "爬祖宗"链条：
    {``{ ()|attr('__class__')|attr('__base__')|attr('__subclasses__')()|...|attr('popen')('whoami')|attr('read')() }} 就能直接系统命令执行。OffSec
  • 官方 docker-compose 默认是以 root 身份跑容器，所以一旦打穿模板，就是直接 root RCE。
  • WAF 绕过点 ：
    • 攻击流量长得就像普通登录用户在发一段富文本内容；
    • 触发是在「另一个用户查看菜谱」时发生的 server-side 渲染，WAF 看不到模板展开后的行为；
    • 你很难在不巨量误报的前提下，简单用 {``{ / __class__ 一类关键字去拦富文本区。

CVE-2025-66434/66435/66436/66437/66438（ERPNext，Jinja2 SandboxedEnvironment 滥权） 国家漏洞数据库+2CVE Details+2

  • 一串 ERPNext 的 Jinja2 SSTI：dunning letter（催款函）、contract template、terms & conditions、address display、print format 等函数都会调用 frappe.render_template()，把数据库里配置的模板 + 当前文档 doc 直接丢进 Jinja2 渲染。
  • 看上去它用了自定义的 SandboxedEnvironment ，但问题在：get_safe_globals() 又把 frappe.db.sql 这类危险函数重新塞回执行环境 ，等于沙箱开了洞。CVE Details+1
  • 只要有权限编辑这些配置（合同模板、条款、地址格式等），就能注入 Jinja 表达式，至少能：
    • 读数据库任意表、拼特定 SQL；
    • 在某些部署下进一步链到代码执行。
  • WAF 绕过点 ：
    • 攻击请求都是后台管理 API，通常已经在 "已认证" 区域，很多企业的 WAF 策略对这块放得很松；
    • 参数名都是业务字段（terms, contract_terms, body_text），payload 混在一大段合法模板代码里，很难写单纯签名规则；
    • 真正的危险发生在后端 render_template 阶段，与 HTTP 层已经脱钩。

CVE-2025-67843（Mintlify 平台 MDX 渲染引擎 SSTI） 国家漏洞数据库+1

  • Mintlify 是文档平台，支持用 MDX（Markdown + JSX） 写文档。
  • 漏洞在于：其 服务器端 MDX 渲染引擎 会对用户提供的 MDX 文件里的 inline JSX 表达式 做服务端执行，而且没有正确限制，导致任意代码执行。国家漏洞数据库
  • 影响范围是：在 2025-11-15 之前的托管服务（NVD 直接给到 CVSS 9.8 / 8.3）。
  • 典型利用方式：攻击者上传/修改某一篇 MDX 文档，在 JSX 表达式里拼 payload，渲染时就能跑任意后端代码。CVE Details
  • WAF 绕过点 ：
    • 攻击流量就是"上传一篇带 JSX 的文档"，从 HTTP 视角看只是一大坨文本；
    • 漏洞发生在 MDX→JSX→服务器执行 的内部链路上，WAF 不理解 MDX/JSX 语义，更别说做 AST 级别白名单；
    • 这是典型的"模板系统作为 SaaS 平台底座"，攻击面完全超出了传统 Web 表单的范畴。

CVE-2025-53833（LaRecipe，Laravel 文档系统 SSTI → RCE） wiz.io+1

  • LaRecipe 是嵌进 Laravel 的文档系统，开发者可以在应用里用 Markdown 写文档。
  • 2.8.1 之前版本会在服务端把这些 Markdown / 配置内容送进模板引擎（Blade/Twig）渲染，但没有正确 neutralize 特殊模板语法，导致 SSTI，可直接 RCE。国家漏洞数据库+1
  • NVD/厂商都明确：攻防双方都把这个洞当成 能读 env / DB / 执行系统命令 的高危 RCE，CVSS 直给 10 分。
  • WAF 绕过点 ：
    • 典型访问路径是 /docs/... 这种内部文档路由，payload 藏在「文档内容」里；
    • 很多场景下是内部知识库，只对内网开放，本身就绕过了大部分 HTTP WAF；
    • 即使有 WAF，在不理解文档语法的情况下，很难区分"正常模板标签" vs "恶意模板 gadget"。

CVE-2025-66294（Grav CMS，Twig 沙箱绕过 SSTI） GitHub+1

  • Grav 用 Twig 做模板，并提供 cleanDangerousTwig() 这个函数，用一个正则把一些危险的 Twig 函数/调用注释掉，以为做了"沙箱"。GitHub+1
  • 实际上问题有两点：
    1. 正则只处理简单形态，对嵌套调用无能为力；
    2. 系统又允许 evaluate / evaluate_twig 这类"执行 Twig 代码"的包装函数。
  • 于是攻击者可以构造 payload：把危险调用塞在 evaluate_twig() 里，绕过 cleanDangerousTwig，例如：
    {``{ grav.twig.twig.registerUndefinedFunctionCallback('system') }} ... {``{ grav.twig.twig.getFunction('id') }}，最终拿到命令执行。GitHub
  • Metasploit/官方 advisory 也提到，经由另一个 Broken Access Control 洞（CVE-2025-66301）可以让普通 editor 改 form 的 process section，从而在某些场景下做到"低权 → RCE"。Rapid7+1
  • WAF 绕过点 ：
    • payload 全是合法 Twig 语法，跟普通模板写法高度相似；
    • 触发点是在 Grav 表单处理 / form message 渲染阶段，HTTP 请求里只是一段 YAML/表单字段；
    • 所谓"沙箱已开"让很多人掉以轻心，实际上是自实现 regex 沙箱出了问题，WAF 完全帮不上忙。

CVE-2025-25362（spacy-llm，LLM Prompt 模板中的 Jinja SSTI） hacktivesecurity.com

  • spacy-llm 是 spaCy 的 LLM 集成插件，用来给 LLM 生成 prompt。
  • 漏洞核心：用的是默认 jinja2.Environment()，而不是 Sandboxed/ImmutableSandboxed 环境 ，然后把配置里的 template 字段直接当 Jinja 模板编译。hacktivesecurity.com
  • 如果攻击者能控制这个 template（比如通过不安全的配置管理、远程项目导入等），就可以塞 payload：
    {``{ self.__init__.__globals__.__builtins__.__import__('os').popen('id').read() }}
    在生成 prompt 时，Jinja 会直接执行系统命令。hacktivesecurity.com
  • 这类漏洞完全发生在 AI/LLM 管道内部：配置 → 模板渲染 → 把结果发给 LLM，跟传统 Web 前端没半毛钱关系。
  • WAF 绕过点 ：
    • 攻击载荷可能来自配置文件、消息队列、gRPC 调用等，压根不经过 HTTP；
    • 即便是 Web 接口提交配置，payload 也是"我换了一段 prompt 模板"，从 HTTP 视角看仍然是正常文本。
    • 这是典型的"旧漏洞模型（Jinja SSTI）+ 新场景（LLM prompt pipeline）"。

CVE-2025-51991（XWiki 管理界面 Velocity SSTI） 国家漏洞数据库+2GitHub+2

  • XWiki 一直支持 Apache Velocity 作为模板引擎。
  • 本洞出在 管理后台的 Global Preferences → HTTP Meta Info 字段 ：管理员填入的内容会作为 Velocity 模板在服务端渲染，但没有做 sandbox / 白名单。国家漏洞数据库+1
  • 拿到管理员的场景下，攻击者可以在 Meta Info 里直接注入 Velocity 代码，借由模板访问系统资源、读敏感配置甚至执行远程代码。
  • WAF 绕过点 ：
    • 这是典型"配置项里的模板"，且只对管理员开放，一般不会被 WAF 算作高风险入口；
    • payload 形态就是一串 Velocity 语法混在 <meta> 标签内容里，很难写通用规则不误杀。

2025 年 SSTI 的几个共性趋势

综合这些 CVE，可以大致看到：

  1. 业务面从"页面模板"扩展到"文档/配置/LLM Prompt"
    • ERPNext / XWiki：把合同条款、HTTP Meta Info 当模板；
    • Tandoor / LaRecipe / Grav：把文档、表单 message 当模板；
    • Mintlify / spacy-llm：把 MDX / Prompt 也当模板。hacktivesecurity.com+3OffSec+3wiz.io+3
      → "能编辑内容"的地方越来越多地被视为代码的一部分，而不是纯数据。
  2. "沙箱已开"≠ 安全：Jinja/Twig/Velocity 沙箱被错用或绕过
    • ERPNext：SandboxedEnvironment 里又暴露了 frappe.db.sql 等危险全局；国家漏洞数据库+1
    • Grav：依赖正则去过滤 Twig 函数，结果被嵌套调用和 evaluate_twig 绕过；GitHub+1
    • XWiki：干脆没有 sandbox，把 Velocity 全权交给管理员字段。国家漏洞数据库+1
  3. 攻击面大部分在"已认证 / 内部 / SaaS 后端链路"，WAF 天然弱势
    • 低权用户/编辑/管理员在后台配置里改模板、改文档，payload 通常看起来就是"复杂一点的富文本"；
    • LLM/MDX/spaCy 这类链路甚至都不走传统 HTTP 网关，或者只经过一次管理 API，之后就是内部微服务调用。国家漏洞数据库+2hacktivesecurity.com+2
  4. 模板语言本身的"元编程能力"被系统性利用
    • 利用 Jinja2/Twig/Velocity 访问 __globals__、环境变量、注册回调、读取文件等，把模板当成半个脚本语言来打。OffSec+2hacktivesecurity.com+2

为什么"关掉 <script> / 简单禁用 {``{ }} / 开沙箱"已经不够了？

类比你前面 SQL 注入里说的"参数化是必要非充分条件"，对 SSTI 现在也可以这么看：

  1. "只要 escape {``{ }} 就安全"是过时模型
    • 很多场景里，字段本身就 应该 支持模板（合同条款、系统消息、表单 message、Prompt 模板），你不可能全禁用模板语法；
    • 真正要做的是：
      • 明确哪些字段是"模板字段"，只能由极少数高信任角色编辑；
      • 模板里暴露的对象/函数要 强白名单（不能把整棵 app context 暴露给模板）。
  2. "用 sandbox 环境就行"在实现层面极易翻车
    • ERPNext 的 Jinja 沙箱因为 get_safe_globals() 放飞自我，直接把 DB API 暴露出去；国家漏洞数据库+1
    • Grav 的 Twig 沙箱把复杂度压在一个 regex 上，实际被 nested call + evaluate 系列完全绕过；GitHub+1
    • 这类问题不是 WAF 能补救的，只能靠 模板环境的最小暴露 + 安全审计。
  3. WAF 的"模板关键字签名"基本只能当心理安慰
    • 你可以写规则拦 {``{ self.__init__.__globals__ 或 popen(，但：
      • 很多生产流量里真的就会出现 {``{ variable }}、循环、if 等正常模板语法；
      • 攻击者可以拆 payload、用变量/过滤器/嵌套函数组合，规避简单关键字；
      • 大量 SSTI 发生在内部链路（LLM、批处理、后台任务），根本不经过 WAF。国家漏洞数据库+1
相关推荐
四谎真好看17 小时前
JavaWeb 学习笔记（Day02）之Vue
笔记·学习·vue·学习笔记·javaweb
南屿欣风17 小时前
Sentinel 资源异常处理优先级笔记
spring boot·笔记·sentinel
淬炼之火17 小时前
笔记：Contrastive Object-Aware Fusion
图像处理·笔记·计算机视觉·多模态·图像融合
乐观主义现代人17 小时前
redis 源码学习笔记
redis·笔记·学习
YJlio17 小时前
Registry Usage (RU) 学习笔记（15.5）：注册表内存占用体检与 Hive 体量分析
服务器·windows·笔记·python·学习·tcp/ip·django
rgc_520_zyl17 小时前
idea离线模式使用备忘录
笔记
超龄超能程序猿18 小时前
Docker常用中间件部署笔记：MongoDB、Redis、MySQL、Tomcat快速搭建
笔记·docker·中间件
时兮兮时18 小时前
CALIPSO垂直特征掩膜（VFM）—使用python绘制主类型、气溶胶和云的子类型
笔记·python·calipso
时兮兮时18 小时前
MODIS Land Cover (MCD12Q1 and MCD12C1) Product—官方文档的中文翻译
笔记·mcd12q1
热门推荐
01GitHub 镜像站点02安娜的档案(Anna’s Archive) 镜像网站/国内最新可访问入口（持续更新）03Linux下V2Ray安装配置指南04Labelme从安装到标注：零基础完整指南05jdk21下载、安装（Windows、Linux、macOS）06【踩坑笔记】50系显卡适配的 PyTorch 安装07手把手教你通过Gemini3 pro 学生认证，白用一年，手慢无！08Opencode CLI 安装成功,但是启动失败09GitLab 零基础入门指南：从安装到项目管理全流程10Claude Code Plan 模式完全指南：从入门到精通