F5 BIG-IP APM under OAuth: a heap overflow that only fires on one configuration
CVE-2026-94127 matters to a subset of BIG-IP APM owners. F5 disclosed the flaw on 22 September 2026 in security advisory K000162605, and CISA added it to the Known Exploited Vulnerabilities catalog the same day. The details make this one worth ten minutes of configuration checking rather than a blanket panic.
What the vulnerability is
CVE-2026-94127 is a heap-based buffer overflow (CWE-122) in BIG-IP Access Policy Manager. F5 tracks it internally as 2524777. Sending crafted network traffic can corrupt memory and lead to remote code execution on the BIG-IP system. The CVSS v3.1 score is 9.8 and the CVSS v4.0 score is 9.3.
The configuration condition that decides everything
The flaw is not reachable on every APM deployment. It requires a virtual server that has both an APM access policy and an OAuth profile, with APM acting as an OAuth Authorization Server. Deployments that use APM only as an OAuth client or as a resource server, with no authorization server profile, are not affected.
This distinction has a practical consequence. A team can be running APM, using OAuth somewhere in the stack, and still be safe, or be exposed, depending on which role APM plays. F5 states that the flaw sits in the data plane that handles application traffic, so restricting access to the management interface does not block exploitation on an affected virtual server. Appliance mode does not change the outcome either.
Checking your own configuration
Two tmsh commands answer the question for most deployments. The first lists the profiles attached to each virtual server:
tmsh list ltm virtual one-line | grep -E 'virtual|profiles { apm'
An access profile appears in the output with a /Common/ prefix, which confirms the first condition. The second command inspects the OAuth profiles and their role:
tmsh list apm profile oauth all-properties
Profiles named with oauth_client or oauth_rs indicate client and resource server roles and do not create the exposure. A profile that puts APM in the authorization server role, attached through an access profile, is the configuration that matters.
Affected versions and fixes
| Branch | Affected range | Engineering hotfix |
|---|---|---|
| 21.1.x | 21.1.0 | Hotfix-BIGIP-21.1.0.2.0.30.22-ENG |
| 17.5.x | 17.5.0 to 17.5.1 | Hotfix-BIGIP-17.5.1.9.0.160.12-ENG |
| 17.1.x | 17.1.0 to 17.1.3 | Hotfix-BIGIP-17.1.3.5.0.41.14-ENG |
Other BIG-IP modules, BIG-IQ, BIG-IP Next, F5 Distributed Cloud Services, the NGINX product line, F5OS and F5 AI Gateway were assessed as not affected. F5 also noted that versions past end of technical support were not assessed, so absence from the affected list is not proof of safety.
Detection and response
F5 published three indicators that deserve correlation rather than isolated review: repeated OAuth authentication failures, suspicious command execution, and subsequent Traffic Management Microkernel (TMM) SIGABRT events. Ten or more invalid-token messages in /var/log/apm from the same source IP warrant a closer look. Analysts can check failure counters with:
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed
A new TMM core file under /shared/core, or an unexplained TMM restart, should be correlated against the authentication failures before drawing a conclusion. A core file alone does not prove compromise.
If immediate patching is not possible, F5 support can provide an iRule as a temporary mitigation. That is a stopgap, not a fix.
References
- F5, Security Advisory K000162605: https://my.f5.com/manage/s/article/K000162605
- CISA, Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Top comments (0)