ForumsExploitsCVE-2025-53521: F5 BIG-IP APM RCE Now in CISA KEV - Active Exploitation Confirmed

CVE-2025-53521: F5 BIG-IP APM RCE Now in CISA KEV - Active Exploitation Confirmed

DNS_Security_Rita 3/28/2026 USER

Just saw the alert drop on Friday: CISA has added CVE-2025-53521 to the Known Exploited Vulnerabilities (KEV) catalog. This one impacts F5 BIG-IP Access Policy Manager (APM), and with a CVSS v4 score of 9.3, it’s as critical as it gets.

CISA is citing evidence of active exploitation, specifically noting that this flaw allows for Remote Code Execution (RCE). If you have APM provisioned, especially on internet-facing edges, assume you are in the crosshairs.

Immediate Checks

First, verify if APM is actually provisioned on your devices. If it's not, the attack surface drops significantly.

tmsh show sys provision | grep apm

Detection Logic

We need to start hunting for unusual activity on APM endpoints. While the specific exploit payload isn't fully public yet, we should be watching for anomalous URI requests or unexpected process executions.

Here is a KQL snippet for Sentinel/defenders to check for spikes in traffic to APM paths:

F5BigIPLogs
| where Uri has "my.policy" or Uri has "oauth" 
| where RequestMethod == "POST"
| summarize Count() by SourceIP, bin(Timestamp, 10m)
| where Count_ > 50 
| order by Count_ desc

Given the severity and the "active exploitation" tag, CISA mandates patching by the deadline. However, we all know BIG-IP maintenance windows can be tricky.

How is everyone handling the rollout? Are you forcing an emergency maintenance window, or relying on WAF signatures until you can schedule the reboot?

LO
LogAnalyst_Pete3/28/2026

We're relying on our ASM (Advanced WAF) signatures for now. F5 released a signature update specific to this CVE yesterday. It's not a perfect fix, but it buys us time to schedule the maintenance windows for next weekend. Rebooting a pair of active-active load balancers in the middle of the week is a career-limiting move in my org.

K8
K8s_SecOps_Mei3/28/2026

Good call on the URI check. I'd also add a hunt for odd child processes spawned by the httpd parent. If RCE is achieved, they usually drop a webshell or reverse shell.

ps aux | grep httpd | grep -v 'root\|nobody'


If you see `httpd` spawning bash or python, you're already pwned.
BA
BackupBoss_Greg3/28/2026

From a pentester perspective, APM is often the 'crown jewel' on the perimeter. It's directly exposed to the internet and handles authentication. If I see this open, it's the first thing I hit. Don't assume your internal network segmentation will save you if ADM/APM is compromised—these devices often have excessive trusted routes to internal backends.

RE
RedTeam_Carlos3/30/2026

To add to Mei's point, verify if the httpd processes correspond with spikes in the APM access logs. Attackers often fuzz the /my.policy endpoint before landing the shell. If you grep for unusual POST requests around the time of the process spawn, you can confirm the vector.

grep -E "POST /my.policy|/vdesk/hangup" /var/log/apm/*.log | tail -50

This helps filter out the noise from standard user traffic.

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created3/28/2026
Last Active3/30/2026
Replies4
Views51