CRITICAL: F5 BIG-IP APM CVE-2026-94127 Exploited for Unauthenticated RCE

F5 published an advisory on Tuesday for a BIG-IP Access Policy Manager flaw, and buried in the careful vendor language was the sentence nobody wants to read about the box guarding their front door. "We have learned that this vulnerability has been exploited." Not "may be exploited." Not "a proof of concept is circulating." Has been. Past tense, already happened, go check your logs.

The bug is CVE-2026-94127, a heap-based buffer overflow in BIG-IP APM that F5 scores at 9.8 on CVSS v3.1 and 9.3 on CVSS v4.0. An unauthenticated attacker who can reach the right virtual server sends crafted traffic and ends up executing code on the appliance. No credentials, no user interaction, no clever phishing pretext. Just traffic arriving at a listener that was placed on the internet deliberately, because that is the entire point of an access gateway.

CISA added it to the Known Exploited Vulnerabilities catalog on September 22, the same day the advisory landed, and told federal agencies to have it handled by Friday. When CISA hands you three days instead of the usual three weeks, that is the agency saying the quiet part out loud.

The configuration that matters

There is good news here, and it is worth establishing before anyone declares a company wide incident. This is not a blanket "every BIG-IP is on fire" situation. The flaw only becomes reachable when APM is acting as an OAuth authorization server, which in practice means a virtual server carrying both an APM access policy and an OAuth authorization server profile at the same time. If you run APM purely as an OAuth client or as a resource server, consuming tokens that something else issued, F5 says you are not affected. That is a real distinction and checking it takes minutes.

The bad news is that the vulnerable configuration is not exotic in the slightest. Organizations land on it precisely when BIG-IP is doing the job it was bought to do, sitting in front of a pile of applications and issuing access tokens for single sign on and federated identity. The appliance hands out the credentials that gate everything behind it. Code execution on that box is not a foothold on some forgotten DMZ host, it is code execution on the system that decides who gets to be who.

Version wise, F5 flagged 21.1.0 on the 21.x branch, 17.5.0 through 17.5.1 on the 17.5 branch, and 17.1.0 through 17.1.3 on the 17.1 branch. Engineering hotfixes are available for all three, shipping as 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. Anything past end of support was not evaluated, which is vendor language for "we did not look, and you should assume the worst."

There is a trap waiting for anyone who felt good about their patching cadence earlier this year. BIG-IP APM already took a turn through the KEV catalog back in March with CVE-2025-53521, and the versions that fixed that flaw sit comfortably inside the affected ranges for this one. Patching the March bug does absolutely nothing for this bug. If APM is running as an OAuth authorization server, the new hotfix is required no matter how current you believed you were.

How the attacks look from the defender side

F5 and CERT-EU both published indicators, and for once they are refreshingly concrete rather than the usual advice to monitor for anomalous activity. The opening signal lives in /var/log/apm, where the thing to hunt for is repeated failed UserInfo requests returning "The access token is invalid." A handful of those scattered across a day is just life on an authentication gateway. Ten or more from a single source address inside a tight window is somebody walking the heap.

You can corroborate from a second angle using the OAuth counters. Running tmctl global_oauth_stat and watching the total_failed value will show an unexplained spike that lines up with the same behavior. From there the interesting material moves to /var/log/audit, where successful exploitation tends to surface as suspicious commands appearing around the same timestamps as the authentication noise. The final piece is the Traffic Management Microkernel itself. TMM core files are worth pulling apart, particularly when the process lands in a loop that gets the SOD daemon to fire a SIGABRT.

F5's own framing of the sequence is the part to tape to the wall above the SOC monitor. Repeated OAuth authentication failures, followed by suspicious commands, followed by a TMM SIGABRT shortly after, is the combination that should pull an actual human into the loop rather than generating one more alert in a queue nobody reads.

Nobody has attributed this to a named group. F5 has not said who, CISA has not said who, and the details of the intrusions themselves have been withheld, which usually means either the victims are sensitive or the investigation is ongoing. Check Point disclosed two actively exploited management server flaws of its own during the same week, tracked as CVE-2026-93616 and CVE-2026-85102, and all four vulnerabilities landed in KEV together carrying the same Friday deadline. Draw your own conclusions about what sort of adversary spends its September systematically collecting authentication and management infrastructure.

Scale is easier to pin down than attribution. Shadowserver is currently tracking north of 14,700 internet facing IP addresses carrying BIG-IP APM fingerprints. That number tells you nothing about how many are already patched, how many are honeypots, or how many run the specific OAuth authorization server configuration that actually matters. What it does tell you is that the addressable target list is large and trivially enumerable from the outside, which is the only arithmetic an opportunistic scanner needs before it starts working through the range.

What to do about it

Patch, and treat it as this week's work rather than next quarter's. The hotfixes exist for every affected branch and the maintenance window is measured in minutes against a bug that is already being used against real networks.

If the window genuinely cannot happen today, F5 has an iRule mitigation available through a support ticket. It filters the hostile traffic before it reaches the vulnerable code rather than changing the code itself, which makes it a legitimate stopgap rather than a fig leaf. CISA actually recommended applying the iRule first and the hotfix second, specifically so defenders get a window to run forensic triage before they overwrite the evidence. That is unusually thoughtful guidance to find inside a binding directive, and it is worth following in that order.

Assume compromise if the indicators are present. Neither F5's advisory nor the CISA and CERT-EU write ups state whether the hotfix evicts an attacker who already established access, and the honest reading of that silence is that it does not. A heap overflow yielding code execution on an appliance gives somebody ample opportunity to leave things behind. Patching closes the door. It does not search the house.

Practically, that means the work after the patch is the real work. Pull the APM and audit logs covering the window before you patched rather than the comfortable window after. Rotate every secret that APM had access to, because an OAuth authorization server holds signing material and client credentials that are worth considerably more than the appliance they live on. Any token issued by a system you suspect was touched should be treated as untrustworthy, which is an unpleasant conversation to have with application owners but a substantially better one than the alternative.

While you are already in there, it is worth asking the broader question of why so much of the authentication and management plane is reachable from the open internet in the first place. The virtual server handling OAuth traffic has to be, that is the job it was given. The administrative interface sitting next to it does not.

The MSP angle

Every client running an F5 access gateway just turned into a justified emergency patching conversation, and emergency work that ends well is the cheapest trust an MSP will ever buy. The genuine revenue sits in the second half of this, though, not the first. Anyone can apply a hotfix, but the compromise assessment, the log review across the pre patch window, and the credential rotation for an identity provider are billable engagements that most internal teams have neither the hours nor the tooling to run properly. Package it as a fixed scope edge device incident review and it sells itself while the KEV deadline is still sitting on the calendar.

The longer play is selling external attack surface inventory as a recurring service. Shadowserver can fingerprint 14,700 BIG-IP APM instances from the outside without any special access, which means so can everybody else, and most clients genuinely cannot tell you what of theirs is exposed and running which version. Knowing that before the next advisory drops is worth a monthly retainer, and this week hands you the best sales argument you are going to get for a while.