Enterprise Cybersecurity IntelligenceFriday

An enterprise cybersecurity intelligence company.For security and technology leaders.

Security.io
Security.io Intelligence

What changed, why it matters,
and how it evolved.

Vulnerability Management · Executive briefing

F5 BIG-IP APM exploitation requires hunting, not patch-only closure

JPCERT/CC's new hunt guidance turns an actively exploited BIG-IP APM patch emergency into a compromise-assessment requirement for exposed OAuth deployments.

By Security.io Intelligence Desk · Published Friday, 25 September 2026

Vulnerability ManagementNetwork SecurityIncident Response
Why it is in today’s brief

F5 disclosed the vulnerability and active exploitation on 22 September, so the underlying issue is older than the priority window. It warrants inclusion because JPCERT/CC published specific hunt guidance on 24 September, including a log threshold, command, request path and file-integrity check. That authoritative update changes the enterprise decision from emergency hotfix deployment to evidence-based compromise assessment and gives today's most executable hunt item.

Read first

F5 confirmed active exploitation of CVE-2026-94127 in a specific BIG-IP APM OAuth configuration. New JPCERT/CC detection guidance requires exposed organisations to preserve evidence and separate hotfix status from compromise status.

Act now

Identify virtual servers combining APM access policies with OAuth profiles.

Accountable owner

Head of Network Security with the BIG-IP platform owner, vulnerability management and incident response.

Decision horizon

Immediate exposure identification and evidence preservation; patch or mitigation and compromise assessment today.

AssessmentHigh confidence
Emerging riskAdditional affected versions, exploit-source indicators, payload artefacts or authoritative confirmation of post-exploitation actions.

What happened

On 22 September 2026, F5 disclosed CVE-2026-94127, confirmed exploitation in the wild and released engineering hotfixes for affected BIG-IP APM branches. On 22 September 2026, CISA added CVE-2026-94127 to the Known Exploited Vulnerabilities catalogue. CVE-2026-94127 affects BIG-IP APM when an access policy and OAuth profile are configured on the same virtual server; vulnerable branches are 21.1.0, 17.5.0 through 17.5.1, and 17.1.0 through 17.1.3 before the specified engineering hotfixes. The flaw allows unauthenticated remote code execution, including on systems operating in Appliance mode. F5 described it as a data-plane issue without direct control-plane exposure.

On 24 September 2026, JPCERT/CC published detection guidance covering OAuth failure logs, request statistics, audit evidence, TMM core files and a persistence-relevant script path. JPCERT/CC advised checking /var/log/apm for OAuth UserInfo failure log ID 01990004 repeated at least 10 times, particularly from one source IP address. The command tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed exposes OAuth request and failure statistics that should be reviewed for unexplained spikes. Investigators should review unusually long Authorization headers sent to /f5-oauth2/v1/userinfo, correlate /var/log/audit activity, inspect TMM core files and verify that /etc/bigstart/scripts/tmm.finish was not modified.

F5 made an iRule mitigation available through support for organisations unable to apply the engineering hotfix immediately. The cited authorities did not publish exploit-source IP addresses, payload hashes or actor infrastructure. Attribution posture: F5 confirmed exploitation, while the cited authorities did not name the exploiting actor or campaign.

Why this matters now

The configuration prerequisite narrows the affected population, but it also makes a decision-grade inventory essential. A generic BIG-IP version list cannot establish exposure: teams must identify virtual servers where an APM access policy and OAuth profile coexist. Because exploitation preceded or accompanied disclosure, patch completion answers only whether future exploitation is blocked. It does not answer whether the device processed malicious traffic before remediation or whether an attacker modified files, credentials or downstream access paths.

JPCERT/CC’s 24 September guidance materially improves operational closure by publishing specific log, statistic, request-path and file-integrity checks. Network appliances often sit outside normal endpoint telemetry and may terminate authentication or remote-access traffic. Security leadership should therefore require preserved logs, command output and integrity findings from the appliance team, with incident response owning the interpretation of anomalies rather than leaving closure solely to patch management.

The decision for security leaders

Direct the network platform owner to produce a configuration-level exposure list, not a product-level inventory. Each listed virtual server needs its running version, applicable hotfix, external reachability, OAuth role, log retention and business owner. Systems without the vulnerable configuration should be documented and removed from the emergency queue so response capacity remains focused.

Require incident response to sign off closure for every exposed system. Hotfix evidence must be paired with a pre-remediation review of log ID 01990004, OAuth statistics, long Authorization headers, audit records, TMM core files and /etc/bigstart/scripts/tmm.finish integrity. Any unexplained finding should move the asset from vulnerability remediation into formal incident handling.

Evidence of closure

  • Configuration inventory identifies every affected and unaffected OAuth virtual server.
  • Change records prove the applicable hotfix or approved mitigation is active.
  • Hunt records contain reviewed logs, statistics, audit data and core-file findings.
  • Integrity validation confirms /etc/bigstart/scripts/tmm.finish is unmodified.

The Security.io assessment

The authoritative evidence supports urgent action but not assumptions about a single campaign or post-exploitation playbook. F5 has confirmed exploitation, while public authorities have not supplied source infrastructure or payload artefacts. Detection therefore depends on appliance-native behaviour and integrity evidence. Organisations lacking retained APM or audit logs should record that assurance limitation rather than treating an absence of alerts as evidence of safety.

JPCERT/CC’s guidance is the material change for this edition. The vulnerability and KEV addition were already known on 22 September, but the 24 September publication gives defenders concrete compromise checks and a threshold for suspicious OAuth failures. This moves the leadership question from whether patching is urgent to whether patching can be accepted as closure without evidence from the period of exposure.

Questions for the morning meeting

  • Can the network team identify every virtual server combining an APM access policy with an OAuth profile?
  • Has incident response reviewed pre-patch evidence rather than accepting hotfix deployment as closure?
  • Are affected appliances retaining the logs and core files required for investigation?

Related intelligence

Shared decision context