Il 24 agosto 2026 la CISA statunitense ha inserito nel catalogo KEV (Known Exploited Vulnerabilities) una falla con punteggio CVSS massimo che riguarda Oracle HTTP Server e il proxy plug-in di Oracle WebLogic Server. Si tratta di CVE-2026-21962, un difetto di controllo degli accessi che consente a un attaccante non autenticato, con la sola raggiungibilità via HTTP, di leggere, modificare o cancellare dati critici sui componenti esposti.

L'inserimento nel KEV non è una novità tecnica: la patch esiste da gennaio 2026. È invece la conferma ufficiale che la falla viene sfruttata in attacchi reali, e questo cambia radicalmente la priorità con cui va trattata.

I fatti verificati

  • CVE: CVE-2026-21962, CVSS 10.0, con scope change: la compromissione può propagarsi oltre il componente vulnerabile.
  • Prodotti e versioni colpite: Oracle HTTP Server e Oracle WebLogic Server Proxy Plug-in per Apache HTTP Server e IIS, versioni 12.2.1.4.0, 14.1.1.0.0 e 14.1.2.0.0.
  • Vettore: rete, via HTTP, senza credenziali né interazione dell'utente.
  • Impatto: creazione, cancellazione o modifica non autorizzata di dati critici, oltre all'accesso completo a tutti i dati raggiungibili dai componenti.
  • Patch: disponibile da Oracle da gennaio 2026 (Critical Patch Update di gennaio).
  • Sfruttamento attivo: confermato. CloudSEK, analizzando un honeypot ad alta interazione che simulava un WebLogic 14.1.1.0.0 fra il 22 gennaio e il 3 febbraio 2026, ha registrato tentativi immediati e diffusi contro CVE-2026-21962. Nella stessa raccolta compaiono attacchi verso falle WebLogic molto più vecchie: CVE-2020-14882/14883 (Console RCE), CVE-2020-2551 (IIOP RCE) e CVE-2017-10271 (WLS-WSAT RCE). GreyNoise ha osservato attività analoga.
  • Scadenza federale USA: le agenzie civili federali statunitensi devono rimediare entro il 27 agosto 2026.

Perché il proxy plug-in è il punto debole peggiore

Vale la pena capire dove si trova questo componente, perché è la ragione per cui la falla è più seria di quanto sembri. Il proxy plug-in di WebLogic è il modulo che si installa su Apache HTTP Server o su IIS per inoltrare le richieste verso il cluster WebLogic retrostante. In un'architettura tipica è quindi il pezzo che sta davanti a tutto: nella DMZ, esposto su Internet, dietro il load balancer, con una rotta privilegiata verso gli application server che contengono la logica di business e i dati.

Questo produce due conseguenze pratiche. La prima è che il componente vulnerabile è spesso quello meno inventariato: viene installato una volta, dall'integratore, come "modulo del web server", e poi non compare in nessun CMDB come prodotto Oracle da patchare. La seconda è che lo scope change non è un tecnicismo del punteggio CVSS: un attaccante che compromette il proxy si trova esattamente nel punto in cui il traffico applicativo viene instradato, con la possibilità di raggiungere backend che nessuno considerava esposti.

Cosa significa per le aziende italiane

WebLogic non è tecnologia di frontiera, ed è proprio questo il problema. In Italia lo stack Oracle Fusion Middleware regge una quota consistente di portali della pubblica amministrazione, sistemi bancari e assicurativi, gestionali industriali e piattaforme sanitarie regionali. Sono ambienti spesso ereditati, con versioni congelate perché "l'applicativo sopra non è certificato per aggiornare", e con finestre di manutenzione negoziate mesi prima.

Da consulente, il pattern che vedo più spesso è questo: l'organizzazione sa di avere WebLogic, ma non sa di avere il proxy plug-in su un Apache che qualcuno ha configurato nel 2019. La superficie esposta è reale e non è mappata.

C'è poi un elemento temporale che merita attenzione. La patch è di gennaio, lo sfruttamento è documentato da febbraio-marzo, l'inserimento nel KEV arriva ad agosto. Chi ha aspettato "il segnale ufficiale" per considerare urgente questa CVE ha lasciato scoperti sette mesi. È un promemoria concreto sul fatto che il catalogo KEV è un indicatore in ritardo, non un sistema di allerta precoce: serve a stabilire priorità e a giustificare interventi fuori finestra, non a decidere se una CVSS 10 non autenticata su un componente esposto vada trattata come urgente.

Sul piano normativo, chi rientra nel perimetro NIS2 come soggetto essenziale o importante deve poter dimostrare un processo di gestione delle vulnerabilità che comprenda la valutazione tempestiva degli avvisi e la tracciabilità delle decisioni di rimedio. Un ritardo di mesi su una CVSS 10 attivamente sfruttata su un sistema esposto è difficile da difendere in sede di audit, tanto più che il bollettino CISA e gli avvisi del CSIRT Italia sono pubblici. Se il sistema tratta dati personali, un'eventuale compromissione fa scattare anche gli obblighi dell'articolo 33 del GDPR, con notifica al Garante entro 72 ore dalla conoscenza del fatto.

Cosa fare subito

  • Inventariare dove è installato il proxy plug-in, non solo dove è installato WebLogic. Sui web server frontali cercare i moduli mod_wl_ohs.so / mod_wl.so su Apache e l'ISAPI filter corrispondente su IIS.
  • Verificare la versione: 12.2.1.4.0, 14.1.1.0.0 e 14.1.2.0.0 sono le linee interessate. Applicare il Critical Patch Update Oracle che corregge CVE-2026-21962.
  • Se la patch non è applicabile subito, limitare l'esposizione: il plug-in non dovrebbe essere raggiungibile da Internet senza un WAF davanti, e le rotte amministrative WebLogic (/console, /wls-wsat, /em) non dovrebbero essere pubblicate affatto.
  • Chiudere anche il debito vecchio: se l'honeypot CloudSEK riceve ancora tentativi su CVE-2017-10271 e CVE-2020-14882, significa che qualcuno là fuori è ancora vulnerabile. Verificare che quelle patch ci siano.
  • Cercare tracce di compromissione nei log del web server frontale: richieste anomale verso path di gestione, risposte 200 su URL che non dovrebbero esistere, JSP o file caricati di recente nelle directory di deploy.
  • Segmentare: il proxy non deve poter raggiungere i backend oltre le porte applicative strettamente necessarie.
  • Documentare la decisione: data di valutazione, rischio accettato, mitigazione applicata e data prevista per la patch definitiva. È la parte che serve in caso di audit NIS2, ed è quella che nella pratica viene saltata.

La scadenza del 27 agosto vale formalmente solo per le agenzie federali statunitensi, ma indica bene l'urgenza tecnica: chi ha un proxy plug-in Oracle esposto e non patchato dovrebbe trattarla come una scadenza propria.