CVE-2026-94127

What is BIG-IP APM?

F5 BIG-IP Access Policy Manager is the access control module of the BIG-IP platform. It runs on the same appliance or virtual edition that does load balancing and application delivery, and it turns a virtual server into an authentication gateway: users hit the published application, APM intercepts the request, runs a visual policy that can require SAML, OAuth, OIDC, Kerberos, certificate or multi-factor authentication, and only then passes traffic to the backend pool. It is also the engine behind F5's VPN and remote access offering.

That places APM in front of the applications an organization most wants to protect, on a device that terminates TLS and therefore sees the plaintext of everything crossing it. BIG-IP appliances also sit at the perimeter by design and frequently hold session tokens, credentials and private keys. Code execution on one is a top-tier outcome for an intruder, which is why this product line has been a sustained target for nation-state actors.

Overview

CVE-2026-94127 is a heap-based buffer overflow in the Traffic Management Microkernel (TMM), the process that handles all data plane traffic on a BIG-IP system. When a virtual server is configured with both a BIG-IP APM access policy and an OAuth profile, specifically crafted traffic to that virtual server can overflow a heap buffer during OAuth handling and lead to remote code execution. No authentication is required.

The CVE carries a CVSS 3.1 base score of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and a CVSS 4.0 score of 9.3. F5 scopes it as a data plane issue with no control plane exposure, and states that systems running in Appliance mode are also affected; Appliance mode restricts administrative shell access, so it constrains what an attacker does next but does not prevent the overflow.

F5 published K000162605 on 2026-09-22 with engineering hotfixes and confirmed the vulnerability has been exploited. CISA added it to the Known Exploited Vulnerabilities catalog the same day with a 2026-09-25 deadline, and the Canadian Centre for Cyber Security issued alert AL26-022.

CISA's required action for this entry is unusually specific: apply the vendor-provided iRule as a temporary mitigation first, to allow for proactive forensic triage, then install the final vendor patch as soon as possible. The ordering is deliberate. Patching a compromised appliance can destroy the evidence that it was compromised.

Affected Versions

Only systems with an APM access policy and an OAuth profile configured on the same virtual server are exploitable. A BIG-IP running APM without OAuth, or OAuth without an APM access policy, does not present the vulnerable path. Check the running configuration rather than assuming, since the combination is common in OIDC-fronted application publishing.

Technical Details

The weakness is CWE-122, heap-based buffer overflow. In plain terms, TMM allocates a buffer on the heap to hold data it is about to process, then writes more into it than it reserved because nothing compares the incoming length against the allocation size. The overflow corrupts adjacent heap memory, which on a mature exploitation target means overwriting heap metadata or function pointers in neighbouring structures to redirect execution.

What makes this severe beyond the usual is where it lands. TMM is not a helper process, it is the single high-performance process that handles all traffic on the device, and it runs with full privileges. Memory corruption inside it is memory corruption inside the data path itself.

The attack profile requires nothing from the attacker but reach: no credentials, no user interaction, low complexity, no chaining with a second CVE. The trigger is crafted traffic to an exposed virtual server, meaning any client that can reach the published application can reach the vulnerable code, because reaching the OAuth handler is what the virtual server is there to do. F5 has not published the specific field, message or OAuth flow stage that overflows, and no proof-of-concept is public.

Detection guidance centres on TMM's behaviour under an unreliable exploit: repeated OAuth authentication failures, unexplained command execution on the device, and TMM SIGABRT crash events. F5 and the national cyber agencies both caution that any one of these alone is weak evidence, since TMM crashes have mundane causes too.

Discovery

F5 has not credited an outside researcher, named a reporting organization, or said how the vulnerability came to its attention. The company acted as CNA and published the CVE record with the advisory and the hotfixes on 2026-09-22, alongside the statement that exploitation had already occurred, which is the pattern of a flaw found through incident response rather than proactive review.

Context worth noting without over-reading: CISA maintains Emergency Directive ED 26-01, "Mitigate Vulnerabilities in F5 Devices," issued after F5's disclosure that a nation-state actor had accessed BIG-IP source code and undisclosed vulnerability information. No public source has connected CVE-2026-94127 to that incident, and F5 has not done so either. It remains an open question rather than an established link.

Exploitation Context

F5 and CISA both state the vulnerability has been exploited, and neither has published more. There is no named threat actor, no victim count, no targeted sector, no campaign name, and no exposure figure from Shodan, Censys or Shadowserver specific to this CVE. CISA does not flag it as used in ransomware campaigns.

The population at risk is smaller than "every BIG-IP" but concentrated in exactly the wrong place: internet-facing virtual servers publishing applications behind OAuth or OIDC authentication. Those are, by construction, reachable by anonymous clients. Given BIG-IP's history as a target of persistent, well-resourced actors, and the absence of a public exploit that would indicate commodity abuse, the reasonable working assumption is targeted exploitation against selected organizations rather than mass scanning, though nothing public confirms that either way.

Remediation

1. Apply the F5-provided iRule mitigation first if there is any chance the device is already compromised. CISA's required action calls for this explicitly, so that forensic triage can happen before a patch overwrites evidence. Obtain the iRule through F5 Support.
2. Preserve evidence before patching a suspect device: capture a qkview, collect TMM core dumps, and export logs off-box.
3. Install the engineering hotfix for your branch: Hotfix-BIGIP-21.1.0.2.0.30.22-ENG on 21.1.0, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG on 17.5.x, or Hotfix-BIGIP-17.1.3.5.0.41.14-ENG on 17.1.x.
4. Inventory which virtual servers actually carry both an APM access policy and an OAuth profile. That combination defines your exposed surface and tells you which systems need the iRule immediately versus which can follow the normal change process.
5. Restrict reachability where the business allows it. If a published application is only used by known networks or by clients arriving through another gateway, front the virtual server with an address allowlist until the hotfix is installed.
6. Review logs for the published indicators: clusters of OAuth authentication failures, TMM SIGABRT crashes and restarts, and any command execution on the appliance not tied to an administrator session. Correlate rather than alerting on any one alone.
7. If compromise is suspected, treat the device's secrets as exposed. Rotate TLS private keys and certificates, administrative credentials, APM session and OAuth signing material, and any credentials cached for backend authentication. Compare the running configuration and iRule set against a known-good baseline.
8. Federal civilian agencies were required to remediate by 2026-09-25 under BOD 26-04. The three-day window and the triage-before-patch instruction together signal that CISA expects some of these devices to already be compromised.