F5 Patches a BIG-IP APM Zero-Day That Attackers Were Already Using Against OAuth Servers

CVE-2026-94127 lets an unauthenticated attacker crash into remote code execution on BIG-IP systems where APM issues OAuth tokens — and CISA added it to its Known Exploited Vulnerabilities catalog the same day F5 disclosed it.

F5 shipped hotfixes on September 22 for a critical flaw in BIG-IP Access Policy Manager, and it didn't wait to say why the update mattered. "We have learned that this vulnerability has been exploited," the company wrote in its advisory — an unusually blunt line for a vendor bulletin, and one that pushed the flaw straight onto CISA's Known Exploited Vulnerabilities catalog the same day.[1][2]

The vulnerability, tracked as CVE-2026-94127, sits in a fairly specific corner of BIG-IP's Access Policy Manager module. It only matters if you've configured APM to act as an OAuth authorization server — the thing handing out tokens to applications, not just consuming them. If that's your setup, an attacker doesn't need a password, a session, or any interaction from a user to reach it.[1]

What F5 disclosed

According to F5's own advisory, when a BIG-IP APM access policy and an OAuth profile are both configured on the same virtual server, specially crafted traffic sent to that server can trigger remote code execution. The bug is a heap-based buffer overflow — CWE-122 in industry shorthand — and F5's product development team tracks it internally as ID 2524777.[1]

Two details in the advisory are worth sitting with. First, this lives entirely in the data plane — the part of the system that processes actual application traffic — rather than the control plane that handles administrative access. That means the usual advice to lock down the management interface doesn't help here; the malicious traffic goes straight to the virtual server that's already exposed to users. Second, BIG-IP systems running in Appliance mode, which is often treated as a hardened configuration, are vulnerable too. Neither of those caveats is a footnote — they're the reason this bug is dangerous rather than merely theoretical.

F5 rates the flaw 9.8 out of 10 on CVSS v3.1 and 9.3 on CVSS v4.0, both comfortably inside the Critical band. No authentication, no privileges, and no user interaction are required to trigger it.

Who is actually exposed

The presence of BIG-IP APM on your network doesn't, by itself, put you in the blast radius. What matters is whether a virtual server has an APM access policy and an OAuth Authorization Server profile configured together. Systems where APM is used purely as an OAuth client or resource server — consuming tokens rather than issuing them — are explicitly not affected, according to F5's advisory.[1]

Affected and fixed versions as published in F5's advisory K000162605.[1]

There's a wrinkle worth flagging for anyone tracking this closely. F5 updated its CVE record at 00:45 UTC on September 23 to narrow the vulnerable condition specifically to the OAuth authorization-server role. CISA's KEV entry and a CERT-EU advisory, both published before that update, describe the condition somewhat more broadly — an access policy and an OAuth profile on a virtual server, without specifying the authorization-server role as narrowly. If you're triaging your own environment, F5's advisory is the definitive source to check against, and it's worth rereading it directly rather than relying on secondary summaries written before the clarification[4][5].

Also worth noting: an earlier APM vulnerability, CVE-2025-53521, landed on the KEV catalog back in March 2026. Its fix versions — 17.1.3 and 17.5.1.3 — fall inside the range this new advisory now marks as vulnerable. A system that was fully patched against last spring's bug still needs this new hotfix if it runs APM as an OAuth authorization server.

How the attack actually works — and what isn't known

What F5 hasn't published is just as important as what it has. There's no public proof-of-concept, no payload details, and no confirmation of how many organizations have actually been hit. F5's CVE record and CISA's KEV entry don't say who's behind the attacks or how widespread they are — anyone claiming otherwise is going beyond what's been verified.

It's also unclear whether applying the hotfix removes access an attacker may already have gained. Neither F5 nor CISA nor CERT-EU addresses that question directly, which is why the recommended response below treats patching and incident response as two separate steps rather than one.

Severity and the KEV clock

CISA's KEV listing gave U.S. federal civilian agencies until September 25 to remediate, three days after F5's disclosure — a compressed window that reflects both the severity score and the confirmed exploitation.[2] Private organizations aren't bound by that deadline, but the same math applies: a 9.8 with no authentication barrier and active exploitation doesn't leave much room for a slow patch cycle.

What to do now

Start by finding every virtual server that pairs an APM access policy with an OAuth Authorization Server profile. That's the entire exposed surface — nothing else in a BIG-IP deployment is implicated by this advisory. Once you've mapped that, the fix is the engineering hotfix matching your branch, listed in the table above.

If you can't patch right away, F5 offers an interim iRule mitigation for the affected virtual server, available by opening a support case.[1] CISA's own guidance for this CVE recommends applying that iRule first, specifically to allow for forensic triage, and then installing the vendor patch once that review is done — a sequencing choice that matters if a system may already be compromised.

F5, through CERT-EU's advisory, published a cluster of signs worth checking regardless of whether you patch immediately. Repeated failed UserInfo requests in /var/log/apm, particularly ten or more from a single IP address in a short window, are one signal. A rise in the total_failed counter from tmctl global_oauth_stat is another. Suspicious commands in /var/log/audit around the same timestamps, followed by a TMM core file and a SIGABRT from the SOD daemon, round out the pattern. None of these on its own proves compromise — a TMM core file can appear for unrelated reasons — but the combination, especially in that order, is what F5 flags as worth a closer look.

What remains genuinely uncertain

A few things aren't nailed down yet, and it's worth being honest about that rather than smoothing over the gaps. F5's advisory and CISA's KEV entry don't disclose how many systems have been hit, who's responsible, or what the attackers did once inside. There's no confirmed public exploit code circulating that F5 or CISA has acknowledged. And whether the hotfix alone clears out any access an attacker already established is not addressed in any of the advisories reviewed here — which is exactly why the forensic-triage-first approach matters more than a simple "patch and move on."

The takeaway

This isn't a sprawling, every-BIG-IP-box-is-doomed situation. It's a narrow but serious one: if APM issues OAuth tokens on your network, you're exposed to an unauthenticated path to remote code execution that's already being used against real targets. If it doesn't, you're not in the affected set at all, according to F5. The work now is confirming which category you're in, and treating the answer with the urgency a 9.8 with confirmed exploitation deserves.

Sources & References

1. F5, Inc. — "K000162605: BIG-IP APM vulnerability CVE-2026-94127," Security Advisory, September 22, 2026
2. CISA — Known Exploited Vulnerabilities Catalog, CVE-2026-94127 entry, added September 22, 2026
3. BleepingComputer — "F5 patches BIG-IP APM zero-day flaw exploited in RCE attacks," Sergiu Gatlan
4. The Hacker News — "F5 Patches Critical BIG-IP APM Zero-Day Exploited for Unauthenticated RCE on OAuth Servers," Swati Khandelwal, September 23, 2026
5. CERT-EU — Security Advisory 2026-013, Critical Vulnerability in F5 BIG-IP APM