F5 BIG-IP Zero-Day CVE-2026-94127: The OAuth Config That Lets Attackers Root Your Edge Appliance

An unauthenticated remote-code-execution bug in F5’s BIG-IP Access Policy Manager is being exploited in the wild right now, and the trigger is a configuration most security teams never treated as an attack surface: OAuth.

F5 published an advisory this week for CVE-2026-94127, a critical flaw scoring 9.8 on the CVSS scale. The company confirmed that attackers had already been exploiting it as a zero-day, well before any patch existed. CISA added the CVE to its Known Exploited Vulnerabilities catalog and gave federal agencies three days to patch.

If your bank, telco or fintech runs a BIG-IP box at the edge, this is your story this week. The same class of device that carried the Check Point VPN mess earlier in September is on the board again, and this time the vulnerable feature is the one standing between your staff logins and the open internet.

What the flaw actually does

Unauthenticated attackers send malicious traffic to a vulnerable BIG-IP appliance and get remote code execution. No credentials, no phishing, no user sitting at a keyboard approving something. The attacker lands on the appliance as whatever the service runs as, and from there the appliance is a proxy for everything behind it.

F5 narrowed the exposure to a specific setup: the bug is reachable only when a BIG-IP APM access policy and an OAuth profile are configured on a virtual server, and only when APM is operating as an OAuth Authorization Server. Deployments using APM as an OAuth Client or Resource Server are not affected. F5 also confirmed that Appliance mode does not save you, because this is a data plane issue rather than a control plane one. Locking down or hiding the management interface is irrelevant here. The traffic doing the exploit is ordinary-looking client traffic on the virtual server’s public listener.

Why this configuration is common in African enterprise

Here is the part that makes this more than a routine patch Tuesday story. Organizations across the continent consolidated single sign-on onto edge appliances over the past decade. A BIG-IP APM virtual server acting as an OAuth Authorization Server is a very normal pattern for banks and payment processors that wanted one front door for web portals, mobile app backends and partner APIs.

That pattern puts an identity issuer on the same hardware that terminates traffic from the entire internet. If the issuer is compromised, the attacker does not need to steal anything. They mint tokens. Tokens for the internal HR system, the core banking console, whatever the APM policy protected. I keep coming back to how weak the detection story is here: the malicious traffic looks like a very confident employee.

What F5 disclosed

• Affected versions: BIG-IP APM 21.1.0, 17.5.0 through 17.5.1, and 17.1.0 through 17.1.3. No other F5 products are affected.
• Fix: F5 has released hotfixes for the affected branches. With active exploitation confirmed, this is not a wait-for-the-next-release situation.
• Discovery: F5 found the defect internally and learned of active exploitation while preparing the advisory.
• IoCs: F5 published three indicators of compromise and says their combined, frequent appearance should be correlated to an attack.

That last bullet deserves a second read. F5 is signaling that any single indicator has a plausible benign explanation, and it is the combination showing up repeatedly that means you are hit. If you run BIG-IP APM, pull your access logs for the past several weeks now, while the hotfix queue for your change board is still forming.

What to do this week

1. Check the configuration before the version. A BIG-IP on a vulnerable branch is only exposed if APM is configured as an OAuth Authorization Server with a profile bound to a virtual server. Inventory that first. You may be affected and not know it, or you may be running the same version with the risky feature switched off.
2. Apply the hotfix. If you are exposed, this goes to the front of the change queue. A CVSS 9.8 zero-day with published IoCs means knowledge of the exploit has spread beyond whoever found it first.
3. Hunt for the IoC combination. Look at traffic patterns against the OAuth endpoints on your virtual servers rather than waiting for signature matches.
4. Assume the edge until proven otherwise. Revoke and reissue OAuth signing material after patching if anything looked odd during the exposure window. A patched box with attacker-minted tokens still in circulation is a half fix.

The pattern behind the product

Edge appliances keep failing in the same direction. They sit at the boundary, they accumulate trust, and the features that earn that trust become the softest spot on the network. Check Point in early September, now F5. Each vendor patched, each time the market moved on. The uncomfortable lesson for anyone running African fintech infrastructure is that your front door is a third party’s software, and its worst day becomes your incident.

eHawu was built around exactly this problem. Packet-level visibility at the network layer means you see what actually crosses the wire to and from your edge appliances, instead of relying on what the appliance itself is willing to log. When a vendor ships three IoCs and tells you to correlate them, correlation only works if you keep independent traffic records of your own. eHawu keeps those. When the next 9.8 lands, you spend your morning verifying your edge is clean instead of wondering what your appliance didn’t tell you.