Read as article
F5 Patches Exploited BIG-IP APM Zero-Day With 9.8 RCE
By @sharedot · · 8 pages
F5 shipped emergency hotfixes for CVE-2026-94127, a 9.8-rated BIG-IP APM zero-day letting unauthenticated attackers run code on OAuth authorization servers.
What Happened
F5 disclosed on September 22 that attackers are exploiting a critical flaw in BIG-IP Access Policy Manager (APM), tracked as CVE-2026-94127, that lets an unauthenticated attacker run arbitrary code on a vulnerable system. The bug is a heap-based buffer overflow rated 9.8 on CVSS v3.1 and 9.3 on CVSS v4.0, and F5 has released engineering hotfixes for all three affected branches. CISA added the flaw to its Known Exploited Vulnerabilities catalog the same day, giving federal civilian agencies until September 25 to apply mitigations.
Why It's Surprising
The exploitable condition is narrower and stranger than most edge-device bugs: exposure exists only when APM acts as an OAuth authorization server — an access policy plus an OAuth authorization server profile on the same virtual server — meaning the token-issuing component of an identity stack is the entry point. Crafted traffic to that virtual server triggers code execution with no credentials at all. F5 updated its CVE record at 00:45 UTC on September 23 to confirm the flaw is present only in the authorization server role; earlier CISA and CERT-EU advisories described the condition more broadly as an access policy paired with any OAuth profile.
Management-Plane Defenses Don't Help
Because the malicious traffic is sent to the data-plane virtual server itself, restricting access to the BIG-IP management interface provides no protection against this flaw, and F5 confirms systems in Appliance mode are also vulnerable. Deployments using APM only as an OAuth client or resource server, with no OAuth authorization server profiles, are not affected. F5 also notes that end-of-technical-support versions were not evaluated, so their status is unknown rather than safe. Only the engineering hotfixes close the flaw — running the latest 17.x point release is not enough, per Cyber Kendra.
Who Is Affected
Per F5's advisory, BIG-IP 21.1.0 needs Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, versions 17.5.0 through 17.5.1 need Hotfix-BIGIP-17.5.1.9.0.160.12-ENG, and 17.1.0 through 17.1.3 need Hotfix-BIGIP-17.1.3.5.0.41.14-ENG. Other BIG-IP modules, BIG-IQ, BIG-IP Next, F5OS and NGINX are not vulnerable. Security Affairs reports that Shadowserver is currently tracking more than 14,700 IP addresses showing BIG-IP APM fingerprints, though that figure does not indicate how many systems are actually vulnerable. A system updated to 17.1.3 or 17.5.1.3 for an earlier APM flaw (CVE-2025-53521) still needs the new hotfix if it serves as an OAuth authorization server.
How to Check for Compromise
F5's indicators, relayed by CERT-EU, flag a specific sequence warranting human review: repeated failed UserInfo requests in /var/log/apm with the error "The access token is invalid" — especially 10 or more from a single IP — then suspicious commands in /var/log/audit, then a TMM SIGABRT shortly after. Admins can also run tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed and look for an unexplained rise in total_failed. TMM core files alone are not a sign of compromise but are worth investigating. Neither F5's record nor CISA's entry says how many systems were attacked, who the attackers are, or whether the hotfix removes access an attacker already has.
What Comes Next
When the hotfix cannot be installed immediately, F5 offers an iRule mitigation for the affected virtual server, obtained by opening a support ticket. CISA told agencies to apply the iRule first "to allow for proactive forensic triage," then install the final vendor patch as soon as possible. CERT-EU advises preserving forensic evidence first, applying the hotfix, checking for indicators of compromise, and starting incident response if any are found. Given that BIG-IP appliances commonly sit at the network edge handling authentication to internal applications, Security Affairs recommends treating patching as an incident-response priority rather than routine vulnerability management.