F5 BIG-IP APM zero-day: patch your OAuth server now

The box that issues your access tokens is the one being exploited. F5 disclosed CVE-2026-94127 on September 22 — a heap-based buffer overflow in BIG-IP APM that gives an unauthenticated attacker remote code execution, rated CVSS 9.8. It was exploited as a zero-day before the advisory existed. CISA added it to the Known Exploited Vulnerabilities catalog the same day, under Binding Operational Directive 26-04.

What actually happened

The flaw only fires under a specific configuration: BIG-IP APM acting as an OAuth authorization server — the role where it issues access tokens to applications — with an APM access policy and an OAuth profile bound to the same virtual server handling that traffic. If you run APM purely as an OAuth client or as a resource server, you are not affected by this one.

That narrowness is not comfort. The affected configuration is exactly how APM gets deployed when it is the front door for remote access and SSO, which is most of the time it is deployed at all.

F5 has shipped engineering hotfixes rather than full releases, per The Hacker News' write-up:

• 21.1.0 — Hotfix-BIGIP-21.1.0.2.0.30.22-ENG
• 17.5.0 through 17.5.1 — Hotfix-BIGIP-17.5.1.9.0.160.12-ENG
• 17.1.0 through 17.1.3 — Hotfix-BIGIP-17.1.3.5.0.41.14-ENG

F5's suggested indicators of compromise are worth reading before you patch, not after: repeated failed UserInfo requests in /var/log/apm, unexplained spikes in the total_failed OAuth counter, and audit-log commands that line up in time with those failures. CISA's alert itself cites BOD 26-04's rapid-remediation requirement rather than printing a date; reporting puts the federal deadline at September 25.

Why patching the identity layer comes first

Most small businesses do not run BIG-IP. Plenty of them sit behind someone who does — a managed IT provider, a parent company, a healthcare or logistics partner whose portal you log into every morning. This is a vendor question before it is a server question.

Assume compromise, not just exposure. This was exploited before anyone knew it existed. Patching closes the door; it does not tell you who already walked through. On an appliance that mints access tokens, the post-patch work is the real work: rotate OAuth client secrets and signing keys, invalidate live sessions, and read the audit log for the window before the hotfix landed.

Know which of your logins terminate on somebody's appliance. The practical version of this is a list: every application your team signs into, and who owns the identity layer in front of it. Most teams cannot produce that list, which is why "are we affected" becomes a three-day email thread instead of a ten-minute check.

Ask your provider in writing, with a date. Not "are we patched" — "which BIG-IP versions do you run, when did the hotfix go on, and were client secrets rotated afterward." A vague yes from an MSP is not an answer, and you want the exchange on the record.

Engineering hotfixes need a follow-up ticket. An -ENG hotfix is a targeted binary, not a maintenance release. It gets you out of the fire, and it also gets forgotten until an upgrade quietly rolls it back. Put the "move to a GA release that includes this fix" item in the backlog today, with a name on it.

An unauthenticated RCE on the device that issues tokens is about as bad as the shape gets. Three days is the federal clock. Yours should be shorter.

Sources: CISA KEV alert, September 22, 2026, The Hacker News, SecurityWeek.