F5's BIG-IP Zero-Day Only Fires If You Flipped One OAuth Setting. CISA KEV'd It Alongside Three Other Edge Appliances the Same Day.

On September 22, 2026, F5 disclosed CVE-2026-94127 — a CVSS 9.8 heap-based buffer overflow in BIG-IP Access Policy Manager — and confirmed it was already being exploited before the patch existed. CISA added it to the Known Exploited Vulnerabilities catalog the same day, alongside two Check Point flaws and an Arista bug, under a new directive that gave federal agencies three days to react, not the usual two weeks. The vulnerability itself only exists in one specific, easy-to-miss configuration — which is exactly why it's worth understanding precisely, not just patching on faith.

The one setting that turns this into pre-auth RCE

F5's advisory is specific about scope: the bug only exists "when a BIG-IP APM access policy and an OAuth profile are configured on a virtual server," and only when APM itself is acting as the OAuth Authorization Server — not merely a client or resource server consuming someone else's tokens. It's a data-plane issue; there is no control-plane exposure. If your APM deployment never turned on the authorization-server role, this specific bug does not reach you — though F5 still shipped the hotfix to every affected branch regardless of configuration, since there's no way to verify the setting from outside.

How one oversized header becomes code execution

watchTowr Labs researcher Sina Kheirkhah published a full technical reconstruction on September 23, under the Labs' characteristically blunt title, "Is This A Joke? In The Auth Header?" The root cause is a textbook unchecked-length buffer copy: APM's OAuth /f5-oauth2/v1/userinfo endpoint allocates a fixed 0x4100-byte heap buffer for the incoming Authorization: Bearer value, then — before the patch — copies the attacker-supplied header into that buffer without first checking its length. Send a bearer token longer than 0x4100 bytes, and the write runs past the buffer into adjacent heap memory.

The straightforward path — overwrite the function pointer, redirect to a ret2plt chain that calls execvp("/bin/sh", ...) — got blocked twice: SELinux refused both the direct shell execution and a web-shell write to disk, returning the same denial both times. watchTowr's own writeup records the exact result: "-1, errno=13 (EACCES)." So they pivoted to something SELinux doesn't guard as tightly — a crash-recovery script. BIG-IP runs a hook, tmm.finish, automatically whenever the tmm process crashes. Using the same overflow primitive to open() and write() an appended command into that script turns every subsequent crash into an execution trigger. It's a reminder that "no PIE, but ASLR and NX are present" doesn't mean no path to RCE — it means the attacker has to find a path the platform's own hardening didn't anticipate, and in this case BIG-IP's own crash handling was it.

The second APM-specific RCE in eleven months

This is not APM's first config-specific RCE. CVE-2025-53521, disclosed October 15, 2025, is a separate bug (CWE-770, resource exhaustion rather than a heap overflow, CVSS 7.5) that also only triggers "when a BIG-IP APM access policy is configured on a virtual server." It was added to CISA's KEV catalog in March 2026. The two bugs are unrelated in root cause, but they share the same lesson: patching for one APM RCE does not patch the other. Admins who applied the October 2025 fix and assumed APM was handled still needed September 2026's hotfix if they also run an OAuth Authorization Server profile.

That's eight F5 CVEs in our own index that CISA has added to KEV since 2020 — spanning TMUI, iControl REST, and now APM twice. The constant isn't a single bad component; it's that BIG-IP's various management and access-control surfaces keep producing unauthenticated RCEs that get used in the wild.

Same KEV batch, three more unauthenticated RCEs

CVE-2026-94127 did not land in KEV alone. CISA's September 22 alert added four vulnerabilities together, all unauthenticated and all remotely reachable on internet-facing enterprise edge infrastructure:

What's confirmed, and what isn't

Being honest about the gaps matters here as much as the technical chain. Neither F5's advisory nor CISA's KEV entry discloses how many systems were attacked, who did it, or which organizations were targeted — "active exploitation observed" is as specific as the public record gets. watchTowr's writeup states plainly that "bad people on the Internet" were already exploiting it before disclosure, but offers no IOCs or sample payloads beyond their own reconstructed exploit chain, and they did not publish working exploit code. Our own database confirms there is still no public proof-of-concept and no Metasploit or Nuclei module for this CVE as of this writing — and, worth flagging honestly, our EPSS score for it sits at just 2.2% (82nd percentile), far below what you'd expect for a KEV-confirmed, actively-exploited critical. EPSS models the next 30 days from historical exploitation patterns and visibly lags a fresh KEV addition; treat the KEV listing, not the EPSS percentage, as the operative signal here.

# Check OAuth userinfo request/failure counters:
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed

# Then review for the trigger pattern:
# >10 OAuth auth failures from the same IP, followed by
# suspicious commands, followed by a TMM SIGABRT
# → escalate for human review.

# Also check:
#   /var/log/audit
#   TMM core files (indicates a crash occurred)

1. Identify every virtual server with both an APM access policy AND an OAuth profile configured, and confirm which ones have APM set as the OAuth Authorization Server (not client/resource server).
2. Apply the branch-specific engineering hotfix: Hotfix-BIGIP-21.1.0.2.0.30.22-ENG for 21.1.0; Hotfix-BIGIP-17.5.1.9.0.160.12-ENG for 17.5.0–17.5.1; Hotfix-BIGIP-17.1.3.5.0.41.14-ENG for 17.1.0–17.1.3.
3. If you can't patch immediately, open an F5 support ticket for the interim iRule mitigation — and apply it before the final patch, per CISA's forensic-triage guidance, not instead of it.
4. Run the tmctl OAuth-failure check and review /var/log/audit and any TMM core files for the failure-then-crash pattern before you conclude you weren't hit.
5. If you also run the October 2025 APM fix for CVE-2025-53521, treat it as unrelated coverage — it does not address this bug.

Data as of 2026-09-23live record →