F5 published an advisory on September 22 for CVE-2026-94127, a heap overflow in BIG-IP Access Policy Manager that gives an unauthenticated attacker code execution on the box. F5 says it has already been exploited. CISA added it to the Known Exploited Vulnerabilities catalog the same day and gave federal agencies until September 25 to fix it. Three days. For a network appliance that most shops patch on a quarterly window.
I've run F5 gear at the edge of hosting networks for a long time. This one is bad in the specific way that matters: it hits the data plane, it needs no credentials, and it lives in the part of APM that people put on the public internet on purpose.
What is affected and what isn't
The bug only fires when a virtual server has both an APM access policy and an OAuth profile attached, with APM acting as the OAuth Authorization Server. If you use APM as an OAuth client or a resource server, F5 says you are not affected. If you use APM for plain SSL VPN or portal access with no OAuth server profile, you are not affected either. That narrows the blast radius, but it narrows it to the deployments where APM is the identity provider for other applications, which is the worst place for a remote code execution bug to sit.
The affected versions from F5's advisory K000162605:
- BIG-IP 21.1.0, fixed in Hotfix-BIGIP-21.1.0.2.0.30.22-ENG
- BIG-IP 17.5.0 through 17.5.1, fixed in Hotfix-BIGIP-17.5.1.9.0.160.12-ENG
- BIG-IP 17.1.0 through 17.1.3, fixed in Hotfix-BIGIP-17.1.3.5.0.41.14-ENG
Note what those fixes are. They are engineering hotfixes, not point releases. An ENG hotfix is built against one exact base build. If you are on 17.1.1, you first go to 17.1.3, then apply the hotfix on top. That is two upgrades and two reboots per unit, and on an HA pair you do it twice. Anyone who has done a BIG-IP upgrade under time pressure knows the failover step is where the surprises live. The fix lands in a regular release later, but later is not this week.
CVSS scores are 9.8 under version 3.1 and 9.3 under version 4.0. Appliance mode does not help you. F5 says the control plane is not exposed, which means an attacker gets the traffic management microkernel, not the management interface, and on a BIG-IP that is still the whole box for practical purposes. TMM sees every request and every credential in every access policy.
How you find out you've been hit
F5 published three indicators of compromise with the advisory, and they are the kind you can check today. The pattern, as Security Affairs summarized it, is a run of OAuth authentication failures in the APM logs, then commands that shouldn't be there, then a TMM SIGABRT. The crash is the tell. A heap overflow exploit that misses will kill TMM, and TMM restarting under load looks like a failover event to most monitoring. If you had an unexplained TMM restart on a virtual server that serves OAuth in the past few weeks, go pull the logs before you patch. Patching first destroys evidence.
F5 found the bug internally, which is the one good detail in the advisory. It means the vendor was looking. It also means someone else was looking too and got there first, because F5 says exploitation was under way before the fix shipped. F5 has not said how many customers were hit or who the attacker is.
Exposure numbers are rough but not small. CSO Online counted more than 15,000 BIG-IP APM instances reachable from the internet, split about evenly between North America and Europe. Shadowserver's count is over 14,700 IP addresses with an APM fingerprint. Neither number tells you how many of those run an OAuth authorization server, and no scanner can tell from outside without triggering the bug. So the count of vulnerable boxes is unknown, and will stay unknown until the patched count converges.
The 2025 breach is the context F5 won't mention
Last October F5 disclosed that a nation-state group had been inside its network for at least a year, and had walked out with BIG-IP source code and details of unpatched vulnerabilities. Mandiant tied it to UNC5221 and the BRICKSTORM malware. CISA issued Emergency Directive 26-01 at the time, and The Record reported the agency telling every federal civilian agency to inventory its BIG-IP fleet and patch within a week.
F5's advisory this week does not connect CVE-2026-94127 to that theft. It may not be connected. But the whole point of stealing undisclosed vulnerability data is to use it before the vendor ships a fix, and here is a bug F5 found on its own that someone else was already exploiting when F5 went to patch it. Either the attacker found the same heap overflow by independent research, or they read about it in F5's own bug tracker. Both are plausible. Neither is comforting for a customer who was told last year that the stolen bugs did not include anything critical or remotely exploitable.
I don't know which it is. Nobody outside F5 and the attacker does. What I do know is that BIG-IP now has a track record of critical unauthenticated bugs at the edge: CVE-2022-1388 in the iControl REST interface, CVE-2023-46747 in the configuration utility, and now this one in APM's OAuth handling. The first two hit the management plane, and the standard advice was "don't expose management to the internet," which most people could follow. This one hits a listener that exists to be public. There is no network segmentation answer to a bug in the thing you built the segment around.
What I'd do this week
The three-day federal deadline is a reasonable target for everyone else too. This is the order I'd work in.
- Inventory. List every virtual server with an access policy attached, then check which of those also carry an OAuth authorization server profile. On most estates this is a short list. If it's empty, you're done with this CVE, and you can spend the time on the other two hundred things.
- Check logs before patching. Look for OAuth authentication failures clustered in time, then TMM restarts. Export what you find. If it looks bad, treat the box as compromised and go to your incident process, which for a BIG-IP means rebuilding from a clean image. Patching in place leaves whatever the attacker left.
- Apply the iRule mitigation if the hotfix cannot ship today. F5 is providing one through support. It is a temporary measure and F5 says so, but a temporary measure in place tonight beats a hotfix scheduled for the next change window.
- Patch to the ENG hotfix, standby unit first, fail over, then the active unit. Keep a copy of the UCS archive from before you start.
Vulnerability scanners have caught up. Rapid7 shipped a check on September 23. But a scanner check for this bug is a version check, and version checks can't see whether the OAuth server profile is present. Your own tmsh output is the only inventory that counts.
One more thing about the fix schedule. F5's version table starts at 17.1. If you are on 16.1 or older, you are on a branch that is past its software development window, and the answer is an upgrade to a supported major, which is a project rather than a change ticket. That is the state a lot of BIG-IP estates are in, because these boxes work for years and nobody wants to touch them. A bug like this is the reason to touch them.
My prediction: the population of exposed APM OAuth servers will still be more than half unpatched a month from now, because the ENG hotfix path is slow and the affected configurations are the ones where downtime needs an approval chain. The attackers know that too. The federal deadline is Friday. Yours should be as well.
