F5 BIG-IP APM CVE-2026-94127 Exploited: Hotfixes and Mitigation

F5 has confirmed that CVE-2026-94127, a critical heap-based buffer overflow in BIG-IP Access Policy Manager (APM), is being exploited. On a vulnerable system, an unauthenticated attacker can run code remotely. The flaw affects BIG-IP APM 21.1.0, 17.5.0 through 17.5.1 and 17.1.0 through 17.1.3 when APM is configured as an OAuth authorization server. F5 published the advisory on September 22, 2026, with engineering hotfixes and an iRule mitigation, and CISA gave federal agencies until September 25 to act.

What F5 disclosed

F5’s security advisory K000162605 for BIG-IP APM vulnerability CVE-2026-94127 went out on September 22, 2026. 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. F5 classifies the bug as CWE-122, a heap-based buffer overflow, tracks it internally as ID 2524777, and says it was discovered internally.

The advisory states plainly that F5 has learned the vulnerability has been exploited. It gives no detail on who is behind the attacks, how many customers were hit or when exploitation began.

F5 describes it as a data plane issue with no control plane exposure. In practice, the attack path is the traffic that flows through the affected virtual server, not the management interface. Restricting access to the BIG-IP configuration utility, the standard defense against management-plane bugs, does not help here. If the virtual server is reachable, so is the bug.

Who is affected?

The vulnerable configuration is narrow, but it is common in organizations that use BIG-IP APM as an identity provider for their own applications. According to F5, three things must be true:

1. The BIG-IP runs the Access Policy Manager (APM) module on an affected version.
2. A virtual server has both an APM access policy and an OAuth profile attached.
3. APM is configured as an OAuth Authorization Server, meaning BIG-IP issues tokens to clients.

F5 says deployments that use APM strictly as an OAuth Client or Resource Server, without OAuth authorization server profiles, are not affected. The same applies to BIG-IP systems that don’t run APM at all: the advisory lists all other BIG-IP modules as not vulnerable.

BIG-IP in Appliance mode, a hardened mode that restricts shell access, is still vulnerable. Admins should not treat Appliance mode as a mitigation.

Affected and fixed versions

F5 has fixed CVE-2026-94127 in engineering hotfixes (EHFs) for each supported branch rather than in a new point release. The hotfix images are on F5 Downloads.

According to F5, the EHFs contain all fixes in BIG-IP Hardened Releases 2 (HR2), and it documents them in K000163302, its overview of the engineering hotfix release on BIG-IP 17.5.1.9 and 17.1.3.5. As with all its advisories, F5 only evaluates versions that have not reached End of Technical Support (EoTS). Older branches such as 16.x and 15.x are not listed as either vulnerable or safe, because F5 no longer assesses them under its security vulnerability response policy (K4602). If you still run APM on an EoTS release with an OAuth authorization server configured, assume you are exposed and plan an upgrade.

Products F5 lists as not vulnerable

• BIG-IP Next CNF and BIG-IP Next for Kubernetes
• F5 Distributed Cloud (all services) and NGINX One Console
• F5OS, F5OS-A and F5OS-C
• All NGINX products
• F5 AI Gateway

What an OAuth authorization server does, and why it matters here

OAuth 2.0, defined by the IETF in RFC 6749, splits the job of granting access among several roles. The authorization server authenticates users and issues access tokens. A client is the application that asks for those tokens. A resource server is the API that accepts the tokens and serves data. BIG-IP APM can play any of these roles, which is why F5’s advisory draws the line so precisely.

When APM is the authorization server, the BIG-IP itself becomes the token issuer that other applications trust. Its endpoints have to accept requests from any client that wants a token or wants to check one, and those clients are often on the public internet. The log entry F5 flags as an indicator, a failed request to the UserInfo endpoint with an invalid token, comes from this token-handling path. F5 has not published the vulnerable code path, so it is not known which endpoint the attack uses.

If your BIG-IP only consumes tokens (for example, APM checks tokens issued by Microsoft Entra ID, Okta or another identity provider before letting traffic through), F5 says that deployment is not affected. The risk sits with organizations that made BIG-IP their identity provider.

How serious is CVE-2026-94127?

The CVSS numbers reflect the worst case: a network attack, low complexity, no privileges, no user interaction, and high impact on confidentiality, integrity and availability. That gives 9.8 under CVSS v3.1 and 9.3 under v4.0. The NVD record for CVE-2026-94127 also carries CISA’s SSVC assessment dated September 22: exploitation “active”, automatable “yes” and technical impact “total”.

That combination is why the flaw jumped straight to the top of patch queues. BIG-IP APM usually sits at the internet edge in front of VPN portals, single sign-on and application access. An OAuth authorization server virtual server has to be reachable by the clients that request tokens. Very often that means it is reachable from the internet.

Mitigation: the F5 iRule

For systems that cannot take the hotfix right away, F5 says an iRule can be applied to the affected APM virtual server to mitigate the vulnerability. The iRule is not published in the advisory. Customers have to contact F5 Support to get it.

CISA’s catalog entry frames the iRule as a stopgap. Its notes say to apply the vendor-provided iRule as a temporary mitigation to allow for proactive forensic triage, then install the final vendor patch as soon as possible. In other words, the iRule buys time to check whether a system has already been compromised. It is not a replacement for the EHF.

Indicators of compromise

F5 lists three indicators and says they should prompt investigation when they appear close together in time. No single one proves compromise. At a high level, the pattern to look for is multiple OAuth authentication failures, followed by suspicious commands, shortly followed by a TMM SIGABRT.

1. Repeated OAuth failures in /var/log/apm

F5 calls this a medium-confidence indicator of attack. The log message below appears in normal operation too, so repetition is the signal, not the message itself. F5 says sustained repetition (10 or more in one log) should be reviewed by a person, especially if every entry comes from a single IP address:

err tmm1[…]: 01990004:3: <PROFILE_NAME>: Request UserInfo from Source ID (null) IP <IP> failed. Error Code (invalid_token) Error Description (The access token is invalid.)

You can also pull the OAuth counters with tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed. F5 says an unexplained increase in total_failed should be investigated.

2. Audit log activity around those timestamps

If the OAuth failures show up in bursts, note the timestamps and review /var/log/audit around them for commands you can’t account for.

3. TMM core files

F5 has seen the Traffic Management Microkernel (TMM) enter a loop during exploitation, which leads the SOD daemon to send it a SIGABRT. A TMM core file alone is not an indicator, F5 says, but any core files should be investigated.

If you find the full sequence, treat the device as potentially compromised. Isolate it where you can, preserve logs and core files, and involve your incident response team before you rebuild or patch, so evidence isn’t lost.

CISA KEV and the September 25 deadline

CISA added CVE-2026-94127 to its Known Exploited Vulnerabilities catalog on September 22, 2026, with a due date of September 25, 2026. The same day, CISA also listed two actively exploited Check Point vulnerabilities with the same deadline. The entry falls under BOD 26-04, CISA’s directive on prioritizing security updates based on risk, which sets remediation urgency from asset exposure, KEV status, exploit automation and technical impact. It is also flagged for CISA’s forensic triage requirements. Whether the flaw has been used in ransomware campaigns is listed as “Unknown”.

The directive binds federal civilian agencies, but the three-day window is a useful benchmark for any organization running an internet-facing APM OAuth server.

What we don’t know yet

F5’s advisory answers the operational questions, but leaves several open:

• Who is exploiting it. F5 has not attributed the activity, and CISA lists ransomware use as unknown.
• When exploitation began. F5 says it discovered the bug internally, but it has not said whether that was before or after the first attacks.
• How widespread attacks are. There is no count of affected customers.
• Whether a regular point release is coming. For now the fix ships only as engineering hotfixes for 21.1.0, 17.5.1 and 17.1.3.

Check the advisory again before you finalize change windows. F5 updates its K articles in place, and the Updated Date at the top of K000162605 will show any revisions.

Timeline

What BIG-IP admins should do now

1. Find APM OAuth authorization servers. List every BIG-IP running APM, then every virtual server that has both an access policy and an OAuth profile, and confirm whether APM is acting as the authorization server. You can use F5 iHealth, which F5 says can diagnose vulnerabilities for BIG-IP systems, to confirm exposure.
2. Check versions. Anything on 21.1.0, 17.5.0–17.5.1 or 17.1.0–17.1.3 without the matching EHF is vulnerable.
3. Get the iRule if you can’t patch today. Open a case with F5 Support and apply it to the affected virtual servers.
4. Hunt before you patch. Review /var/log/apm, the OAuth counters, /var/log/audit and any TMM core files for the pattern F5 describes.
5. Install the engineering hotfix. Apply Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG or Hotfix-BIGIP-17.1.3.5.0.41.14-ENG as appropriate.
6. Plan upgrades off EoTS branches. If APM OAuth runs on a release F5 no longer evaluates, there is no listed fix.

The bottom line: the vulnerable setup is specific, but for organizations that run BIG-IP APM as an OAuth authorization server, this is a pre-authentication remote code execution bug in an edge device that is already being exploited. Apply the iRule today, check the logs, and schedule the hotfix this week.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage