F5 BIG-IP APM Vulnerability: CVE-2026-94127

If you run F5 BIG-IP with Access Policy Manager, check today whether any of your virtual servers have both an access policy and an OAuth profile configured, because that exact combination is what CVE-2026-94127 exploits, and F5 says attackers are already using it. This note is for the IT lead, MSP, or business owner whose remote access, VPN, or single sign-on runs through a BIG-IP. The F5 BIG-IP APM vulnerability is narrower than the severity score makes it sound, so the whole job today is small: find out whether that pairing exists on your box, and if it does, follow the steps in the order below.

F5 published its advisory on September 22, 2026 and said plainly, “We have learned that this vulnerability has been exploited.” CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a September 25 deadline for federal agencies. That three-day window is not a law that applies to a business in Phoenix or Tucson, but it tells you how seriously the people with visibility into active attacks are taking it.

What the F5 BIG-IP APM vulnerability actually does

In plain English: the part of BIG-IP that handles OAuth sign-in traffic can be fed malformed data that overruns the memory set aside for it, and an attacker can use that to run their own commands on the device. No password, no account, no prior access.

The technical name is a heap-based buffer overflow, CWE-122. Software reserves a chunk of memory for an expected amount of data. If it does not check the size carefully enough, oversized input spills past the end and into memory holding other things, including instructions the system will go on to run. That is how a formatting bug turns into someone else’s code executing on your gateway.

Two details set the severity. It needs no login at all, which is why it scores 9.8 out of 10 on the standard severity scale. And it applies to systems running in Appliance mode as well, so the hardened configuration is not a defense here.

There is genuinely good news in the advisory, and it is worth saying out loud rather than skipping past. F5 describes this as a data plane issue with no control plane exposure. The traffic-handling side is affected, not the management side. That does not make it minor, but it does narrow what you are looking at.

Are you exposed

Start with the part most coverage will gloss over: having a BIG-IP does not mean you are vulnerable. A remote-access gateway is supposed to be reachable from the internet. That is its job, and it is not a finding. The question is whether a specific pair of features is configured together, and whether you are on a patched build.

The flaw only applies where a virtual server has an APM access policy and an OAuth profile on it. One without the other does not trigger it. So the first check is an inventory, not a patch.

If you do find that pairing, match your version against the fixes:

Your version train	Fix to apply
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

Note these are engineering hotfixes, not regular point releases, which is usually a sign the vendor is moving faster than its normal release train allows.

One more line in F5’s advisory deserves attention, because it is easy to read past: versions that have reached End of Technical Support were not evaluated. If your BIG-IP is on an older train than the three above, do not read that as “not affected.” Read it as “nobody checked, and no hotfix is coming.” For those boxes the answer is a replacement or upgrade plan, not a patch.

The order matters: mitigate, look, then patch

Most write-ups on a day like this say patch now and stop there. CISA’s catalog entry is more specific, and the sequence it lays out is the useful part.

The entry flags this one as requiring forensic triage, and the note tells you to apply F5’s iRule as a temporary mitigation first, specifically so you have room to check whether anything already happened, then install the vendor patch. That ordering exists for a reason. Patching closes the door, but it can also disturb or age out the very logs and state that would tell you whether someone walked through it last week. If your vulnerable virtual server was live and reachable, “were we already hit” is a fair question, and it is much easier to answer before you rebuild over the answer.

Be practical about how far to take this. If you check your inventory and nothing pairs an access policy with an OAuth profile, you are done, and the sequence above is not your problem. If you find the pairing but the service was internal only, patch on your normal emergency cadence and move on. The triage-first ordering earns its keep in the case where the vulnerable virtual server was genuinely internet-facing.

For the looking part, the Canadian Centre for Cyber Security alert gives concrete guidance: review access logs for OAuth authentication failures, especially in rapid succession or unusual volume, and check administrative accounts and access policies for activity nobody can account for.

What to do today

In order, and most readers will stop at step two.

1. Inventory. List every virtual server and note which ones have both an APM access policy and an OAuth profile. This is the check that decides everything else.
2. If none pair those two, write that down and stop. Schedule the hotfix into your normal patch window so you are not carrying it, but today is over for you.
3. If any do pair them, get the iRule. Open a ticket with F5 Support and ask for the mitigation iRule for CVE-2026-94127, then apply it. It is the fastest way to take the exposure off the table.
4. Check the logs before you patch. OAuth authentication failures in bursts, and admin or policy changes nobody owns. If something looks off, stop and get help rather than patching over it.
5. Apply the hotfix for your train from the table above.
6. Confirm management interfaces are restricted to trusted networks. Not because of this bug, which does not touch the control plane, but because you are already in there looking.

Why a gateway flaw is worth more attention than a typical app bug

BIG-IP APM is usually the front door. It is the thing deciding who gets into the VPN, which staff member reaches which internal application, and whether a sign-in is honored. Code execution on the device making those decisions is a different category from a bug in one internal application, because the gateway was trusted by everything behind it.

That is the argument for knowing what your perimeter actually runs, not just that it exists. An external penetration test is the independent version of the inventory in step one, across everything reachable from outside rather than one product: what is exposed, what version it is on, and what is genuinely misconfigured versus simply present by design. An internal penetration test answers the second half of the question, which is what someone actually reaches once they are past the gateway. That second answer is the one that decides whether a bad day is contained or not.

None of that is a reason to be alarmed about today. The F5 BIG-IP APM vulnerability is serious, and it is also closable in an afternoon by the smaller group it actually applies to. F5 found it, shipped a fix inside of two days, and told the truth about exploitation. The businesses that end up with a problem are almost never the ones that read the advisory. They are the ones that did not know the feature was turned on.

Not sure what your internet-facing systems are running, or whether anything out there is on a build that has quietly fallen behind? Tell us a little about your setup and what is prompting the question, and we will come back with a fair, fixed quote. Request a quote.