F5 ha corretto una vulnerabilità critica di BIG-IP Access Policy Manager (APM) che risulta già sfruttata in attacchi reali. Identificata come CVE-2026-94127, la falla può permettere a un soggetto esterno di eseguire codice da remoto su un sistema vulnerabile senza dover prima effettuare l’autenticazione. La gravità assegnata dal produttore è 9,8 su 10 secondo CVSS v3.1.
La notizia richiede però una lettura precisa delle configurazioni coinvolte. Il problema non interessa indistintamente ogni apparato BIG-IP né ogni utilizzo di APM: la condizione vulnerabile si verifica quando il modulo è impiegato come OAuth Authorization Server, cioè nel ruolo che rilascia token di accesso alle applicazioni, e un’access policy APM con il relativo profilo OAuth è associata allo stesso virtual server. Le installazioni in cui APM agisce soltanto da OAuth Client o Resource Server non rientrano nel perimetro indicato da F5.
Il traffico malevolo passa dal piano dati
CVE-2026-94127 è un heap-based buffer overflow, una classe di errore di gestione della memoria che, nel caso specifico, può essere innescata attraverso traffico costruito ad arte inviato al virtual server che gestisce il flusso OAuth. Il risultato potenziale è particolarmente rilevante: l’esecuzione remota di codice sull’appliance BIG-IP senza credenziali.
Questo dettaglio ha conseguenze operative importanti. L’attacco non passa dall’interfaccia di amministrazione del prodotto, ma dal data plane, il livello che riceve e instrada il traffico destinato ai servizi pubblicati. Restringere l’accesso alla console di gestione resta una misura essenziale di sicurezza, ma non neutralizza questa vulnerabilità. F5 precisa inoltre che sono esposti anche i sistemi BIG-IP configurati in Appliance mode.
Il produttore afferma di avere individuato internamente il difetto e di avere appreso che è stato sfruttato prima della disponibilità della correzione pubblica. Al momento non sono stati diffusi elementi su numero e identità delle vittime, gruppi responsabili o finalità delle intrusioni. L’assenza di attribuzione non riduce l’urgenza: la conferma dello sfruttamento basta a trasformare una patching activity in una verifica di possibile compromissione.
Quali versioni richiedono intervento
F5 ha pubblicato engineering hotfix per i rami supportati interessati: BIG-IP 21.1.0, BIG-IP 17.5 dalla versione 17.5.0 alla 17.5.1, e BIG-IP 17.1 dalla 17.1.0 alla 17.1.3. Gli hotfix distribuiti sono rispettivamente Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG e Hotfix-BIGIP-17.1.3.5.0.41.14-ENG.
La presenza di una release compresa negli intervalli non è da sola sufficiente a definire un’istanza esposta: va controllato il ruolo OAuth svolto da APM e la configurazione del virtual server. Al contrario, non è prudente dedurre che le versioni arrivate alla fine del supporto tecnico siano sicure. F5 non ne ha valutato lo stato, che rimane quindi sconosciuto.
È utile anche evitare un errore frequente nella gestione delle piattaforme di rete: considerare risolto il rischio perché l’appliance è stata aggiornata in occasione di un advisory precedente. Un’altra vulnerabilità APM, CVE-2025-53521, era stata inserita nel catalogo delle falle sfruttate da CISA nei mesi scorsi; le correzioni allora disponibili per le linee 17.1 e 17.5 ricadono negli intervalli ora interessati. Chi aveva installato quelle build deve dunque applicare anche il nuovo hotfix se usa APM come OAuth Authorization Server.
Patch, mitigazione e controlli forensi
La priorità per i team che amministrano BIG-IP è identificare i virtual server con un profilo OAuth Authorization Server, verificare il ramo software installato e applicare la correzione prevista da F5. Se l’hotfix non può essere implementato immediatamente, il fornitore mette a disposizione una mitigazione basata su iRule, ottenibile aprendo una richiesta al supporto. Si tratta di una misura temporanea: non sostituisce l’installazione della patch.
La Cybersecurity and Infrastructure Security Agency statunitense ha inserito CVE-2026-94127 nel catalogo Known Exploited Vulnerabilities il 22 settembre. Alle agenzie federali civili degli Stati Uniti è stato chiesto di applicare le mitigazioni entro il 25 settembre, seguendo la direttiva BOD 26-04. CISA suggerisce di adottare inizialmente l’iRule per consentire attività forensi preventive e di installare poi il fix definitivo del vendor appena possibile.
Prima di modificare sistemi potenzialmente coinvolti, preservare log e altre evidenze disponibili può essere decisivo per capire se ci sia già stata un’intrusione. F5 ha diffuso tre indicatori di compromissione, da interpretare in correlazione e non come prova isolata. Tra i segnali segnalati figurano ripetute richieste UserInfo fallite nei log APM, con l’errore relativo a un access token non valido; un volume elevato di richieste da un singolo indirizzo IP in poco tempo merita un esame mirato.
La catena osservabile assume maggiore rilievo quando alle anomalie OAuth seguono comandi sospetti e, poco dopo, un arresto SIGABRT del processo TMM. Per i responsabili della sicurezza, questo significa incrociare i log di APM, gli eventi del sistema e il traffico sul virtual server, anziché affidarsi a una sola firma o a un singolo evento. Qualora emergano indicatori compatibili con lo sfruttamento, la risposta dovrebbe passare dalle normali procedure di incident response, includendo isolamento, raccolta delle evidenze e valutazione dell’impatto sugli accessi e sui token gestiti dall’infrastruttura.
Perché BIG-IP è un bersaglio delicato
BIG-IP viene spesso collocato in punti centrali dell’architettura aziendale: bilanciamento del traffico, pubblicazione di applicazioni, accesso remoto e controllo delle identità. Nel caso di APM configurato come Authorization Server, il componente interviene inoltre nel rilascio dei token OAuth. Un’esecuzione di codice a questo livello può quindi interessare un nodo esposto che svolge una funzione di mediazione fra utenti, applicazioni e servizi interni.
Non significa automaticamente che ogni sfruttamento porti agli stessi risultati o all’accesso a tutte le risorse di un’organizzazione: gli effetti dipendono da configurazione, privilegi del processo, segmentazione e capacità di rilevamento. Ma la combinazione tra assenza di autenticazione, esecuzione remota di codice e sfruttamento già confermato impone una risposta rapida. Le organizzazioni dovrebbero trattare l’advisory come un intervento prioritario di esposizione esterna, verificando nel contempo che le proprie procedure di inventario distinguano davvero i ruoli OAuth configurati sugli apparati.
