Il 20 ottobre 2026 Oracle ha pubblicato il Critical Patch Update (CPU) trimestrale: 1.295 patch di sicurezza che, secondo il conteggio di Tenable ripreso da eSecurityPlanet, corrispondono a 1.209 CVE uniche su 33 famiglie di prodotti. La differenza fra i due numeri non è un errore: una stessa vulnerabilità può richiedere correzioni in più prodotti, quindi genera più patch. Fra le correzioni, Tenable conta 112 patch critiche relative a 95 CVE. Il dato che merita attenzione, però, non è il volume: sono sei vulnerabilità con punteggio CVSS 3.1 pari a 10.0, tutte potenzialmente sfruttabili da remoto senza autenticazione.

Cosa è successo

Le sei falle di gravità massima riguardano quattro insiemi di prodotti, secondo l'elenco riportato da CSO Online e confermato da eSecurityPlanet:

  • Oracle E-Business Suite, componente Workflow (Notification Mailer), CVE-2026-101809, versioni da 12.2.3 a 12.2.15: raggiungibile via HTTP, può portare alla compromissione del mailer delle notifiche e, da lì, al controllo di Workflow con possibili effetti su altri prodotti.
  • Oracle SOA Suite (Fusion Middleware), tre CVE: CVE-2026-91231 (componente Adapters) e CVE-2026-91216 e CVE-2026-91221 (Fabric Layer), versioni 12.2.1.4.0 e 14.1.2.0.0. Le due falle del Fabric Layer si raggiungono tramite i protocolli T3 e IIOP e Oracle stessa le descrive come facilmente sfruttabili.
  • Oracle Access Manager (Fusion Middleware), CVE-2026-87337, versioni 12.2.1.4.0 e 14.1.2.1.0: raggiungibile via HTTP, consente la creazione, modifica o cancellazione non autorizzata di dati critici.
  • JD Edwards EnterpriseOne Orchestrator, CVE-2026-91299, versioni da 9.2.0.0 a 9.2.26.5: via HTTP, permette di prendere il controllo dell'orchestratore.

Oltre a queste, l'advisory di Oracle segnala altri problemi gravi: nel database server la CVE-2026-75803 (CVSS 9.8, legata a OpenSSL, sfruttabile da remoto senza autenticazione), in APEX la CVE-2026-101521 (9.8, via HTTPS senza autenticazione) e un gruppo di falle in Essbase con punteggi fra 9.8 e 9.9. Per quanto riguarda la distribuzione dei volumi, eSecurityPlanet riporta 206 patch per Fusion Middleware (134 delle quali potenzialmente sfruttabili da remoto senza autenticazione), 194 per E-Business Suite, 122 per Siebel CRM, 110 per Communications, 109 per PeopleSoft e 102 per JD Edwards.

Un punto di precisione necessario: nessuna delle fonti consultate indica sfruttamento attivo né exploit pubblici per le sei CVE a punteggio 10. Il fatto che una falla sia raggiungibile senza autenticazione è un fattore di rischio, non la prova di attacchi in corso. Oracle, tuttavia, ricorda nel proprio avviso che in passato gli attaccanti hanno avuto successo contro clienti che non avevano applicato patch già disponibili, e la nostra cronaca recente lo conferma: a luglio abbiamo documentato lo sfruttamento reale di una falla in E-Business Suite e ad agosto l'ingresso di componenti Oracle nel catalogo KEV di CISA.

Perché un CVSS 10 senza exploit noto va comunque trattato come urgente

Il punteggio CVSS descrive la gravità tecnica teorica, non la probabilità di attacco. Eppure, per questa classe di prodotti, il tempo che passa fra la pubblicazione della patch e i primi tentativi di sfruttamento si è accorciato: chi studia le correzioni (il cosiddetto patch diffing) può ricostruire la vulnerabilità in pochi giorni. Le tre condizioni che qui coincidono (assenza di autenticazione, raggiungibilità da rete, componenti di middleware che spesso sono esposti per integrare partner e fornitori) sono esattamente quelle che rendono una falla appetibile per chi attacca in modo opportunistico. Il consiglio pratico è quindi di non aspettare la conferma di uno sfruttamento: quando arriverà, la finestra utile sarà già chiusa.

Cosa significa per le aziende italiane

Oracle E-Business Suite, JD Edwards, PeopleSoft e Siebel sono presenti in molte realtà italiane: manifattura, distribuzione, sanità privata, università, enti pubblici e utility. Sono sistemi gestionali di lungo corso, spesso personalizzati, con cicli di aggiornamento lenti perché ogni patch richiede test funzionali su processi di contabilità, magazzino e paghe. È proprio questa inerzia, più della singola falla, il vero rischio: un ERP non aggiornato per due o tre cicli trimestrali accumula decine di vulnerabilità note.

Ci sono almeno tre letture utili per chi decide.

La prima riguarda la superficie esposta. Molte installazioni di E-Business Suite o JD Edwards sono raggiungibili da Internet per consentire a agenti, fornitori o dipendenti da remoto di usare moduli web. Se un'istanza è esposta, le CVE via HTTP di questo ciclo vanno trattate come priorità assoluta. Le interfacce T3 e IIOP del SOA Suite, invece, non dovrebbero mai essere raggiungibili da reti non fidate: se lo sono, il problema precede la patch.

La seconda riguarda i sistemi gestiti da terzi. Una quota rilevante dei gestionali Oracle in Italia è in hosting o in manutenzione presso system integrator. In questi casi la responsabilità giuridica resta del titolare, mentre la capacità tecnica di intervenire è del fornitore. Conviene chiedere per iscritto lo stato di applicazione del CPU di ottobre e le date previste, e non accontentarsi di rassicurazioni generiche.

La terza riguarda il contesto normativo. Per i soggetti essenziali e importanti NIS2, la gestione delle vulnerabilità e la sicurezza della catena di fornitura rientrano fra le misure di base richieste dalle determinazioni dell'ACN, e a ridosso della scadenza del 31 ottobre per i soggetti elencati nel 2025 la capacità di mostrare un ciclo di patching documentato è proprio il tipo di evidenza che ci si aspetta. Per il GDPR, un gestionale non aggiornato che contiene dati di dipendenti o clienti rende più difficile dimostrare «misure tecniche adeguate» (art. 32) in caso di violazione: l'omissione di una patch resa disponibile dal produttore è un elemento che il Garante tende a valutare con severità. Non è una conclusione automatica, ma è un rischio da mettere in conto.

Cosa fare subito

  • Censire tutte le istanze Oracle (E-Business Suite, Fusion Middleware, SOA Suite, Access Manager, JD Edwards, database, APEX, Essbase), comprese quelle in hosting o gestite da fornitori, indicando versione e patch level.
  • Ordinare per esposizione e gravità: prima le istanze raggiungibili da Internet e quelle con le sei CVE a punteggio 10, poi il resto; concordare le finestre di manutenzione con i responsabili applicativi.
  • Verificare le dipendenze: per E-Business Suite gli aggiornamenti di Oracle Database e di Fusion Middleware non sono nella matrice di rischio di EBS e vanno controllati separatamente.
  • Chiudere gli accessi non necessari ai protocolli HTTP, T3 e IIOP, con segmentazione di rete e regole di firewall. Sono misure temporanee: possono compromettere funzionalità applicative, vanno provate prima in ambiente di test e non sostituiscono la patch.
  • Preparare backup e rollback prima di applicare gli aggiornamenti, e verificare dopo l'installazione patch level, funzioni critiche e risultati di una nuova scansione.
  • Controllare i log alla ricerca di attività anomale sui componenti interessati, senza dare per scontata una compromissione ma senza escluderla.
  • Tenere traccia delle eccezioni: ogni sistema che non può essere aggiornato subito deve avere un responsabile, una scadenza e un controllo compensativo documentato.
  • Pianificare i prossimi appuntamenti: Oracle indica il 17 novembre, il 15 dicembre 2026 e il 16 febbraio 2027 come date di rilascio dei Critical Security Patch Update, mentre il prossimo CPU trimestrale è previsto il 19 gennaio 2027. Mettere queste date in calendario evita di inseguire le patch quando i sistemi sono già esposti.

Nota finale: Oracle fornisce patch solo per le versioni coperte da Premier o Extended Support. Chi ha ancora versioni fuori supporto non ha nulla da applicare e deve considerare la migrazione come un'azione di sicurezza, non solo di modernizzazione.