F5 BIG-IP APM 漏洞惊魂：CVE-2025-53521 引发的运维凌晨应急响应

那是一个周六的凌晨三点。

阿峰本来已经躺下了，手机屏幕突然亮起来——是公司内部运维群的消息。

他瞟了一眼，睡意全消。

「告警：F5 BIG-IP APM 设备异常流量，TMM 进程 CPU 持续 100%」
「有人监控到吗？」
「@阿峰，你那边呢？」

他一骨碌坐起来，连拖鞋都来不及穿，直接打开了笔记本。

公司的 F5 BIG-IP APM 集群是整个企业 VPN 和零信任接入的核心。几千名员工通过它远程办公，十几个核心业务系统的访问策略全在上面。

如果这玩意儿挂了，或者被攻进去了……

阿峰不敢再往下想。

第一眼看到的，是一个不该存在的请求

他登上了 BIG-IP 的管理控制台，打开了流量日志。

日志刷得很快，太快了。

他往上翻了翻，试图找到异常开始的时间节点。然后他看到了一条很奇怪的请求：

2026-04-05 02:47:13 [TMM] SRC=203.0.113.88 DST=10.10.100.5:443
METHOD=POST URI=/my.policy?type=apmui
CONTENT-LENGTH=1048576
STATUS=... [TMM process stalled]

POST /my.policy。

他愣了一下。这个路径……是 APM 的访问策略页面，正常用户应该是 GET 请求，而且有 Session 认证。

但这个请求：

1. 是 POST
2. Content-Length 写的是 1MB
3. 没有任何 Session Token

而且，这不是一条请求，是 成千上万条。

来自不同的源 IP，同样的 URI，同样的模式。

阿峰的后背开始冒冷汗。

「TMM 崩了，但崩之前……它在做什么？」

他叫醒了安全组的同事小林。

「你说 TMM 进程满了？」小林听完，语气也变得凝重，「给我看看 TMM 的 core dump。」

BIG-IP 的 TMM（Traffic Management Microkernel）是整个流量处理的核心进程——SSL 卸载、负载均衡、访问策略执行，全都在这里。

小林拉出了 core dump 文件，开始分析。

沉默了大约十分钟。

然后他发来了一行话：

「阿峰，这不是 DoS。TMM crash 之前……执行了不该执行的代码。」

阿峰盯着这句话看了三秒钟，才意识到它的含义。

不是 DoS。是 RCE。

有人在他们的 F5 上执行了任意代码。

漏洞真相：一个潜伏已久的「炸弹」

后来他们才知道，这个漏洞早在 2025 年 10 月就被 F5 官方悄悄打了补丁，编号是：

CVE-2025-53521

CVSS 基础分：9.8（满分10，严重级）

F5 的官方描述很克制，但内容触目惊心：

"当 BIG-IP APM 访问策略配置在虚拟服务器上时，特制的恶意流量可导致 TMM 进程的资源分配异常，从而触发拒绝服务或远程代码执行。"

翻译成人话就是：

只要你的 F5 配置了 APM 策略，攻击者不需要账号、不需要认证、不需要任何权限，发一个精心构造的 HTTP 请求，就能在你的 F5 上跑任意代码。

而阿峰公司的 F5 版本？

BIG-IP 16.1.3。

正好在受影响范围里，而且他们……从来没打过这个补丁。

为什么这个漏洞这么可怕？

让阿峰和小林彻底睡不着的，不仅仅是这次事件本身，而是当他们深入理解了 CVE-2025-53521 的技术细节之后。

APM 是什么？为什么是高价值目标？

BIG-IP APM（Access Policy Manager）是 F5 旗下最重要的产品之一，被数千家企业用于：

• SSL VPN 接入：替代传统 VPN，员工通过 APM 远程登录内网
• 零信任访问控制：基于用户身份、设备状态、位置等多因素控制访问
• Web 应用网关：统一管理 Web 应用的认证与授权
• SSO 单点登录：集成 AD/LDAP/SAML

换句话说，APM 是企业网络的门卫+钥匙+警报系统三合一。

攻破 APM，就等于站在了企业网络的十字路口。这类涉及核心网络/系统设备的漏洞，往往牵一发而动全身。

漏洞根因：TMM 的资源分配没有节流

根据技术分析（CWE-770：不受限制的资源分配），漏洞的根因在于：

BIG-IP APM 在处理 /my.policy 接口的特定 HTTP 请求时，没有对 Content-Length 超大的请求做有效节流，导致 TMM 进程在为请求分配内存时触发异常。

这个异常不是简单的 crash，而是一个 可控的内存破坏原语——在特定构造下，攻击者可以利用它实现代码执行。

正常请求处理流程：
Client → BIG-IP Virtual Server → APM Policy → Backend

攻击流程：
攻击者 → 构造特制 POST 请求（无认证）
        → 目标：/my.policy 接口
        → Content-Length: 异常值
        → TMM 资源分配异常 → heap corruption
        → 控制流劫持 → 任意代码执行（RCE）

CISA 已在野确认：不是理论，是真实攻击

2026 年 3 月 27 日，CISA 正式将 CVE-2025-53521 加入 KEV（已知被利用漏洞）目录。

这意味着：不是「可能被利用」，是「已经在被利用了」。

EPSS 评分：19.16%，位于所有 CVE 的前 5% 被利用概率。

受影响版本速查

请立刻对照以下表格，检查你的 BIG-IP APM 版本：

受影响版本范围	修复版本	说明
17.5.0 ~ 17.5.1	17.5.1.3	必须升级
17.1.0 ~ 17.1.2	17.1.3	必须升级
16.1.0 ~ 16.1.6	16.1.6.1	必须升级
15.1.0 ~ 15.1.10	15.1.10.8	必须升级

官方安全公告编号：F5 Security Advisory K000156741

BIG-IP 版本查询命令：

# 在 BIG-IP 命令行执行
tmsh show sys version

# 或查看 TMOS 版本文件
cat /etc/f5-release

你现在需要做的四件事

第一件事：确认你是否有 F5 BIG-IP APM

# 确认是否启用了 APM 模块
tmsh show sys provision | grep apm

# 输出示例（已启用）：
# apm    nominal

如果 apm 状态为 nominal 或 dedicated，你受影响。

第二件事：检查日志，确认是否已被探测

# 检查 APM 访问日志中的异常 POST 请求
grep -i "my.policy" /var/log/apm | grep "POST" | tail -100

# 检查 TMM 进程 crash 日志
ls -lt /var/core/  
# 如果有最近的 .core 文件，立即分析

# 检查异常大流量请求
grep "content-length" /var/log/ltm | awk '{print $NF}' | sort -rn | head -20

第三件事：临时缓解（无法立即打补丁时）

方法一：在虚拟服务器前置 iRule，拦截异常请求

when HTTP_REQUEST {
    # 拦截对 /my.policy 的异常 POST 请求
    if { [HTTP::method] eq "POST" and [HTTP::uri] starts_with "/my.policy" } {
        set cl [HTTP::header Content-Length]
        if { $cl > 65536 } {
            # Content-Length 超过 64KB 的 POST，直接丢弃
            reject
            log local0.warn "CVE-2025-53521 mitigation: blocked oversized POST from [IP::client_addr]"
        }
    }
}

将此 iRule 挂载到配置了 APM 策略的 Virtual Server 上。

方法二：启用 HTTP Request Policy 中的请求大小限制

# 在 APM Profile 中设置最大请求体大小
tmsh modify apm profile access <your-profile-name> max-request-body-size 65536

第四件事：打补丁（最终解决方案）

# 1. 下载对应版本的补丁包（从 F5 官方下载页，需要有效支持合同）
# 补丁包命名示例：BIGIP-16.1.6.1-0.0.XX.iso

# 2. 上传补丁到 F5
scp BIGIP-16.1.6.1-0.0.XX.iso admin@<F5-MGMT-IP>:/shared/images/

# 3. 在 BIG-IP 上安装（切换到备用 boot slot）
tmsh install sys software image BIGIP-16.1.6.1-0.0.XX.iso volume HD1.2

# 4. 设置启动分区并重启
tmsh modify sys software volume HD1.2 active

# 5. 验证版本
tmsh show sys version | grep Version

重要提示：升级前务必备份配置文件 tmsh save sys config，并在维护窗口执行。HA 双机环境建议先升级 Standby，再做 Failover 后升级原 Active。

尾声：阿峰后来怎么样了？

天亮了。

阿峰和小林花了整整六个小时，做了以下几件事：

1. 隔离了受攻击的 F5 设备，临时切换到备用链路
2. 分析了 core dump，确认 TMM 被利用，但攻击者在持久化阶段被 EDR 阻断——他们运气还不算太差
3. 紧急打了 16.1.6.1 的补丁，重新上线
4. 全面清查了 F5 上的访问策略日志，确认哪些账号在攻击窗口期内曾被访问
5. 向公司安全委员会递交了应急处置报告

事后，阿峰在内部分享会上说了一句话：

"F5 是个好产品。但我们以为它在门口站着，就万事大吉了。
其实门卫本身，也需要有人盯着。"

这一夜，他理解了一件事——

零信任的零信任，是你不能无条件信任任何一个网络设备，包括你最贵的那台。

对于每一个奋战在一线的运维和安全工程师而言，保持对威胁的敏感、建立有效的漏洞响应流程，远比单纯依赖某个“坚固”的设备更重要。如果你也在处理类似的棘手问题，或想分享你的应急故事，欢迎来云栈社区与更多同行交流探讨。

快速行动清单

• [ ] 确认 BIG-IP APM 版本，对照受影响列表
• [ ] 检查 /var/log/apm 和 /var/core/ 是否有异常迹象
• [ ] 如无法立即升级，部署 iRule 临时缓解
• [ ] 制定升级计划，目标版本：17.5.1.3 / 17.1.3 / 16.1.6.1 / 15.1.10.8
• [ ] 更新 SIEM/WAF 规则，监控 /my.policy POST 请求
• [ ] 与 F5 支持联系，获取补丁下载权限（官方公告 K000156741）