CVE-2025-53521: BIG-IP APM unauthenticated remote code execution

What it is

BIG-IP Access Policy Manager (APM) handles remote access and SSO. F5’s CVE record says that when an APM access policy is configured on a virtual server, specific malicious traffic can lead to remote code execution. The weakness is a stack-based buffer overflow (CWE-121). It needs no login and no user interaction: CVSS 9.8 (v3.1), 9.3 (v4.0).

It matters because of how it was handled. F5 published it in October 2025 as a denial of service. In late March 2026, F5 reclassified it as RCE and said it is exploited. CISA added it to the KEV catalog on March 27, 2026. If you read the first advisory and filed this as low priority, revisit it.

Attackers are reported to be deploying webshells on unpatched devices (BleepingComputer). The webshell is described as running in memory, which makes file-based checks unreliable (SOCRadar, citing F5). Defused Cyber saw scanning of a device-info endpoint, reported by Hadrian. We found no public proof of concept and no attribution to a named group. CISA lists ransomware use as unknown.

F5 credits Kristian Vlaardingerbroek, Hugo Trippaers and others at Schuberg Philis, plus Bart Vrancken, Fox-IT and the Dutch NCSC.

Am I affected?

You’re exposed if both are true:

1. You run BIG-IP with the APM module on an affected version (see the table above).
2. An APM access policy is attached to a virtual server.

Versions past End of Technical Support were not evaluated by F5, so treat them as exposed.

The fixed versions come from F5’s CVE record. Some secondary sources list different fixed releases (for example 17.5.2 or 16.1.7). Use the numbers in the table, and confirm against K000156741 before you schedule the change.

To find exposure, list your virtual servers and see which have an access policy attached, then check which of those are reachable from the internet or from untrusted networks. We could not open F5’s advisory, so we have no vendor menu path or tmsh command to give you here. F5’s article K000156741 describes the check.

What to do

1. Upgrade to 17.5.1.3, 17.1.3, 16.1.6.1 or 15.1.10.8 or later on your branch. Start with APM virtual servers that face the internet.
2. Inventory every APM system and note its version and whether an access policy is attached. Don’t forget standby units and lab or disaster-recovery devices.
3. Restrict management access (the configuration utility and iControl REST) to known admin ranges. Hadrian recommends this; it does not fix the bug.
4. Assume compromise if you were exposed. Check for the indicators below before and after patching. A patch does not remove a webshell or an attacker’s persistence.
5. If you find signs of compromise, follow F5’s guidance: use your incident-handling and forensic process, collect evidence first, then recover. If you can’t bound the compromise window, rebuild the device rather than clean it. Rotate admin, service and API credentials, and any secrets the device handled.

F5’s CVE record lists no workaround. We found none in the sources we opened.

Detection

F5 advises checking disks, logs and terminal history (BleepingComputer). Indicators published in F5’s K000160486, as relayed by SOCRadar:

• The files /run/bigtlog.pipe or /run/bigstart.ltm.
• Hash, size or timestamp changes on /usr/bin/umount and /usr/sbin/httpd. Compare against a known-good copy from the same version.
• Local-user activity against iControl REST that originates from localhost.
• Attempts to disable SELinux.
• HTTP 201 responses that use a CSS content type as camouflage.

From Hadrian’s write-up, which is less authoritative:

• Requests to /mgmt/shared/identified-devices/config/device-info, including from outside your admin ranges. Defused Cyber reported scanning here after the KEV listing.
• iControl REST requests to /mgmt/* from sources outside your private and admin ranges.
• New or changed authorized_keys files for root or tmadmin.
• An apmd process that spawns shells or runs binaries from unusual paths.
• Outbound connections from the appliance on unusual ports, or large sustained outbound transfers.

Check logs back to at least October 15, 2025, the first public disclosure, but pay most attention to the period from late March 2026.