HPE ArubaOS corregge 72 falle, Ruby chiude gli exploit di GitLab

🛡️ Executive Summary

• HPE corregge 72 vulnerabilità in ArubaOS AOS-8 e AOS-10, comprese otto falle CVSS 10 che consentono bypass dell’autenticazione ed esecuzione remota di codice. Non risultano attacchi confermati.
• Ruby rilascia le versioni 4.0.9, 3.4.12 e 3.3.13 per correggere tre difetti di Onigmo collegati a quattro vulnerabilità GitLab, due delle quali classificate CVSS 10.
• PHP mantiene senza patch CVE-2026-115560, vulnerabilità RCE sfruttabile soltanto attraverso una configurazione insolita delle sessioni. La mitigazione consiste nel disabilitare session.upload_progress.enabled.

Hewlett Packard Enterprise corregge 72 vulnerabilità in ArubaOS, otto delle quali raggiungono il punteggio massimo CVSS 10 e possono permettere ad aggressori remoti di aggirare l’autenticazione o eseguire codice sugli apparati di rete aziendali. Contemporaneamente, Ruby distribuisce tre nuove release per risolvere i difetti del motore Onigmo, alla base di quattro vulnerabilità critiche già corrette da GitLab, mentre PHP segnala un’ulteriore RCE ancora priva di patch definitiva. Gli aggiornamenti del 22 e 23 ottobre 2026 interessano livelli tecnologici differenti, dagli access point e controller wireless fino ai linguaggi utilizzati dalle applicazioni web e dalle piattaforme DevOps. Il rischio comune riguarda l’elaborazione di input non attendibili in componenti che operano con privilegi elevati o gestiscono servizi critici.

HPE ArubaOS espone otto vulnerabilità CVSS 10 senza autenticazione

HPE Networking ha pubblicato il bollettino HPESBNW05162 il 22 ottobre 2026, correggendo complessivamente 72 vulnerabilità nelle famiglie ArubaOS AOS-8 e AOS-10 utilizzate da Mobility Conductors, Mobility Controllers, gateway e access point aziendali. Otto problemi, identificati consecutivamente da CVE-2026-79844 a CVE-2026-79851, raggiungono il punteggio massimo di 10 secondo CVSS 3.1. Il quadro comprende tecniche di authentication bypass, command injection, SQL injection e buffer overflow, con scenari di compromissione che possono arrivare all’esecuzione remota di codice sul sistema operativo sottostante. Secondo il bollettino HPE, ripreso nella documentazione delle vulnerabilità ArubaOS registrata dal NIST, alcuni problemi non richiedono credenziali né interazione dell’utente, riducendo sensibilmente gli ostacoli necessari per colpire i dispositivi raggiungibili attraverso la rete. CVE-2026-79844 riguarda un bypass dell’autenticazione con possibile esecuzione di codice in AOS-10, mentre CVE-2026-79845 interessa il protocollo PAPI, impiegato nelle comunicazioni fra componenti dell’infrastruttura wireless. Per AOS-8, CVE-2026-79846 introduce una command injection non autenticata e CVE-2026-79848 e CVE-2026-79849 interessano difetti SQL injection che possono evolvere in compromissione del dispositivo. Completano il gruppo CVE-2026-79847 e CVE-2026-79851, due buffer overflow in AOS-10 potenzialmente sfruttabili per eseguire codice, e CVE-2026-79850, un ulteriore bypass dell’autenticazione con conseguenze sul controllo del sistema. La posizione di questi apparati all’interno delle reti aziendali amplifica il rischio: un controller compromesso non equivale a un normale endpoint, perché può diventare un punto privilegiato dal quale osservare, modificare o interferire con componenti dell’infrastruttura wireless. La distinzione rispetto alla precedente RCE in ArubaOS-CX corretta da HPE a settembre è importante: ArubaOS-CX riguarda principalmente gli switch, mentre il nuovo bollettino coinvolge il sistema operativo delle piattaforme wireless Aruba. HPE non segnala exploit pubblici né evidenze di sfruttamento attivo al momento della divulgazione, ma la combinazione di attacchi remoti, assenza di autenticazione e privilegi ottenibili impone un aggiornamento prioritario.

Leggi anche: SharePoint e Aruba HPE: vulnerabilità critiche mettono a rischio infrastrutture aziendali

ArubaOS 8 e 10 devono essere aggiornati: le interfacce di gestione sono il punto critico

Il perimetro dei prodotti interessati comprende diversi rami software di AOS-8 e AOS-10, rendendo necessario distinguere gli apparati gestiti centralmente da quelli amministrati attraverso controller locali. Le versioni vulnerabili comprendono AOS-10.8 fino alla 10.8.1.1, AOS-10.7 fino alla 10.7.2.6, AOS-10.4 fino alla 10.4.1.13, AOS-8.13 fino alla 8.13.3.0 e AOS-8.10 fino alla 8.10.0.23. Le corrispondenti release correttive indicate nei resoconti tecnici del bollettino HPESBNW05162 sono 10.8.1.2, 10.7.2.7, 10.4.1.14, 8.13.3.1 e 8.10.0.24; prima dell’installazione occorre comunque verificare nel portale HPE la matrice applicabile al modello e al ramo effettivamente utilizzato. La presenza di più versioni vulnerabili non implica che ogni CVE interessi indistintamente tutte le configurazioni, poiché alcune debolezze riguardano componenti specifici di AOS-8 o AOS-10. In attesa degli aggiornamenti, HPE raccomanda di restringere l’accesso alle interfacce CLI e web di amministrazione, collocandole in segmenti o VLAN dedicati e applicando regole firewall di livello 3 o superiore. La raccomandazione mira a impedire che soggetti non autorizzati raggiungano direttamente i servizi di gestione, senza presentare la segmentazione come sostituto delle patch. Gli amministratori devono inoltre controllare la registrazione delle attività e degli accessi, perché alcuni scenari di compromissione possono produrre modifiche alla configurazione difficilmente riconoscibili attraverso i tradizionali sistemi di protezione degli endpoint. Il problema è particolarmente delicato nelle infrastrutture che utilizzano reti wireless per connettere personale, sistemi di produzione, dispositivi IoT e servizi amministrativi, dove una compromissione del piano di gestione può avere conseguenze superiori a quelle di un singolo access point vulnerabile. La situazione conferma quanto già emerso con le precedenti vulnerabilità che avevano interessato apparati HPE, Cisco e altri componenti di rete: l’inventario delle versioni firmware e la protezione dei servizi amministrativi devono procedere insieme, perché l’aggiornamento di un apparato non corregge automaticamente quelli che utilizzano release differenti.

Ruby corregge Onigmo: tre bug del motore regex dietro quattro falle GitLab

Sul versante applicativo, Ruby ha pubblicato il 23 ottobre le versioni 4.0.9, 3.4.12 e 3.3.13 per correggere tre difetti del motore di espressioni regolari Onigmo, individuati durante l’analisi di quattro vulnerabilità GitLab. L’advisory originale del progetto Ruby spiega che i problemi emergono quando un’applicazione compila espressioni regolari costruite utilizzando input controllati da un aggressore, attraverso funzioni come Regexp.new, Regexp.union, Regexp.compile oppure mediante interpolazione diretta all’interno di un pattern. Il risultato può essere una corruzione della memoria durante la compilazione della regex, con possibile evoluzione verso l’esecuzione di codice nel processo interessato. Le quattro vulnerabilità GitLab associate sono CVE-2026-89078, relativa a un double free nel parser, CVE-2026-93577 e CVE-2026-97229, collegate a un integer overflow nel calcolo delle dimensioni del pattern compilato, e CVE-2026-110264, associata a un overflow degli identificatori interni quando un’espressione contiene numerose ripetizioni. I difetti fondamentali sono quindi tre, anche se GitLab ha assegnato quattro identificativi CVE ai differenti scenari individuati. Ruby precisa che non tutte le applicazioni sviluppate nel linguaggio sono vulnerabili: il prerequisito essenziale è la possibilità per un attaccante di influenzare direttamente il contenuto dell’espressione regolare da compilare. Le applicazioni che utilizzano esclusivamente pattern definiti dagli sviluppatori non raggiungono normalmente i percorsi problematici. Il collegamento con GitLab è particolarmente importante perché la piattaforma permette di definire espressioni regolari all’interno delle configurazioni CI/CD e in altri componenti applicativi, ampliando la superficie esposta agli input degli utenti. Le vulnerabilità avevano già portato alla distribuzione di aggiornamenti GitLab, compresa CVE-2026-97229 con punteggio CVSS 10, ma il nuovo intervento modifica la portata della correzione: non riguarda più soltanto il pacchetto Ruby incluso in GitLab, bensì tutte le applicazioni che utilizzano una versione vulnerabile di Onigmo attraverso il runtime Ruby e compilano regex non attendibili.

Ruby 4.0.9 diventa necessaria anche per chi aveva aggiornato alla 4.0.8

Il dettaglio tecnico più importante riguarda la distribuzione non uniforme delle correzioni nei rami precedenti. Ruby chiarisce che la versione 4.0.8 contiene già alcune modifiche, ma non corregge CVE-2026-110264, rendendo necessario aggiornare alla 4.0.9 per ottenere una copertura completa dei tre difetti. Le versioni 3.4.12 e 3.3.13 rappresentano invece le prime release delle rispettive linee che integrano tutte le correzioni. Ruby 3.2 e precedenti non riceveranno aggiornamenti ufficiali per questi problemi, essendo fuori dal ciclo di manutenzione; gli sviluppatori raccomandano quindi la migrazione verso una versione supportata. Un’altra precisazione riguarda le mitigazioni: Regexp.timeout non protegge dalle vulnerabilità, perché interviene sul tempo di esecuzione delle espressioni regolari e non sui difetti di memoria che possono manifestarsi durante la loro compilazione. Anche imporre una lunghezza massima ai pattern non costituisce una protezione affidabile, poiché alcuni errori possono essere attivati attraverso espressioni relativamente brevi. Per gli ambienti che non possono aggiornare immediatamente, la misura indicata consiste nell’evitare la compilazione di regex provenienti da sorgenti non attendibili, modificando la logica applicativa dove necessario. Ruby non ha ancora richiesto CVE autonomi per i tre difetti di Onigmo e suggerisce di utilizzare temporaneamente gli identificativi già pubblicati da GitLab. Il progetto intende inoltre chiarire la propria posizione sulla sicurezza della compilazione di pattern non attendibili, una scelta significativa perché la documentazione precedente trattava soprattutto i rischi di denial-of-service associati alle espressioni regolari. Il nuovo bollettino dimostra che il problema può essere più grave: quando un motore regex gestisce scorrettamente la memoria, la costruzione di un pattern può diventare un vettore RCE, come confermato dalle correzioni GitLab del 21 ottobre per CVE-2026-110264.

PHP mantiene una RCE senza patch dopo l’emergenza PHP2Shell

Il terzo sviluppo interessa CVE-2026-115560, vulnerabilità segnalata ufficialmente dal team PHP il 23 ottobre, due giorni dopo gli aggiornamenti straordinari distribuiti per correggere CVE-2026-109618 e CVE-2026-109619. La nuova falla non deve essere confusa con quelle precedenti, perché richiede condizioni di configurazione particolarmente specifiche. Nell’avviso ufficiale PHP dedicato alla gestione delle sessioni gli sviluppatori spiegano che il problema può verificarsi quando un’applicazione configura inizialmente session.serialize_handler con il valore php_binary oppure php_serialize e successivamente lo modifica in php attraverso ini_set(), prima di eseguire session_start(). Affinché il percorso vulnerabile sia raggiungibile, deve rimanere abilitata anche la funzionalità Session Upload Progress, utilizzata per monitorare l’avanzamento dei caricamenti. PHP considera questa combinazione insolita nella pratica e ha deciso di programmare la correzione nel normale ciclo di manutenzione, senza distribuire un ulteriore aggiornamento straordinario. La mitigazione consiste nell’impostare session.upload_progress.enabled=0 in una configurazione applicata prima dell’elaborazione delle richieste; chi aveva già introdotto questa misura contro CVE-2026-109619 non deve ripeterla. Lo sviluppo era già stato esaminato nell’approfondimento sulla nuova RCE PHP priva di patch, mentre il nuovo quadro Ruby e HPE permette di distinguere tre condizioni operative differenti: software che dispone di aggiornamenti immediati, runtime che richiede una revisione del codice applicativo e una vulnerabilità ancora in attesa della correzione definitiva. Per PHP rimane indispensabile verificare l’installazione delle patch PHP2Shell del 21 ottobre, disponibili nelle release 8.5.12, 8.4.27, 8.3.36 e 8.2.35. La nuova mitigazione non sostituisce quegli aggiornamenti, perché non elimina le altre condizioni di esecuzione remota di codice già documentate nel runtime.

Continua con:

GitLab a rischio RCE, Node.js e HTTP/3 aprono nuove falle nei server

Zero-day attivi su Windows Defender e patch critiche per Cisco, Apache e PHP

Le vulnerabilità di rete e runtime richiedono priorità di intervento differenti

Gli aggiornamenti HPE, Ruby e PHP evidenziano tre condizioni che devono essere affrontate con procedure differenti. HPE mette a disposizione correzioni per vulnerabilità critiche che possono essere sfruttate senza autenticazione, ma non segnala campagne offensive confermate; la priorità riguarda quindi l’identificazione degli apparati vulnerabili, l’installazione delle release corrette e la limitazione dell’esposizione dei servizi amministrativi. Ruby corregge difetti di memoria già associati a quattro vulnerabilità GitLab, ma l’effettiva esposizione delle altre applicazioni dipende dalla possibilità di compilare espressioni regolari controllate dagli utenti. PHP segnala invece una nuova vulnerabilità non ancora corretta, che richiede però una particolare combinazione di impostazioni e codice applicativo. Trattare indistintamente queste situazioni come emergenze di sfruttamento attivo significherebbe confondere gravità, raggiungibilità e disponibilità delle patch. Per le imprese italiane che utilizzano infrastrutture Aruba, piattaforme GitLab self-managed, applicazioni Ruby e servizi web PHP, la conseguenza operativa è la necessità di mantenere un inventario che comprenda firmware, runtime, librerie e dipendenze applicative. Non è sufficiente conoscere il nome di un prodotto: occorre identificare quale versione viene effettivamente eseguita, quali interfacce risultano raggiungibili e quali input possono arrivare al componente vulnerabile. La diversa maturità delle correzioni dimostra inoltre che la sicurezza non può basarsi esclusivamente sulla pubblicazione degli advisory, perché alcune debolezze sono risolvibili immediatamente, altre richiedono modifiche al codice e altre ancora rimangono temporaneamente affidate a configurazioni restrittive. L’elemento comune delle tre vicende è il fallimento dei controlli sulle operazioni eseguite a basso livello: protocolli di gestione che possono consentire l’accesso senza autenticazione, espressioni regolari che corrompono la memoria e sessioni che attraversano configurazioni interne non previste. La priorità difensiva non deve seguire automaticamente il numero di CVE pubblicate, ma la combinazione fra possibilità di sfruttamento, privilegi raggiungibili, esposizione reale e disponibilità di una correzione verificabile.