La settimana in cui lo stesso emittente di identità è caduto — zero-day OAuth di F5 BIG-IP APM (CVE-2026-94127) e la concentrazione di KEV sui piani di gestione e di identità
F5 ha comunicato il 22 settembre che uno zero-day critico nel percorso OAuth di BIG-IP APM (CVE-2026-94127, CVSS 9.8) consente l'esecuzione di codice remoto senza autenticazione, e ha confermato lo sfruttamento in the wild. CISA lo ha aggiunto al catalogo KEV lo stesso giorno, con una scadenza federale al 25 settembre. Arista VCO e due difetti dei server di gestione Check Point sono entrati anch'essi in KEV quel giorno — esaminiamo la convergenza degli attacchi sui piani di gestione e di identità delle appliance di confine.
Questo articolo è stato tradotto automaticamente.
Il 22 settembre 2026, F5 ha comunicato CVE-2026-94127 (ID interno 2524777) in BIG-IP Access Policy Manager (APM). Quando una policy di accesso APM e un profilo OAuth sono configurati su un virtual server, traffico malevolo specifico può portare all'esecuzione di codice remoto (RCE) — un buffer overflow basato su heap (CWE-122) — con un punteggio CVSS v3.1 di 9.8 (come riportato da F5) e un CVSS v4.0 di 9.3 (come riportato da F5, tramite NVD). Il difetto è limitato alle implementazioni in cui BIG-IP APM è configurato come OAuth Authorization Server; le implementazioni che usano APM strettamente come Client / Resource Server non sono interessate. F5 dichiara di essere «a conoscenza del fatto che questa vulnerabilità è stata sfruttata» e nota che il difetto è stato scoperto internamente. È un problema del data plane senza esposizione del control plane, e BIG-IP in Appliance mode è anch'esso vulnerabile. Le release interessate sono 21.1.0 (corretta in Hotfix-BIGIP-21.1.0.2.0.30.22-ENG), 17.5.0-17.5.1 (corretta in Hotfix-BIGIP-17.5.1.9.0.160.12-ENG) e 17.1.0-17.1.3 (corretta in Hotfix-BIGIP 17.1.3.5.0.41.14-ENG); BIG-IP Next, F5 Distributed Cloud, NGINX e F5OS non sono interessati (advisory F5 K000162605).
CISA ha aggiunto la vulnerabilità al proprio catalogo KEV il 22 settembre, dando alle agenzie civili federali tempo fino al 25 settembre per rispondere (BOD 26-04, tre giorni dall'inserimento). È soggetta a triage forense, e le note KEV di CISA indirizzano gli operatori ad applicare l'iRule fornita dal vendor come mitigazione temporanea, quindi a installare la patch finale non appena possibile. Anche F5 offre una mitigazione iRule per il virtual server interessato, disponibile tramite il supporto F5. Per la valutazione del compromesso, F5 ha pubblicato tre indicatori di compromissione, che l'advisory di CERT-EU (2026-013) organizza in una revisione in quattro passi: fallimenti ripetuti di autenticazione OAuth (invalid_token) in /var/log/apm, un aumento inspiegato di total_failed tramite tmctl global_oauth_stat, comandi sospetti in /var/log/audit intorno a quei timestamp, e il loop TMM che fa inviare al daemon SOD un SIGABRT (la sola presenza di un file core TMM non è un indicatore) — è la combinazione e la frequenza di questi elementi a correlarsi con un attacco (secondo The Hacker News, il catalogo KEV di CISA e CERT-EU).
Analisi (separata dai fatti): ciò che merita attenzione è meno il singolo CVE che la composizione delle quattro voci entrate nel catalogo KEV il 22 settembre: questo difetto di F5 BIG-IP APM, più Arista VeloCloud Orchestrator (CVE-2026-93952) e due difetti dei server di gestione Check Point (CVE-2026-93616 / CVE-2026-85102). Il filo comune è che i «piani di gestione e di identità» delle funzioni di rete distribuite sono i bersagli. La settimana scorsa questo osservatorio ha trattato il bypass di autenticazione dell'API di gestione di Cisco ISE (CVE-2026-76460) e il problema per cui i log della stessa appliance compromessa non sono più una fonte primaria. Questo caso fa avanzare quel punto di un passo: dove APM è usato come authorization server OAuth, l'appliance stessa è di fatto l'emittente di identità, e un RCE non autenticato sul suo data plane porta la connotazione di catturare l'emittente stesso. Il fatto che F5 abbia scoperto il difetto internamente suggerisce una finestra silenziosa di sfruttamento in the wild prima della comunicazione; l'attribuzione della parte che sfrutta non è ancora pubblica.
Implicazioni difensive: (1) Se si esegue BIG-IP APM come authorization server OAuth, applicare per prima la hotfix corrispondente (o una release successiva sullo stesso branch). Le implementazioni che usano APM strettamente come client / resource server sono fuori ambito, ma le configurazioni ibride che includono un profilo di authorization server richiedono un inventario per ogni virtual server. (2) Dove la mitigazione iRule è distribuita prima della patch, registrarla come mitigazione — secondo le note di CISA, come misura ponte da affiancare alla patch finale. (3) Eseguire il rilevamento in quattro stadi di CERT-EU (ripetizione dei fallimenti OAuth, total_failed, log di audit, core TMM) sull'appliance stessa, rivedendo anche la cronologia firewall / NetFlow del traffico verso APM, sulla premessa che i log della stessa appliance possano non essere più una fonte primaria. (4) Con la stessa lente, inventariare l'esposizione degli asset del «piano di gestione e di identità» — inclusi Arista VCO e i server di gestione Check Point — insieme alla patch per ciascun CVE. I fatti qui attingono all'advisory di F5 (https://my.f5.com/manage/s/article/K000162605), al catalogo KEV di CISA (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), al record CVE di NVD (https://nvd.nist.gov/vuln/detail/CVE-2026-94127), all'advisory CERT-EU 2026-013 (https://cert.europa.eu/publications/security-advisories/2026-013/), a The Hacker News (https://thehackernews.com/2026/09/f5-patches-critical-big-ip-apm-zero-day.html) e a SecurityWeek (https://www.securityweek.com/critical-f5-big-ip-vulnerability-exploited-as-zero-day/). L'analisi è tenuta separata dal resoconto.