blogwatchTowr Labs·24 Sept 2026·@SinSinology

Is This A Joke? In The Auth Header? (F5 BIG-IP UnAuth Heap-Overflow to RCE CVE-2026-94127)

watchTowr turns an unauthenticated heap overflow in the F5 BIG-IP auth header into RCE, CVE-2026-94127.

Depth 5/5Score 5.20

Extract

Well, well, well, well, well, well, well, well, well, well, well, well, well, well, well. We're back. Sorry. We've been watching the onslaught of vulnerabilities flood the internet. Every man, dog, and their grandmas (apparently?) are now using LLMs to find and reproduce vulnerabilities - it’s a free-for-all (unless you’re trying to buy RAM). Unfortunately, while we're all finding more vulnerabilities and flexing obfuscated stack traces… (or emoji-ridden HTTP requests that are actually complete slop and not real, and please, for the love of god, no, those slop-ridden payloads appearing in your access_log are not proof of exploitation jesus wept, it’s becoming traumatic) …on many social media networks, some things have remained reassuringly steadfast: the vendors and their struggle to seemingly care about the security of your network. Yes, that’s right - it’s time for more Secure by Design jokes. Welcome back to another watchTowr Labs blog post. We’ve missed you (admit you’ve missed us, please). You’ve guessed it - we’re looking at F5’s BIG-IP solution today. What Is CVE-2026-94127, and How Does Refresh Have A CVE? Hah. F5, the Seattle-based vendor quietly responsible for a worrying amount of the internet's plumbing, makes BIG-IP: an application delivery controller (ADC) that sits in front of your applications and decides where every request goes. Beyond basic load balancing, a typical BIG-IP deployment handles Layer 4 and Layer 7 traffic management, SSL/TLS offloading, DNS and global server load balancing, and, depending on how many licenses procurement signed off on, a web application firewall (Advanced WAF) and a remote access and SSO gateway (APM). All of this runs on F5's own TMOS operating system and is administered through a web-based Configuration Utility (TMUI) and the iControl REST API. In other words, it lives at the very edge of your network, terminates your TLS, sees all of your traffic in plaintext, and holds the keys to your authentication. But what is CVE-2026-94127? As with all good stories, it began with a new KB ID. On Sept 22nd (yesterday), F5 published the following advisory: Despite the talk about planes, there was no flying (see! you’ve missed this humor!). The F5 official advisory (K000162605) lists the following versions as affected: Product Branch Versions known to be vulnerable Fixes introduced in BIG-IP APM 21.x …

Explained

What happened

CVE-2026-94127 is an unauthenticated heap buffer overflow in F5 BIG-IP APM, the remote-access and SSO module, reachable through its OAuth flow and exploited in the wild. The flow is short:

On a virtual server with an OAuth profile, BIG-IP exposes endpoints such as /f5-oauth2/v1/userinfo.
Handling a request, the code allocates a fixed heap buffer of 0x4100 bytes (16,640) for the Authorization header.
It then copies the header value into that buffer without checking the length first. The patch adds exactly one guard: if the size exceeds 0x4100, return "Authorization header too big" instead of copying.
Sending a Bearer token longer than 0x4100 bytes overflows the heap. The researchers got an immediate crash in the allocator (ufree asserting on corrupted heap metadata, with 0x41414141 in a register from the A padding), a denial of service and a path toward remote code execution.

No login is required. The overflow happens before the token is even validated.

Why it works

A fixed-size destination buffer received variable-size, attacker-controlled input with no bound at the copy. This is the plainest form of the bug: memcpy of n bytes into a 0x4100 buffer where n comes from the request. The length was available the whole time; the code just never compared it to the capacity before copying. Because the vulnerable path is the OAuth userinfo handler, it runs for unauthenticated callers, so the appliance that terminates your TLS and guards your SSO can be crashed by one request.

The bigger pattern

This is a classic heap buffer overflow (CWE-787, out-of-bounds write), a primitive that is decades old, appearing in modern credential-handling code on a security appliance. Two recurring lessons: edge devices that terminate TLS and hold authentication are the highest-value targets, and the hardest bugs to accept are the simplest ones in the most sensitive code. Mitigations like ASLR, stack canaries and non-executable heap raise the cost of turning the overflow into code execution, but they do not prevent the crash, so DoS is immediate regardless.

What it means in practice

Bound every copy of external input against the destination size at the copy site. For headers and tokens, enforce a maximum length before allocating or copying, and reject early.
Validate size before you validate content. Here the overflow beat the Bearer type check, so auth logic never got a chance to help.
Prefer memory-safe handling for parsing untrusted input: length-checked buffer APIs, or languages that bounds-check. Where C is unavoidable, treat every memcpy from the network as a review checkpoint.
Do not lean on ASLR, canaries or NX as your only defense. They complicate exploitation but leave a reliable crash and DoS.
Operationally: inventory internet-facing APM or OAuth endpoints, patch to the fixed hotfix builds immediately, and watch for abnormally large Authorization headers at the perimeter. An unauthenticated edge RCE warrants assume-breach handling.