F5 BIG-IP Access Policy Manager exists to decide whether a remote user gets in. CVE-2025-53521 lets an attacker run code on it without logging in at all. The fixed versions have been available since October 2025, CISA added the flaw to its Known Exploited Vulnerabilities catalog on 28 March 2026, and on 7 September 2026 the Shadowserver Foundation still counted 795 internet-exposed endpoints vulnerable to it.
On 8 September, Sophos published an analysis of what has been landing on some of them: an implant that hides a PHP web shell in Apache's memory rather than on disk, and that Sophos observed embedded in the appliance's own upgrade images.
What actually happened
CVE-2025-53521 affects BIG-IP APM systems with an access policy configured on a virtual server, which is the ordinary configuration for a published remote-access webtop. No credential is required, and SecurityWeek reports the reclassified CVSS score as 9.3.
| Date | Event |
|---|---|
| 15 October 2025 | F5 publishes CVE-2025-53521, classified as a denial-of-service issue |
| 27 March 2026 | F5 reclassifies it as remote code execution. Exploitation confirmed |
| 28 March 2026 | CISA adds it to the Known Exploited Vulnerabilities catalog, with a federal remediation deadline days rather than weeks away |
| April 2026 | ESET analyzes related samples and names the implant PoisonedRefresh |
| 7 September 2026 | Shadowserver counts 795 exposed endpoints still vulnerable |
| 8 September 2026 | Sophos publishes its technical analysis |
How the implant and the CVE are joined is worth stating carefully. Sophos describes the malware as targeting BIG-IP APM environments running Apache and PHP components by way of CVE-2025-53521, which it characterizes as an exploited unauthenticated remote code execution flaw. BleepingComputer is more guarded, writing that the rootkit shows signs of being a second-stage payload likely deployed after exploitation of that flaw. Neither firm names a threat actor, and Sophos says it lacks sufficient evidence to do so.
What Sophos did observe is a two-stage design. An installer modifies /usr/sbin/httpd and alters the SELinux configuration. The infected httpd then intercepts Apache's module loading and places a memory-resident web shell in front of three legitimate webtop scripts, apm_css.php3, full_wt.php3 and webtop_popup_css.php3. Security Affairs reports that the first stage arrives inside a modified umount binary and is written into upgrade images, so the implant persists across device updates.
The gap: authentication was the second decision
The uncomfortable part of this incident is where it lands. Not on an application behind the access layer. On the access layer.
- Single sign-on and multi-factor authentication evaluate an identity once one is presented. A pre-authentication path is reached before the access policy runs, so nothing was presented.
- File integrity monitoring and disk scanning are doing the job they were built for, and Sophos's finding is precisely that the shell never lands on disk to be found.
- Patching was correct and available. It shipped for five months under a denial-of-service heading, and that advisory does not win the same change window as an unauthenticated code execution advisory. That is a reasonable prioritization that turned out to be wrong, which is not the same as a careless one.
The device whose entire job is deciding who may connect had to answer the connection first.
What would have had to be true
For the exploited path to be out of reach, the APM virtual server would have had to not answer the attacker's network.
That capability was never missing. BIG-IP supports source restriction on a virtual server directly, and most of these appliances sit behind a firewall the same organization operates. So why was anything answering on 7 September?
Because the legitimate callers of a remote-access webtop are people, and people move. A hand-maintained list of source networks decays from the moment it is written, and it decays asymmetrically: an address left in too long is silent, while a missing address is a ticket from somebody who cannot work, filed against the appliance that grants access to everything.
The window that mattered was not the patch window. It ran from October 2025 until each appliance was actually updated, and Security Affairs reports the implant surviving in upgrade images, so updating late is not the same as never having been reached.
Where Veribound would have fitted
Veribound is a Pre-session Edge Access Control (PEAC) platform, and an intelligence layer rather than an enforcement point. BIG-IP stays. APM stays. The access policy, the identity provider and the multi-factor prompt all stay, and the customer's own equipment keeps enforcing its own rules, unchanged.
An agent on each staff device keeps confirming it is still the one the organization trusted. What reaches the customer's existing controls is a trusted origin: the network that device is connecting from, in practice its public address. Those arrive as address-group updates against policy the organization already has, applied in front of the virtual server rather than inside it.
Applied here:
- The scan returns nothing, so the appliance never reaches a target list.
- The pre-authentication request is never received, because the virtual server is not asked to handle input from a network no trusted device is working from.
- The list keeps itself current, which is the part that was failing, and it changes when somebody changes network.
- The patch is still required. F5's fixed versions are the only thing that removes the flaw.
What this would not have done deserves stating plainly. It does not repair CVE-2025-53521, and it does nothing about an implant already installed: a memory-resident shell and a payload written into upgrade images are an incident response problem, for which F5 and Sophos have published guidance including an integrity check tool and comparing in-memory modules against their copies on disk. It would not have changed the outcome for an appliance reached from inside by an attacker already holding a workstation, because internal reachability satisfies the same precondition.
There is a scope boundary too. This holds where the APM virtual server serves the organization's own staff and contractors, the deployment those targeted webtop scripts belong to. Where an APM publishes applications to the general public, or to a partner population nobody can enumerate in advance, the set of legitimate origins is not a set of trusted devices and none of this applies.
Nearly eleven months after a fix existed, the difference between an affected appliance and an unaffected one was still whether it answered a stranger.
Source: Hackers breach F5 BIG-IP APM devices to deploy Linux rootkit, BleepingComputer, 8 September 2026.