F5 BIG-IP Access Policy Manager has an unauthenticated remote code execution flaw, CVE-2026-94127, and it was a zero-day: exploitation was already underway when F5 published advisory K000162605 on September 22, 2026. It only bites deployments where APM acts as an OAuth authorization server. If that is you, this is a patch-now event. CISA gave US federal agencies until September 25 to remediate.
What happened
- September 22, 2026: F5 published K000162605 and confirmed active exploitation. NVD published the record the same day. CISA added the CVE to the Known Exploited Vulnerabilities catalog with a three-day remediation window under BOD 26-04, and flagged it for forensic triage, not just patching. The same KEV batch carried two exploited Check Point flaws.
- September 25, 2026: KEV due date for federal agencies.
The bug is a heap-based buffer overflow (CWE-122) that F5 SIRT scored CVSS v3.1 9.8 / v4.0 9.3: network vector, no privileges, no user interaction. It is a data-plane issue with no control-plane exposure, and Appliance mode does not help. Shadowserver counted more than 14,700 BIG-IP APM instances exposed on the internet when the advisory landed.
Are you affected
Two conditions must both hold on the same virtual server: an APM access policy, and an OAuth profile with APM acting as an OAuth authorization server (issuing tokens). Deployments that use APM purely as an OAuth client or resource server are not affected, per F5’s advisory text.
| Branch | Affected | Fix |
|---|---|---|
| 21.1 | 21.1.0 | Hotfix-BIGIP-21.1.0.2.0.30.22-ENG |
| 17.5 | 17.5.0 to 17.5.1 | Hotfix-BIGIP-17.5.1.9.0.160.12-ENG |
| 17.1 | 17.0.0 to 17.1.3 | Hotfix-BIGIP-17.1.3.5.0.41.14-ENG |
Fixes shipped as engineering hotfixes; versions past end of technical support were not evaluated. Check your exact build against K000162605 rather than assuming a later point release is clean.
How the attack works
Public detail is deliberately thin. What F5 has said: specially crafted traffic to the OAuth-configured virtual server overflows a heap buffer and yields code execution as an unauthenticated remote attacker. The observed attack pattern is not subtle: a burst of failed OAuth authentications, then suspicious commands, then a TMM crash with SIGABRT. That crash is your friend: exploitation attempts, successful or not, tend to leave a mess in the logs. Attribution has not been published.
Detection
This maps to ATT&CK T1190, Exploit Public-Facing Application. F5’s guidance is to correlate three signals by frequency, source, and time: OAuth failures in /var/log/apm, command execution in /var/log/audit, and TMM SIGABRT events.
On the box, check the OAuth counters for unexplained spikes in failures:
Data source: BIG-IP shell, tmctl OAuth statistics
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failedIn the SIEM, start with the failure burst. F5 flags ten or more related invalid-token failures from one source IP in a short period as the investigation threshold.
Data source: /var/log/apm forwarded via syslog to Splunk (field names assume the F5 Add-on; adjust index/sourcetype to your ingestion)
index=* sourcetype="f5:bigip:apm:syslog" "invalid_token"
| bin _time span=5m
| stats count AS failures BY _time, src_ip, host
| where failures >= 10
| sort - failuresData source: Syslog table (Microsoft Sentinel), BIG-IP forwarding /var/log/apm
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has "OAuth" and SyslogMessage has_any ("invalid_token", "failed")
| extend SrcIp = extract(@"\b(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\b", 1, SyslogMessage)
| summarize Failures = count() by bin(TimeGenerated, 5m), SrcIp, HostName
| where Failures >= 10
| order by Failures descTuning honestly: OAuth failure bursts happen for boring reasons, like expired tokens or a misconfigured client retrying in a loop. The signal is the combination: a failure burst from one source, then commands in /var/log/audit you did not run, then a TMM SIGABRT close in time. Also review the appliance for unexpected outbound connections and configuration changes without an administrator behind them.
Mitigation
- Apply the hotfix for your branch from the table above.
- Cannot patch today: F5 provides an iRule mitigation through K000162605 for affected virtual servers. F5 and CISA both frame it as a stopgap that also buys time for forensic triage. Deploy it, triage, then patch.
- Internet-exposed and in the affected configuration since before September 22: treat the box as potentially compromised and follow CISA’s forensic triage guidance before you trust it again. Patching does not evict an attacker who is already on the appliance.
Bottom line
If BIG-IP APM issues OAuth tokens anywhere in your estate, assume you were scanned. Patch or apply the iRule this week, then go look for the failure-burst-plus-SIGABRT pattern in the window before you did.