Root on the Token Mint: F5 BIG-IP APM CVE-2026-94127 and the Keys a Hotfix Can't Recall

On September 22, 2026, F5 published advisory K000162605 with a sentence no BIG-IP owner wants to read: "We have learned that this vulnerability has been exploited." CISA put CVE-2026-94127 into the Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies until today, September 25, to act. The bug is a heap-based buffer overflow in Access Policy Manager, scored 9.8 on CVSS v3.1 and 9.3 on v4.0. No login required. No user interaction.

Most coverage has stopped at "patch your F5." Fair enough. But the detail that caught my attention is where the bug lives. It only fires on a virtual server that has an APM access policy and an OAuth authorization server profile attached. In plain terms, the vulnerable box is the one that issues access tokens to your applications.

I spend a lot of my working life on the attacking side of engagements. When you land code execution on an edge device, you look around for what's worth taking. Most of the time it's session cookies, maybe a cached LDAP bind password. Landing on a token issuer is a different class of prize, and it changes what "remediated" means.

What the advisory actually says

Before the opinions, the facts, cross-checked between F5's advisory as quoted by The Hacker News, Rapid7's emerging threat report, and BleepingComputer's coverage.

• Affected builds: BIG-IP 17.1.0 through 17.1.3, 17.5.0 through 17.5.1, and 21.1.0. Engineering hotfixes exist for each branch. Versions past End of Technical Support weren't assessed, so The Hacker News correctly describes their status as unknown, not safe.
• Exposure condition: a virtual server carrying both an APM access policy and an OAuth authorization server profile. Deployments that use APM only as an OAuth client or resource server are not affected.
• Attack surface: the data plane. The crafted traffic goes to the virtual server itself, so locking down the management interface does nothing here. Appliance mode is also vulnerable.
• Interim fix: an iRule you get by opening a case with F5 support (BleepingComputer cites K000135931).
• Public exploit: Rapid7 says a public proof of concept had not been confirmed as of September 23.
• Attribution: none. F5 hasn't named the actor or the victims.

Shadowserver, per BleepingComputer, tracks more than 14,700 IP addresses that look like BIG-IP APM. That number overstates the vulnerable population, because only a subset run the authorization server role. It also tells you nothing about what's sitting behind those IPs, and that's the part I care about.

One timing detail matters for anyone who triaged early. At 00:45 UTC on September 23, F5 revised the CVE record to narrow the condition to the authorization server role. CISA's KEV entry and CERT-EU's advisory had gone out before that change and used the broader wording, "any access policy plus an OAuth profile." If your team scoped its response against one version and your change ticket quotes the other, sort that out before someone closes the ticket on the wrong premise.

The "we already patched in March" trap

This one will bite people. In March, F5 fixed a different APM flaw, CVE-2025-53521, which is also on the KEV list. The fixed builds for that were 17.1.3 and 17.5.1.3. Both sit inside the affected range for CVE-2026-94127.

So there is a very specific failure mode here: a team that did the right thing six months ago, remembers doing it, and assumes the box is current. It isn't. If APM on that appliance acts as an authorization server, it needs the new hotfix regardless of what you applied in the spring.

The second trap is the forgotten pilot. I've walked into more than one environment where somebody set up the BIG-IP as an OAuth authorization server for a proof of concept, the project moved to Entra ID or Okta, and the profile stayed attached to a virtual server nobody remembers. "We don't use F5 for OAuth" is a belief, not an inventory. Check under Access > Federation > OAuth Authorization Server on every appliance, and check which virtual servers reference those profiles.

What I'd take from a token issuer

Let's be precise about what's confirmed and what isn't. No public reporting so far describes what the attackers did after they got code execution. Nobody has said signing keys were stolen. What follows is my analysis of what sits within reach of an attacker with code execution on an APM authorization server, based on how the feature is built, not a claim about any specific intrusion.

An OAuth authorization server exists to do three things: authenticate clients, authenticate users, and sign tokens that downstream applications trust. On BIG-IP, that means the configuration holds:

1. JWT signing key material. The private keys the authorization server uses to sign access tokens. Every resource server that trusts this issuer validates signatures against the matching public key.
2. Client application secrets. The client_id and client_secret pairs for every app registered against the server.
3. The access policy logic itself. Which directory it talks to, which service account it binds with, what claims it stamps into tokens.

Now think like the attacker. Stealing one user's session gives you one user, until the session expires. Stealing the signing key gives you every user, including ones that don't exist yet, for as long as the key stays in use. You don't need the BIG-IP anymore. You mint tokens offline, with whatever sub and scope claims you like, and present them straight to the resource servers. The resource servers check the signature, it verifies, and they let you in.

This is the same shape of problem Neha covered in the SharePoint CVE-2026-55040 forged-JWT teardown: a token that validates is, from the application's point of view, a legitimate user. There's no failed login to alert on because there's no login at all.

Client secrets are the quieter prize. With them, an attacker can request tokens through the client credentials grant as the application itself, which frequently carries broader scopes than any single human user. Service-to-service tokens rarely get the scrutiny that interactive sign-ins get. Nobody sends an MFA push to a daemon.

Why the hotfix isn't eviction

We've written this sentence before on this blog, and I'll keep writing it until it stops being true. In the Artifactory CVE-2026-82329 post, Kabir made the case that patching a credential-issuing system closes the door but doesn't collect the keys that already walked out. CVE-2026-94127 is a sharper version of the same thing.

If an attacker copied the JWT signing key, the hotfix does nothing to the tokens they can now mint. If they copied client secrets, those secrets keep working until you rotate them. If they planted persistence on the appliance, the hotfix doesn't remove it. None of the sources I read say otherwise, and nothing in the advisory claims the patch invalidates anything.

That's why the ordering CISA and CERT-EU gave you matters. CISA says apply the iRule first "to allow for proactive forensic triage," then install the vendor patch. CERT-EU says preserve evidence, hotfix, hunt, then start incident response if you find anything. Both put forensics ahead of "done."

For an exposed authorization server that was reachable from the internet during the exploitation window, I'd go further and treat key rotation as the default, not the escalation path:

• Rotate the JWT signing keys and publish the new public key to every resource server. Then remove the old key from trust. Adding the new one isn't enough if the old one still validates.
• Rotate every client secret registered on the server. Yes, all of them. This is painful, which is exactly why attackers count on you skipping it.
• Rotate the directory bind account the access policy uses.
• Shorten token lifetimes for a while, so anything minted with stolen material ages out faster.

Reading F5's indicators with a skeptical eye

F5's compromise indicators, as reproduced in CERT-EU advisory 2026-013, are worth reading closely:

• In /var/log/apm, repeated failed UserInfo requests with the error "The access token is invalid." F5 flags 10 or more from one IP in a short window as suspicious.
• An unexplained rise in total_failed from tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed.
• Suspicious commands in /var/log/audit around the same time.
• A TMM SIGABRT shortly afterwards. F5 notes it has seen TMM stuck in a loop, with the SOD daemon killing it.

Here's my problem with relying on these. Look at the first indicator. "The access token is invalid" is also exactly what you see when a mobile app ships with a stale token cache, when a developer points a test client at production, or when a load balancer health check is misconfigured. Every OAuth authorization server I've looked at in a real environment has a background hum of invalid-token errors. The exploit hides inside that hum.

And the indicators only cover the break-in. They tell you nothing about what happens after the attacker leaves with key material. A forged token presented to a resource server never touches the BIG-IP again. It won't show up in /var/log/apm. It won't bump total_failed. It will look like a normal authenticated request in your application logs. This is the same gap Arjun described on the Cisco ISE CVE-2026-76460 box: when the gatekeeper itself is compromised, the gatekeeper's logs are the wrong place to look for the aftermath.

Where deception gives you a signal the logs won't

This is the part of the problem I think most teams underinvest in. You can't write a reliable detection for "a validly signed token was presented," because that's what every legitimate request looks like. What you can do is plant things that no legitimate request would ever touch, and alert when something does.

A few that map directly onto this CVE:

A canary OAuth client. Register a client application on the authorization server that no real app uses. Give it a plausible name, something like reporting-svc-legacy. Its client_id should never appear in a token request. The day it does, someone read your client list off the box or out of a config backup. There's no baseline to tune and no false-positive budget to argue about.

Decoy credentials where BIG-IP backups live. UCS archives contain the full configuration, keys included, and in my experience they end up on file shares and admin jump hosts with far weaker controls than the appliance. Seed those locations with honeytoken credentials. An attacker who goes hunting for UCS files to extract keys will find yours too, and using them trips the alarm.

Decoy services behind the edge. An attacker holding forged tokens or stolen client secrets still has to find things to use them on. Decoy services such as MineField sit on the internal network looking like real applications, databases or admin consoles. Legitimate users have no reason to connect to them, so any connection is worth investigating, whether or not the credential presented was valid.

None of this replaces patching or rotation. It covers the window those steps leave open: the days or weeks between "the attacker got the key" and "we noticed."

The part that should worry you most

BleepingComputer notes that since November 2021, CISA has flagged eight actively exploited F5 flaws, and four were used in ransomware attacks. The same report recalls that in October 2025, F5 disclosed that state-sponsored hackers had been inside its systems since August 2025 and took BIG-IP source code along with details of unpublished vulnerabilities. F5 says it found CVE-2026-94127 internally. Nobody has publicly linked this bug to that theft, and I won't pretend to. But if you were a well-resourced actor holding BIG-IP source, the OAuth authorization server code path is exactly where I'd read first. It's niche enough to get less fuzzing than the core traffic paths, and it guards the most valuable secrets on the box.

That's the real lesson here. Edge appliances have quietly become identity providers. When one of them issues tokens, it isn't just a door. It's the key-cutting machine, and a compromise of the machine lasts longer than a compromise of any single door.

So check every BIG-IP for an OAuth authorization server profile, including the ones you're sure don't have one. Hotfix. Rotate the signing keys and client secrets even if the indicators come back clean, because the indicators can't see what happens after the key leaves. Then plant something that only an intruder would touch. If you want to see what a canary client and decoy services look like on your own network before the next edge zero-day lands, book a Mine2 demo and we'll walk through it with you.