CVE-2026-94127: Unauthenticated RCE in BIG-IP APM OAuth, exploited

What it is

BIG-IP APM has a heap-based buffer overflow (CWE-122) in its OAuth handling. An unauthenticated attacker on the network can trigger it with crafted OAuth traffic and get remote code execution. It works even when the device runs in Appliance mode.

F5 describes it as a data plane issue with no control plane exposure, so the vulnerable surface is the virtual server that serves OAuth, not the management interface. CISA’s assessment in the CVE record rates exploitation as active, the attack as automatable, and the technical impact as total. F5’s advisory says: “We have learned that this vulnerability has been exploited.” CISA added the CVE to KEV on the day F5 published and gave federal agencies three days. No ransomware use is recorded in KEV, and no attacker has been named. F5 found the bug internally. No public proof of concept has been confirmed.

F5 scores it 9.3 in CVSS 4.0; CERT-EU and other reports quote 9.8 (CVSS 3.1). BleepingComputer reports that Shadowserver sees more than 14,700 IP addresses with BIG-IP APM fingerprints, though that count includes APM systems without the vulnerable OAuth setup.

Am I affected?

You are exposed only if both are true:

1. You run BIG-IP in an affected version (see the table above).
2. A virtual server has an APM access policy and an OAuth profile, and APM acts as an OAuth Authorization Server.

Not affected: APM deployments that are only an OAuth Client or Resource Server, with no authorization server profiles. F5 did not evaluate versions that have reached End of Technical Support, so treat those as unsupported and at risk.

To check, look for OAuth Authorization Server profiles on virtual servers that also have an access policy. The OAuth statistics under Detection also show whether a system is answering OAuth requests at all. The F5 advisory (K000162605) has the exact steps for your version.

What to do

1. Save the evidence first. CERT-EU recommends preserving forensic evidence before patching: /var/log/apm, /var/log/audit and any TMM core files. Upgrades and log rotation can destroy what you need for step 5.
2. Install the fixed engineering hotfix for your branch: 21.1.0 needs Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, 17.5.x needs Hotfix-BIGIP-17.5.1.9.0.160.12-ENG, and 17.1.x needs Hotfix-BIGIP-17.1.3.5.0.41.14-ENG. Confirm the running build afterwards.
3. If you can’t patch tonight, apply F5’s iRule mitigation. It is available on request through an F5 support ticket. CISA says to use it as a temporary measure so you can do forensic triage, then install the patch as soon as possible.
4. Reduce exposure. If the OAuth virtual server doesn’t need to face the internet, restrict who can reach it.
5. Assume compromise if it was exposed while vulnerable. The exploitation is confirmed and began before the advisory. Check the indicators below, and review admin activity, configuration changes, local accounts, running processes, scheduled tasks and outbound connections (Field Effect’s guidance). If you find signs of compromise, start incident response and rotate the secrets the device held, including the OAuth Authorization Server’s signing keys: an attacker with them can mint tokens for your applications.

Detection

No indicators such as IP addresses, hashes or domains have been published. F5’s indicators, as relayed by CERT-EU, are behavioural. The key pattern is multiple OAuth authentication failures, then suspicious commands, shortly followed by a TMM SIGABRT. That combination should go to a human.

• OAuth failures in /var/log/apm. Look for repeated invalid_token errors in the UserInfo request log message. Ten or more from a single IP address in a short window is the anomaly F5 highlights.
• OAuth statistics. Check the total_requests, total_userinfo_requests and total_failed fields, and look for an unexplained rise in total_failed:

tmctl global_oauth_stat

• Audit log. If you see the OAuth failures, review /var/log/audit around the same times for commands nobody on your team ran.
• TMM crashes. F5 has seen TMM (Traffic Management Microkernel) go into a loop until the SOD daemon kills it with SIGABRT. A TMM core file alone doesn’t prove compromise, but investigate any that line up with the OAuth failures.

Do this on every device with an OAuth Authorization Server profile, and go back to before September 22, 2026, as far as your logs reach.