Is CVE-2025-53521 (F5 BIG-IP Stack-Based Buffer Overflow) being exploited in the wild?

Yes. CISA added CVE-2025-53521 to its Known Exploited Vulnerabilities catalogue on 27 March 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. F5 BIG-IP APM contains a stack-based buffer overflow vulnerability that could allow a threat actor to achieve remote code execution.

What being in the KEV catalog means for this CVE

CISA’s KEV inclusion is the practical signal that matters most here. It means defenders should treat CVE-2025-53521 as an active exploitation problem, not just a theoretical product flaw. For F5 BIG-IP environments, that shifts the question from “is there a bug?” to “is any exposed BIG-IP instance still reachable, and has it already been used as an entry point?”

For a stack-based buffer overflow in an internet-facing appliance, the risk is concentrated where management, traffic-handling, or adjacent services are exposed. A remote code execution outcome can turn a perimeter device into a foothold, a relay point, or a persistence layer, which is why exploited edge-device flaws often demand faster action than routine patch cycles.

The relevant response is to verify exposure, apply the vendor’s fix or mitigation as soon as possible, and use CISA’s KEV entry plus the vendor advisory for authoritative version and remediation details rather than relying on secondary summaries. If the affected appliance has management access exposed to untrusted networks, treat that as a priority condition even before you confirm abuse.

How to judge whether you are exposed or already impacted

Start with inventory and reachability, not with assumptions about which teams own the device. Confirm where F5 BIG-IP APM is deployed, which instances are internet-facing or reachable from partner networks, and whether they can accept administrative or service traffic from outside the intended boundary. In edge-device cases, “not directly public” is often not the same as “safe.”

Then validate whether the vulnerable service path is present in your deployed configuration and whether compensating controls actually reduce exposure. A patch that exists in a change ticket is not evidence of protection if the device is still running the exposed software path or if the mitigation was only partially applied.

If you have logs, telemetry, or packet captures from the period before CISA listed the CVE, review them for unusual authentication attempts, anomalous requests to the appliance, unexpected process activity, or configuration changes. On appliances like BIG-IP, compromise signs may be subtler than on general-purpose servers, because attackers often aim to keep the device quiet while using it to reach other assets.

What to do if patching must wait

When immediate remediation is not possible, reduce the reachable attack surface first. Restrict administrative access, remove unnecessary exposure, isolate the appliance from broad trust zones, and watch for any traffic or session patterns that should not exist on a normal load balancer or access gateway. For edge systems, a temporary network restriction can buy time, but it is not a substitute for remediation.

Where the device provides access to authentication flows, sessions, or upstream applications, assume that a successful exploit may have exposed more than the appliance itself. In practice, that means you should be ready to rotate credentials, invalidate sessions, or review connected application trust relationships if evidence suggests the box was used operationally after compromise.

Risk and Threat Considerations

Exploited perimeter appliances are attractive because they sit at a trusted boundary and often have high-value network reach. A stack-based buffer overflow in such a product can be used for remote code execution, which makes the device useful both for initial access and for maintaining a durable foothold.

Failure mechanism: An attacker can send crafted input to a vulnerable code path, trigger memory corruption, and potentially execute code with the privileges of the appliance process or a nearby privileged component.

Impact: The result can include device takeover, traffic interception, lateral movement into internal systems, and the loss of confidence in authentication or access decisions that depend on the appliance.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes rapid vuln triage and remediation central to this CVE.
Recommendation — Prioritise and remediate KEV-listed appliances immediately.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about an actively exploited software flaw and remediation urgency.
	CA-7 — Continuous Monitoring	Exposure validation and compromise checks depend on continuous monitoring evidence.
Recommendation — Accelerate patching and mitigation for the affected BIG-IP system. Review appliance telemetry for signs of exploitation and persistence.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	Answering this requires confirming exposure and understanding the vulnerable asset state.
	PR.IR-01 — Network protections are managed	Network restriction is a key interim control when patching must wait.
Recommendation — Identify and document every exposed BIG-IP instance. Restrict access to the appliance until remediation is complete.

Practitioner Guidance

What to prioritise: Treat exposed BIG-IP instances as a high-priority asset class, especially where they front authentication, remote access, or sensitive internal applications. If you have multiple appliances, focus first on the ones that are reachable from the internet or from less-trusted partner paths.

What to verify: Confirm the exact deployed BIG-IP APM software state, the active exposure path, and whether any device-side or network-side mitigation is still in force. If logs are available, retain pre-remediation telemetry so you can compare normal appliance behavior with the period before the KEV listing.

Decision rule: If the appliance is exposed and you cannot prove it was not reachable during the exploitation window, assume potential compromise until review is complete. In that case, patching should be paired with a compromise assessment, not treated as the end of the response.

Practitioner takeaway: KEV listing changes the operational posture immediately, the right response is to compress the exposure window first, then prove whether the appliance was used as an attack path.