F5 BIG-IP APM Zero-Day CVE-2026-94127 Under Active Attack: Unauthenticated RCE on OAuth Servers, CISA Gives Feds Three Days
F5 BIG-IP APM Zero-Day CVE-2026-94127 Under Active Attack: Unauthenticated RCE on OAuth Servers, CISA Gives Feds Three Days
F5 has released emergency engineering hotfixes for a critical flaw in BIG-IP Access Policy Manager (APM) that attackers are already exploiting to run code on BIG-IP systems without logging in. The flaw, tracked as CVE-2026-94127, was disclosed in an F5 advisory on September 22, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities (KEV) catalog the same day — giving federal civilian agencies until September 25 to apply F5's mitigations. It is the second APM flaw to reach the catalog this year — CVE-2025-53521 was added in March — and the latest in a summer of network-appliance zero-days that has run from Citrix NetScaler pre-auth RCE to Check Point management server flaws.
The vulnerability is a heap-based buffer overflow rated 9.8 out of 10 on CVSS v3.1 (9.3 on CVSS v4.0). It affects only systems where APM serves as an OAuth authorization server — issuing access tokens to applications. The vulnerable configuration places an APM access policy and an OAuth authorization server profile on the same virtual server, the BIG-IP address that receives the OAuth traffic. Specific malicious traffic sent to that virtual server leads to remote code execution, F5 said.
Two assumptions that normally reduce risk do not help here. Because the malicious traffic goes to the virtual server itself rather than the management plane, limiting access to the BIG-IP management interface provides no protection. BIG-IP systems running in Appliance mode are also vulnerable. Systems that use APM only as an OAuth client or resource server, with no OAuth authorization server profiles, are not affected — F5 updated its CVE record on September 23 to narrow the condition to the authorization server role.
Affected Versions and Fixes
For systems in the vulnerable configuration, the hotfixes cover the three supported branches: 21.1.0 and earlier on the 21.1 train, 17.5.0 through 17.5.1, and 17.1.0 through 17.1.3. F5 has not evaluated versions that have reached End of Technical Support, so their status is unknown rather than safe. A detail that matters for anyone who patched in the spring: the fixes for CVE-2025-53521, an APM flaw added to KEV in March, fall inside the affected ranges — a system updated to 17.1.3 or 17.5.1.3 still needs the new hotfix if APM runs as an OAuth authorization server on it.
Where the hotfix cannot be installed immediately, F5 offers an iRule mitigation for the affected virtual server, available by opening a support ticket. CISA told agencies to apply the iRule first "to allow for proactive forensic triage," then install the final patch as soon as possible, and CERT-EU recommends preserving forensic evidence before any remediation.
What Should You Do?
- Check your role first. The flaw exists only where an access policy and an OAuth authorization server profile share a virtual server (created under Access > Federation > OAuth Authorization Server). Client-only or resource-server deployments are not affected.
- Install the engineering hotfix for your branch — 21.1, 17.5, or 17.1 — without waiting for a maintenance release.
- If you cannot hotfix now, request the iRule mitigation through an F5 support ticket and apply it to the affected virtual server.
- Hunt for compromise before you patch. The signals F5 lists: repeated failed UserInfo requests in /var/log/apm ("The access token is invalid"), especially ten or more from a single IP; a rise in total_failed in tmctl OAuth counters; suspicious commands in /var/log/audit; and TMM core files or a TMM loop ending in a SIGABRT from the SOD daemon.
The WAF Angle
KEV entries like this one are arriving faster than patch windows, and CVE-2026-94127 has an uncomfortable property for defenders: the attack surface is a production-facing listener, not a management interface. The usual "restrict management access" playbook does not apply, and the token-issuing endpoint is doing its normal job while under attack. A WAF or traffic filter in front of the virtual server can catch the probe pattern — bursts of failed UserInfo requests from one source are high-signal, cheap to alert on, and visible before any code execution attempt. Bigger picture: treat your BIG-IP, WAF and load-balancer fleet as attack surface in its own right, with the same exposure reviews and rapid-patch discipline you apply to the applications behind it.
