Is CVE-2021-22986 (F5 BIG-IP and BIG-IQ Centralized Management iControl REST Remote Code Execution) being exploited in the wild?

What it means when a vulnerability is “being exploited in the wild”

That phrase means defenders are no longer dealing with a theoretical flaw or a proof-of-concept only. Active exploitation changes the problem from planning to exposure management: you must assume real attackers are probing for the condition described by the advisory, and that exploitation may already be automated, repeated, and opportunistic across the internet.

For a question like this, the practical value is in separating “can be exploited” from “is being exploited.” Once active exploitation is confirmed, prioritisation shifts immediately toward exposure reduction, compromise checks, and rapid containment rather than routine patch scheduling.

For internet-facing appliances, management-plane weaknesses are especially sensitive because they sit outside normal application-layer assumptions and can provide direct control of the device. NHIMG’s Edge Device Security Guide is useful here because the same exposure pattern applies to load balancers, gateways, and other perimeter systems with administrative interfaces.

Why active exploitation changes the response for F5 BIG-IP and BIG-IQ

When a vulnerability gives unauthenticated remote code execution on a network-reachable management interface, the operational question is not just whether a patch exists. The important issues are whether the device is exposed, whether the interface was reachable from untrusted networks, and whether the system has already been used to run commands, drop files, or disable services.

In practice, that means the response has to treat the device as potentially touched even before compromise is proven. If the service supports logging and command history, review it immediately; if the platform has limited visibility, rely more heavily on network telemetry, configuration drift, and integrity checks. The CISA Known Exploited Vulnerabilities Catalog is the authoritative signal that exploitation is known, while the F5 advisory remains the place to confirm version-specific remediation details.

Because the flaw sits in the iControl REST interface, the exposure surface is not just “the appliance,” but the management API path itself. That matters when organisations have allowed admin access from broad network ranges, left management services exposed to the internet, or assumed the device was protected because it was not hosting a user-facing application.

What practitioners should check first after a KEV listing

The first priority is to confirm whether the appliance is externally reachable or reachable from any untrusted internal segment. Next, determine whether the management interface was exposed during the exploitation window, whether the host shows command execution or unexpected file changes, and whether service disruption aligns with attacker activity rather than routine maintenance.

• Verify whether the vulnerable management plane was reachable from the internet or from broadly trusted networks.
• Review device logs, authentication traces, and administrative changes for unexplained activity.
• Look for altered files, disabled services, new user or admin accounts, and unexpected command execution.
• Correlate network alerts with maintenance windows to separate legitimate operations from intrusion activity.

When exploitation is already confirmed in the wild, these checks should happen in parallel with remediation planning rather than after patching. The NIST National Vulnerability Database is useful for record-level reference, but the KEV entry is the stronger operational prioritisation signal because it indicates active abuse, not just theoretical exposure.

Risk and Threat Considerations

Internet-facing appliances with administrative interfaces are attractive to attackers because they often combine broad reach with high privilege. A remote code execution flaw in that layer can become an initial foothold for persistence, service disruption, or lateral movement into adjacent systems.

Failure mechanism: An unauthenticated attacker sends crafted requests to the exposed iControl REST interface, executes commands on the appliance, and may then alter files or disable services to maintain access or disrupt operations.

Impact: The result can include full device compromise, outage of routing or load-balancing services, credential and configuration exposure, and use of the appliance as a pivot point into broader infrastructure.

Practitioner Guidance

What to prioritise: Treat exposure and compromise assessment as one workstream. If the appliance was reachable from the internet or from a low-trust segment, prioritise containment, credential review, and forensic validation before normal change control.

What to verify: Confirm the exact management paths that were exposed, the time they were exposed, and whether admin actions occurred outside approved maintenance. If logs are incomplete, use packet captures, configuration history, and neighbouring system telemetry to reconstruct likely access.

Practitioner takeaway: A KEV listing means the question is no longer “is this interesting?”, but “can we prove it was not used against us and have we removed the exposed path?”

Related resources from NHI Mgmt Group

• CVE-2021-22986 (F5 BIG-IP and BIG-IQ Centralized Management iControl REST Remote Code Execution)
• Is CVE-2021-22991 (F5 BIG-IP Traffic Management Microkernel Buffer Overflow) being exploited in the wild?
• CVE-2020-5902 (F5 BIG-IP Traffic Management User Interface (TMUI) Remote Code Execution)
• What should security teams do first when F5 BIG-IP or BIG-IQ advisories disclose unauthenticated remote code execution risk?