F5 patches a BIG-IP APM zero-day exploited for unauthenticated code execution

September 22, 2026. F5 publishes an advisory and engineering hotfixes for a flaw in the APM module of BIG-IP. September 22, 2026. CISA adds the flaw to its KEV catalog of actively exploited vulnerabilities. September 23, 2026. F5 narrows the scope: only the OAuth authorization server role is affected. Why it matters: CVE-2026-94127 allows remote code execution with no authentication at all, and the attack targets the virtual server itself — locking down the management interface changes nothing.

A flaw that lives in the OAuth authorization server role

BIG-IP APM (Access Policy Manager) is the module that controls how users reach an organization’s applications and network. The vulnerable configuration is specific: an OAuth authorization server profile must be attached to an access policy on the same virtual server, the one that receives the OAuth traffic.

The defect is a heap-based buffer overflow. Crafted traffic sent to that virtual server triggers remote code execution. F5 scores it 9.8 out of 10 on CVSS v3.1 and 9.3 on CVSS v4.0 — the practical ceiling for a flaw that is remotely exploitable with no interaction and no privileges.

The scope narrowed the next day. F5 updated its CVE record at 00:45 UTC on September 23 to state that the flaw exists only when APM acts as the authorization server — the component that issues access tokens. A system where APM serves only as an OAuth client or resource server, with no authorization server profile, is not affected. The CERT-EU advisory and CISA’s KEV entry, published before that change, describe the condition more broadly as an access policy and an OAuth profile on a virtual server.

Why cutting off the management plane does not help

The lesson of this flaw is a single sentence: the management interface is not the target. For most network appliance bugs, the first move is to stop exposing the admin surface — the management port, SSH, the web UI. Here, that measure is useless.

The malicious traffic reaches the virtual server itself, the data plane that carries user connections. A BIG-IP in production that exposes its OAuth authorization service — exactly what it is supposed to do — is reachable without the attacker ever needing an admin credential. Systems in Appliance mode, usually considered more locked down, are also vulnerable.

That nuance explains CISA’s speed: the agency added the flaw to KEV the same day it was disclosed, September 22, and gave federal civilian agencies until September 25 to act, under a directive issued in June. Three days to patch a perimeter device says how trivial the flaw is judged to exploit.

Affected versions and the fixes

F5 did not ship a regular release, but engineering hotfixes per branch. Only three branches are affected, and only on systems where APM is an OAuth authorization server:

Two details deserve attention. First, F5 did not evaluate versions that have reached End of Technical Support, so their status is unknown rather than safe. Second, the neighboring flaw CVE-2025-53521, already added to KEV in March, has fixes 17.1.3 and 17.5.1.3 that fall inside the affected ranges above. A system upgraded to either build still needs the new hotfix if it runs an OAuth authorization server.

When the hotfix cannot be installed immediately, F5 provides an iRule workaround to apply on the affected virtual server, obtained by opening a ticket with support. CISA told agencies to apply the iRule first “to allow for proactive forensic triage,” then install the final vendor patch as soon as possible.

Detecting exploitation before it becomes a confirmed breach

Exploitation leaves a readable signature in the logs. F5 and CERT-EU describe a trio that should trigger human review: repeated OAuth authentication failures, followed by suspicious commands, followed by a TMM SIGABRT shortly after.

# OAuth counters for the APM module — watch for a rise in total_failed
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed

# Repeated UserInfo failures: the exploitation signature
grep "The access token is invalid" /var/log/apm

# Suspicious commands in the audit log, around the timestamp of the failures
grep -iE "useradd|/bin/|curl|wget|tmctl" /var/log/audit/audit.log

Specifically, the combination to hunt for is this. The APM log shows failed UserInfo requests in /var/log/apm with the message “The access token is invalid” — especially ten or more requests from a single IP address within a short window. The OAuth counter shows an unexplained rise in total_failed. The audit log records suspicious commands around those failures. TMM core files are not a sign on their own, but they are worth investigating — F5 has seen TMM enter a loop and the SOD daemon send a SIGABRT.

One blind spot remains, acknowledged by the advisories: neither F5, CISA, nor CERT-EU says whether installing the hotfix revokes access an attacker has already gained. The reflex is therefore twofold — patch, but also hunt for signs of compromise before closing the case.

The identity angle: why an OAuth authorization server is a prime target

The flaw is worth pausing on because of what an OAuth authorization server is. It is the component that issues the access tokens applications then present to call APIs or protected resources. By compromising it, an attacker does not steal a password: they forge their own legitimacy. A corrupted authorization server can mint valid tokens for any client application — turning a single code execution into a durable compromise of the entire identity chain.

That is what separates this flaw from a plain RCE on a routing appliance. Here the target is not traffic, but trust. An attacker who holds the authorization server can, in principle, revoke everyone else’s access, issue tokens for themselves, or settle into the authentication flow permanently. CERT-EU’s instruction — preserve evidence before patching — makes full sense: no one yet knows whether the fix closes access an attacker already has.

One more wrinkle: the flaw does not depend on third-party software, but on configuration — the pairing of an OAuth authorization profile with an access policy. Teams that use APM to federate identities (SAML, OIDC, OAuth) are exactly the ones exposed. The recommendation is therefore not just “patch,” but inventory the virtual servers that carry an authorization-server role, and triage those first.

Verdict

CVE-2026-94127 proves a perimeter device can be compromised through its data plane, not its management plane. If your BIG-IP APM acts as an OAuth authorization server, apply the hotfix for your branch now, or the iRule workaround in the meantime. If APM is used only as an OAuth client or resource server, you are not exposed to this specific flaw — but verify the configuration rather than assume it. In every case, hunt for repeated UserInfo failures and a rising total_failed: that is the most reliable trace of an exploit already in progress.

References

• The Hacker News — F5 Patches Critical BIG-IP APM Zero-Day Exploited for Unauthenticated RCE on OAuth Servers (September 23, 2026)
• CISA — Known Exploited Vulnerabilities Catalog
• NVD — CVE-2026-94127