F5 BIG-IP APM CVE-2026-94127: Pre-Auth RCE, Exploited Now

F5 BIG-IP Access Policy Manager (APM) earns its keep as an identity checkpoint. When you run it as an OAuth authorization server, it does something more sensitive still: it mints the access tokens that let your applications trust a user. CVE-2026-94127 is an unauthenticated flaw that lets an attacker run code on exactly that box, and F5 says it is already being exploited. Treat this as a compromise of your token issuer, not a routine appliance patch.

CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 22, 2026 and gave federal agencies until September 25 to act. A three-day window is rare. It is the signal to read: CISA does not set a deadline that tight unless it is confident the attacks are live.

Which configurations are exposed

The scope is narrower than "everyone on BIG-IP," and getting it right is the first piece of work. The bug only triggers when a single virtual server carries both an APM access policy and an OAuth authorization server profile. That is the setup where APM issues tokens on your behalf. If you run APM only as an OAuth client or as a resource server, this specific flaw does not reach you.

So the triage is an inventory question, not a scramble across every appliance: which of your virtual servers are configured as OAuth authorization servers? Those are the ones to patch first and to hunt on. Everything else can follow the normal schedule. The flaw is a heap-based buffer overflow, which is why crafted traffic to that virtual server ends in code execution rather than a simple crash.

Why an RCE on a token issuer is worse than a normal edge bug

A pre-authentication remote code execution (RCE) flaw on a load balancer is bad. The same flaw on the thing that issues authentication tokens is a different category. An attacker who owns the authorization server owns the trust root: they can reach the material used to sign tokens, and any application that accepts tokens from that server now accepts the attacker. Patching the box closes the hole. It does not un-issue the tokens an intruder may already have minted.

We have watched this play out on the edge-identity tier all quarter. SonicWall SMA1000 and Citrix NetScaler both took pre-auth hits on the boxes that gate access, and in the Klue campaign the damage came from abusing OAuth trust rather than cracking a password. The pattern holds: the gateway that grants access is the asset attackers want, because owning it means they never have to log in again. It is the same lesson as edge devices being the entry point, moved up one layer to the identity plane.

Affected and fixed versions

The affected trains are 21.1.0, 17.5.0 through 17.5.1, and 17.1.0 through 17.1.3, and F5 has published an engineering hotfix for each. Match your version, then apply the matching hotfix.

If you cannot deploy a hotfix immediately, F5 offers an iRule mitigation for affected virtual servers through its support team. Apply that as a stopgap, not a substitute. CERT-EU's guidance is to put the iRule in place first, so you have a forensic tripwire, then install the hotfix.

How to tell if you were already hit

Patching answers "am I still exposed." It does not answer "was I already caught in the window before I patched." For a token issuer, that second question matters more, so pull your logs before you close the book. Investigators have described a recognizable failure signature: a burst of OAuth token-validation errors from one source, followed by unusual commands and a crash of the traffic management process.

Repeated OAuth UserInfo failures from one source IP
  error "The access token is invalid" (10+ in a short window)
Unexplained rise in the total_failed OAuth counter metric
Suspicious shell commands in /var/log/audit near those failures
TMM core files / repeated SIGABRT (traffic management process crash)

None of these is proof on its own. Taken together, a run of UserInfo failures from a single address, a spike in the failed-token counter, unexplained commands in the audit log, and a TMM crash in the same window is the shape of an attempted or successful exploit. Public scans put the number of internet-exposed BIG-IP APM instances above 14,700, per BleepingComputer, so the target set is large.

Patch the token issuer, then hunt the logs

Work it in this order:

• Inventory which virtual servers run an OAuth authorization server profile alongside an APM access policy. Those are in scope.
• Apply the F5 hotfix for your branch today. If you cannot, request the iRule mitigation from F5 support and schedule the hotfix immediately after.
• Hunt the logs on any exposed instance for the signature above, reaching back to before your patch.
• If you find evidence of exploitation, treat it as an identity incident: rotate the keys used to sign OAuth tokens and revoke tokens issued from the affected server. A patched box can still have handed valid tokens to an attacker.

The flaws that keep landing on CISA's must-patch list this year share an address: the edge and identity tier, the boxes that decide who gets in. F5 BIG-IP is a repeat resident there, and this one sits on the most sensitive job that tier does. Patch it like the token mint it is.