Threat Intelligence 6 min read

F5 BIG-IP RCE Flaw: Patch Before Attackers Own Your Network

Kyanite Blue Labs, Threat Intelligence·31 March 2026

What happened with the F5 BIG-IP vulnerability?

F5 has revised its assessment of a vulnerability in BIG-IP Access Policy Manager (APM) — and the revision is significant. What was originally classified as a denial-of-service (DoS) flaw has been reclassified as a critical-severity remote code execution (RCE) vulnerability. That distinction matters enormously. A DoS flaw can knock a service offline. An RCE flaw lets an attacker run their own code on your system. According to F5's updated advisory, threat actors are actively exploiting this vulnerability to deploy webshells on unpatched BIG-IP devices. A webshell is a script planted on a compromised server that gives an attacker persistent, browser-accessible control over the machine — think of it as leaving a hidden back door that works even after a reboot. Once a webshell is in place, the attacker can execute commands, exfiltrate data, move laterally across the network, and return at any point in the future. The flaw affects BIG-IP APM, a product widely deployed in enterprise environments to manage application access and enforce security policies at the network edge. In other words, the very component meant to control who gets in has become an entry point for attackers.

Why reclassifying a flaw mid-attack is a serious warning sign

Severity reclassification mid-exploitation is one of the clearest signals in threat intelligence that a vulnerability has moved from theoretical risk to active weapon. It tells you that researchers or F5's own security team examined real-world attack behaviour and found the flaw could do far more damage than originally assessed. This pattern is not new. The Log4Shell vulnerability in December 2021 followed a similar trajectory — initially understood as serious, then confirmed as catastrophic as exploits proliferated within hours of public disclosure. The F5 situation carries a comparable warning: the window between 'patch available' and 'your device is compromised' is measured in days, not weeks. BIG-IP is not a niche product. F5 estimates its technology is used by roughly 48 of the Fortune 50 companies, and BIG-IP deployments are common across financial services, healthcare, government, and large enterprise environments in both the UK and Australasia. That installed base makes it a high-value target. Attackers do not pick their victims at random — they scan for exposed, unpatched instances of known-vulnerable software and move fast.

How the webshell attack chain works

Understanding the attack chain helps you assess your own exposure. Based on the pattern F5 has described, the exploitation flow looks like this: An attacker identifies an internet-facing BIG-IP APM device running a vulnerable version. They send a crafted request that exploits the RCE flaw, executing code on the device without authentication. That code writes a webshell — typically a small PHP, JSP, or ASPX file — to a web-accessible directory on the device. From that point, the attacker has persistent access via a standard HTTPS request, which blends into normal traffic and often evades detection by signature-based tools. The webshell itself is the pivot point. It is not the end goal — it is the foothold. From there, attackers typically conduct reconnaissance of the internal network, harvest credentials stored in memory or configuration files, and establish additional persistence mechanisms before anyone realises the device has been compromised. This is precisely where traditional perimeter-focused defences fall short. The attack enters through a legitimate-looking HTTPS session on a device that organisations inherently trust. Detection requires monitoring for anomalous behaviour on the device itself — unusual process execution, unexpected file writes, or outbound connections to unfamiliar destinations.

  • Attacker scans for exposed BIG-IP APM instances running vulnerable firmware versions
  • Unauthenticated RCE exploit delivers initial payload — no credentials required
  • Webshell written to web-accessible path, establishing persistent remote access
  • Attacker uses webshell to conduct internal reconnaissance and credential harvesting
  • Lateral movement begins — often days or weeks before detection

What organisations running F5 BIG-IP should do right now

F5 has released patches addressing this vulnerability. The immediate priority is straightforward: identify every BIG-IP APM instance in your environment, confirm its firmware version, and apply F5's patched release without delay. If patching is not immediately possible due to change control constraints, F5 has also published mitigations — apply these as a temporary measure, not a substitute for patching. Beyond the patch itself, security teams should treat any unpatched BIG-IP device as potentially compromised and conduct forensic review accordingly. Look for unexpected files in web-accessible directories, review web server logs for unusual request patterns, and check for outbound connections that do not match expected traffic baselines. For organisations using Hadrian for continuous attack surface management, this is an example of exactly the scenario it is designed to catch. Hadrian continuously maps your external attack surface, identifies exposed services, and flags newly disclosed vulnerabilities against your live asset inventory — meaning your team gets actionable intelligence about your specific exposure, not just generic advisories. If BIG-IP APM is visible on your attack surface, you want to know before an attacker does. You can learn more about how Hadrian works at /products/hadrian.

Why attack surface visibility is the missing piece in most patch programmes

Most organisations have a patching process. The gap is almost never in the process itself — it is in knowing what assets exist and which ones are actually exposed to the internet. Shadow IT, forgotten test environments, and legacy infrastructure create blind spots that formal asset inventories miss. The F5 BIG-IP case illustrates this perfectly. An organisation might patch every BIG-IP device on its official inventory and still miss a development instance spun up six months ago and never decommissioned. Attackers do not check your asset register — they scan the entire internet and find what you forgot you had. This is where continuous attack surface management changes the calculus. Rather than relying on periodic audits, tools like Hadrian maintain a live, attacker's-eye view of your external perimeter. When F5 publishes an advisory, your team can immediately cross-reference against confirmed exposed assets rather than working from potentially outdated spreadsheets. For New Zealand and Australian organisations running ESET for endpoint protection, the same principle applies at the endpoint layer. ESET's vulnerability and patch management capabilities help ensure that endpoints running affected software versions are identified and remediated systematically — but that needs to be paired with visibility at the network and application delivery layer, where BIG-IP lives. More information on our Australasia offering is available at /new-zealand and /australia.

The bigger pattern: network edge devices are the new frontline

The F5 BIG-IP flaw is not an isolated incident. It is part of a sustained pattern in which attackers target network edge devices — load balancers, VPN gateways, firewalls, and application delivery controllers — as primary entry points into enterprise environments. In 2023 and 2024, critical vulnerabilities in Ivanti Connect Secure, Citrix NetScaler, Fortinet FortiGate, and Palo Alto Networks GlobalProtect were all actively exploited within days of disclosure. These are products that sit at the boundary between the internet and internal networks, handle authentication, and are often excluded from standard endpoint security tooling. They are high-value, sometimes poorly monitored, and frequently under-patched due to the operational complexity of taking them offline. Sophos next-generation firewalls and Sophos MDR address part of this challenge by providing both boundary enforcement and continuous monitoring — the MDR service maintains 24/7 detection coverage that does not depend on your internal team catching anomalies during business hours. That matters because attackers do not restrict their activity to working hours. You can explore Sophos MDR and firewall capabilities at /products/sophos. For organisations concerned about what happens after an attacker gains a foothold — specifically, the risk of sensitive data being exfiltrated before detection — BlackFog's anti data exfiltration technology provides a layer specifically designed to stop that outcome. Even if a webshell establishes persistence, BlackFog can block the outbound data movement that makes the breach commercially damaging. More on BlackFog's approach is at /products/blackfog.

The supply chain dimension: do your vendors run BIG-IP?

One dimension of this vulnerability that deserves attention is third-party risk. BIG-IP is deployed by managed service providers, cloud platforms, and large enterprises that may be part of your supply chain. If a critical supplier uses BIG-IP APM and has not patched, an attacker could compromise that supplier's environment and use the access to pivot towards your organisation's data or systems — without ever touching your own infrastructure directly. This is not a hypothetical risk. Supply chain attacks via compromised third-party infrastructure have become a standard technique in sophisticated threat campaigns, including state-sponsored intrusions. Your own patching cannot protect you from a breach that enters through a trusted vendor. Panorays, which Kyanite Blue offers for third-party supply chain risk management, continuously assesses the security posture of your suppliers — including scanning for known vulnerabilities in their externally exposed infrastructure. If a key vendor has an unpatched BIG-IP instance facing the internet, that risk becomes visible before it becomes your incident. Learn more at /products/panorays. The F5 BIG-IP situation is a prompt to ask not just 'have we patched?' but 'have our critical vendors patched?' Both questions matter.

Frequently Asked Questions

What is the F5 BIG-IP APM vulnerability and how serious is it?

F5 reclassified a BIG-IP APM vulnerability from denial-of-service to critical-severity remote code execution (RCE). Attackers are actively exploiting it to deploy webshells on unpatched devices, giving them persistent, unauthorised access. F5 has issued patches and organisations should apply them immediately, treating any unpatched device as potentially compromised.

How can I tell if my F5 BIG-IP device has been compromised by this exploit?

Check web-accessible directories on the device for unexpected or unfamiliar files, particularly scripts with extensions such as PHP, JSP, or ASPX. Review web server access logs for unusual request patterns. Monitor outbound network connections from the device for traffic to unfamiliar destinations. If in doubt, treat the device as compromised and conduct a full forensic review before returning it to service.

Does this F5 BIG-IP vulnerability affect UK and New Zealand businesses?

Yes. BIG-IP is widely deployed in enterprise environments across the UK, New Zealand, and Australia, particularly in financial services, healthcare, and government sectors. Any organisation running BIG-IP APM on an internet-facing device is potentially at risk if unpatched. Attackers scan globally for vulnerable instances and do not target specific regions selectively.

F5 BIG-IPremote code executionvulnerability managementattack surfacepatch management

Want to discuss this with our team?

Book a free 20-minute call with David or Max.

Book a call