- watchTowr Labs reported on September 23, 2026 that F5 BIG-IP has a flaw, disclosed a day earlier, where an oversized Authorization header overflows a fixed 16,640-byte memory buffer in its OAuth handler.
- No login is needed to trigger it. In watchTowr's tests, the overflow gave them control of execution about 90% of the time, and they turned it into lasting code execution.
- Organizations running BIG-IP with the APM module and OAuth profiles are directly exposed. Check which units have them, confirm they run the patch level in F5 advisory K000162605, and review crash-handler scripts.
A Missing Bounds Check at the Network Edge
F5's BIG-IP sits at the edge of enterprise networks, terminating TLS, routing Layer 4 and Layer 7 traffic, and in many deployments running the Access Policy Manager module that handles single sign-on and OAuth authentication. Because it decrypts and inspects traffic before anything reaches an application, a flaw in BIG-IP itself carries wider consequences than a bug in one of the applications behind it.
Researchers at watchTowr Labs published an analysis on September 23, 2026 of a vulnerability F5 disclosed a day earlier in advisory K000162605. The root cause, found by diffing a patched BIG-IP build against its predecessor, was a missing bounds check in the code path that handles OAuth authentication requests: a value taken from an incoming Authorization header was copied into a fixed-size heap buffer with no check that it would fit.
How the Overflow Works
To find it, watchTowr compared hotfix build 0.30.22 against BIG-IP 21.1.0.2 using the binary-diffing tool Diaphora, exporting and comparing every function in each build's ELF binary before isolating the single changed routine.
The vulnerable code allocates a 16,640-byte heap buffer, reads a length value associated with the Authorization header, and previously copied the header's contents into that buffer regardless of size. The patch adds the missing comparison: if the header exceeds 16,640 bytes, the request is now rejected instead of processed.
From Crash to Persistent Code Execution
Triggering the bug required no authentication. After enabling BIG-IP's APM OAuth profile and sending an oversized Authorization header to an OAuth endpoint, watchTowr corrupted heap metadata and crashed the process. In roughly 90% of their test runs, the overflow landed near an object containing a function pointer, which the process later called, giving the researchers control of execution.
Turning that crash into remote code execution took extra work because BIG-IP runs under SELinux, which blocked a direct attempt to execute a command and blocked writing a web shell to the file server. watchTowr instead located a bash script that BIG-IP invokes automatically whenever the monitored process crashes, and used their heap primitive to append an attacker-controlled command to that script, a persistence path that survived the SELinux restrictions placed on the exec and web-server processes directly.
F5 has since patched the flaw in the BIG-IP versions listed in advisory K000162605. Because the vulnerable code sits in an authentication-handling module reachable without credentials, organizations running APM with OAuth profiles enabled are the ones directly exposed to this exploitation path.
What to Ask Your Team
A budget-holder should ask: which BIG-IP appliances in the environment have the APM module active with OAuth profiles configured, whether those units are running a version at or above the patch level in K000162605, and whether crash-handler or hook scripts on network-edge appliances are writable by the same process they are meant to monitor, the exact gap watchTowr used to turn a crash into persistent code execution.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: watchTowr.
