Every enterprise has a machine that decides who you are. You log in once, it checks the session, issues a token, and tells every application behind it to trust you. For a lot of organizations, that machine is F5 BIG-IP Access Policy Manager (APM) acting as an OAuth authorization server.
On September 22, F5 confirmed that attackers are already running their own code on it. Without logging in. Tracked as CVE-2026-94127, this one is rated 9.8 (CVSS v3.1), and the hotfix needs to be on your schedule today, not next quarter.
The short version
- CVE-2026-94127 is a heap-based buffer overflow (CWE-122) in BIG-IP APM, rated 9.8 on CVSS v3.1 and 9.3 on v4.0.
- It exists only where APM is configured as an OAuth authorization server — an access policy plus an OAuth profile on the same virtual server.
- Specific malicious traffic sent to that virtual server leads to remote code execution by an unauthenticated attacker.
- F5 disclosed it on September 22 and shipped engineering hotfixes. CISA added it to the KEV catalog the same day and gave federal agencies until September 25.
- F5's own wording: "We have learned that this vulnerability has been exploited."
Three days from advisory to federal deadline. That is the new patch math, and it is not a typo.
What the flaw actually is
BIG-IP APM is the module that brokers access to your applications: it runs the access policy, applies the posture checks, and hands out the tokens that downstream apps accept as proof of identity.
The vulnerable configuration is narrow but common: an APM access policy and an OAuth authorization server profile living on the same virtual server. When a system is configured that way, malformed traffic aimed at the virtual server can overflow a heap buffer and hand the attacker execution.
The affected branches and their fixes:
- 21.1 — 21.1.0 before the hotfix →
Hotfix-BIGIP-21.1.0.2.0.30.22-ENG - 17.5 — 17.5.0 through 17.5.1 →
Hotfix-BIGIP-17.5.1.9.0.160.12-ENG - 17.1 — 17.1.0 through 17.1.3 →
Hotfix-BIGIP-17.1.3.5.0.41.14-ENG
There is one piece of good news. If APM is only acting as an OAuth client or resource server — no authorization server profiles configured — you are not affected. F5 updated its CVE record at 00:45 UTC on September 23 to narrow the condition to the authorization server role specifically, which means the earliest CERT-EU and KEV wording was broader than the final scope. Check the role, not just the version.
Why locking down the management interface won't save you
The instinct after any edge-appliance zero-day is to hide the admin UI behind a jump host and call it a day. That does nothing here.
This is a data plane issue. The malicious traffic goes to the virtual server that handles OAuth flows — the same address your users, and your partners' users, are supposed to reach. F5 states there is no control plane exposure, and, crucially, that BIG-IP systems in Appliance mode are also vulnerable. Appliance mode is generally the hardening people apply precisely to make these boxes harder to abuse.
So the exposure is not "who can reach the management port." The exposure is "who can reach the identity endpoint." In most architectures, that is the internet.
And these appliances are not rare. Shadowserver is currently tracking more than 14,700 IP addresses with a BIG-IP APM fingerprint. That count does not tell us how many are unpatched or misconfigured, but it does tell us how attractive the target class is.
How to tell whether you were already hit
This is where the story gets uncomfortable. F5 disclosed the flaw as a zero-day — meaning the exploitable details existed in the wild before you had a patch to install. Anything that arrives as a zero-day has an unknown amount of lead time already burned.
F5 published indicators defenders can hunt for. The pattern worth alerting on is a sequence, not a single event:
- Repeated OAuth authentication failures against the BIG-IP APM virtual server.
- Suspicious commands appearing shortly after those failures.
- A TMM SIGABRT event following close behind.
If you see that chain in one window, treat it as a confirmed compromise, not a theory. The later steps of the pattern — post-exploitation commands — only exist if something got in first.
If you cannot install the hotfix immediately, F5 has published an iRule through its support channels that can be attached to the affected virtual server as a temporary mitigation. Temporary means exactly that: it buys you the hours to schedule the real fix, it does not replace it.
What we would do this week
- Audit the configuration, not the version banner. A remote scan cannot tell you whether OAuth authorization server profiles are configured. Pull the config and list every virtual server that has both an access policy and an OAuth profile.
- Patch the affected branches with the named hotfixes, starting with anything internet-facing. If a maintenance window is unavoidable, put the iRule in place first and log the exception.
- Hunt the IOC chain back further than September 22. Attackers had access to the flaw before the advisory; start your log review earlier than the disclosure date.
- Rotate on suspicion, not on certainty. If the IOC chain appears, assume the tokens and client secrets that appliance issued may be compromised. Rotate OAuth client secrets, review signing key handling, and invalidate outstanding sessions.
- Map the blast radius. Every application that trusts that authorization server as its identity provider is downstream of this bug. The ones that blindly accept tokens without rechecking claims are the ones you worry about first.
- Restore-test the identity plane. Your access manager sits in front of nearly everything. If it goes down, how do you get back in? Most teams we talk to have never rehearsed that.
The takeaway
Identity infrastructure is now the crown jewel, and the attackers agree. Two days ago we wrote about Check Point VPN appliances; today it is F5's access manager. The pattern is consistent: the boxes that decide who gets in are the boxes worth breaking, and their flaws do not care about your management interface restrictions.
Patch this one fast — but do not stop at patching. The three-day deadline is a signal about how quickly exploitation follows disclosure. Detection, configuration audit, and a rehearsed recovery path are what carry you through the days you do not have a fix for.
If you are not certain whether your BIG-IP APM deployment is running as an OAuth authorization server, that uncertainty is the risk. Let's close it.