On 22 September 2026 F5 published K000162605 for CVE-2026-94127, a heap-based buffer overflow in BIG-IP Access Policy Manager. When an APM access policy and an OAuth profile are configured on a virtual server, specific malicious traffic can lead to unauthenticated remote code execution. CISA added it to the Known Exploited Vulnerabilities catalog the same day with a federal due date of 25 September.
F5's advisory states that the vulnerability has been exploited. It was discovered internally by F5, and the article was last updated on 15 October.
What's affected
The condition is narrow, which helps with triage. F5 says the bug is only present when BIG-IP APM is configured as an OAuth Authorization Server. Deployments that use APM strictly as an OAuth client or resource server, without OAuth authorization server profiles, are not affected.
| Branch | Vulnerable | Fixed release | Engineering hotfix |
|---|---|---|---|
| 21.x | 21.1.0 | 21.1.0.3 | Hotfix-BIGIP-21.1.0.2.0.30.22-ENG |
| 17.5 | 17.5.0 to 17.5.1 | 17.5.1.10 | Hotfix-BIGIP-17.5.1.9.0.160.12-ENG |
| 17.1 | 17.1.0 to 17.1.3 | 17.1.3.6 | Hotfix-BIGIP-17.1.3.5.0.41.14-ENG |
Other details from the advisory:
- Severity: Critical, CVSS 3.1 score 9.8 and CVSS 4.0 score 9.3. CWE-122.
- It is a data plane issue with no control plane exposure. Appliance mode is also vulnerable.
- Other BIG-IP modules, BIG-IQ, BIG-IP Next, F5OS, NGINX and F5 Distributed Cloud are not vulnerable.
- F5 only evaluates versions that haven't reached End of Technical Support, so older branches are simply not assessed.
How to check if you're exposed
Get the version:
tmsh show sys version
Then find whether any virtual server combines an APM access policy with an OAuth authorization server profile. A quick first pass is to search the saved config for OAuth objects, then confirm in the GUI which virtual servers use them:
grep -n -i "oauth" /config/bigip.conf | head -50
If you only see client or resource server configuration and no authorization server profiles, F5 says you are not affected.
F5 published indicators of compromise for this bug, tracked internally as ID 2524777. It stresses that no single indicator proves compromise. The pattern to review is multiple OAuth authentication failures, then suspicious commands, then a TMM SIGABRT shortly after.
OAuth failures in /var/log/apm. F5 calls this medium confidence and says repetition is the signal, especially 10 or more in one log from a single IP:
grep "01990004:3" /var/log/apm* | grep "invalid_token" \
| grep -oE 'IP [0-9.]+' | sort | uniq -c | sort -rn | head
OAuth failure counters. An unexplained rise in total_failed deserves a look:
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed
Audit log. Note the timestamps of any burst of OAuth failures and review /var/log/audit around them.
TMM core files. F5 observed TMM entering a loop that makes the SOD daemon send SIGABRT. A core file alone is not an indicator, but investigate any from around the same time:
ls -la /var/core/ 2>/dev/null
What to do now
- Upgrade to 21.1.0.3, 17.5.1.10 or 17.1.3.6, or install the engineering hotfix for your release. F5 notes a fix in a given branch applies to all later releases in that branch.
- If you can't upgrade yet, F5's mitigation is an iRule applied to the affected APM virtual server. Contact F5 Support to obtain it. CISA's KEV note describes applying the vendor iRule as a temporary step that allows proactive forensic triage, followed by the final patch as soon as possible.
- Run the IOC checks above across every appliance where APM acts as an OAuth authorization server, and keep the results with your incident records.
- If the pattern shows up, treat the device as compromised. Preserve logs and core files, rotate the OAuth signing keys and client secrets the authorization server holds, and review tokens issued during the window.
- If you don't need APM as an OAuth authorization server, remove that role. Fewer exposed features on the data plane mean fewer bugs like this one that apply to you.
Why it matters
An identity component on the network edge is a high value target twice over. It is reachable without credentials by design, and it issues the tokens other applications trust. Code execution there can mean forged access to every service that relies on it, not just the box itself.
The narrow precondition is also a reminder that configuration inventory is part of vulnerability management. Teams that can answer "which BIG-IPs run APM as an OAuth authorization server" in minutes can scope this bug in minutes. Teams that can't end up patching everything blind.
Try it yourself
Build a one page inventory of your BIG-IP fleet with three columns: version, modules provisioned, and whether APM acts as an OAuth authorization server. Then compare it against the table above. The exercise usually surfaces at least one forgotten device.
This demo shows how an exploitability check narrows a CVE list to what actually applies to your configuration:
Click through it at your own pace, or open it full screen.
Quick check
Is my BIG-IP vulnerable if APM is only an OAuth client?
No. F5 says deployments that use APM strictly as an OAuth client or resource server, without OAuth authorization server profiles, are not affected.
Is a TMM core file proof of compromise?
No. F5 says a core file alone is not an indicator. The pattern that warrants human review is repeated OAuth failures, then suspicious commands, then a TMM SIGABRT shortly after.
Which releases fix CVE-2026-94127?
21.1.0.3, 17.5.1.10 and 17.1.3.6, plus engineering hotfixes for 21.1.0.2, 17.5.1.9 and 17.1.3.5.
