Attackers are exploiting a critical zero-day in F5 BIG-IP Access Policy Manager (APM) that lets an unauthenticated attacker run code on systems acting as OAuth authorization servers. F5 disclosed the flaw on September 22 and has shipped engineering hotfixes for all three affected release branches.
Tracked as CVE-2026-94127, the bug is a heap-based buffer overflow rated 9.8 on CVSS v3.1 and 9.3 on CVSS v4.0. F5’s advisory confirms that “this vulnerability has been exploited,” and CISA has added it to its Known Exploited Vulnerabilities catalog, giving federal agencies until September 25 to mitigate.
How the BIG-IP APM Zero-Day Works
Exposure requires an APM access policy and an OAuth authorization server profile on the same virtual server. An attacker sends crafted traffic to that virtual server, overflows a heap buffer in the data plane, and gains code execution without credentials. The attack never touches the management interface, so restricting control-plane access offers no protection, and systems in Appliance mode are also vulnerable. Deployments that use APM only as an OAuth client or resource server are not affected.
F5 narrowed that condition on September 23. Rapid7’s earlier analysis describes it more broadly as any APM access policy paired with an OAuth profile.
Which Versions Are Affected and Patched?
BIG-IP APM 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. Running the latest 17.x point release is not enough; only the engineering hotfix closes the flaw. Other BIG-IP modules, BIG-IQ, BIG-IP Next, F5OS, and NGINX are not vulnerable, while end-of-support versions were not evaluated.
Also Read
Admins who cannot patch immediately can request an iRule mitigation from F5 Support.
How to Detect Exploitation
F5 flags a specific sequence: repeated OAuth failures, then suspicious commands, then a TMM crash. In practice, that means ten or more failed UserInfo requests with an invalid_token error in /var/log/apm, particularly from one IP, and an unexplained rise in total_failed from tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed. Admins should then check /var/log/audit around those timestamps and investigate any TMM core files, since F5 has seen TMM enter a loop that makes the SOD daemon send a SIGABRT.
F5 has not named the attackers or said how many systems were hit, and Rapid7 has not confirmed a public proof of concept.
Community Discussion
Join the conversation. Ask questions, share solutions, and help others.
Be the first to start the discussion!
