On October 15, 2025, F5 published security advisory K000148735 disclosing CVE-2025-53521 as a denial-of-service vulnerability in BIG-IP Access Policy Manager (APM), with a CVSS v3.1 score of 7.5. On March 28, 2026, F5 re-issued the advisory with the score escalated to 9.8 and the classification upgraded to remote code execution after the vendor confirmed exploitation in the wild during March 2026. CISA added CVE-2025-53521 to its Known Exploited Vulnerabilities catalog on March 28, 2026, with a remediation due date of March 30, 2026 — leaving defenders 48 hours to apply a patch that, for organizations that took the October 2025 advisory at face value, was already installed. This advisory is a case study in late-cycle severity changes: defenders cannot treat the initial CVSS as final.
What does the vendor advisory say?
F5's revised K000148735 describes CVE-2025-53521 as a vulnerability in the BIG-IP APM access-policy evaluation engine. When a virtual server is configured with a BIG-IP APM access policy, specifically crafted malicious traffic can bypass security boundaries and achieve remote code execution under the tmm (Traffic Management Microkernel) process context. The original October 2025 advisory characterized the impact as a kernel panic and box reload (denial of service); the revised March 2026 advisory confirms that the same trigger, with different payload framing, achieves arbitrary code execution. F5's advisory text reads: "Based on new information obtained in March 2026, the vendor has revised the severity score and is recommending immediate patching for all customers, including those who applied the October 2025 advisory's denial-of-service mitigations rather than the full patch." Patches released in October 2025 work correctly — customers who applied the patched build at that time are not exposed to the reclassified RCE.
Which versions are affected and which are patched?
CVE-2025-53521 affects BIG-IP versions across the APM-enabled platform:
- BIG-IP 17.x — affected versions 17.0.0 through 17.1.1.4; fixed in 17.1.1.5 (October 2025) and 17.1.2 (February 2026 cumulative)
- BIG-IP 16.x — affected versions 16.0.0 through 16.1.5.2; fixed in 16.1.5.3 (October 2025) and 16.1.6 (February 2026 cumulative)
- BIG-IP 15.x — affected versions 15.1.0 through 15.1.10.5; fixed in 15.1.10.6 (October 2025) and 15.1.11 (February 2026 cumulative)
- BIG-IP 14.x — END OF LIFE, no fix; migrate to 15.1.11 minimum
- BIG-IP 13.x and earlier — END OF LIFE
The vulnerability is only reachable when APM is licensed and a virtual server has the access-policy attribute populated. BIG-IP LTM, ASM, AFM, and DNS modules without APM licensing are not exposed to this CVE. Verify the running version with tmsh show sys version from the CLI, and verify APM module status with tmsh list sys provision apm.
Is it in CISA KEV and what is the EPSS score?
CISA added CVE-2025-53521 to KEV on March 28, 2026, with a remediation deadline of March 30, 2026 — a 48-hour window matching the urgency of CVE-2022-1388 (also F5 BIG-IP, also pre-auth RCE). The KEV entry tagged the vulnerability known to be used in ransomware campaigns: Unknown but referenced the F5 confirmation of in-the-wild exploitation. EPSS at the original October 2025 disclosure was 0.07; at the March 2026 reclassification it jumped to 0.71 within 48 hours as red-team frameworks integrated the RCE trigger pattern. CISA's accompanying alert urged operators who had not yet applied the October 2025 patch to assume any internet-reachable BIG-IP APM device was compromised.
How do you find vulnerable instances in your SBOM?
BIG-IP appliances expose their version through the iControl REST API as well as the CLI. For SBOM-driven inventories, ingest the /mgmt/tm/sys/version endpoint into the asset graph nightly. Safeguard saved query:
# Identify every BIG-IP APM device still on a pre-fix build
safeguard scan --cve CVE-2025-53521 --product big-ip-apm
# Filter to APM-licensed devices with at least one access-policy-bound virtual server
safeguard assets list \
--filter "vendor=f5 AND product=big-ip AND module=apm AND has-access-policy=true" \
--include-cve CVE-2025-53521
For shops without firmware SBOMs, the lightest enumeration is a scripted iControl REST call per management IP that returns version and module-provisioning state, joined against the fixed-build matrix. F5 BIG-IQ users can query the central management console for the device inventory across the entire estate.
What is the recommended patch rollout?
F5's recommended sequence:
- Snapshot the BIG-IP configuration with
tmsh save sys configand back up/configvia the standard UCS archive (tmsh save sys ucs /var/local/ucs/pre-patch.ucs). - For HA pairs (active/standby), upgrade the standby unit first. Stage the patched image with
tmsh install sys software image <hotfix>.iso volume HD1.2. Reboot the standby into the new volume withtmsh reboot volume HD1.2. - Force failover after verifying the standby comes up healthy in the new version:
tmsh run sys failover standby. - Repeat the upgrade on the new standby (which was the original active).
- Verify both units with
tmsh show sys version. - Re-test access policies against a representative user population to confirm no regressions.
For organizations that had already applied the October 2025 hotfix, no action is required beyond verifying the running version is 17.1.1.5, 16.1.5.3, or 15.1.10.6 minimum. For organizations on the February 2026 cumulative (17.1.2, 16.1.6, or 15.1.11), no action is required.
Compensating control while patching: disable APM access policies on internet-facing virtual servers temporarily, or restrict source IP ranges via a top-level firewall rule. Neither closes the vulnerability but they shrink the trigger surface during the rollout window. F5's WAF (ASM) signature ID 200103024 (released March 28, 2026) detects and blocks the exploit pattern at the data plane — apply it if ASM is provisioned on the same device, but do not treat it as a substitute for the upgrade.
What detections does the vendor or CISA publish?
F5 published signature IDs 200103024 through 200103027 in the March 2026 attack signature update for BIG-IP ASM/Advanced WAF. CISA AA26-087A includes a Sigma detection for the access pattern visible in the BIG-IP /var/log/apm and /var/log/ltm logs, which defenders should import directly:
# Source: CISA AA26-087A F5 BIG-IP APM exploitation, 2026-03-28
title: F5 BIG-IP APM Suspicious Access Policy Pre-Auth POST
status: stable
logsource:
product: f5
service: apm
detection:
selection:
log_message|contains:
- 'Access policy evaluation: result=error'
- 'Session-tmm process consuming abnormal CPU'
- 'Access policy result: deny, action: terminate'
threshold:
src_ip|count_gt: 10
in_window: 60s
condition: selection AND threshold
fields:
- src_ip
- virtual_server
- access_policy
- session_id
level: high
F5 Labs published a YARA rule pack for the post-exploitation implant observed in March 2026 victim telemetry, including in-memory rootkit indicators that persist across tmm process restarts but not across full device reboots.
How Safeguard Helps
Safeguard ingests F5 iControl REST output from every BIG-IP device registered through the SCM/network-asset integration, parsing version, module provisioning state, and virtual-server access-policy bindings into a normalized SBOM. The default policy gate fails any change-management ticket promoting a BIG-IP APM image below the fixed-build table, and a built-in compliance check verifies the device has been rebooted into the new volume after the upgrade — catching the most common F5 patching mistake where the new image is installed but the device is still running from the old volume. Griffin AI scores BIG-IP devices by APM exposure, virtual-server count with access policies, and internet-reachability of the data plane, surfacing the highest-blast-radius devices first. VEX statements from F5 are auto-ingested for devices without APM licensing or without access-policy-bound virtual servers, suppressing dashboard noise. The ServiceNow connector files a per-HA-pair change ticket with the patched ISO hash, the CISA KEV deadline copied into the SLA field, the ASM signature update version pinned in the body, and the volume-reboot verification check attached as evidence — turning a 48-hour emergency into a tracked workflow.