Vulnerabilities

F5 has fixed CVE-2026-94127, a CVSS 9.8 heap-based buffer overflow in BIG-IP Access Policy Manager (APM) that lets an attacker with no account run code on the box. The flaw only appears on a virtual server that has both an APM access policy and an OAuth profile configured to make APM act as an OAuth Authorization Server, issuing tokens to other applications. A deployment that uses APM only as an OAuth client or resource server, checking tokens rather than issuing them, is not affected.

F5 published advisory K000162605 on September 22 and said it had learned the flaw was already being exploited, though it had not confirmed a public proof-of-concept existed at that point. CISA added CVE-2026-94127 to its Known Exploited Vulnerabilities (KEV) catalog the same day, in a batch of four that also listed two Check Point flaws we covered separately and an Arista VeloCloud Orchestrator bug, with a September 25 deadline for US federal agencies. Shadowserver counted more than 15,000 internet-reachable BIG-IP APM instances, roughly 5,000 each in North America and Europe, a figure that covers every exposed APM instance rather than only the ones running OAuth as an authorization server.

How it works

BIG-IP APM can sit in front of an application as an OAuth Authorization Server: its access policy authenticates the user, then APM issues the OAuth access and ID tokens the application trusts instead of checking credentials itself. That authorization endpoint is usually the part of APM reachable from outside the network, because it is what remote users and partner applications hit to sign in, which is why this specific role, not APM in general, is the one worth checking today.

The bug itself is a heap-based buffer overflow, tracked as CWE-122. A running program that needs memory it did not know the size of in advance asks the operating system for a block from the heap, a pool it hands out on request rather than reserving at compile time. A heap-based overflow happens when the program writes more data into that block than it reserved, so the extra bytes spill into whatever memory sits next to it, often other data the program is tracking or a pointer it will use later. F5 describes this as a data plane issue, meaning it sits in the traffic-processing code (TMM, BIG-IP's packet-handling process) rather than the management interface, so a crafted request to the OAuth endpoint reaches the flawed parsing code without needing a login. Once an attacker can control what gets written past the buffer's end, they can shape that overflow to overwrite a pointer the program will later follow, which is what turns a memory corruption bug into code execution rather than just a crash. It also explains why the two look alike from the outside: an overflow that does not land exactly right often shows up first as the same process aborting.

What attackers are doing

F5 has not named an attacker, a start date beyond "already exploited" at the time of its September 22 advisory, or how many organizations were hit. Rapid7 reports that a public proof-of-concept was not confirmed to exist as of that date, which fits a small number of attackers working from detail F5 has not published. That tends to change once researchers have a patch to compare against the old code and enough time to build a working exploit from the difference.

What to do

1. Patch. Update BIG-IP 21.1.0 to Hotfix-BIGIP-21.1.0.2.0.30.22-ENG or later, 17.5.0 to Hotfix-BIGIP-17.5.1.9.0.160.12-ENG or later, and 17.1.0 to Hotfix-BIGIP-17.1.3.5.0.41.14-ENG or later. This is a data plane issue, so it reaches Appliance mode deployments as well as standard ones.

2. If you cannot patch today. If you do not actually need APM to act as an OAuth Authorization Server, remove or disable the OAuth profile on the affected virtual server; that alone takes it out of the vulnerable configuration. If you do need it, restrict the virtual server's OAuth endpoints to trusted networks only with an access control list until the hotfix is in, or open a support case referencing K000162605 for F5's iRule mitigation, which the advisory offers for virtual servers that combine an access policy with an OAuth profile and cannot come offline.

3. Check whether you were hit. Run tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed on each device and look for a rise in total_failed you cannot explain from your own client traffic. Then check /var/log/audit around the same timestamps for commands you do not recognize, and look for TMM core files, since a crash from SIGABRT (the watchdog daemon forcing the traffic-handling process to abort) is common when an exploit attempt does not land cleanly. F5's own guidance is that the pattern worth escalating to a human is more than ten OAuth authentication failures from one address, followed by unusual commands, followed by a TMM crash, in that order. Any one of those three on its own has innocent explanations too.

4. Review what the authorization server issued. Pull the OAuth access and refresh tokens BIG-IP issued since September 22 and check any downstream system that trusts them for reissuance you cannot tie to a real user session. A working exploit against a token-issuing endpoint can mint or replay tokens as well as run code, so the blast radius extends to whatever accepts a BIG-IP-issued token.

An OAuth authorization server is exactly the kind of internet-facing identity component our network penetration tests look for, because it is often the one login boundary an outsider can reach directly. Our attack surface management work is what puts an internet-facing APM virtual server on a list to check the day a KEV entry lands, instead of waiting for the next scheduled scan. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: CISA: four KEV additions, September 22, F5 advisory K000162605, Rapid7, CSO Online, The Register.