CVE-2026-94127: F5 BIG-IP APM Hotfixes for Actively Exploited OAuth RCE

F5 confirms active exploitation of CVE-2026-94127 in BIG-IP APM​

F5's own advisory is short. It says that when a BIG-IP APM access policy and an OAuth profile are configured on a virtual server, specific malicious traffic can lead to remote code execution (RCE). It also carries an unusual warning for a vendor bulletin: "We have learned that this vulnerability has been exploited."

F5 describes the impact plainly: the vulnerability allows an unauthenticated attacker to perform RCE, the BIG-IP system in Appliance mode is also vulnerable, and this is a data plane issue with no control plane exposure. F5 Product Development has assigned ID 2524777 to the vulnerability, and it has been classified as CWE-122 Heap-based Buffer Overflow. GBHackers reports that the advisory assigns it a CVSS v3.1 score of 9.8 and a CVSS v4.0 score of 9.3. CERT-EU, the EU institutions' security team, lists the same 9.8 CVSS score.

APM is F5's access management proxy. It sits in front of applications, APIs and cloud resources and decides who gets through. A bug that gives an unauthenticated outsider code execution on that gateway sits right on the path attackers most want to control. Field Effect adds that exploitation is remote, requires no authentication, and does not require user interaction.

The "Appliance mode" detail deserves attention. Appliance mode is a hardened BIG-IP setting that restricts administrative access, and some admins may assume it protects them from this kind of bug. F5 says it does not. The "data plane" wording tells you where the attack comes in: the flaw is reached through client traffic hitting a virtual server, not through the management interface. Locking down the management port is still good practice, but it does not close this hole.

The OAuth authorization server setup is what puts BIG-IP systems at risk​

The key question for every BIG-IP owner is whether their configuration matches. Many APM deployments will not.

The trigger requires both pieces on one virtual server: an APM access policy and an OAuth profile. The Canadian Centre for Cyber Security, in its alert AL26-022, puts it the same way: the flaw affects systems "where an APM access policy and an OAuth profile are configured on the same virtual server." Under those conditions, crafted traffic can lead to code execution and possibly full system compromise.

F5 narrows this further. As quoted by BleepingComputer, F5's advisory says the flaw affects instances configured as an OAuth Authorization Server. It adds: "Deployments using APM strictly as an OAuth Client / Resource Server (without OAuth authorization server profiles configured) are not affected by this vulnerability." GBHackers reports the same thing: the vulnerable condition arises when APM is configured to function as an OAuth Authorization Server.

In practice this is a real dividing line. When BIG-IP acts as an OAuth client or resource server, it consumes tokens that some other identity provider issues. When it acts as an authorization server, BIG-IP issues the tokens itself. Field Effect notes that organizations commonly use the vulnerable pairing when BIG-IP acts as an authentication gateway for applications that use OAuth-based authentication, single sign-on, or federated identity services. If your BIG-IP fronts applications but hands identity to a separate identity provider, F5's wording suggests you are outside the blast radius. You still need to confirm that no authorization server profile exists anywhere on the box.

Affected BIG-IP 17.1, 17.5 and 21.1 releases and the ENG hotfixes​

CERT-EU lists the affected releases, where the vulnerable configuration is present, as:

Independent trackers report the same three fix identifiers. HOL's research record notes the flaw is fixed by ENG hotfixes Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG, and Hotfix-BIGIP-17.1.3.5.0.41.14-ENG.

Two practical points follow from the table. First, these are engineering hotfixes ("-ENG"), not new point releases. Judging by the names, each one appears to be built on the latest release of its branch (17.1.3, 17.5.1 and 21.1.0). Admins running an older point release on 17.1 or 17.5 should check F5's release matrix to see whether they must move to that base version first. Second, the published CVE record states that software versions which have reached End of Technical Support (EoTS) are not evaluated. If you run an older BIG-IP branch with the vulnerable OAuth setup, you have no statement either way. The safe reading is that your exposure is unknown, not that you are fine.

The Canadian Centre also flags that organizations running Common Criteria-evaluated configurations should apply the updates in line with their change management and certification requirements. For regulated environments, that paperwork is another reason the interim mitigation matters.

F5's iRule mitigation buys time for forensic triage​

For customers who cannot install a hotfix right away, F5 offers an interim fix. According to CERT-EU, if patching cannot happen immediately, F5 provides an iRule-based mitigation for the affected virtual server, and customers must contact F5 Support to get it. An iRule is BIG-IP's scripting mechanism for inspecting and acting on traffic, so this mitigation filters traffic before it reaches the vulnerable code. It does not change that code. The iRule has not been published openly, so there is no public text to copy. Customers need an F5 Support contract relationship to get it.

CISA's catalog entry spells out the intended order of work. The Known Exploited Vulnerabilities (KEV) listing for CVE-2026-94127, added September 22 with a September 25 due date, tells agencies to apply the vendor-provided iRule "for temporary mitigation to allow for proactive forensic triage," then "install the final vendor patch as soon as possible." The entry marks forensic triage as required under Binding Operational Directive 26-04. HOL's summary of the listing agrees: the federal KEV due date is 2026-09-25, forensic triage is marked Yes, and CISA's notes say apply F5's temporary iRule for triage, then install the vendor hotfix.

That order matters beyond federal networks. Patching a compromised appliance closes the door but does nothing about an attacker who is already inside. CERT-EU's advice follows the same sequence: preserve forensic evidence, apply the relevant hotfix, check for signs of compromise, and start incident response if you find any. If you upgrade first, you may overwrite the evidence you need.

Reading F5's indicators of compromise without chasing false alarms​

F5 has published detection guidance, and CERT-EU has repeated it in usable detail. F5's high-level rule is that multiple OAuth authentication failures, followed by suspicious commands, shortly followed by a TMM SIGABRT, is the combination that should trigger human review. TMM is the Traffic Management Microkernel. As one technical write-up on DEV Community explains, the Traffic Management Microkernel implements the data plane. SIGABRT is the signal that forces a process to abort.

The review CERT-EU describes works as a sequence:

1. Search /var/log/apm for repeated OAuth failures, especially 10 or more from a single IP address in a short window. F5's example entry is a Request UserInfo failure with Error Code (invalid_token) and the description "The access token is invalid."
2. Check the OAuth counters with tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed and look for an unexplained increase in total_failed.
3. If OAuth failures appear, review /var/log/audit around the same timestamps for suspicious commands.
4. Investigate any TMM core files in that context. F5 says it has seen TMM enter a loop that causes the SOD daemon to send a SIGABRT.

Each signal alone has an innocent explanation. Clients with expired tokens produce invalid-token errors every day, and CERT-EU says outright that a TMM core file alone is not an indicator of compromise. The sequence is what counts: a burst of token failures, then unexpected commands in the audit log, then a TMM abort. Field Effect notes one limit: the advisory does not describe the exploitation process or explain how these events relate to each stage of exploitation. Defenders have a pattern to hunt for, not a full picture of the attack.

The Canadian Centre adds a broader review: check access logs for fast or high-volume OAuth failures, and look at administrative accounts and access policies for anything suspicious. A clean run of the four steps above should not end the hunt if an attacker could have created accounts or changed policies.

Exposure figures and F5's track record raise the stakes​

Exact exposure is hard to measure. BleepingComputer reports that the nonprofit Shadowserver tracks more than 14,700 IP addresses with BIG-IP APM fingerprints. That figure counts APM instances visible on the internet, not vulnerable ones. It cannot show which have the OAuth authorization server setup, which are patched, or which are honeypots. Still, it gives a rough idea of how many APM front doors are reachable.

History argues against waiting. BleepingComputer notes that CISA has flagged eight actively exploited F5 vulnerabilities since November 2021, four of them also used in ransomware attacks. The outlet also recalls that F5 disclosed in October 2025 that state-sponsored hackers had breached its systems and stolen BIG-IP source code and information on undisclosed vulnerabilities. No public evidence connects that breach to CVE-2026-94127. The relevant point is simpler: BIG-IP is a long-standing, well-studied target, and exploitation began before the patch was out.

CVE-2026-94127 also landed in a crowded week. The same KEV update on September 22 added Check Point gateway and management flaws and an Arista VeloCloud Orchestrator bug, all with the same three-day federal deadline. Teams that run perimeter gear from several vendors are dealing with more than one emergency at once.

What BIG-IP admins should do now​

The first decision is scoping. Find out whether any BIG-IP virtual server combines an APM access policy with an OAuth profile acting as an authorization server. If one does, treat the device as possibly compromised until you have evidence otherwise, apply the iRule, preserve evidence, hunt, then patch. If you use APM only as an OAuth client or resource server, F5 says you are not affected. Schedule the hotfix through normal change control and confirm the configuration rather than assuming it.

• Take inventory of every BIG-IP virtual server with both an APM access policy and an OAuth profile, and confirm whether any OAuth authorization server profile is set up. That configuration is the exposure test, not the version number alone.
• Install Hotfix-BIGIP-17.1.3.5.0.41.14-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG or Hotfix-BIGIP-21.1.0.2.0.30.22-ENG for your branch. Check whether you need to reach that branch's base release first.
• If you cannot patch immediately, get F5's mitigation iRule from F5 Support. Treat it as a bridge for forensic triage, not a replacement for the hotfix.
• Preserve logs and core files before upgrading. Then hunt /var/log/apm, the tmctl global_oauth_stat counters and /var/log/audit for the failure-command-crash sequence F5 describes.
• Do not rely on Appliance mode or management-interface restrictions for protection. F5 says the bug is in the data plane and Appliance mode systems are vulnerable.
• Treat vulnerable systems on End of Technical Support branches as unassessed. They need an upgrade plan, not an assumption of safety.

CVE-2026-94127 is dangerous because of where APM sits: at the network edge, trusted to decide who gets in, and now shown to run attacker code from a single crafted OAuth request. The fix exists, the mitigation exists, and the detection guidance is specific enough to act on. The September 25 federal deadline is effectively the timeline for everyone with an exposed OAuth authorization server. Organizations that find the failure-command-crash pattern in their logs will be dealing with a breach investigation, not just a patch.