A new wave of attacks against F5 BIG-IP Access Policy Manager (APM) appliances is forcing security teams to rethink what “clean” actually means on a production edge device. Researchers disclosed this month that a newly identified malware strain, dubbed PoisonedRefresh, injects a fully functional PHP web shell directly into a running process’s memory rather than writing it to disk. A traditional file-integrity scan, antivirus sweep, or malware signature check comes back completely clean, because there is nothing on disk to find. The web shell only exists in RAM, activated the moment Apache loads one of the appliance’s own legitimate PHP scripts.
Why F5 BIG-IP APM Is Such a High-Value Target
BIG-IP Access Policy Manager is not a peripheral component sitting quietly at the edge of a network. It is the appliance that terminates authentication, enforces access policy, and decides which requests are allowed to reach the applications, APIs, and data sitting behind it. When an attacker controls the box that controls access, patching the application behind it stops mattering: the attacker already has a foothold with a privileged view of every session that passes through. That is precisely why BIG-IP devices have been a recurring target for state-linked threat actors over the last several years, and why this particular campaign has drawn so much attention from the vulnerability research and penetration testing community.
Inside PoisonedRefresh: A Web Shell That Lives Only in Memory
The technique itself is what makes this campaign genuinely novel rather than just another web shell drop. When Apache loads one of the BIG-IP appliance’s own bundled PHP scripts, the malware patches the in-memory copy of that script, appending the web shell’s logic directly into the running process. The file sitting on disk is never modified. Anyone who pulls a hash of the PHP files and compares them against a known-good baseline will get a perfect match, because the file genuinely has not changed.
The injected shell accepts specially crafted “magic” HTTP requests, decrypts an embedded payload, and executes it through PHP’s eval() function. To avoid tripping network monitoring or catching a curious administrator’s eye, the response is disguised as an HTTP 201 reply formatted to look like ordinary CSS content rather than command output. Every layer of this design, from the memory-only persistence to the disguised response, is built around one goal: surviving a routine security review without being noticed.
The Vulnerability Behind the Intrusions
F5 has tied the malicious activity to appliances affected by CVE-2025-53521, a flaw the vendor originally classified more conservatively before new evidence forced a reassessment in March 2026. F5 confirmed the bug allows remote code execution with no authentication required, and rated it 9.8 out of 10 on CVSS 3.1 (9.3 on CVSS 4.0). An unauthenticated attacker who can reach the management or client-facing interface of a vulnerable BIG-IP APM instance can use this flaw as the initial entry point, with PoisonedRefresh deployed afterward as the persistence mechanism that keeps that access alive long after the network perimeter believes the incident is over.
This Is Not F5’s First Bad Year
Context matters here, because this is not an isolated appliance bug landing on an otherwise clean vendor. In October 2025, F5 disclosed that a “highly sophisticated nation-state threat actor” had maintained long-term, persistent access to its internal network for roughly a year, ultimately exfiltrating BIG-IP source code and internal documentation describing undisclosed vulnerabilities from the company’s product development and engineering knowledge-management systems. Researchers linked the intrusion to the China-nexus group UNC5221 and the BRICKSTORM backdoor, and F5’s own numbers put the platform’s footprint at more than 23,000 customers across 170 countries, including 48 of the Fortune 50. The breach was serious enough that CISA issued an emergency directive ordering U.S. federal agencies to inventory every BIG-IP deployment and patch on an accelerated timeline.
That earlier breach is exactly what makes PoisonedRefresh so uncomfortable for defenders. An attacker who spent a year quietly reading a vendor’s own source code and internal vulnerability notes is in an unusually strong position to know precisely which flaws are worth exploiting and how to build persistence mechanisms that the vendor’s own detection tooling will not catch. Whether or not the two campaigns are formally linked, the pattern is the one security teams should be planning around: BIG-IP is not a commodity appliance anymore, it is a confirmed, high-value target that sophisticated actors have already studied closely.
Why Conventional Detection Keeps Missing It
Most enterprise security programs still lean heavily on file-based detection: hash comparisons, disk-resident YARA scans, and antivirus engines that inspect what is written to storage. In-memory web shells are specifically engineered to defeat exactly that model. A forensic analyst who only checks the filesystem will conclude the appliance is healthy. Detecting this class of malware realistically requires memory forensics, close inspection of Apache’s running process for anomalous behavior, and network-level analysis capable of spotting the disguised “magic request” traffic pattern rather than relying on any single static signature.
This is also why security teams increasingly treat internet-facing infrastructure like BIG-IP, VPN concentrators, and access gateways as targets for regular, hands-on penetration testing rather than something covered adequately by patch management alone. A scheduled vulnerability scan will often miss a flaw like CVE-2025-53521 in the window between disclosure and patch deployment, and it will never catch an in-memory implant that has already been planted. Only an active assessment that goes looking for exactly this kind of post-exploitation footprint, the way a real attacker would, has a realistic chance of finding it before it is used against you.
There is also a practical operational problem few organizations plan for: BIG-IP APM appliances frequently run for months without a restart, because they sit in the critical path of production authentication and nobody wants to be the one who schedules the maintenance window. Every hour of uptime is another hour the in-memory patch survives untouched, since a simple reboot or Apache restart would flush the compromised process and force the attacker to re-exploit CVE-2025-53521 from scratch to regain the foothold. That single operational detail, restart cadence, has quietly become a security control in its own right for this specific threat, which is not a sentence any infrastructure team expected to write a year ago.
What Organizations Running BIG-IP APM Should Do Now
- Confirm you are running a version of BIG-IP APM that includes the fix for CVE-2025-53521, and treat any appliance still on an affected build as compromised until proven otherwise.
- Do not rely on a disk-based malware scan to clear a BIG-IP appliance. Capture memory from the running Apache process and have it reviewed by someone with experience in memory forensics.
- Review outbound and inbound traffic to the appliance for unusual HTTP 201 responses or requests with abnormal formatting, which is the pattern researchers have associated with PoisonedRefresh’s “magic request” handling.
- Rotate credentials and session material that passed through the appliance during the suspected exposure window. If APM was compromised, every authentication decision it made during that period should be considered untrustworthy.
- Bring in an outside team to run a genuine adversarial assessment against the appliance and the systems behind it, rather than a checklist audit. This is exactly the kind of scenario a professional penetration testing engagement is designed to surface before attackers do it for you.
A Broader Trend: Memory-Resident Persistence Is Becoming Normal
PoisonedRefresh is not an isolated curiosity. It fits a pattern security researchers have been flagging for the past two years: sophisticated intrusion sets increasingly favor memory-resident implants specifically because they defeat the file-integrity tooling most organizations already have in place. As detection-on-disk becomes a solved problem for defenders, attackers simply stop touching disk. The practical implication is that any organization treating “the antivirus scan came back clean” as sufficient assurance for a critical, internet-facing appliance is working from an outdated threat model. Edge infrastructure like BIG-IP, load balancers, VPN gateways, and API gateways deserves the same adversarial scrutiny as the applications sitting behind it, not less.
Frequently Asked Questions
Is every BIG-IP APM appliance affected?
Only appliances running versions vulnerable to CVE-2025-53521 that have not yet been patched are at risk from this specific exploitation path. F5 has published fixed versions, and any appliance still on an older build should be treated as exposed until it is updated and independently verified.
Can a normal antivirus or malware scanner detect PoisonedRefresh?
No. Because the web shell is injected into a running process’s memory rather than written to a file, disk-based antivirus and file-integrity monitoring will not see it. Detection realistically requires memory analysis or behavioral network monitoring tuned to the malware’s specific traffic pattern.
Does rebooting the appliance remove the infection?
A restart clears the in-memory implant, but it does not fix the underlying vulnerability. Without patching CVE-2025-53521, an attacker with continued network access can simply re-exploit the flaw and reinject the web shell after the reboot.
How can a business confirm it has not been compromised?
The only reliable way is an independent technical assessment: memory forensics on the appliance itself, combined with a broader penetration test of the infrastructure sitting behind it, since a compromised APM instance may have already exposed downstream systems.
Getting Expert Help
If your organization runs F5 BIG-IP, any other access-control appliance, or simply has not had its internet-facing infrastructure independently tested recently, this is the moment to close that gap. SiteGuarding customers who need a deeper technical assessment can turn to specialists in the field: SecurityLab.Pro’s penetration testing service for hands-on testing of infrastructure and web applications, AgentOffense for organizations whose exposure increasingly involves AI agents and LLM-connected systems, and CyprusPentest for businesses in Cyprus and the wider EU that need a locally based penetration testing partner. Waiting for the next disclosure is not a strategy: attackers already have a head start on every device still running an unpatched, unverified build.
