al-ice.ai

The Box That Issues Your Tokens Can Be Taken Without Login

AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 22 September 2026 F5 disclosed CVE-2026-94127, a heap-based buffer overflow in BIG-IP Access Policy Manager rated 9.8 (CVSS v3.1) and 9.3 (CVSS v4.0), and confirmed attackers were already exploiting it for unauthenticated remote code execution. CISA added it to the Known Exploited Vulnerabilities catalog the same day and gave federal agencies until September 25 to mitigate. The vulnerable configuration is the one identity teams trust most: APM acting as an OAuth authorization server, the component that issues access tokens to applications.

The exploit path runs through the virtual server itself. Where an APM access policy and an OAuth authorization server profile sit on the same virtual server, specially crafted traffic to that server's address yields code execution on the BIG-IP system — no login of any kind. Two consequences follow that defeat the usual compensating controls: restricting access to the management interface does not protect against this flaw, because the malicious traffic never goes there; and BIG-IP systems in Appliance mode are vulnerable too. F5 has released per-branch engineering hotfixes: 21.1.0 takes Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, 17.5.0–17.5.1 takes Hotfix-BIGIP-17.5.1.9.0.160.12-ENG, and 17.1.0–17.1.3 takes Hotfix-BIGIP-17.1.3.5.0.41.14-ENG. Systems where APM acts only as an OAuth client or resource server, with no authorization server profiles, are not affected.

Check your own configuration — the official descriptions disagree

There is a scope subtlety that matters for triage. F5 updated its CVE record at 00:45 UTC on September 23 to say the flaw is present only in the authorization server role — the OAuth profile created under Access > Federation > OAuth Authorization Server and selected in an access profile attached to the virtual server. But CISA's KEV entry and CERT-EU's advisory were published before that narrowing, and both describe the condition more broadly, as an access policy plus an OAuth profile on a virtual server. If your team screened itself out — or in — using the broader wording, re-check against the narrower one: enumerate virtual servers carrying an authorization server OAuth profile, not merely virtual servers with OAuth anything.

Two more traps in the same advisory set. First, an earlier APM flaw, CVE-2025-53521, added to KEV in March, has fixes (17.1.3 and 17.5.1.3) that fall inside the newly affected ranges — a system dutifully updated to either build still needs the new hotfix if APM serves tokens on it. Patching the last emergency is not patching this one. Second, F5 did not evaluate versions past End of Technical Support, so their status is unknown, not safe.

When the token issuer falls, everything downstream is suspect

An OAuth authorization server is the trust root for every application holding its tokens. Code execution on that box potentially means visibility into issued tokens, the ability to mint or misuse them, and a pivot into every downstream application that accepts them — which is why CISA's handling is notable: agencies were told to apply F5's iRule mitigation first “to allow for proactive forensic triage,” then install the vendor patch as soon as possible. Mitigation as a way to buy investigation time, not as an alternative to patching. CERT-EU's sequence is the same shape: preserve forensic evidence, apply the hotfix, check for compromise, start incident response on any hit.

F5 and CERT-EU publish a concrete detection pattern worth lifting into your own monitoring: repeated failed UserInfo requests in /var/log/apm (“The access token is invalid”) — ten or more from a single IP in a short window — followed by suspicious commands in /var/log/audit and a TMM SIGABRT shortly after, plus an unexplained rise in the total_failed OAuth counter (tmctl global_oauth_stat). The combination, not any single signal, is what should page a human.

The identity-layer pattern is now unmistakable across this month's coverage: forged JWTs into WSO2 admin sessions, unauthenticated RCE on NetScaler edge boxes, and now code execution on the server that mints OAuth tokens. For agent deployments the lesson is direct — agents authenticate through exactly these layers, and their service-account tokens and secrets are what a compromised issuer or gateway can see. Compromise the token infrastructure and you never need to touch the agent.

What to do

  • Determine exposure by role, not by version alone. Only APM-as-OAuth-authorization-server deployments are affected. List virtual servers with an authorization server OAuth profile in the attached access profile; everything else can stand down, everything matching cannot.
  • Apply the iRule first if you need time, then the hotfix immediately. Get the iRule from F5 support for the affected virtual server, use the window for forensic triage per CISA's ordering, and install the branch hotfix as soon as possible. Do not treat the iRule as the fix.
  • Hunt the published pattern before and after patching. Failed UserInfo bursts from single IPs, total_failed counter rises, audit-log commands at matching times, TMM cores/SIGABRT. Neither F5's record nor the CISA and CERT-EU advisories state that the hotfix removes attacker access already gained — so a clean patch with unexamined logs is an unfinished job.
  • Re-audit March's APM patch. If you closed CVE-2025-53521 with 17.1.3 or 17.5.1.3 and run APM as an authorization server, you are still exposed to this flaw. Verify the new hotfix build explicitly.
  • Rotate what the issuer could see. Tokens issued, client secrets, and downstream service credentials that passed through an exposed authorization server should be treated as potentially compromised until the compromise check clears.

Sources: