F5 CVE-2026-94127: the overflow happens before authentication

1 Find the authorization server that receives the request

APM can perform several OAuth roles. As an Authorization Server, it issues tokens and provides services such as token introspection, revocation and user information. As a Client or Resource Server, it uses identity information supplied by another authorization server. F5's current advisory limits CVE-2026-94127 to the first role, with an APM access policy and the corresponding OAuth profile configured on a virtual server. Deployments operating strictly as clients or resource servers, without Authorization Server profiles, are outside this vulnerability's stated scope.

An inventory flag saying "OAuth enabled" therefore leaves an important question unanswered. Follow the virtual server receiving traffic to its assigned access profile, then to the associated OAuth profile. F5's configuration guide describes this association as OAuth profile, access profile and virtual server. The presence of a login page does not establish that every OAuth request handler runs only after the user has authenticated.

The default UserInfo path, /f5-oauth2/v1/userinfo, lets a client retrieve user information. The OAuth profile command reference allows userinfo-url to be changed, so log searches and temporary rules need the paths actually configured on the device. We use that reference for configuration semantics, without extending the affected range to BIG-IP 14. JPCERT/CC also warns about possible exploitation through other URL paths. Blocking only the default string leaves unexamined entry points.

F5 classifies this as a data-plane issue. Requests handled by the business-facing virtual server can reach the vulnerable processing; management-page exposure is a separate configuration question. Restricting the management network helps protect administration interfaces, while remediation here must cover the OAuth authorization service in ordinary application traffic. F5 also includes Appliance mode in the affected scope, so that mode cannot exclude a device from assessment.

Check each node, including standby units and older instances scheduled to return to service. F5's OAuth overview explains that one device can hold both types of role using different virtual servers and hostnames. Finding a client-only endpoint should lead to checking the remaining authorization services on that device. Identical product names can conceal very different request-processing configurations.

2 An unchecked length reaches a fixed buffer

The implementation is closed source. This explanation draws on watchTowr's original September 23 research, which compares tmm64.pgo_use from 21.1.0, build 0.0.38, with 21.1.0.2, hotfix build 0.30.22. Its published decompiled snippets show a 0x4100-byte heap allocation, an Authorization-header copy using a request-derived length, and a subsequent Bearer-format check. The patch adds a rejection branch for n > 0x4100 before the copy.

Hexadecimal 0x4100 is 16,640. If the allocated buffer starts at address p, its byte positions run from p through p + 16639. Copying 16,641 bytes writes the last byte to p + 16640, beyond the allocated object. On a real appliance, the adjacent object and the time at which it is used affect the outcome. The underlying error is already clear: the requested copy exceeds the destination's capacity.

Bearer names the HTTP authentication scheme. Checking for the Bearer prefix is one step in interpreting a credential. When that check follows the copy, rejecting an invalid credential cannot undo an earlier out-of-bounds write. This ordering explains the advisory's unauthenticated attack condition. An access policy's identity checks cannot retroactively supply the missing capacity check in earlier request processing.

Simplified ordering; unrelated implementation details omitted

capacity C = 0x4100
obtain the Authorization field and its length n

added by the fix: if n > C, reject and exit
an empty field follows the existing error branch
copy n bytes into the buffer of capacity C
check Bearer format, then continue credential processing

We use n and C as explanatory symbols. Names generated by a decompiler are not F5 source interfaces. Without acquiring the appliance binary, we cannot supply an official function name, source-file line range or vulnerability-introducing commit. The published snippets support the copy ordering and the new condition; complete parser behavior across header variants still requires validation by F5 or researchers holding the relevant image.

Scroll sideways to read the diagram.

We checked this condition in an offline model that allocates no destination buffer and sends no network requests. Its input lengths were 0, 6, 7, 16,639, 16,640 and 16,641. The first five do not exceed capacity; the last exits at the added branch. A length equal to capacity is not rejected by this greater-than comparison and still needs format checking. The following standalone code reports only length relationships, not an appliance response or a reproduction of the vulnerability.

const capacity = 0x4100;
for (const n of [0, 6, 7, 16639, 16640, 16641]) {
  console.log({
    n,
    rejectBeforeCopy: n > capacity,
    bytesBeyondCapacity: Math.max(0, n - capacity)
  });
}

The operational consequence depends on the overwritten heap data. In its experiment, watchTowr overwrote a callback pointer in a neighboring object, redirecting subsequent control flow through the modified pointer. SELinux in that environment restricted direct process execution; the researchers then used the writable lifecycle script /etc/bigstart/scripts/tmm.finish to have process cleanup execute changed contents. We have not reproduced that path or measured success rates across platforms and versions. For responders, this explains why device files and startup behavior belong in the investigation: normal-looking service after an interruption can coexist with modifications requiring investigation.

3 Identify the complete EHF build

As of September 28, F5 lists the following fixes. EHF means engineering hotfix. These complete package identifiers serve as both the current advisory's deployment targets and the historical first-fixed packages. When adopting a newer release, confirm that its notes include Bug 2524777 or an explicit vendor statement that it contains this repair.

A shared base version can obscure the difference. F5's current EHF guidance also retains the earlier builds 17.5.1.9.0.46.12-ENG and 17.1.3.5.0.1.14-ENG, which are not listed as fixes for CVE-2026-94127. An asset field storing only 17.5.1.9 cannot distinguish those packages. Preserve the running version, hotfix/build, image name and associated advisory when checking the device, including its alternative boot volumes.

# Read the running version and hotfix on a BIG-IP you administer
tmsh show sys version detail

This read-only command retrieves version information. Installation preparation also needs the EHF instructions: place the target hotfix and matching base image in /shared/images. The installer handles the base image when necessary; preparation does not require first booting the unfixed base as a serving node. Devices with a custom EHF need their existing bug fixes compared with the target package. Ask F5 Support about a combined build when a necessary fix is missing, avoiding a regression in an earlier business-specific repair.

Public databases contain a discrepancy requiring human judgment. On September 28, NVD starts one CPE range at 17.0.0, while F5's current affected table starts at 17.1.0; the F5 release matrix lists 17.0 as EOL. F5 explicitly excludes end-of-technical-support versions from its assessment. Older systems therefore require separate confirmation or migration: absence from the table establishes neither safety nor an introduction date, and the CPE starting point cannot establish that date either. NVD currently attributes CVSS 3.1 9.8 and CVSS 4.0 9.3 to F5, with no separate NIST score visible.

A practical deployment approach is to verify the image and business behavior on one controlled node, then process the remaining nodes through the established HA change procedure. If an upgrade fails and troubleshooting requires an old boot volume, keep the affected authorization service isolated or under vendor-approved temporary protection. Reopening traffic still requires a verified running build containing 2524777. An unfixed old volume is suitable only for controlled recovery work.

4 Investigate earlier activity while restricting new requests

F5 currently directs customers to Support for a temporary iRule. Its public advisory does not publish the rule body, so we cannot independently establish its handling of repeated headers, HTTP versions or custom paths. Before deployment, confirm the applicable build, the virtual servers receiving the rule, the actual OAuth paths and the behavior of legitimate large-token requests. These are questions for the vendor during implementation. A locally invented rule matching only the default URL has no equivalent coverage assurance.

Disabling or restricting the authorization service temporarily affects dependent applications. New logins, token renewal or UserInfo requests may fail, with the extent depending on client token caching and user-information retrieval. The response owner needs to choose an acceptable degraded mode and identify calls that must remain available. Temporary filtering reduces opportunities for new triggering requests; files, accounts or configuration already altered on a device need separate investigation and recovery.

CERT-EU recommends preserving forensic material before patching. In practice, capture vulnerable-to-loss logs, existing cores, running configuration and accurate timestamps in a controlled location while containment and upgrade preparations proceed. Keeping an exposed service available indefinitely for more complete evidence collection adds avoidable risk. Remove sensitive session, key and user information from public tickets.

F5's initial indicator is repeated OAuth UserInfo failure in /var/log/apm, event 01990004, including invalid_token. It describes ten or more such errors in a single log, especially from one source IP, as a medium-confidence indicator. That condition specifies no per-minute rate. Expired tokens and application retry failures can also increase the count, so examine request timing, source and the actual path together.

# Read local counters and correlate them with the available log period
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed

An unexplained rise in total_failed can narrow the period to investigate; the counter does not record who executed which action. Correlate that period with unexpected commands and administrative activity in /var/log/audit, then inspect TMM behavior. F5 explains that a looping TMM can cause SOD to send SIGABRT and produce a core. Other faults can also produce cores, so interpret them alongside OAuth failures and command records.

JPCERT/CC's September 24 notice adds checks for unusually long Authorization headers and the integrity of /etc/bigstart/scripts/tmm.finish. Compare the file with a trusted baseline appropriate to the exact image or provided by vendor support, preserving differences and timestamps. Suspicious modifications should broaden the investigation to files, administrator accounts, access policies and token-related keys. The Canadian Centre for Cyber Security also explicitly calls for review of administrative accounts and access policies.

Each source of evidence answers a different question. Unusual requests show contact with the entry point; changed files and audit commands help establish what happened afterward; the running build identifies the currently installed repair. Logs can rotate and their coverage depends on configuration. If those indicators are absent, record the nodes, logs and period actually examined. Public information remains insufficient to establish the complete victim population, attacker attribution or success rates across platforms.

5 Verify tokens and standby nodes before restoring service

Completion evidence should come from running nodes. Record each full EHF build and confirm that a failover will not restore the old processing code. Then use accounts and applications you control to exercise login, token issuance, UserInfo and refresh flows. Check expected rejection with invalid or expired tokens and correlate the errors with counters and logs. Deliberately oversized requests enter memory-safety testing territory; production acceptance does not require them to establish that the documented patch is installed.

If investigation finds that the device was controlled, recovery extends to credentials it held. An OAuth Authorization Server may contain signing keys, client secrets and token databases. F5 documents automatic HA synchronization of the OAuth database and its inclusion in UCS backups. Assess the trustworthiness of backup and synchronization sources before recovery. Rotate potentially exposed signing keys and client secrets, retiring old trust with attention to token lifetimes, verifier caches and application compatibility. A restart cannot determine whether these materials were previously read.

Retiring the temporary iRule also needs a normal-traffic check. Once every node serving that authorization service is fixed and the compromise investigation has an actionable disposition, remove the temporary rule according to vendor guidance and confirm expected traffic and monitoring behavior. Keep the relevant restrictions when node versions remain uncertain, file changes are unexplained or necessary logs are missing, with an identified owner for the remaining investigation.

This vulnerability leaves a specific question for authentication-service reviews: how many parsing, allocation and copy operations handle a credential before it is established as valid? Each operation must treat that input as untrusted. For teams running APM, the immediate work is equally concrete: identify the authorization server, verify the complete hotfix build and investigate the period before patching far enough to justify restoring service.