F5 BIG-IP APM Zero-Day CVE-2026-94127 Exploited: OAuth Servers Get Unauthenticated RCE
Security

F5 BIG-IP APM Zero-Day CVE-2026-94127 Exploited: OAuth Servers Get Unauthenticated RCE

A heap overflow in BIG-IP APM's OAuth handling gives unauthenticated attackers code execution in the data plane. F5 confirms exploitation, ships ENG hotfixes; CISA sets a 25 September deadline.

AB
Anthony Bahn IT Director & Cybersecurity Consultant
f5 big-ipcisa kevoauthheap overflowzero-day

What Happened

On 22 September 2026, F5 published advisory K000162605 for CVE-2026-94127, a heap-based buffer overflow in BIG-IP Access Policy Manager (APM). An attacker who can reach a vulnerable virtual server with crafted traffic gets code execution on the BIG-IP without any credentials. F5 states the flaw is being exploited in the wild, and it released engineering hotfixes for every supported branch instead of waiting for a scheduled point release.

The rest of the ecosystem moved the same day. NVD published the record at 15:17 UTC with a CVSS 3.1 score of 9.8 and a CVSS 4.0 score of 9.3. CISA added the CVE to the Known Exploited Vulnerabilities catalog with a due date of 25 September, three calendar days, and flagged it for forensic triage under BOD 26-04. CERT-EU issued advisory 2026-013 at 16:52 UTC, and the Canadian Centre for Cyber Security published alert AL26-022, both repeating F5's exploitation statement.

The trigger condition is narrow but common. A virtual server has to carry both an APM access policy and an OAuth profile, which is the configuration used when APM acts as an OAuth 2.0 authorization server, the component that authenticates users and issues access tokens to client applications. Deployments where APM is only an OAuth client or a resource server are not affected.

This is the second pre-authentication memory-corruption bug in APM to reach KEV in six months. CVE-2025-53521, a stack-based buffer overflow triggered when an access policy is configured on a virtual server, was published in October 2025 with the same 9.8 score and added to KEV on 27 March 2026.

CVE-2026-94127 arrived in a KEV batch aimed squarely at edge infrastructure. The same 22 September update added Check Point CVE-2026-93616, a path traversal in Security Management Server and related products that lets an unauthenticated attacker upload and execute scripts, Check Point CVE-2026-85102, the VPN certificate-validation bug covered here on 14 September, and Arista VeloCloud Orchestrator CVE-2026-93952. All four carry the same 25 September deadline. Check Point told Help Net Security that CVE-2026-93616 had been exploited against a handful of customers as far back as 23 July.

Who Is Affected

F5's advisory lists three vulnerable branches and the engineering hotfix that closes each one:

  • BIG-IP APM 21.1.0: fixed in Hotfix-BIGIP-21.1.0.2.0.30.22-ENG
  • BIG-IP APM 17.5.0 through 17.5.1: fixed in Hotfix-BIGIP-17.5.1.9.0.160.12-ENG
  • BIG-IP APM 17.1.0 through 17.1.3: fixed in Hotfix-BIGIP-17.1.3.5.0.41.14-ENG

Two details in the advisory remove the usual escape hatches. Restricting access to the management interface does not help, because the vulnerable code runs in the data plane that processes application traffic, not in the control plane behind the admin login. Systems running in Appliance mode, which strips the bash shell and limits administrators to tmsh, are also vulnerable. The only true fix is the hotfix.

If you run BIG-IP without the APM module, or with APM but without any OAuth profile bound to an access policy, you are outside the affected set. The catch is proving that. OAuth profiles are created under Access, Federation, OAuth Authorization Server in the configuration utility, then attached to an access profile, which is in turn assigned to a virtual server. That indirection means a scan of virtual-server names tells you nothing, and the exercise described in How to Confirm Whether a Configuration-Dependent CVE Applies to Your Appliance Fleet is the fastest way to get a defensible answer.

Technical Analysis

BIG-IP separates the control plane, where the configuration utility, tmsh and REST API live, from the data plane, which is the Traffic Management Microkernel (TMM). TMM is the process that owns the virtual servers, terminates client connections and, when APM is licensed, executes access policies against those connections. The overflow sits in this data-plane code, which is why network placement of the management port is irrelevant and why an unauthenticated client can reach it.

An OAuth authorization server is unauthenticated by design at the point where it matters. The authorization, token, userinfo and introspection endpoints exist to be contacted by parties who have not yet proven anything. F5 has not published root-cause detail, but the indicators it did publish are telling. The advisory describes a three-part pattern that should trigger human review: a burst of failed OAuth authentication attempts, followed by suspicious commands in the audit log, followed shortly by TMM aborting with SIGABRT. CERT-EU adds the specific log string to search for in /var/log/apm, a failed "Request UserInfo from Source ID (null) IP" message. Taken together, this reads like an exploit that hammers the userinfo path with malformed requests until the heap layout cooperates, and crashes TMM when it does not. That last part matters operationally: a failed exploitation attempt is also a data-plane outage, because every virtual server on the box stops passing traffic until TMM restarts.

Code execution inside TMM is close to the worst outcome an ADC can have. That process holds the private keys for every TLS virtual server it terminates, the session state for every logged-in APM user, and the secrets used to sign or encrypt the OAuth tokens it issues. An attacker at that vantage point does not need to escalate; they are already positioned to mint tokens that every downstream application trusts. Why the Server That Issues Your Access Tokens Is a Tier-0 Asset works through what that means for the applications behind it.

Immediate Actions

Enumerate exposure first. Identify every virtual server that has an access profile with an OAuth profile attached. The tmsh reference documents the OAuth profile object under the apm profile module, so listing those objects and then tracing which access profiles and virtual servers reference them is the practical approach. Record the result even when it is "none," because the CISA deadline applies to federal agencies in 72 hours and auditors will want evidence of the check.

Install the engineering hotfix on every affected unit. The three hotfix builds are listed above and in K000162605. Start with anything whose OAuth virtual server is reachable from the internet, then work inward. Do not treat an internal-only authorization server as safe; anything that can open a TCP connection to the virtual server can attempt this.

If you cannot patch inside the window, get the iRule. F5 is distributing a mitigation iRule through support tickets rather than publishing it. CISA's catalog entry describes it as a temporary measure to allow proactive forensic triage before installing the final patch, which is the right framing: it buys time, it is not a fix.

Hunt before you patch, or at least preserve first. CERT-EU's first recommendation is to preserve forensic evidence, and BOD 26-04's forensic-triage flag means federal operators must do this before remediation. The checks F5 and CERT-EU describe are:

  • Search /var/log/apm for repeated OAuth authentication failures, particularly the failed UserInfo request pattern. F5's threshold is ten or more invalid-token messages, especially from one source IP.
  • Run tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed and compare the failure counts against your baseline.
  • Correlate the timestamps of those failures with entries in /var/log/audit, looking for commands nobody on your team ran.
  • Check for TMM core files and SIGABRT events in the same window.

F5 is explicit that any one of these alone is not proof of compromise; the combination and timing are what correlate with attack.

If the pattern lines up, treat the box as owned. Rebuild from known-good media rather than patching in place, rotate the OAuth signing keys and every client secret the profile holds, revoke outstanding refresh tokens, and force re-authentication across the applications that trusted the tokens. The Canadian Cyber Centre also recommends reviewing administrative accounts and access policies for changes nobody can account for, and restricting management interfaces to trusted networks as general hardening, even though that does not block this bug.

Long-Term Outlook

Two exploited pre-auth overflows in the same APM data-plane code within a year is a pattern, not an accident. Access policies exist to parse untrusted input from unauthenticated clients, in C, inside a privileged process, and every protocol APM speaks (SAML, OAuth, Kerberos, RADIUS, form logon) is another parser in that position. Buyers should assume this class of bug will recur and plan around it: shorter patch SLAs for the ADC tier, out-of-band change windows, and a standing answer to the question "which virtual servers are exposed to which features."

The broader lesson is about where the security boundary actually is. Years of hardening guidance focus on the management plane: lock down port 443 on the admin interface, enable Appliance mode, restrict tmsh. None of that touched this vulnerability, and F5 said so in the advisory. Why Locking Down the Management Interface Does Not Protect an Appliance's Data Plane covers why data-plane bugs keep dominating the exploited-vulnerability lists for edge devices and what controls actually reduce that exposure. Planning for Repeat Zero-Days in Remote-Access Appliances, published here after the SonicWall SMA1000 chain, is the operational companion.

Finally, note what CISA did with this batch. Four edge-infrastructure flaws, three vendors, one three-day deadline, all tagged for forensic triage. Three days is the new normal for exploited perimeter bugs, and organizations that still need a week to schedule an ADC change window will keep finding themselves behind the attackers.

Sources

  • CISA Known Exploited Vulnerabilities catalog JSON feed, catalog version 2026.09.22: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
  • NVD, CVE-2026-94127: https://nvd.nist.gov/vuln/detail/CVE-2026-94127
  • NVD, CVE-2025-53521: https://nvd.nist.gov/vuln/detail/CVE-2025-53521
  • F5, K000162605 BIG-IP APM vulnerability CVE-2026-94127: https://my.f5.com/manage/s/article/K000162605
  • CERT-EU Security Advisory 2026-013: https://cert.europa.eu/publications/security-advisories/2026-013/
  • Canadian Centre for Cyber Security, AL26-022: https://www.cyber.gc.ca/en/alerts-advisories/al26-022-vulnerability-impacting-f5-big-ip-access-policy-manager-apm-cve-2026-94127
  • F5 BIG-IP documentation, Using APM as an OAuth 2.0 Authorization Server: https://techdocs.f5.com/en-us/bigip-17-1-0/big-ip-access-policy-manager-oauth-configuration/using-apm-as-an-oauth-2-server.html
  • F5 tmsh reference, apm profile oauth: https://clouddocs.f5.com/cli/tmsh-reference/v14/modules/apm/apm_profile_oauth.html
  • The Hacker News, 23 September 2026: https://thehackernews.com/2026/09/f5-patches-critical-big-ip-apm-zero-day.html
  • Help Net Security, Zeljka Zorz, 23 September 2026: https://www.helpnetsecurity.com/2026/09/23/check-point-f5-big-ip-apm-zero-days-targeted/
  • Cyber Security News, 23 September 2026: https://cybersecuritynews.com/f5-big-ip-oauth-server-0-day-flaw/
  • Field Effect, 22 September 2026: https://fieldeffect.com/blog/f5-fixes-big-ip-apm-vulnerability
← Back to all news