The short answer
CVE-2026-94127 is a critical, already-exploited flaw in F5 BIG-IP Access Policy Manager, but only one configuration is exposed: APM running as an OAuth Authorization Server, with an access policy and an OAuth profile on the same virtual server. If that describes any of your virtual servers, install F5’s hotfix or apply the iRule mitigation now, then check logs for signs of compromise from before the patch. Our security audit team sees the same gap often: companies know they run BIG-IP, but nobody can say which OAuth roles it plays.
The broader lesson is familiar. The appliances that sit in front of your applications, such as load balancers, VPN gateways, and identity proxies, are now a favorite first target. They face the internet, handle credentials, and are patched on a slower cycle than the code behind them.
What did F5 disclose?
F5 published advisory K000162605 on September 22, 2026, describing a heap-based buffer overflow in BIG-IP APM. An attacker with no credentials can send specially crafted traffic to an affected OAuth configuration and execute arbitrary code on the BIG-IP system. The company said plainly that the vulnerability “has been exploited,” which is why it went out as a zero-day disclosure with hotfixes rather than in a scheduled quarterly patch.
CISA added the flaw to its Known Exploited Vulnerabilities catalog the same day, alongside two Check Point bugs and one in Arista VeloCloud Orchestrator. U.S. federal civilian agencies had until September 25 to remediate, a three-day window that CISA reserves for the most urgent cases. Neither F5 nor CISA has said how many systems were compromised or who is behind the attacks, and Rapid7 reported no public proof-of-concept as of disclosure.
F5 serves more than 23,000 customers, including 48 of the Fortune 50, according to BleepingComputer. That reach, plus the fact that attackers stole BIG-IP source code and vulnerability details from F5 in a nation-state intrusion disclosed in October 2025, is why security teams treat any new BIG-IP zero-day as a priority.
Who is actually exposed?
This is the part that separates a calm patch window from an incident. Having BIG-IP APM licensed is not enough to be vulnerable. F5 says a virtual server must have both an APM access policy and an OAuth profile, and the bug triggers only when APM acts as the OAuth Authorization Server, meaning it issues tokens to clients. If you use APM only as an OAuth Client or Resource Server, validating tokens issued by Entra ID, Okta, or another identity provider, F5 says you are not affected.
The catch is that many companies cannot answer this quickly. BIG-IP configs grow over years, often built by a network team that has since changed, and OAuth roles are set per profile, not per box. A single forgotten virtual server that federates a partner portal or a legacy mobile API can be the exposed one. The attack also targets the data plane, meaning the traffic path your users hit, so restricting the management interface does not help here.
F5’s guidance for spotting exploitation is specific: multiple OAuth authentication failures and suspicious commands, shortly followed by a TMM SIGABRT (a crash of the Traffic Management Microkernel). An unexplained TMM restart on an APM box in recent weeks deserves a closer look.
What it means for US & EU software teams
First, edge appliances are part of your application’s attack surface, not a network-team side issue. When BIG-IP issues OAuth tokens for your SaaS product or mobile API, a code-execution bug in it can mean stolen signing material, forged sessions, or a pivot into the internal network. Threat models and architecture reviews should list the proxy and its OAuth role just as they list the API gateway and the database.
Second, compliance clocks start at detection. For EU companies in scope of NIS2, a significant incident needs an early warning within 24 hours. Under GDPR, a personal-data breach must be reported to the regulator within 72 hours. For US public companies, material incidents trigger SEC disclosure within four business days. A compromised identity proxy in front of customer data can hit all three, so “we patched on day two” is only half the answer. You also need logs that show whether anyone got in before then.
Third, inventory beats heroics. Teams that already keep their edge configuration in version control, with automated checks for risky settings, answered “are we exposed?” within minutes this week. Teams without that were reading configs by hand. Building that inventory and patch automation into your cloud and DevOps practice is the fix that holds up for the next appliance zero-day, not just this one.
What should you do now?
- Find the exposed configuration. List every virtual server that has both an APM access policy and an OAuth profile, and check whether APM acts as the Authorization Server. Include staging and partner-facing environments.
- Patch or mitigate. Install the F5 engineering hotfix for your branch (21.1.0, 17.5.x or 17.1.x, per K000162605). If you cannot patch today, get the iRule mitigation from F5 Support and apply it.
- Hunt before you relax. Review logs for bursts of OAuth authentication failures followed by suspicious commands and a TMM SIGABRT. Look back before September 22; the flaw was a zero-day.
- Assume token material may be exposed. If you find signs of compromise, rotate the OAuth signing keys and client secrets held on the device, revoke active tokens, and check for new admin accounts or config changes.
- Close the inventory gap. Put edge configs under version control and add them to your threat model and vulnerability scanning, so the next “are we affected?” takes minutes.
Frequently asked questions
What is CVE-2026-94127?
CVE-2026-94127 is a heap-based buffer overflow (CWE-122) in F5 BIG-IP Access Policy Manager (APM). An unauthenticated remote attacker can send specially crafted traffic to an affected OAuth configuration and execute arbitrary code on the BIG-IP system. F5 rates it CVSS v3.1 9.8 and CVSS v4.0 9.3, and disclosed it on September 22, 2026 after learning it had already been exploited.
Is every BIG-IP APM deployment vulnerable?
No. Exposure depends on configuration. A virtual server must have both an APM access policy and an OAuth profile, with BIG-IP APM acting as an OAuth Authorization Server. Deployments that use APM only as an OAuth Client or Resource Server, without an authorization server profile, are not affected according to F5.
Which versions are fixed?
F5 has released engineering hotfixes for the supported branches: 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.x, and Hotfix-BIGIP-17.1.3.5.0.41.14-ENG for 17.1.x, or later. Teams that cannot patch immediately can request an iRule mitigation from F5 Support. Always confirm against F5 advisory K000162605.
How do I know if my BIG-IP was already compromised?
F5 advises looking for multiple OAuth authentication failures and suspicious commands, shortly followed by a TMM SIGABRT, in BIG-IP logs. Because exploitation started before the patch, teams with an exposed OAuth Authorization Server configuration should review logs from before September 22, 2026, not just from the day they patched.
What is the CISA deadline?
CISA added CVE-2026-94127 to its Known Exploited Vulnerabilities catalog on September 22, 2026 and required U.S. federal civilian agencies to remediate by September 25, 2026. The deadline binds federal agencies, but CISA urges every organization to prioritize KEV-listed flaws.
Sources
F5 — K000162605: BIG-IP APM vulnerability CVE-2026-94127 (vendor advisory)
CISA — CISA Adds Four Known Exploited Vulnerabilities to Catalog (September 22, 2026)
BleepingComputer — F5 patches BIG-IP APM zero-day flaw exploited in RCE attacks
The Register — Someone’s attacking a critical 0-day RCE in F5 BIG-IP APM
Rapid7 — CVE-2026-94127: Critical Unauthenticated RCE in F5 BIG-IP APM