F5 BIG-IP APM OAuth Servers Under Active Attack

Attackers are running code on F5 BIG-IP systems with no credentials at all. F5 disclosed CVE-2026-94127 on September 22, a heap-based buffer overflow in Access Policy Manager rated 9.8 out of 10 on CVSS v3.1 and 9.3 on CVSS v4.0. Exploitation was already happening when the advisory went out. CISA added the flaw to the Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies until September 25, three days, to apply mitigations.

The blast radius is the worst part. APM is the module that decides who reaches your applications and networks. On an affected system it is also issuing OAuth access tokens. Code execution on that device means code execution on the thing that terminates sessions, holds the certificates and mints the tokens for everything behind it.

The exact condition that makes you vulnerable

This is not every BIG-IP, and it is not every APM deployment. The vulnerable configuration is narrow and specific: an APM access policy and an OAuth authorization server profile on the same virtual server, with APM acting as the OAuth authorization server. In F5's configuration guide for APM 17.1, 17.5 and 21.0, that profile is built under Access, then Federation, then OAuth Authorization Server, then OAuth Profile, and selected in an access profile attached to the virtual server.

Systems where APM is only an OAuth client or a resource server, with no authorization server profiles configured, are not affected. That distinction is the difference between an emergency change window and a routine patch cycle, so confirm it on the box rather than from an inventory spreadsheet.

Affected versions and hotfixes

• Branch 21.1: version 21.1.0 before the hotfix. Fixed in Hotfix-BIGIP-21.1.0.2.0.30.22-ENG.
• Branch 17.5: versions 17.5.0 to 17.5.1 before the hotfix. Fixed in Hotfix-BIGIP-17.5.1.9.0.160.12-ENG.
• Branch 17.1: versions 17.1.0 to 17.1.3 before the hotfix. Fixed in Hotfix-BIGIP-17.1.3.5.0.41.14-ENG.
• End of Technical Support versions: F5 did not evaluate them. Treat unknown as vulnerable, not as safe.

There is a trap in that table for anyone who patched earlier this year. CVE-2025-53521, another APM flaw, landed in CISA's KEV catalog in March. Its fixes were 17.1.3 and 17.5.1.3. Both of those builds fall inside the affected ranges above. A system you already patched in March against the previous APM zero-day still needs this new hotfix if APM acts as an OAuth authorization server on it. Do not let the earlier remediation ticket close this one.

The advisory changed after publication

F5 updated its CVE record at 00:45 UTC on September 23 to narrow the condition to the authorization server role specifically. CISA's KEV entry and the CERT-EU advisory were both published before that change and describe the trigger more broadly, as an access policy plus an OAuth profile on a virtual server. If your team scoped the exposure from the KEV entry or from CERT-EU in the first hours, you may have pulled in client-only and resource-server deployments that are not actually affected. Rescope against the current F5 record before you burn a change window on systems that do not need it.

Hunting for compromise

F5 published indicators, relayed through CERT-EU. No single one of these is conclusive. The combination that should trigger a human looking at the system is repeated OAuth authentication failures, then suspicious commands, then a TMM abort shortly after.

• APM log: repeated failed UserInfo requests in /var/log/apm carrying the error description "The access token is invalid." Ten or more from a single source IP in a short window is the threshold F5 calls out.
• OAuth counters: an unexplained climb in total_failed relative to total_requests and total_userinfo_requests.
• Audit log: unexpected commands in /var/log/audit timestamped around those failures.
• TMM core files: F5 has observed TMM entering a loop, after which the SOD daemon sends a SIGABRT. Not proof on its own, worth investigating when it lines up with the above.

tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed
grep -c "The access token is invalid" /var/log/apm
ls -la /var/core/ 2>/dev/null | grep -i tmm

Order of operations matters

What the advisories do not tell you

Three gaps are worth stating plainly, because your incident response plan has to account for them. F5's CVE record and the CISA and CERT-EU advisories do not say how many systems were attacked, who the attackers are, or which organizations were targeted. They also do not say whether installing the hotfix removes access an attacker already established. Treat the hotfix as closing the door, not as evicting anyone already inside.

For a device this central, that means the patch is step one of three. Patch, hunt using the indicators above, and then rotate what the box holds: OAuth signing keys, client secrets, device certificates and any administrative credentials stored on or reachable from the BIG-IP. If you find indicators, assume the tokens that device issued during the exposure window are untrustworthy and invalidate sessions downstream.

Priority order for the next 24 hours

• Enumerate every BIG-IP running 21.1.0, 17.5.0 to 17.5.1, or 17.1.0 to 17.1.3, including the ones you patched in March for CVE-2025-53521.
• On each, confirm whether any virtual server carries both an access policy and an OAuth authorization server profile. That is your real target list.
• Open the F5 support ticket for the iRule mitigation for anything you cannot patch inside the change window.
• Pull /var/log/apm, /var/log/audit and the tmctl OAuth counters off the affected boxes before you change anything, so you keep the forensic record.
• Install the branch hotfix, then rotate keys and secrets on any system where the indicators line up.

tmsh show sys version

tmsh list apm oauth | grep -iE 'oauth|profile|authorization'

grep "The access token is invalid" /var/log/apm | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

tmsh save sys ucs /var/local/ucs/pre-hotfix-$(date +%Y%m%d).ucs

tmsh install sys software hotfix Hotfix-BIGIP-17.1.3.5.0.41.14-ENG volume HD1.2

tmsh modify ltm virtual /Common/vs_oauth_as disabled