An exposed F5 BIG-IP APM virtual server configured as an OAuth Authorization Server has a heap-based buffer overflow that can let an unauthenticated attacker execute code. On September 22, CISA listed CVE-2026-94127 among known exploited flaws. Its September 25 federal remediation deadline has passed; as of October 3, teams running APM access infrastructure should identify the affected configuration and arrange F5’s interim protection while preparing the final patch.
F5’s published CVE record says this vulnerability is present when an access policy and OAuth profile are configured on a virtual server and APM acts as the OAuth Authorization Server. APM used strictly as an OAuth Client or Resource Server, without an authorization-server profile, is outside the stated affected scope. F5 also lists BIG-IP systems in Appliance mode as vulnerable.
OAuth authorization changes the exposure
An access policy is the gate through which APM handles a user’s access request. On a virtual server carrying an OAuth Authorization Server profile, F5 says specific malicious traffic can trigger the overflow and remote code execution before the attacker authenticates. F5 says: “This is a data plane issue; there is no control plane exposure.” The overflow reaches BIG-IP’s traffic-handling side; successful code execution there can compromise the appliance.
Start the inventory with virtual servers and their assigned access policies and OAuth profiles. Determine whether each profile makes APM an Authorization Server or only a Client or Resource Server. Also identify the BIG-IP software branch and any engineering hotfix already installed. F5 lists affected versions beginning at 21.1.0, 17.5.0, and 17.1.0, each with its own engineering-hotfix threshold; versions that reached End of Technical Support were not evaluated, so ask F5 to assess those installations rather than treating them as cleared.
F5 lists branch-specific hotfixes
For the three listed lines, F5’s CVE version ranges end at Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG, and Hotfix-BIGIP-17.1.3.5.0.41.14-ENG, respectively. Match each appliance’s branch and installed hotfix to F5’s supported update path; those engineering-hotfix names are branch-specific thresholds, not a single upgrade target for the fleet. Get the applicable final patch and deployment instructions from F5 support before changing an access gateway that carries live traffic.
F5 says an iRule is available on request through a support ticket. CISA says to apply that vendor-provided iRule as temporary mitigation “to allow for proactive forensic triage,” then install the final vendor patch as soon as possible. Coordinate the iRule with the affected virtual server, preserve relevant appliance and access-traffic evidence for the triage team, and schedule the vendor-approved patch. A configuration or version inventory identifies exposure; an appliance already exposed to exploitation still needs investigation.
Triage the exposed virtual servers
CISA calls for forensic triage and for each asset’s internet exposure to be evaluated under its federal guidance. The federal due date was September 25. For compromise hunting, ask F5 for current detection guidance through the support case and review the appliance and traffic evidence preserved from exposed virtual servers. For each exposed virtual server, record its Authorization Server profile, reachability window, running software and hotfix, and when the interim iRule and final patch became active.
Confirm protection on each appliance
Inventory the access policies and OAuth profiles assigned to traffic-serving APM virtual servers. For those acting as Authorization Servers, open an F5 support case for the iRule, preserve appliance evidence during triage, and install the vendor-approved patch for the running branch. Compare the running build and hotfix with F5’s branch-specific threshold after maintenance; confirm the assigned profile and the interim iRule state on the same virtual server using F5’s supported procedure. The running configuration tells you which gateways need this response, and the running build tells you when each gateway is protected by the final fix.