TL;DR - CVE-2026-94127 is a heap-based buffer overflow in F5 BIG-IP Access Policy Manager, rated 9.8, and it is reachable without credentials. The catch that decides whether you care is narrow and specific: it affects BIG-IP APM only when it is acting as an OAuth Authorization Server, with an APM access policy and an OAuth profile configured on the same virtual server. F5 disclosed it on 22 September and shipped engineering hotfixes the same day. CISA added it to the Known Exploited Vulnerabilities catalog on 22 September and gave US federal agencies until 25 September to remediate, which is three days. Attackers were already using it when F5 published. What you need to do: find out whether any of your BIG-IP virtual servers run APM in that OAuth Authorization Server configuration, patch those to the engineering hotfix, apply F5's iRule mitigation if you cannot patch tonight, and then hunt for compromise rather than assuming a clean patch closes the incident.
By The Numbers
| Item | Value |
|---|---|
| CVE | CVE-2026-94127 |
| CVSS v3.1 | 9.8 |
| CVSS v4.0 | 9.3 |
| Disclosed | 22 September 2026 |
| Added to CISA KEV | 22 September 2026 |
| US federal deadline | 25 September 2026 |
| Affected branches | 21.1.0, 17.5.0 to 17.5.1, 17.1.0 to 17.1.3 |
| Plane affected | Data plane (no control-plane exposure per F5) |
I have a standing habit of reading appliance advisories quickly and moving on, because most of them land in the "authenticated administrator, unlikely chain, patch in your next window" bucket. This one did not let me do that. It is a 9.8. It needs no credentials. And the sentence in F5's advisory that actually decides your week is not the score, it is the configuration condition attached to it.
That condition is worth reading twice, because it is the difference between "we have a BIG-IP, so this is on us" and "we have a BIG-IP, and this is somebody's change ticket on Thursday".
F5 states the vulnerability is present when BIG-IP APM operates as an OAuth Authorization Server with an APM access policy and an OAuth profile configured on the same virtual server. Deployments using APM only as an OAuth client, or as a resource server, are not affected.
Let me walk you through what the flaw actually is, why the deadline you may have seen mentioned is already gone, and the three checks I would run before anyone opens a change window.
What the flaw actually is
CVE-2026-94127 is a heap-based buffer overflow. Crafted traffic sent to an affected virtual server can trigger remote code execution without authentication. Rapid7 published a technical analysis; watchTowr Labs wrote it up under the title "Is This A Joke? In The Auth Header?", which is a fair summary of the reaction from people who read F5's APM code for a living.
The part that matters architecturally: F5 says the flaw affects the BIG-IP data plane, that systems operating in Appliance mode remain vulnerable, and that there is no control-plane exposure.
Sit with that for a second, because it inverts the instinct most of us have with appliance bugs. Our default mental model for a network appliance CVE is "is the management interface exposed to the internet". For this one, the exposure is in the path that is designed to be internet-facing. You cannot solve this one by hiding the management interface, because the management interface was never the problem.
Affected releases are BIG-IP 21.1.0, 17.5.0 through 17.5.1, and 17.1.0 through 17.1.3. F5 notes that releases which have reached End of Technical Support were not evaluated, which is vendor code for "we did not look, so treat them as affected".
The deadline you saw has already passed
CISA added CVE-2026-94127 to the Known Exploited Vulnerabilities catalog on 22 September, the same day F5 disclosed it, and set a remediation deadline of 25 September for covered US federal civilian agencies. Three days to remediate, for a class of bug that normally gets three weeks.
That deadline has now passed. If you are reading this from Adelaide, Auckland or anywhere else outside the US federal scope, no such clock was ever running on your estate, and that is precisely the problem worth naming. Vendors and agencies reacted in three days because exploitation was already confirmed in the wild when the advisory dropped. Your organisation has no equivalent forcing function. The realistic sequence for most ANZ shops is that this lands in a monthly patch cycle, gets scheduled, and gets deferred once because someone is on leave.
For an actively exploited, unauthenticated, remotely reachable 9.8 on infrastructure that terminates your internet traffic, that sequence is the wrong shape.
The score is not the story. The configuration condition is the story, and the closed federal deadline is the tell that this one is already being used.
The three checks I would run before the change window opens
You are not trying to inventory your whole BIG-IP estate to a forensic standard here. You are trying to answer one question: does any of our BIG-IP APM deployments match the vulnerable configuration? That is a smaller job than it sounds, and it is the only job that changes your priority.
1. Find every BIG-IP running APM, then find which ones run it as an OAuth Authorization Server.
This is a configuration question, not a network question. Ask whether APM is configured as an OAuth Authorization Server, and whether an APM access policy and an OAuth profile sit on the same virtual server. If both are true, that virtual server is the thing to patch first. If APM is only ever the OAuth client or the resource server in your setup, F5's own wording puts you outside the affected set, and that is worth writing down so the next person does not re-derive it at 6pm on a Friday.
2. Patch the affected branches to the engineering hotfix.
F5 shipped build-specific hotfixes: Hotfix-BIGIP-21.1.0.2.0.30.22-ENG for the 21.1 branch, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG for 17.5, and Hotfix-BIGIP-17.1.3.5.0.41.14-ENG for 17.1. Note the word hotfix: these are engineering builds, not a routine maintenance release, which usually means a change record that does not look like your standard upgrade and a vendor case if your support entitlement has lapsed. Get that unblocked before the window, not during it.
3. If you cannot patch tonight, ask F5 Support for the iRule.
F5's published temporary mitigation is an iRule that customers can request through F5 Support to reduce exposure while preparing the permanent fix. An iRule is a stopgap, not a fix, and it carries its own operational risk on an appliance your authentication path already depends on. Treat it as insurance for the hours between "we know we are exposed" and "we have a maintenance window", and get the real patch scheduled in the same conversation.
Patch is the start of the incident, not the end
This is the part I would push hardest on with a team that has just finished the patch. When exploitation is confirmed before disclosure, the patched systems are not clean systems. They are systems that were reachable while a working unauthenticated RCE was in active use, for a period nobody has bounded yet.
The practical implication is that the change record should have a hunting task attached to it, and that task should look at the BIG-IP itself rather than only at whatever sits behind it. F5's own guidance says to preserve evidence and hunt for compromise, and CERT-EU's advisory on the APM issue points the same direction. If your APM appliance is a policy decision point for authentication, then a compromise there is an identity event, not just a network event: it is a box that sees credentials, sessions and policy outcomes for everything behind it. That is a materially worse thing to have had popped than a transit router.
So the questions I would want answered inside the first week: what did the Appliance-mode filesystem look like before, is there a known-good configuration backup to diff against, and did anything about the appliance's own behaviour change in the window between 22 September and your patch.
What this says about how you handle appliances
Two things, and neither of them is "buy a different load balancer".
The first is that the vulnerable surface on modern appliances keeps moving into the data plane. F5 is not unusual here. The traffic-handling path runs more logic than it used to, because it is expected to make policy decisions, terminate TLS, and speak OAuth. Every one of those capabilities is code sitting on a path that has to be reachable from the internet to be useful. The mental model of "the appliance is a bump in the wire, and the risky part is its admin UI" is out of date, and advisories like this are how it gets updated.
The second is that the configuration is now part of your exposure surface, and configuration is rarely inventoried with the discipline that firmware versions get. Most organisations can tell you their BIG-IP software versions within a few minutes. Far fewer can tell you which virtual servers run which APM roles, because that knowledge lives with whoever built the config and has never needed to be written down in a form a security team can query. That gap is the reason this CVE takes a week of your team's time instead of an afternoon, and it is worth closing while the topic is live rather than during the next incident.
Key Takeaways
- The vulnerable configuration is specific. BIG-IP APM as an OAuth Authorization Server, with an APM access policy and an OAuth profile on the same virtual server. APM as an OAuth client or resource server is not affected.
- It is the data plane, not the management interface. F5 states no control-plane exposure, and Appliance mode remains vulnerable. Hiding your admin UI does not reduce your exposure to this one.
- CISA's 25 September deadline has passed, and it never applied to you. US federal agencies had three days because exploitation was confirmed at disclosure. If you are in ANZ, that forcing function does not exist on your estate, and the default monthly cycle is too slow for an actively exploited 9.8.
- Affected branches are 21.1.0, 17.5.0 to 17.5.1, and 17.1.0 to 17.1.3, with End of Technical Support releases not evaluated and therefore unproven either way.
- Patch, then hunt. Exploitation was confirmed before the advisory. A patched appliance is a system that was reachable while a working unauthenticated RCE was in use. Preserve evidence and look at the appliance itself, not only at what it protects.
- Configuration is your blind spot. You can produce a firmware version list in minutes. Fewer teams can produce a list of which virtual servers run which APM roles.
FAQ
What is CVE-2026-94127?
A heap-based buffer overflow in F5 BIG-IP Access Policy Manager, rated 9.8 under CVSS v3.1 and 9.3 under v4.0, reachable without authentication from the data plane. It allows remote code execution on affected virtual servers.
Am I affected if I run BIG-IP but not APM?
No. The flaw is in APM, and F5's advisory ties exposure specifically to APM operating as an OAuth Authorization Server with an access policy and OAuth profile on the same virtual server.
We use APM as an OAuth client, not as the authorization server. Are we exposed?
F5 states that deployments using APM only as an OAuth client or as a resource server are not affected. Confirm that against your own configuration rather than assuming it, because the role a virtual server plays is not always recorded where a security team can see it.
Does hiding the management interface protect us?
Not for this vulnerability. F5 states there is no control-plane exposure and that the flaw affects the data plane. This is the opposite of the usual appliance pattern where locking down the admin UI is the mitigation.
Which versions need patching?
BIG-IP 21.1.0, 17.5.0 through 17.5.1, and 17.1.0 through 17.1.3. Releases that have reached End of Technical Support were not evaluated, so unless you have written confirmation from F5, treat them as affected.
What if we genuinely cannot patch this week?
Request F5's iRule mitigation through F5 Support, treat it as temporary insurance rather than a fix, and get the patch scheduled in the same conversation. Then plan the hunting work, because the mitigation addresses exploitation going forward, not what may already have happened.
Is this being exploited right now?
Yes. F5 confirmed active exploitation at disclosure, which is why CISA both added it to the KEV catalog and gave federal agencies only three days.
My Take
The thing I keep coming back to is not the vulnerability. It is the shape of the response. This is an internet-facing, unauthenticated, code-execution bug on an appliance class that sits in the middle of the network, and the industry reaction was competent and compressed, because the US federal community has a mechanism that turns "this is being exploited" into "fix it in three days". That mechanism is the interesting artefact. It is not clever technology; it is a deadline with consequences attached, pointed at a list that everyone can see.
Nothing stops an ANZ organisation from running that same mechanism on its own estate. KEV is public. The vendors publish. The only missing part is the internal rule that says an actively exploited, unauthenticated, remotely reachable vulnerability jumps the queue regardless of what the patch cycle had planned. Most teams would agree with that rule in a meeting. Getting it written down, so that a team can act on it on a Tuesday without a round of escalation, is the work.
If you take one thing from this week, let it be that you can produce a list of your BIG-IP software versions, and check whether you can also produce a list of which virtual servers run which APM roles. One of those lists is on your dashboard already. The other one is what this CVE actually required.
Mathew Clark Founder, SecureInSeconds Currently: patching a box that should have been decommissioned in 2024, because a 9.8 outranks my tidy-up list
Further Reading
- F5 security advisory for CVE-2026-94127 (K-article and hotfix links)
- CISA Known Exploited Vulnerabilities catalog
- CERT-EU security advisory 2026-013: critical vulnerability in F5 BIG-IP APM
- F5 BIG-IP zero-day under active attack as the 25 September CISA deadline looms (eSecurityPlanet)
- Android 17 turns on certificate transparency, and your internal CA pays for it
- 440 GitHub Apps were running on leaked private keys
