F5 BIG-IP APM OAuth Authorization Server heap overflow: remote code execution without logging in, exploited as a zero-day

Who is affected

BIG-IP is F5’s network appliance, often placed at the edge of an organization’s network to route traffic and control logins. APM (Access Policy Manager) is the module that handles access control and sign-in. You are affected only if all of these are true:

Affected versions and fixes (from the CVE record written by F5):

Notes:

• The version ranges disagree. NVD’s CPE data starts the 17.x range at 17.0.0, but F5’s CVE record, CERT-EU and news reports all start at 17.1.0. This page follows F5. Whether 17.0.x is affected is unconfirmed; it may just be broad CPE matching.
• Versions past End of Technical Support were not evaluated (Rapid7).
• The CISA KEV short description only says “access policy and an OAuth profile”. It does not mention the Authorization Server limit that F5 states in the CVE record.
• Exposure: BleepingComputer reports that Shadowserver tracks more than 14,700 IP addresses with BIG-IP APM fingerprints, but that number doesn’t show which have an OAuth Authorization Server configured or which are patched. We did not check Shadowserver’s data directly.

How it works

OAuth is a standard that lets one service issue “access tokens” that other applications accept. BIG-IP APM can act as the “Authorization Server” that issues those tokens.

According to F5, APM has a heap-based buffer overflow (CWE-122) in how it handles OAuth Authorization Server traffic. The program sets aside a fixed-size block of memory (on the “heap”), but specially crafted traffic causes data to be written past the end of that block, overwriting neighbouring data. That can end with the attacker running their own code on the device. The CVE record also lists CAPEC-100 (Overflow Buffers).

F5 describes this as a data plane issue (the part that handles user traffic), with no control plane exposure. In practice, hiding the management interface does not stop the attack, because it targets the public-facing virtual server.

F5 has not published which code is at fault, and BIG-IP is closed source, so there is no public fix commit. The code below only shows the general shape of this kind of bug. It is not F5’s actual code.

The flawed approach (conceptual illustration, not F5 source code):

char *buf = malloc(FIXED_SIZE);
// Copies outside input straight in, without checking its length first
memcpy(buf, input, input_len);

The fixed approach:

char *buf = malloc(FIXED_SIZE);
if (input_len > FIXED_SIZE) {
    reject_request();   // Too long: refuse, don't write
    return;
}
memcpy(buf, input, input_len);

Timeline

When F5 first found the flaw or first saw it exploited is unconfirmed. The CVE record credits F5 itself as the finder (internal discovery).

Further reading

• Scoring: F5 (the CNA) scores it 9.8 under CVSS 3.1 and 9.3 under CVSS 4.0, both Critical. NVD’s status is “Analyzed”, but its API data shows only F5’s scores and no score of NVD’s own.
• Exploitation: F5 says it has learned the flaw has been exploited. Attackers, victims and scale have not been disclosed. KEV marks ransomware use as “Unknown”.
• F5’s advisory could not be loaded: F5’s advisory K000162605 requires JavaScript and we could not load it, so the indicator list comes from CERT-EU and news reports and should still be checked in a browser. How to get the iRule (a support ticket with F5) is confirmed by the CVE record F5 wrote.
• No known link to the 2025 F5 breach: BleepingComputer mentions the August 2025 state-sponsored breach at F5 in which BIG-IP source code was stolen, but no source links that breach to this flaw, and this page doesn’t either.
• Our analysis (not a source claim): Other applications trust the tokens that an APM Authorization Server issues, so if that server is compromised, the downstream apps that rely on those tokens could be affected too.
• Related weakness types: CWE-122 (heap-based buffer overflow), CAPEC-100.