PoisonedRefresh: The F5 BIG-IP Rootkit Your File Scanner Will Never Find

What Happened

Over the past two weeks, researchers have published detailed teardowns of PoisonedRefresh, a Linux rootkit targeting F5 BIG-IP Access Policy Manager (APM) devices. It doesn't drop a file. It injects a PHP web shell directly into the memory space of the APM's PHP runtime, patches libphp's memory protections to keep it resident, and answers to attacker requests without ever touching disk. Security Affairs, BleepingComputer, Help Net Security, and The Hacker News all ran versions of this story within days of each other, which tells you how fast this moved once someone found it in the wild (Security Affairs, BleepingComputer, The Hacker News).

The entry point is CVE-2025-53521, an F5 BIG-IP APM vulnerability F5 originally patched and scoped in October 2025 (F5 K000156741). It was later reclassified as unauthenticated remote code execution rather than the lower-severity issue first described, and CISA added it to the Known Exploited Vulnerabilities catalog on March 28, 2026 after confirming active exploitation (The Hacker News, SOCRadar). Anyone running BIG-IP APM that hasn't applied F5's fix is sitting on an unauthenticated path in, and PoisonedRefresh is what walks through it once it's open.

Who's affected: any organization running BIG-IP APM, which in practice means a lot of enterprise VPN and access-control infrastructure sitting at the network edge, exactly where you don't want an invisible web shell.

Why Your File Scanner Reports a Clean Bill of Health

Traditional endpoint tools, antivirus, and file-integrity monitoring all work from the same assumption: malicious code lives somewhere on disk, has a hash, and eventually gets written to a file you can checksum. PoisonedRefresh doesn't play that game. It lives entirely in the memory of the running PHP process, patches around libphp's own memory protections so it doesn't get flagged or overwritten, and never writes the web shell as a file an AV agent could scan (CybelAngel, DEV Community).

This is the punchline every SOC analyst already knows and nobody outside security wants to hear: a file scanner can only find what shows up as a file. Ask it about memory and it will shrug, hand you a clean report, and go back to checksumming last quarter's config backups. PoisonedRefresh isn't clever because it's unbreakable. It's clever because it exploits the gap between what your compliance checklist asks for and what your tooling actually watches.

The Signals That Are Still There, If You're Looking at Logs

Here's the part that should change how partners think about detection coverage: fileless doesn't mean invisible. It means the evidence moved from the file system to the process and the network stack, and both of those generate log-visible behavior. Researchers documenting PoisonedRefresh identified a specific set of indicators that show up regardless of whether the payload ever touches disk (Help Net Security, Andrea Fortuna):

• Anomalous reads of /proc/self/maps. The rootkit needs to inspect its own memory layout to inject and relocate the web shell, and that read is not something normal PHP request handling does.
• Memory protection changes on libphp. Flipping page permissions to write executable code into a shared library's address space is a distinctly abnormal syscall pattern for a production web application.
• Unexpected local sockets. The web shell needs a way to receive commands, and that channel shows up as a socket that has no business existing on a stock APM deployment.
• POST requests to .php3 endpoints. F5 BIG-IP APM doesn't normally serve .php3 files. A POST hitting one is a strong, specific tell.

None of these require finding a file. All four require watching logs and process behavior, which is precisely the telemetry a monitored SOC ingests continuously and a file scanner never looks at.

What a Partner Should Actually Do This Week

For MSSPs and MSPs with BIG-IP APM in a client's environment, three things matter more than a press release:

First, confirm patch status against CVE-2025-53521. This isn't optional and it isn't scoped by "if you saw the original advisory." F5 published the fix in October 2025, but the vulnerability's severity was corrected upward well after that, and it's now KEV-listed, which for regulated clients often carries a mandated remediation clock (CISA KEV coverage via The Hacker News, Truesec). If a client's BIG-IP APM instance hasn't been patched, that's the call to make before anything else on this list.

Second, stop treating a clean AV scan as evidence of anything on this class of device. BIG-IP APM sits at the network edge doing authentication and access control, which is exactly the kind of high-value, high-trust box where a fileless implant does the most damage and gets the least scrutiny from disk-based tools. If your monitoring stack for these devices is file-integrity checks and signature AV, you have a gap, and it's the gap PoisonedRefresh was built for.

Third, get log and behavioral telemetry flowing from these devices into something that's actually being watched around the clock. The indicators above are only useful if someone is correlating them in near real time. A quarterly log review finds this after the fact. A monitored SOC finds it while the socket is still open.

Where Vijilan Fits

Vijilan's Global SOC works from log and behavioral telemetry, not file signatures. That's a deliberate design choice, not a marketing line, and PoisonedRefresh is a clean illustration of why it matters. The four indicators Sophos and other researchers published for this rootkit, the /proc/self/maps reads, the libphp memory protection changes, the unexpected local sockets, the .php3 POST requests, are exactly the kind of events our analysts build detection logic around: process behavior, syscall anomalies, and network connections that don't match a device's normal operating pattern.

A payload that never writes to disk is invisible to a file scanner by design. It is not invisible to a SOC watching the log stream from that device, because injecting code into a running process and standing up a command channel both generate activity that has to leave a trace somewhere outside the file system. That's the trace ThreatRespond™, our Managed XDR service, is built to catch, correlate against the CVE-2025-53521 exploitation pattern, and act on, whether the client is running CrowdStrike Falcon, Microsoft Defender and Sentinel, or a mixed edge-device stack that includes BIG-IP APM feeding logs into the pipeline.

For partners, this is also a straightforward monitoring gap to close for clients who don't yet have edge-device telemetry under watch. We never compete with our partners for their clients, and white-label delivery means your BIG-IP APM customers get 24/7 coverage from our Global SOC under your brand, with the underlying detection logic doing the work file scanners structurally can't.

If you're evaluating whether your current stack would have caught PoisonedRefresh before this article existed, that's a conversation worth having now rather than after the next KEV entry. Visit /msp to talk through partner coverage, or check /pricing for program details.

Frequently asked questions

What is PoisonedRefresh?

PoisonedRefresh is a fileless Linux rootkit targeting F5 BIG-IP APM devices. It injects a PHP web shell directly into the memory of the APM's PHP runtime and patches libphp's memory protections to stay resident, without ever writing a file to disk.

How does PoisonedRefresh get onto a BIG-IP APM device in the first place?

Reported activity ties to CVE-2025-53521, an F5 BIG-IP APM vulnerability originally patched in October 2025 and later reclassified as unauthenticated remote code execution. CISA added it to the Known Exploited Vulnerabilities catalog on March 28, 2026 after confirming active exploitation.

Why can't antivirus or file-integrity monitoring detect this rootkit?

Because the web shell lives entirely in process memory and never touches the file system. AV and FIM tools are built to scan files and checksums, so they have nothing to hash and will report a clean device even when the implant is active.

What log signals indicate a PoisonedRefresh infection even without a file to scan?

Published indicators include anomalous reads of /proc/self/maps, memory protection changes on libphp, unexpected local sockets, and POST requests to .php3 endpoints, none of which BIG-IP APM would generate under normal operation.

What should MSSPs do first if they manage BIG-IP APM for clients?

Confirm the client's BIG-IP APM instance is patched against CVE-2025-53521, then make sure log and behavioral telemetry from the device is flowing into active, continuous monitoring rather than relying on periodic file-based scans.