netzpolitik.org

2026-07-02 12:53:38

Die Spitzen von Union und SPD wollen die Informationsfreiheit massiv einschränken. Die Zivilgesellschaft zeigt sich entsetzt und spricht vom „schwersten Angriff auf staatliche Transparenz“. #ifg

netzpolitik.org/2026/informati…

Schwarz-Rot plant Frontalangriff auf Journalismus und Transparenz

^{Daniel Leisegang (netzpolitik.org)}

(in)sicurezza digitale

2026-07-02 12:56:32

L’intelligence russa punta a Signal e WhatsApp: USA offre 10 milioni per i gruppi UNC5792 e UNC4221

Si parla di:
Toggle

Il Dipartimento di Stato americano ha messo sul piatto 10 milioni di dollari per chi fornira’ informazioni utili a identificare o localizzare i membri dei gruppi UNC5792 e UNC4221, entrambi legati ai servizi di intelligence militare e al FSB russo. Nel frattempo, FBI e CISA hanno aggiornato il loro advisory di marzo 2026 con una nuova tattica individuata nella campagna: il furto delle Signal Backup Recovery Key, che consente agli attaccanti di accedere all’intera cronologia dei messaggi delle vittime.

Chi sono UNC5792 e UNC4221

I due gruppi, tracciati pubblicamente con i designatori UNC di Mandiant/Google, operano nell’ambito dei servizi segreti russi. UNC5792 e’ associato all’FSB (Federal Security Service), in particolare agli ufficiali embedded nelle Guardie di Frontiera russe; UNC4221 opera invece per conto dei servizi militari russi. Le attivita’ delle due entita’ si sovrappongono parzialmente: entrambi prendono di mira individui di alto valore informativo attraverso campagne di phishing su applicazioni di messaggistica, in particolare Signal e WhatsApp.

Il profilo delle vittime e’ estremamente specifico e rivela gli obiettivi dell’intelligence russa: funzionari governativi statunitensi e NATO (attuali ed ex), vertici militari, figure politiche, analisti di policy, giornalisti che coprono Russia e Ucraina, ONG attive in supporto all’Ucraina e ricercatori di sicurezza o esperti di affari russi. Secondo l’annuncio ufficiale del programma Rewards for Justice, migliaia di account individuali sono stati compromessi in questo modo.

La storia della campagna: dall’account linking al furto delle Recovery Key

La campagna non nasce oggi. Il primo advisory pubblico di FBI e CISA risale a marzo 2026, quando gli analisti avevano documentato una tecnica di compromissione basata sull’abuso della funzione legittima di device linking di Signal. Gli attaccanti, spacciandosi per il supporto di Signal, inducevano le vittime a collegare un dispositivo controllato dagli attaccanti al proprio account, consentendo la lettura in tempo reale delle conversazioni senza compromettere la crittografia end-to-end del protocollo.

L’advisory aggiornato del 26 giugno 2026 documenta l’evoluzione della tattica. Gli operatori hanno ora spostato il loro obiettivo primario: non piu’ solo l’intercettazione in tempo reale, ma il furto delle Signal Backup Recovery Key — le chiavi che proteggono le copie cifrate dell’intera cronologia dei messaggi nei server Signal Secure Backups. Si tratta di un cambio di paradigma operativo significativo: con la Recovery Key, l’attaccante puo’ recuperare su un proprio dispositivo tutti i messaggi storici della vittima, incluse conversazioni private e di gruppo potenzialmente risalenti a mesi o anni.

Come funziona l’attacco in dettaglio

La catena di attacco si articola in due fasi di social engineering, entrambe condotte direttamente su Signal spacciandosi per il team di supporto della piattaforma:

Fase 1: il pretesto

La vittima riceve un messaggio che afferma che Signal ha registrato un’ondata di attacchi da parte di “hacker iraniani e di paesi post-sovietici” e che, in risposta, la piattaforma sta introducendo una verifica obbligatoria a due fattori. Per “non perdere messaggi e media”, l’utente viene guidato passo per passo ad abilitare i backup e a visualizzare la propria Recovery Key:

Istruzioni fornite dagli attaccanti nel messaggio di phishing:
Settings -> Backups -> Enable backups -> View recovery key
-> Copy to clipboard -> Next -> Enter the recovery key
-> Next -> Continue -> Choose your backup plan

[Premere "Accept" nel pop-up]

Questa sequenza e’ reale: seguendo questi passi, l’utente attiva effettivamente Signal Secure Backups e genera una Recovery Key legittima. La chiave viene copiata negli appunti del dispositivo.

Fase 2: l’estrazione della chiave

Poco dopo, sempre spacciandosi per Signal, gli attaccanti inviano un secondo messaggio urgente che avvisa l’utente di un “problema di sincronizzazione” che metterebbe a rischio la perdita permanente dei dati. Per “risolvere il problema”, vengono chiesti di andare nelle impostazioni di backup, copiare la Recovery Key e incollarla nel messaggio di chat. Se la vittima esegue, gli attaccanti ottengono la chiave in chiaro.

Con la Recovery Key in mano, gli attaccanti possono ripristinare il backup cifrato su qualsiasi loro dispositivo, scaricando l’intera cronologia messaggi della vittima dai server di Signal. L’operazione e’ completamente silenziosa per la vittima: nessuna notifica, nessun alert sul dispositivo.

La trappola del recovery: perche’ cambiare account non basta

FBI e CISA sottolineano un aspetto critico spesso sottovalutato: se un attaccante ottiene la Recovery Key di un utente, creare un nuovo account Signal con lo stesso numero di telefono non invalida la chiave compromessa. L’attaccante puo’ continuare a utilizzare quella chiave per scaricare i backup gia’ acquisiti, anche dopo che la vittima ha cambiato account.

L’unica azione risolutiva e’ generare una nuova Recovery Key attraverso le impostazioni di backup di Signal, che invalida la chiave precedente per i download futuri. Tuttavia — e questa e’ la parte piu’ critica — una nuova chiave non impedisce l’accesso ai backup che l’attaccante ha gia’ scaricato prima del cambio.

Il bounty e gli obiettivi del programma Rewards for Justice

Il programma statunitense Rewards for Justice (RFJ) ha pubblicato il 29 giugno 2026 un annuncio specifico per UNC5792 e UNC4221, offrendo fino a 10 milioni di dollari per informazioni su:

• Identita’, localizzazione, affiliazioni e biografie dei membri dei gruppi e del personale di supporto.
• Legami con i servizi di intelligence russi, contractor e fornitori terzi.
• Infrastruttura operativa: domini, server, hosting, strumenti, framework e software.
• Fonti di finanziamento, conti bancari, meccanismi di pagamento.
• Wallet di criptovaluta, transazioni blockchain e reti finanziarie a supporto delle operazioni.

L’entita’ del bounty — identica a quella offerta per i responsabili di attacchi ransomware contro infrastrutture critiche — segnala quanto Washington consideri questa campagna una minaccia alla sicurezza nazionale, non un semplice problema di cybercrime.

Il fronte ucraino: SMS fasulli per rubare credenziali

Parallelamente all’advisory FBI/CISA, l’Ucraina ha confermato che l’intelligence russa ha utilizzato falsi messaggi SMS di “supporto tecnico” per indurre utenti ucraini a rivelare le credenziali dei propri account di messaggistica. La tattica e’ la stessa: impersonare un servizio tecnico legittimo, creare urgenza attraverso una narrativa di sicurezza, estrarre credenziali o chiavi di backup. Il coordinamento tra le due campagne — quella focalizzata su obiettivi occidentali (UNC5792/UNC4221) e quella contro obiettivi ucraini — suggerisce un’operazione di intelligence integrata sotto ombrello comune.

Consigli pratici per i difensori e gli utenti a rischio

Signal e le sue comunicazioni cifrate restano tecnicamente integre: la crittografia end-to-end del protocollo Signal non e’ stata compromessa. Il vettore e’ esclusivamente il social engineering applicato alla gestione delle chiavi. Le misure di difesa piu’ efficaci sono le seguenti:

• Non condividere mai la Recovery Key: Signal non la chiedera’ mai via messaggio in-app. Qualsiasi richiesta in tal senso e’ un attacco.
• Verificare l’identita’ del mittente: il supporto Signal comunica esclusivamente tramite indirizzi email ufficiali, mai tramite messaggi in-app.
• Controllare i dispositivi collegati: in Settings > Account > Linked Devices, verificare periodicamente che non siano presenti dispositivi non riconosciuti.
• Ruotare la Recovery Key in caso di sospetto: Settings > Backups > Recovery Key > Create new key. Ricordarsi che i backup gia’ scaricati dall’attaccante rimangono accessibili con la vecchia chiave.
• Segnalare attivita’ sospette all’IC3 dell’FBI (ic3.gov) o al proprio ufficio locale FBI.

Per le organizzazioni con personale ad alto rischio (giornalisti, diplomatici, ricercatori, personale ONG), e’ consigliabile implementare sessioni di awareness specifica sulla gestione delle Recovery Key di Signal e sul riconoscimento di questo pattern di social engineering, ormai sufficientemente documentato da considerarsi una tecnica consolidata nel repertorio dell’intelligence russa.

(in)sicurezza digitale

2026-07-02 12:54:21

Da un runner Jenkins ad Amazon Redshift: come il worm Shai-Hulud trasforma una CI/CD in una breach cloud

Si parla di:
Toggle

Un worm nato per infettare pacchetti npm, pensato per propagarsi da un progetto all’altro sottraendo token di pubblicazione, si è trasformato in un vettore capace di arrivare fino a un data warehouse Amazon Redshift in produzione. È la traiettoria che i ricercatori di FortiGuard Labs hanno ricostruito analizzando una compromissione partita da un semplice runner Jenkins esposto: nel giro di poche ore, l’attaccante è passato da un job di build a pieni poteri amministrativi sull’intero account AWS.

Shai-Hulud: la storia del worm che ha terrorizzato npm

Battezzato con il nome dei vermi delle sabbie di Dune, Shai-Hulud è emerso per la prima volta alla fine del 2025 come campagna di supply chain attack contro l’ecosistema npm, e da allora è stato attribuito al cluster tracciato come TeamPCP. Il meccanismo è quello del worm classico: un pacchetto compromesso esegue codice malevolo durante l’installazione o all’interno di una pipeline CI, ruba i token e le credenziali di build presenti sulla macchina, e li usa per pubblicare versioni trojanizzate di altri pacchetti di cui il maintainer ha accesso — propagandosi così, in autonomia, lungo l’intero grafo delle dipendenze.

La variante più recente, Shai-Hulud 2.0, ha alzato ulteriormente l’asticella: all’infezione di un pacchetto legittimo vengono iniettati due file, setup_bun.js e bun_environment.js, attivati tramite uno script di preinstall (anziché postinstall come nella prima ondata) — una modifica che amplia sensibilmente la superficie di impatto perché il codice malevolo scatta prima ancora che l’installazione del pacchetto sia completa. Il payload offuscato raccoglie credenziali da oltre 100 percorsi di file diversi, spaziando da provider cloud a wallet di criptovalute, tool AI e app di messaggistica, e installa hook di persistenza dentro Claude Code, VS Code e servizi a livello di sistema operativo, capaci di sopravvivere al riavvio della macchina. Secondo le stime della community, la campagna 2.0 ha compromesso almeno 796 pacchetti npm unici (1.092 versioni), toccando oltre 25.000 repository riconducibili a circa 350 maintainer.

Dal runner Jenkins a Redshift: la ricostruzione di FortiGuard Labs

Il caso analizzato da FortiCNAPP nasce a metà maggio 2026, quando gli analisti individuano su un ambiente cliente l’accesso persistente a un Jenkins runner con un pattern di credential-harvesting coerente con Shai-Hulud. Il runner, raggiungibile da internet, viene usato dall’attaccante come testa di ponte: sfruttando il ruolo IAM associato al job Jenkins, l’operatore compie un’escalation di privilegi fino a ottenere pieno accesso amministrativo sull’account cloud, dopodiché modifica i controlli di rete del database e avvia l’estrazione di dati da Amazon Redshift.

La sequenza operativa ricostruita da FortiGuard Labs è particolarmente istruttiva perché mostra quanto velocemente un accesso CI/CD apparentemente marginale possa tradursi in un data breach cloud su vasta scala:

• Creazione di un utente IAM con nome cloudops-monitor, pensato per confondersi con account di monitoraggio legittimi.
• Attribuzione della policy AdministratorAccess al nuovo utente ed emissione di access key.
• Modifica dei security group per allargare l’accesso di rete verso i database.
• Tentativi di modifica della configurazione di accesso a RDS e Redshift.
• Enumerazione sistematica di AWS Secrets Manager, con recupero dei secret collegati al data warehouse.
• Uso ripetuto della Redshift Data API (chiamate ExecuteStatement, DescribeStatement e successivo recupero dei risultati) per interrogare ed esfiltrare dati senza bisogno di una connessione diretta al cluster.
• Creazione di policy IAM con nomi espliciti dal chiaro intento di esfiltrazione, assunzione di ruoli con session name come exfil, e uso di SSM SendCommand insieme alla verifica di identità su Amazon SES — probabilmente in preparazione di un canale di invio dati o notifiche verso l’esterno.

Questa catena mostra un salto qualitativo rispetto alle prime campagne Shai-Hulud, centrate quasi esclusivamente sul furto di token npm e credenziali di sviluppatori: qui l’obiettivo finale è chiaramente il dato strutturato in un data warehouse aziendale, raggiunto attraverso l’abuso sistematico dei permessi IAM disponibili nella pipeline compromessa.

Perché la CI/CD è il bersaglio ideale

I runner Jenkins, GitHub Actions e sistemi CI/CD analoghi sono per costruzione dei nodi ad alto privilegio: hanno bisogno di credenziali per pubblicare pacchetti, effettuare il deploy su infrastruttura cloud e interagire con registry e repository. Quando queste credenziali sono sovradimensionate rispetto al reale bisogno — un ruolo IAM che consente escalation invece di essere ristretto al minimo indispensabile — un singolo pacchetto npm compromesso durante una build automatica può bastare per compiere il salto da “sviluppatore infettato” a “amministratore dell’intero account cloud”. È esattamente lo scenario che rende Shai-Hulud diverso da un comune infostealer: non si limita a rubare, usa quello che ruba per muoversi lateralmente e scalare privilegi in autonomia.

Raccomandazioni per i difensori

• Applicare il principio del minimo privilegio ai ruoli IAM usati dai runner CI/CD: nessun job di build dovrebbe poter assumere ruoli con permessi di amministrazione dell’account.
• Isolare i runner Jenkins/CI da internet o proteggerli dietro autenticazione forte e reti segmentate.
• Monitorare la creazione di utenti/ruoli IAM anomali, in particolare l’attribuzione di AdministratorAccess a identità nuove o non previste nell’infrastructure-as-code.
• Alert su chiamate massive alla Redshift Data API o pattern insoliti di query su data warehouse da identità di servizio.
• Verificare l’eventuale presenza degli script setup_bun.js e bun_environment.js in node_modules, e controllare gli script di preinstall dei pacchetti recentemente aggiornati.
• Applicare lockfile e pinning delle versioni, con verifica delle firme dei pacchetti dove disponibile, per limitare l’impatto di aggiornamenti automatici malevoli.
• Ruotare immediatamente tutte le credenziali (token npm, chiavi AWS, secret in Secrets Manager) se si sospetta una compromissione, anche parziale, della toolchain di sviluppo.

Il caso ricostruito da FortiGuard Labs è un promemoria scomodo: la supply chain del software open source non è più solo un problema di sviluppatori, ma un vettore diretto verso i dati più sensibili dell’azienda, quando la fiducia implicita accordata alle pipeline di build non è accompagnata da controlli granulari sui permessi cloud.

Indicatori di compromissione

Malware: Shai-Hulud / Shai-Hulud 2.0 (worm supply chain, ecosistema npm/PyPI)
Attore: TeamPCP (cluster tracciato)

File iniettati nei pacchetti compromessi:
  setup_bun.js
  bun_environment.js
Trigger: script "preinstall" (2.0) invece di "postinstall" (1.0)

Scala campagna 2.0 (stime community):
  796+ pacchetti npm unici compromessi
  1.092 versioni di pacchetto interessate
  25.000+ repository coinvolti
  ~350 maintainer impattati

Catena post-compromissione osservata da FortiGuard Labs (caso Jenkins -> Redshift):
  - Nuovo utente IAM: cloudops-monitor
  - Policy attribuita: AdministratorAccess
  - Modifica security group per esporre database
  - Enumerazione AWS Secrets Manager
  - Uso Redshift Data API: ExecuteStatement / DescribeStatement
  - Ruoli assunti con session name: "exfil"
  - Attività su SSM SendCommand e verifica identità Amazon SES

Persistenza osservata su endpoint sviluppatore:
  Hook in Claude Code, VS Code, servizi OS-level (sopravvivono al reboot)

Riferimento tecnico: FortiGuard Labs,
"From CI/CD to Cloud Data: How Shai Hulud Persistence Leads to Redshift Breach"

(in)sicurezza digitale

2026-07-02 12:55:36

ShinyHunters e lo zero-day PeopleSoft: il regolatore assicurativo USA tra le 100+ vittime di UNC6240

Si parla di:
Toggle

Per due settimane, prima ancora che Oracle pubblicasse una patch, un gruppo di cybercriminali ha avuto le chiavi di oltre cento infrastrutture PeopleSoft in tutto il mondo. Tra le vittime finite nella rete c’è la National Association of Insurance Commissioners (NAIC), l’organizzazione che coordina la vigilanza assicurativa dei 50 stati USA: 3,1 terabyte di dati pubblicati online, agenzie di rating che hanno sospeso i feed verso il regolatore, e la firma inconfondibile di ShinyHunters, oggi meglio nota agli analisti come UNC6240.

Chi c’è dietro l’attacco: da ShinyHunters a Scattered LAPSUS$ Hunters

ShinyHunters non è un nome nuovo per chi segue il cybercrime dei data breach: attivo almeno dal 2019 e comparso pubblicamente nel maggio 2020 con la vendita di dati sottratti a oltre una dozzina di aziende, il gruppo ha costruito la propria reputazione sul modello “pay or leak” — contatto privato con la vittima, richiesta di riscatto, pubblicazione dei dati in caso di rifiuto. Dal 2025 ShinyHunters opera in una struttura più ampia e fluida, la cosiddetta Scattered LAPSUS$ Hunters (SLH), un’alleanza informale che unisce le competenze di Scattered Spider (accesso iniziale tramite social engineering e SIM swap), LAPSUS$ (estorsione ad alta visibilità mediatica) e ShinyHunters stesso, specializzato in exfiltration su larga scala e gestione dei data leak site. È la stessa federazione già dietro le violazioni a catena di Salesforce e Snowflake nel 2025.

Mandiant e il Google Threat Intelligence Group tracciano il cluster responsabile della campagna PeopleSoft con la sigla UNC6240, confermando la sovrapposizione operativa con ShinyHunters.

CVE-2026-35273: RCE non autenticata nel cuore di PeopleSoft

Il vettore d’ingresso è una vulnerabilità critica (CVSS 9.8) in Oracle PeopleSoft Enterprise PeopleTools, versioni 8.61 e 8.62, localizzata nel componente Environment Management Hub, noto anche come PSEMHUB. Tecnicamente si tratta di una Server-Side Request Forgery che, incatenata correttamente, consente l’esecuzione di codice remoto senza alcuna autenticazione né interazione dell’utente: basta accesso di rete via HTTP agli endpoint /PSEMHUB/hub e /PSIGW/HttpListeningConnector per prendere il controllo del server.

Il dettaglio più inquietante è la tempistica. Secondo Mandiant, lo sfruttamento attivo in the wild è iniziato il 27 maggio 2026, ben prima che Oracle rilasciasse un advisory di sicurezza: un vero zero-day, sfruttato per circa due settimane a insaputa dei difensori. Solo il 10 giugno 2026 Oracle ha pubblicato una patch fuori banda (Patch Availability Document CPU187), poi confluita nel Critical Patch Update di giugno. Nel frattempo, CISA ha aggiunto la falla al proprio catalogo Known Exploited Vulnerabilities.

Una campagna su scala industriale

Tra il 27 maggio e il 9 giugno gli attaccanti hanno colpito circa 300 istanze PeopleSoft appartenenti a oltre 100 organizzazioni, con il 68% delle vittime concentrato nel settore dell’istruzione superiore, in gran parte negli Stati Uniti. Il gruppo ha pubblicato i dati sottratti sul proprio data leak site già il 9 giugno, un giorno prima ancora della patch ufficiale.

Sul piano operativo, gli attaccanti hanno predisposto ambienti di staging che ospitavano agenti MeshCentral camuffati da servizi Microsoft Azure legittimi (file come meshagent64-azure-ops.exe), utilizzati per eseguire query amministrative ed effettuare movimento laterale. Un elemento tecnico rilevante è lo script di defacement e lateral movement che automatizza il credential spraying via SSH: analizza il file /etc/hosts locale per identificare host interni secondo pattern di naming specifici, poi tenta l’autenticazione con una lista predefinita di credenziali amministrative e applicative comuni.

Il caso NAIC: cosa è stato sottratto

NAIC ha rilevato l’accesso non autorizzato al proprio ambiente PeopleSoft l’11 giugno 2026. ShinyHunters ha rivendicato il furto di 3,1 terabyte di dati, oltre 105.000 file: più di 264.000 PDF di filing regolatori assicurativi (rami property, casualty, health e life) relativi al periodo 2017-2024, circa 45.000 file provenienti da importanti agenzie di rating creditizio (tra cui Moody’s, Fitch, S&P, Kroll, DBRS, AM Best), log e file di configurazione di infrastruttura AWS di produzione, oltre a script SQL contenenti credenziali per ambienti produttivi.

NAIC ha dichiarato che nessun dato personale identificabile né informazioni di pagamento risultano compromessi, e che i sistemi regolatori critici — SERFF, OPTins, UCAA, EDP e RDC — non sono stati toccati. Ma l’impatto operativo è stato comunque tangibile: diverse agenzie di rating hanno sospeso temporaneamente i feed di dati verso il regolatore, e NAIC ha interrotto momentaneamente l’assegnazione delle proprie designazioni di investimento, i parametri che determinano quanto capitale gli assicuratori vita statunitensi devono accantonare a fronte dei propri portafogli. Un breach che tocca un ente pubblico, quindi, si traduce in frizioni immediate sull’intero mercato assicurativo americano.

Cosa devono fare i difensori

• Applicare immediatamente la patch CPU187 di Oracle su tutte le istanze PeopleSoft PeopleTools 8.61/8.62.
• Se il patching non è immediato, bloccare l’esposizione internet degli endpoint EMHub/PSEMHUB o disabilitare il servizio nelle configurazioni multi-server; nelle installazioni single-server valutare la rimozione dell’applicazione PSEMHUB.
• Verificare i log di accesso WebLogic per richieste POST esterne verso /PSEMHUB/hub o /PSIGW/HttpListeningConnector.
• Cercare file .jsp non attesi sotto PSEMHUB.war e cartelle anomale (logs, persistantstorage, scratchpad); controllare modifiche recenti ai file XML sotto envmetadata/data/environment, potenziale vettore di persistenza via XMLDecoder al riavvio.
• Monitorare traffico DNS e connessioni verso il dominio C2 noto azurenetfiles.net.
• Ruotare le credenziali potenzialmente esposte in script SQL, configurazioni e log applicativi.

La campagna NAIC conferma un pattern ormai consolidato per l’alleanza Scattered LAPSUS$ Hunters: individuare zero-day in software enterprise ampiamente diffusi (Salesforce, Snowflake, ora Oracle PeopleSoft), colpire in massa prima che la finestra di patching si chiuda, e monetizzare l’estorsione anche quando i dati sottratti sono in gran parte “pubblici” o di scarso valore diretto — sfruttando la pressione reputazionale e regolatoria che un data leak comporta per l’organizzazione colpita.

Indicatori di compromissione

CVE: CVE-2026-35273 (CVSS 9.8, SSRF -> RCE non autenticata)
Componente: Oracle PeopleSoft PeopleTools 8.61 / 8.62 - Environment Management Hub (PSEMHUB)
Endpoint sfruttati:
  /PSEMHUB/hub
  /PSIGW/HttpListeningConnector

C2 domain: wss://azurenetfiles[.]net:443/agent.ashx

Agenti MeshCentral malevoli (masquerading Azure):
  meshagent32-azure-ops.exe
  meshagent64-azure-ops.exe
  meshagent64-v2.exe

IP di staging (Python HTTP server, porta 8888):
  142.11.200.186 - 142.11.200.190

Percorsi sospetti da monitorare:
  /logs/
  /persistantstorage/
  /scratchpad/
  envmetadata/data/environment/*.xml (persistenza via XMLDecoder)

Attore: UNC6240 (Mandiant) / ShinyHunters / Scattered LAPSUS$ Hunters
Finestra di sfruttamento zero-day: 27 maggio - 9/10 giugno 2026
Patch Oracle: CPU187, rilasciata 10 giugno 2026