F5 BIG-IP APM Malware Uses In-Memory PHP Shells (2026)

A rootkit that never touches disk

Security researchers have found a Linux rootkit aimed at F5 BIG-IP APM systems that hooks into PHP file loading and plants a memory-resident web shell designed to avoid leaving malicious artefacts on disk for conventional scanners to catch. Reports identify three PHP scripts the rootkit hooks into — apm_css.php3, full_wt.php3, and webtop_popup_css.php3 — on affected appliances.

According to Sophos, F5 linked the activity cluster c05d5254 with appliances vulnerable to CVE-2025-53521. BleepingComputer reported that the malware avoids writing malicious code to disk and assessed it as a likely second-stage payload deployed after exploiting that flaw.

From denial-of-service to unauthenticated RCE

CVE-2025-53521 has had a two-stage disclosure history. F5 initially disclosed it in mid-October 2025, including on 15 October in its advisory, as a denial-of-service flaw. In updated guidance dated 27 March 2026, F5 stated — quoted by NCSC and others — that new information had led it to reclassify the flaw as remote code execution, and that it had been exploited.

F5's updated advisory, as quoted by NCSC, assigns CVSS 3.1: 9.8 and CVSS 4.0: 9.3. The NCSC describes it as an unauthenticated remote code execution vulnerability affecting F5 BIG-IP Access Policy Manager. That reclassification matters for risk registers: a flaw logged internally as "DoS, low priority" in late 2025 needs to be re-scored as critical, exploited RCE today.

Why disk-based scanning misses this

The whole point of the in-memory approach is to defeat the controls most estates already have. If your monitoring stack relies primarily on file-integrity checks and signature-based scans of disk artefacts, a shell that never writes a file simply won't trip those alarms.

This is a strong argument for UK teams to enhance their managed detection and response capabilities specifically around memory forensics — process memory dumps, anomalous PHP interpreter behaviour, and unexpected child processes spawned from the APM web service — rather than assuming appliance-level AV coverage is sufficient. What remains unsettled is the complete attack chain: public reporting so far connects the malware to CVE-2025-53521 without establishing that every compromised device fell through the exact same entry point, so defenders shouldn't assume one indicator will catch everything.

Which BIG-IP APM versions are exposed

Vulnerable builds cut across several BIG-IP release lines — 17.5.0–17.5.1, 17.1.0–17.1.2, 16.1.0–16.1.6, and 15.1.0–15.1.10 — with fixed versions released as 17.5.1.3, 17.1.3, 16.1.6.1, and 15.1.10.8.

Given confirmed active exploitation, organisations still running unpatched builds in these ranges should treat this as an active exploitation scenario, not a theoretical one. Teams managing mixed-version estates should implement robust vulnerability management strategies that can quickly identify every APM instance still on a vulnerable branch, including appliances that may have drifted from a standard patch baseline.

Immediate steps for UK buyers running BIG-IP

The NCSC has pressed UK organisations to act without delay to address CVE-2025-53521. Given the fileless nature of the follow-on malware, patching alone won't clear an already-compromised appliance — memory needs to be checked, not just the filesystem.

• •Patch to the fixed versions (17.5.1.3, 17.1.3, 16.1.6.1, or 15.1.10.8) without delay
• •Audit BIG-IP access and authentication logs for anomalous sessions predating patching
• •Add memory-forensic capability to detect in-memory PHP injection, not just disk scans
• •Treat any pre-patch appliance as potentially compromised and inspect running processes

The lifecycle and procurement angle

This incident is also a reminder that load balancer and access management appliances sit on a long refresh cycle, which means vulnerable versions can linger in production far longer than on typical servers. Organisations running older BIG-IP hardware that's approaching or past vendor support should read our guidance on keeping end-of-support hardware secure and consider whether they can explore options for third-party maintenance for their F5 BIG-IP estate to bridge patching gaps safely.

More broadly, edge appliances like APM are a prime example of why buyers need to understand attack surface management to mitigate future risk — a single unauthenticated RCE on an internet-facing access gateway can undo segmentation elsewhere in the network.