F5 BIG-IP APM CVE-2026-94127: hunt the OAuth server that took unauth traffic
An F5 BIG-IP Access Policy Manager virtual server that also carries an OAuth Authorization Server profile is supposed to speak trusted OAuth. On 22 September 2026, F5 published K000162605 for CVE-2026-94127: a heap-based buffer overflow (CWE-122) that can turn unauthenticated data-plane traffic to that VIP into remote code execution. F5 rates CVSS 3.1 at 9.8 and CVSS 4.0 at 9.3, discovered the defect internally, and states, "We have learned that this vulnerability has been exploited." CISA added it to KEV the same day, with a federal due date of 25 September 2026 and BOD 26-04 forensic-triage guidance: vendor iRule first, then the hotfix.
For estates that run APM as an OAuth Authorization Server, the practical questions are:
Which VIPs on trains 21.1.0, 17.5.0 through 17.5.1, or 17.1.0 through 17.1.3 combine an APM access policy with an OAuth Authorization Server profile?
Can untrusted networks reach those data-plane addresses?
Do /var/log/apm, tmctl global_oauth_stat, /var/log/audit, and TMM cores show the vendor hunt triad in one window?
After a suspected hit, which sessions, policies, and credentials on that edge broker still deserve trust?
How the attack works
Stage A. An AS-profiled VIP is live
Operators put an APM access policy and an OAuth Authorization Server profile on the same virtual server, and that combination is the attack surface. F5 scopes the flaw to the data plane, with no control-plane exposure, and appliance mode is vulnerable too. The scoping detail worth pausing on is the one that lets most people out: APM used strictly as an OAuth Client or Resource Server, with no Authorization Server profile, is out of scope entirely. So inventory the Authorization Server role before anything else, because treating every APM box as in scope wastes the two days you have.
Stage B. Unauthenticated heap overflow to RCE
From there an attacker needs one thing, a network path to the affected VIP. No APM login is required. Crafted traffic against the OAuth path triggers the heap overflow and yields remote code execution, which means the investigative signal is unauthenticated data-plane traffic arriving where only trusted OAuth should ever have spoken.
Stage C. Edge identity broker compromise
What that costs you is the host that brokers access and OAuth for every application behind it. Session material, policy abuse, and a quiet foothold on a high-trust edge appliance all sit outside the workstation telemetry most teams actually hunt in. Treat the broker as a trust root until inventory, logs, and cores say otherwise, rather than the other way around.
Stage D. Vendor hunt triad only
F5 and CERT-EU published a correlation pattern rather than a single smoking gun, and the distinction matters because any one of these four signals on its own will send you chasing nothing. The pattern is clusters of failed UserInfo requests in /var/log/apm carrying invalid_token or "The access token is invalid", roughly ten or more from one source IP in a short window; an unexplained rise in the total_failed counter from tmctl global_oauth_stat; suspicious commands in /var/log/audit near those same timestamps; and then a TMM loop that leads SOD to send SIGABRT, with TMM cores landing shortly after. Bind the hunt to that triad. Do not invent extra indicators and do not try to reconstruct exploit HTTP bodies.
Risk: the edge identity broker
BIG-IP APM acting as an OAuth Authorization Server is a high-value edge identity broker, so the company risk is not one box. It is unauthenticated RCE on the broker, session and policy abuse downstream of it, and a foothold that workstation hunting will never surface. Internet-facing and flat-network AS VIPs stay in scope until inventory says otherwise, and empty APM logs are not clearance, not for the other F5 roles you do not operate and not for boxes whose syslog never left the host.
Mitigate and reduce risk
Start by inventorying every VIP that combines an APM access policy with an OAuth Authorization Server profile on the affected trains, which are 21.1.0, 17.5.0 through 17.5.1, and 17.1.0 through 17.1.3. Then contact F5 Support for the temporary mitigation iRule, because F5 does not publish it and you have to open a ticket to get it. Apply that for forensic triage first, then install the engineering hotfixes from K000162605: Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG, and Hotfix-BIGIP-17.1.3.5.0.41.14-ENG.
Restrict AS VIP reachability to trusted networks wherever you can. If you suspect compromise, preserve /var/log/apm, /var/log/audit, tmctl snapshots, and TMM cores before any reboot or config change, because all four are the kind of thing that a well-meaning remediation step destroys. Federal stakeholders have a KEV due date of 25 September 2026, and BOD 26-04 adds a forensic triage requirement on top of it. That ordering is the whole point: the upgrade remediates the software, and the investigation covers what happened before it.
How to hunt the activity
There are five artifact classes to reconstruct from the F5 and CISA guidance, and they only mean something together. Start with the inventory of APM plus OAuth Authorization Server VIPs on the affected trains, then the /var/log/apm clusters of failed UserInfo carrying invalid_token or "The access token is invalid", then an unexplained rise in tmctl global_oauth_stat total_failed, then suspicious commands in /var/log/audit near those timestamps, and finally the TMM loop with SOD SIGABRT and TMM cores arriving shortly after. One of those is a lead. Four of them in the same window is an incident.
Hunt in KQL
Tune fields to your BIG-IP syslog or APM export. Replace example hosts and VIPs with inventory.
let StartTime = datetime(2026-09-22);
let AsVipHosts = dynamic(["apm-as.example.com"]); // replace
Syslog
| where TimeGenerated >= StartTime
| where Computer in (AsVipHosts) or HostName in (AsVipHosts)
| where SyslogMessage has_any ("invalid_token", "The access token is invalid", "Request UserInfo", "global_oauth_stat", "SIGABRT", "SOD")
| project TimeGenerated, Computer, HostName, SyslogMessage, ProcessName, Facility
| order by TimeGenerated ascCommonSecurityLog
| where TimeGenerated >= datetime(2026-09-22)
| where DestinationHostName in (dynamic(["apm-as.example.com"])) or DestinationIP in (dynamic(["203.0.113.10"]))
| project TimeGenerated, DestinationHostName, DestinationIP, SourceIP, RequestMethod, RequestURL, DeviceAction, AdditionalExtensions
| order by TimeGenerated ascPair with CMDB for versions on 21.1.0, 17.5.0-17.5.1, or 17.1.0-17.1.3 with APM plus OAuth Authorization Server on a VIP. On-box, run tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed against baseline.
Hunt in Falcon CQL
Select the view covering BIG-IP syslog or APM ingest, network to AS VIP IPs, and host sensors on /var/log/apm or /var/log/audit.
(@rawstring=/invalid_token|The access token is invalid|Request UserInfo|global_oauth_stat|SIGABRT|SOD|TMM/i OR (#event_simpleName=NetworkConnectIP4))
| table([@timestamp, ComputerName, UserName, aip, LocalAddressIP4, RemoteAddressIP4, FileName, FilePath, CommandLine, @rawstring], limit=1000)Scope network rows to AS VIP destinations. Audit command lines beside APM invalid_token clusters deserve the same timeline as TMM crash markers.
Hunt in Splunk
Replace indexes. Time picker from 22 September 2026 unless you expand earlier.
index=YOUR_BIGIP_SYSLOG_INDEX OR index=YOUR_APM_INDEX OR index=YOUR_FW_INDEX
| eval msg=coalesce(message, syslog_message, _raw)
| eval client=coalesce(src_ip, src, clientip, client_ip, SourceIP)
| eval dest=coalesce(dest_ip, dest, dest_host, DestinationHostName, host)
| where like(msg, "%invalid_token%") OR like(msg, "%The access token is invalid%") OR like(msg, "%Request UserInfo%") OR like(msg, "%SIGABRT%") OR like(msg, "%global_oauth_stat%") OR match(msg, "(?i)SOD|TMM.*core|/var/log/audit")
| table _time host dest client msg
| sort 0 _timePreserve the timeline. Early aggregation by IP can hide whether APM failures, audit commands, and TMM aborts line up in F5's order.
Hunt in Kibana / Elastic
Use KQL in Discover against ECS-mapped syslog, firewall, and host audit indices for the exposure window.
(message: ("invalid_token" OR "The access token is invalid" OR "Request UserInfo" OR "SIGABRT" OR "global_oauth_stat" OR SOD OR TMM) OR destination.ip: ("203.0.113.10") OR host.name: ("apm-as.example.com") OR file.path: ("/var/log/apm" OR "/var/log/audit"))Columns: @timestamp, host.name, source.ip, destination.ip, message, process.name, file.path. Replace examples with inventory. Run AS-profile inventory from CMDB separately.
Field mapping, false positives, and empty results
Field mapping: validate which field actually carries the APM error string before you trust a negative. Some connectors keep the full line only in raw text, so a parsed-field search comes back clean while the evidence is sitting right there. The tmctl counters may never leave the box at all unless someone exports them, and network logs to the VIP prove reachability rather than content, so they do not substitute for APM data.
False positives: legitimate OAuth clients fail UserInfo with invalid_token all the time, on token expiry, on misconfiguration, and from monitoring probes, while planned upgrades and F5 Support sessions generate their own audit noise. So require the full F5 pattern before escalating, meaning roughly ten or more failures from one IP in a short window, a total_failed rise, audit anomalies, and TMM SIGABRT or cores. A lone failed token is a Tuesday.
Empty results: no APM Authorization Server VIP is not clearance for the other F5 roles you do not operate. Missing APM syslog, no tmctl export, short retention, or an inventory that never records OAuth profile mode will all look clean while the risk sits untouched. Empty means not seen in the telemetry you collected, which is a different claim from proven absent.
Interpret the results before escalating
An APM Authorization Server VIP on an affected train: apply the F5 Support iRule for triage, schedule the hotfix, and expand the hunt window. Do not wait for an indicator before you inventory.
Clusters of UserInfo invalid_token failures from one source IP, roughly ten or more in a short window: preserve /var/log/apm, pull tmctl global_oauth_stat, and review /var/log/audit over the same window.
An unexplained rise in the total_failed counter: compare it against change tickets and known OAuth outages first, then correlate the client IPs with the APM failures.
Suspicious audit commands landing near the APM failures: preserve the audit logs, then go back and question session and policy trust on that broker.
A TMM loop, a SOD SIGABRT, or TMM cores arriving after all of the above: preserve the cores and logs before you remediate, and prioritize human review, as F5 instructs. A core file on its own is not an indicator.
Empty SIEM searches: validate forwarding, field mapping, retention, AS VIP inventory, and whether tmctl output was ever exported anywhere in the first place.
None of this justifies escalating on a single OAuth failure, a monitoring probe, or a planned upgrade. Require the correlated triad before anyone calls it an incident.
Sources
F5 K000162605: BIG-IP APM vulnerability CVE-2026-94127
CVE Record: CVE-2026-94127 https://www.cve.org/CVERecord?id=CVE-2026-94127
NVD: CVE-2026-94127 https://nvd.nist.gov/vuln/detail/CVE-2026-94127
CISA Known Exploited Vulnerabilities Catalog https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-94127 added 2026-09-22; federal due 2026-09-25; BOD 26-04 forensic triage)
CERT-EU Security Advisory 2026-013: Critical Vulnerability in F5 BIG-IP APM https://cert.europa.eu/publications/security-advisories/2026-013/ (2026-09-22)
BleepingComputer: F5 patches BIG-IP APM zero-day flaw exploited in RCE attacks https://www.bleepingcomputer.com/news/security/f5-warns-of-f5-big-ip-apm-remote-code-execution-zero-day-exploited-in-attacks/ (2026-09-23)
What This Means for Your Team
F5 BIG-IP APM CVE-2026-94127 will be old news inside a week. The durable detection opportunity will not, because it is authority mismatch on the edge identity broker. An Authorization Server profiled VIP accepted unauthenticated data-plane traffic where only trusted OAuth should ever have spoken, and then the box produced invalid_token clusters, total_failed spikes, audit anomalies, and TMM abort evidence that a patched build alone does not explain.
Installing the hotfix closes the path. It does not tell you whether anyone walked through it in the days before you got there, and CISA has now made that distinction explicit by attaching a forensic triage requirement to the deadline. Most teams cannot answer it either way, because BIG-IP syslog was never forwarded off the appliance, retention on what was forwarded is seven days, and nobody has ever exported tmctl output in their life. So the order of work stays the same every time: establish which VIPs still run APM as an OAuth Authorization Server, identify what the data plane accepted without a login, investigate the mismatch, then follow it into sessions, access policies, credentials, and every application that trusted that broker.
For teams using Microsoft Sentinel and Defender, Inception Security can help connect those questions to the telemetry already available. Inception Foresight can help identify visibility and detection gaps that affect that work.
Inception Protection
At Inception Security, Inception Protection is our MDR for Microsoft environments. We use the Defender, Sentinel, Conditional Access, and Azure licenses you already have. For this APM Authorization Server case we help connect BIG-IP syslog and APM exports to Sentinel hunts on invalid_token UserInfo failures, network telemetry to AS VIP addresses, host evidence around /var/log/apm and /var/log/audit, and correlation with TMM crash markers, while you apply F5's Support iRule for forensic triage and install the engineering hotfixes from K000162605.
Inception Foresight
Want a clearer view of visibility and detection gaps on the Microsoft stack that affect investigations like this APM OAuth broker hunt? Grab our free Inception Foresight at https://www.inceptionsecurity.com/m365assessment. No strings. Follow Inception Security on LinkedIn and @inceptionsec on X.
