On 22 September 2026, F5 published an advisory for CVE-2026-94127, a heap-based buffer overflow in BIG-IP Access Policy Manager that allows remote code execution with no credential, and stated that the vulnerability had already been exploited. CISA added it to the Known Exploited Vulnerabilities catalog the same day.
The detail worth stopping on is which configuration is affected. Not every BIG-IP, and not every APM deployment: the condition is a virtual server carrying both an APM access policy and an OAuth profile, which is the one acting as an OAuth authorization server. The component whose entire purpose is to establish who somebody is was reachable, and exploitable, before it had established anything about anyone.
What actually happened
Crafted OAuth traffic reaching an affected virtual server overflows a heap buffer during parsing. Nothing authenticates in front of it, because that traffic is what a caller sends in order to begin authenticating.
| Element | Detail |
|---|---|
| Vulnerability | Heap-based buffer overflow, unauthenticated remote code execution |
| Rating | CVSS 9.8 under v3.1, and 9.3 under v4.0 as reported by The Hacker News |
| Affected | BIG-IP APM 17.1.0 to 17.1.3, 17.5.0 to 17.5.1, and 21.1.0, per CERT-EU's advisory |
| Precondition | A virtual server with both an APM access policy and an OAuth profile |
| Disclosure and fix | Advisory and engineering hotfixes, 22 September 2026 |
| Interim measure | An iRule available through F5 Support for anyone who cannot patch at once |
| Federal deadline | 26 September 2026, as reported by BleepingComputer |
What is not known matters as much as what is. BleepingComputer quotes F5 as saying only that "we have learned that this vulnerability has been exploited", and The Hacker News notes that neither F5's record nor CISA's entry says how many systems were attacked, who attacked them, or which organizations were hit. First exploitation, discovery, disclosure and patch are four separate dates, and two of them are public. BleepingComputer reports the Shadowserver Foundation counting more than 14,700 addresses showing BIG-IP APM fingerprints online, which is a measure of exposure rather than of vulnerability, since patch status is not visible from outside.
The gap: the access policy runs second
It is easy to read this as a failure of the access controls on those devices. It is not. An APM access policy is a capable control, and the organizations running one are doing more than most.
- The access policy evaluates a session. It runs once a request has been parsed well enough to belong to one. The overflow happens during that parsing.
- Multi-factor authentication, single sign-on and posture checks are steps inside that policy, so all of them sit downstream of the code that failed.
- Monitoring behaved normally. F5's own indicators are repeated OAuth failures from an address and suspicious audit log commands before a traffic management process crashes, all of which describe an intrusion that has already happened.
An authorization server cannot check a credential it has not been given yet. Everything an organization had positioned behind the login was positioned behind an event that never happened.
Patching is the correct answer and F5 shipped it with the advisory. It lands on the appliance that publishes the organization's applications, which means a maintenance window on the busiest surface in the estate. The iRule offered for the gap is a reasonable thing for a vendor to provide, and it is still a change to how the device parses requests rather than to who reaches it.
What would have had to be true
Ask the narrow question. On 22 September, before a hotfix could be scheduled, what property of an affected virtual server could have changed that day?
Only one: which networks it answers. That is a decision the equipment in front of it was already able to make, and source-based rules on a firewall or a cloud security group are not an advanced feature.
So why does almost nobody run that way? Because an authorization server for staff applications has to answer staff, and staff move. They sign in from home, from a customer site, from a hotel, from a broadband connection reassigned overnight. A hand-kept list decays from the day it is written, and it decays asymmetrically: an address left in too long is invisible, while a missing one locks somebody out of every application at once. So the ranges widen until they are no longer a control.
Where Veribound would have fitted
Veribound is a Pre-session Edge Access Control platform and an intelligence layer. It is additive. The BIG-IP stays, the access policy stays, the OAuth profile stays, the hotfix is still required, and the organization's own equipment keeps enforcing its own rules, unchanged.
Agents on staff devices continuously attest that each device is still the one the organization trusted, and a trust-scoring engine turns those attestations into a per-device decision. What reaches the customer's existing controls is a trusted origin: the network that device is connecting from, in practice its public address, while the device behind it is still trusted. Those origins stay current in the address groups and security groups the organization's own policy already references.
Applied here:
- A sweep for the fingerprint returns nothing, so the virtual server does not enter a list assembled from whatever answered.
- The crafted OAuth request is never parsed, because it arrives from a network the organization's policy does not recognize.
- The overflow is still there until the hotfix is applied, and reachable only by people already trusted while it waits.
- The list maintains itself, changing when somebody changes network, which is the part that fails when it is kept by hand.
The limits need stating plainly. This does not patch CVE-2026-94127 or alter it. It does nothing where the authorization server publishes applications to the general public or to a partner population nobody can enumerate, because there is no set of trusted origins that leaves those services working. It would not have distinguished an attacker operating from a device and network the organization already trusts, and it has no bearing on persistence or outbound channels established after code execution. The claim also rests on a customer-operated control sitting in front of that virtual server, a perimeter firewall or a cloud security group. A deployment where the appliance is itself the outermost device, with nothing ahead of it, is a different conversation and is not what this post analyzes.
Veribound does not enforce anything. It gives equipment a company already owns a current answer to a question that equipment cannot work out for itself. When the flaw is in the part of the stack that decides who you are, there is nothing behind it left to catch the request.
Source: F5 patches BIG-IP APM zero-day flaw exploited in RCE attacks, BleepingComputer, 23 September 2026.