Come preferisci leggerla?
Stessa edizione, spiegata senza gergo — e altrettanto fedele. Non è un riassunto sbrigativo: un controllo indipendente verifica che la versione divulgativa resti fedele all'originale, senza perdere né alterare nulla.
Micron supera i 1.000 miliardi di dollari di capitalizzazione trainata dalla penuria di memoria per l'AI
Il 26 maggio 2026 Micron è entrata nel club da mille miliardi di dollari dopo un balzo del 19% in una sola seduta, spinta dalla domanda di memoria ad alta banda per l'AI e da un upgrade record di UBS.
Micron Technology ha superato per la prima volta i 1.000 miliardi di dollari di capitalizzazione il 26 maggio 2026, dopo un balzo di circa il 19% in una sola seduta — il miglior rialzo giornaliero dal 2011 — con il titolo che ha chiuso attorno ai 895 dollari. Il produttore di Boise diventa così l'undicesima maggiore società quotata statunitense, superando Walmart per valore di mercato, dopo aver più che triplicato la quotazione dall'inizio dell'anno.
Il catalizzatore immediato è stato un upgrade record: l'analista di UBS Timothy Arcuri ha triplicato il prezzo obiettivo da 535 a 1.625 dollari, il più alto di Wall Street. Ma la spinta di fondo è strutturale e arriva dalla memoria ad alta banda (HBM), componente essenziale per l'addestramento e l'inferenza dell'AI. Micron controlla circa il 21% del mercato HBM e, insieme agli unici altri due produttori su scala — Samsung e SK Hynix — ha già esaurito la capacità HBM per tutto il 2026, riuscendo a coprire solo il 50-65% della domanda di medio termine dei clienti.
La scarsità ha effetti sui prezzi: secondo Counterpoint Research i prezzi della memoria sono saliti dell'80-90% da inizio anno. Le espansioni produttive a Singapore e Taiwan non aggiungeranno capacità prima della fine del 2027, e sempre secondo Counterpoint Research il sollievo sull'offerta non arriverà prima del quarto trimestre 2027. Come riportato da gagadget e da Crypto Briefing, il mercato sta riconoscendo che il vincolo dell'AI non è solo la GPU, ma anche la memoria che la alimenta.
Perché conta
- IMPRENDITORI · INGEGNERI ICT / IT MANAGER: Con la capacità HBM già esaurita per il 2026 e la DRAM in forte tensione di offerta, e con i prezzi della memoria su dell'80-90%, l'approvvigionamento di memoria diventa una variabile diretta di costo, pianificazione e resilienza. Chi acquista server, GPU o capacità AI deve mettere in conto contratti pluriennali, lock-in sui pochi fornitori (Micron, Samsung, SK Hynix) e una penuria che non si allenterà prima del 2027-2028. Per chi gestisce roadmap e budget IT, significa anticipare gli ordini e valutare l'impatto del rincaro memoria sul TCO dell'infrastruttura AI.
Drupal core, SQL injection critica (CVE-2026-9082): sfruttamento attivo e patch imposta da CISA
Una falla di SQL injection non autenticata nel core di Drupal è già attaccata in massa. Colpisce solo i siti su PostgreSQL, ma CISA l'ha inserita nel catalogo KEV con scadenza di patch federale al 27 maggio.
Il team di sicurezza di Drupal ha pubblicato l'advisory SA-CORE-2026-004 per CVE-2026-9082, una vulnerabilità di SQL injection nella API di astrazione del database del core. Il difetto risiede nel gestore delle condizioni di EntityQuery per PostgreSQL: chiavi di array PHP controllate dall'utente raggiungevano la costruzione dei placeholder SQL senza sanitizzazione. La correzione applica array_values() per scartare le chiavi fornite dall'attaccante. La falla è sfruttabile da remoto e senza autenticazione, con possibile information disclosure, escalation di privilegi e in alcuni casi esecuzione di codice. La scoperta è attribuita a Michael Maturi, ricercatore di Google/Mandiant.
Un dettaglio decisivo sul perimetro: sono vulnerabili solo i siti con backend PostgreSQL; MySQL, MariaDB e SQLite non lo sono. Tenable riporta ancora un CVSS di 6.5, ma NVD/Drupal CNA indica oggi CVSS 9.8 ("Critical"). Il punteggio di rischio interno di Drupal era 20/25 nell'advisory iniziale ed è stato aggiornato a 23/25 il 22 maggio, dopo i tentativi di exploit in the wild ("Highly Critical"). Le versioni corrette includono 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10 e 10.4.10.
La patch è uscita il 20 maggio; l'advisory, inizialmente classificato come rischio teorico, è stato aggiornato il 22 maggio quando i tentativi di exploit sono comparsi in the wild. Imperva ha osservato oltre 15.000 tentativi di attacco contro quasi 6.000 siti in 65 Paesi nei primi due giorni, concentrati su gaming e servizi finanziari (~50%). Per ora gli attacchi sono prevalentemente in fase di ricognizione e validazione. CISA ha inserito la falla nel catalogo KEV imponendo alle agenzie federali (FCEB) di applicare la patch entro il 27 maggio 2026.
Perché conta
- INGEGNERI ICT / IT MANAGER: Impone un'azione d'emergenza immediata: aggiornare subito ogni installazione Drupal su PostgreSQL alle versioni corrette, perché lo sfruttamento è massivo e indiscriminato (quasi 6.000 siti presi di mira) e la scadenza CISA è un riferimento di compliance anche fuori dal perimetro federale. Soprattutto, ricorda di mappare il backend del database come parametro di rischio a sé: lo stesso applicativo è esposto o sicuro a seconda che giri su PostgreSQL o su MySQL/MariaDB, quindi l'inventario degli asset deve censire il motore DB, non solo la versione dell'app.
Ghost CMS, una SQL injection nella Content API piega oltre 700 siti per campagne ClickFix
La falla CVE-2026-26980 (CVSS 9.4), corretta a febbraio ma lasciata senza patch su centinaia di installazioni, ha permesso di rubare le Admin API Key e trasformare siti fidati — Harvard, Oxford, DuckDuckGo — in trappole per distribuire malware ai loro lettori.
Una vulnerabilità critica in Ghost CMS, la piattaforma di pubblicazione usata da oltre 100.000 siti, è stata sfruttata in massa per compromettere più di 700 domini e usarli come vettori di distribuzione malware. La falla, tracciata come CVE-2026-26980 e valutata CVSS 9.4 secondo GitHub/CNA (NVD le assegna invece 7.5), è una SQL injection nella Content API: un attaccante non autenticato può leggere qualsiasi tabella del database — incluse Admin API Key, hash bcrypt delle password e session secret — iniettando payload nei parametri filter=slug o order=slug. Colpisce le versioni dalla 3.24.0 alla 6.19.0; la patch 6.19.1 è stata pubblicata da Ghost il 16 febbraio 2026, mentre la CVE è stata pubblicata su NVD il 19 febbraio 2026.
La campagna, rilevata da inizio maggio, segue una catena ClickFix: rubata l'Admin API Key, gli attaccanti usano l'API legittima per modificare in blocco gli articoli e iniettare loader JavaScript a fondo pagina. Ai visitatori dei siti compromessi viene mostrata una finta pagina di verifica Cloudflare che li invita a incollare un comando nel prompt di Windows. Il comando scarica payload come DLL loader, dropper JavaScript e un eseguibile Electron chiamato UtilifySetup.exe. Tra le vittime figurano Harvard University, Oxford University, Auburn University e DuckDuckGo. Secondo l'analisi di XLab (QiAnXin), almeno due gruppi distinti operano in parallelo, contendendosi gli stessi siti infetti; circa la metà delle vittime sono blog personali, il resto realtà di software, AI e criptovalute. La remediation impone l'aggiornamento ad almeno 6.19.1, la rotazione di tutte le chiavi e credenziali e la rimozione degli script iniettati a livello di database.
Perché conta
- INGEGNERI ICT / IT MANAGER: Una patch disponibile da febbraio non basta se non è applicata: aggiornare a Ghost ≥6.19.1 è necessario ma non sufficiente, perché le Admin API Key potrebbero essere già state esfiltrate. Serve ruotare tutte le chiavi e credenziali, verificare l'integrità delle pagine pubblicate e bonificare gli script iniettati direttamente nel database.
- UTENTI FINALI: Il rischio arriva da siti che si considerano affidabili: una pagina di un'università o di un servizio noto può mostrare una falsa verifica Cloudflare. La regola difensiva è netta — nessun sito legittimo chiede mai di incollare e lanciare comandi nel prompt o nel terminale per "dimostrare di non essere un robot".
GitHub ruota la signing key di GitHub Enterprise Server dopo un accesso non autorizzato ai repository interni
Un'estensione VS Code avvelenata (Nx Console) ha compromesso il device di un dipendente, esponendo circa 3.800 repository interni. GitHub impone agli amministratori GHES self-hosted la rotazione della chiave di firma.
GitHub ha dichiarato di aver rilevato e contenuto il 18 maggio 2026 la compromissione del device di un dipendente causata da una versione avvelenata dell'estensione VS Code Nx Console. Secondo la copertura di GovInfoSecurity, l'estensione malevola è rimasta pubblicata sul Visual Studio Marketplace per appena 18 minuti prima di essere rimossa, ma è bastata a innescare l'incidente.
L'attaccante ha rivendicato l'accesso a circa 3.800 repository, una cifra che GitHub definisce "directionally consistent" con la propria indagine. Sono stati toccati solo repository interni di GitHub, alcuni dei quali contenevano "excerpts of support interactions"; l'azienda afferma di non avere "no evidence" di impatto sui dati dei clienti. GitHub.com e GitHub Enterprise Cloud non risultano coinvolti.
L'azione operativa pesa invece sugli amministratori di GitHub Enterprise Server (GHES) self-hosted. Il CISO Alexis Wales ha chiesto di ruotare tutte le chiavi, inclusa la signing key di GHES. Gli amministratori devono eseguire uno script ufficiale (digest SHA256 3009bf5c…6b43) che rigenera la chiave pubblica GPG sia sull'account admin sia su root. I percorsi sono distinti per topologia a nodo singolo e per cluster/HA (ghe-cluster-each). Le patch future saranno firmate con la nuova chiave: senza rotazione gli upgrade falliranno con l'errore "The file provided is not a valid GitHub Enterprise Server package".
Perché conta
- INGEGNERI ICT / IT MANAGER: Chi gestisce istanze GHES self-hosted deve agire subito: ruotare la signing key seguendo lo script ufficiale (verificandone il digest SHA256) prima dei prossimi aggiornamenti, altrimenti le patch verranno rifiutate. L'incidente è anche un promemoria di supply chain: le estensioni IDE di terze parti sono un vettore reale di compromissione degli endpoint sviluppatori, e meritano policy di approvazione e monitoraggio al pari di qualsiasi altra dipendenza.
Papa Leone XIV dedica la prima enciclica all'intelligenza artificiale e condanna l'AI in guerra
Nella sua prima enciclica, Magnifica humanitas, Papa Leone XIV pone la persona umana al centro dell'era dell'AI. La tecnologia «non è mai neutrale», l'intelligenza artificiale non può avere supremazia sull'uomo e il suo impiego bellico va condannato.
Papa Leone XIV ha presentato la sua prima enciclica, Magnifica humanitas (circa 42.300 parole), dedicata alla salvaguardia della persona umana nell'era dell'intelligenza artificiale. Il documento porta la data del 15 maggio 2026, ma il Pontefice lo ha illustrato di persona in Vaticano il 25 maggio: un gesto inusuale, di norma delegato ai cardinali. Ad assistere c'era una platea di esperti del settore, tra cui il cofondatore di Anthropic Chris Olah.
Il testo non descrive la tecnologia come nemica dell'uomo né come intrinsecamente cattiva. Avverte però che «non è mai neutrale, perché assume le caratteristiche di chi la progetta, la finanzia, la regola e la usa». La scelta di fondo è resa con due immagini bibliche: costruire una nuova torre di Babele oppure edificare la città in cui Dio e l'uomo abitano insieme. L'AI, priva di esperienze, valori e sentimenti, non può e non deve assumere un ruolo di responsabilità e di supremazia sull'intelligenza umana. Il rischio, altrimenti, è una civiltà «meno umana» e la svalutazione del lavoro.
Come sintetizza Vatican News, l'enciclica denuncia che l'AI amplifica il potere di chi già dispone di risorse economiche, competenze e accesso ai dati. Sostiene poi che la proprietà dei dati non può restare solo in mani private e invoca strumenti regolatori adeguati. Condanna inoltre in modo esplicito l'uso dell'AI in guerra: il minore controllo umano sulle armi rende più facile avviare i conflitti. Arriva persino a definire «superata» la tradizionale dottrina della guerra giusta. È la prima enciclica pubblicata senza una versione ufficiale in latino e si inserisce nel solco della dottrina sociale avviata da Leone XIII. La presa di posizione è stata ripresa a livello internazionale come il primo grande testo magisteriale interamente dedicato all'AI.
Perché conta
- UTENTI FINALI: Offre a centinaia di milioni di persone una cornice morale condivisa per decidere quanto delegare ai sistemi automatici: invita a non cedere all'eccesso di affidamento e a presidiare dignità e relazioni umane là dove l'AI rischia di sostituirle.
- IMPRENDITORI: Il richiamo alla tecnologia «mai neutrale», alla concentrazione di potere e dati e al valore del lavoro umano fissa aspettative etiche e reputazionali — e anticipa pressioni regolatorie — su come progettare, governare e comunicare l'adozione dell'AI in azienda.
Data breach 7-Eleven: 185.000 persone colpite e l'estorsione di ShinyHunters
7-Eleven notifica oltre 185.000 persone dopo un'intrusione di ShinyHunters partita da un server con i documenti dei franchisee; il gruppo rivendica oltre 600.000 record Salesforce e un tentativo di estorsione.
7-Eleven ha confermato un data breach che ha esposto i dati personali di oltre 185.000 persone. Secondo il chief information security officer Jim Kastle, l'8 aprile 2026 gli aggressori hanno violato un server interno contenente i documenti dei franchisee. Si tratta dei moduli presentati durante il processo di candidatura all'apertura di un punto vendita (TechCrunch).
I dati compromessi includono nomi, date di nascita, indirizzi, numeri di telefono ed email. Per un sottoinsieme di interessati sono stati esposti anche codici fiscali statunitensi (Social Security number) e numeri di patente, come documentato nelle notifiche all'ufficio dell'attorney general del Massachusetts. Have I Been Pwned quantifica gli account esposti in circa 185.300; il filing del Maine riporta 2 residenti del Maine e non indica un totale complessivo (SecurityWeek).
L'attacco è rivendicato da ShinyHunters, gruppo specializzato in hack-and-extortion che dalla metà del 2025 prende di mira le istanze Salesforce di grandi organizzazioni. Tra le organizzazioni precedentemente collegate o rivendicate dal gruppo figurano Google, Cisco e la Commissione europea. La rivendicazione che riguarda Cisco non è confermata pubblicamente. Il gruppo afferma di aver sottratto oltre 600.000 record Salesforce con PII e dati aziendali interni. Aveva fissato al 21 aprile la scadenza per il riscatto, minacciando la pubblicazione (SecurityAffairs). Resta una discrepanza tra i ~600.000 record rivendicati dagli attaccanti e i ~185.000 individui finora confermati come colpiti. Mancato il pagamento, i dati sono stati diffusi online e indicizzati da Have I Been Pwned.
Perché conta
- IMPRENDITORI: Il caso mostra il costo reale di un breach a conto economico: notifiche regolamentari in più stati, esposizione a contenziosi e a richieste estorsive, danno reputazionale. E l'incidente parte dai dati di candidati e franchisee, non dei clienti: anche le informazioni di chi propone una partnership o una fornitura sono superficie d'attacco e rischio di compliance.
- INGEGNERI ICT / IT MANAGER: 7-Eleven conferma l'accesso a sistemi per i documenti dei franchisee; ShinyHunters sostiene, senza conferma dell'azienda, un coinvolgimento di Salesforce. I dati di candidati e fornitori vanno segmentati, minimizzati e protetti come quelli dei clienti. Il modus operandi di ShinyHunters contro le piattaforme SaaS conferma che la postura di sicurezza deve estendersi ai sistemi di terze parti e ai dataset 'secondari' spesso trascurati.
OpenAI rilascia la workload identity federation e apre il tunnel MCP sicuro per l'enterprise
Sulla developer platform di OpenAI i workload fidati scambiano token OIDC per credenziali effimere, senza più API key statiche. Un tunnel solo-uscita collega i server MCP privati senza esporli a Internet.
Il 26 maggio 2026 OpenAI ha rilasciato la workload identity federation sulla sua developer platform. Secondo il changelog, i workload fidati possono "exchange externally issued identity tokens for short-lived OpenAI access tokens without storing long-lived API keys". In pratica un servizio scambia un token OIDC emesso dalla propria infrastruttura con un access token OpenAI a vita breve. Così elimina le API key statiche dai sistemi di produzione. I provider di identità supportati sono Kubernetes, AWS, Microsoft Azure, Google Cloud e GitHub Actions.
La guida ufficiale descrive quattro componenti. Un workload identity provider definisce l'emittente OIDC fidato (URL, audience, fonte delle chiavi). Un mapping autorizza specifici attributi del token a generare credenziali per un dato service account. Seguono poi lo scambio del token e l'uso del token OpenAI come bearer per le chiamate API. Le trasformazioni degli attributi usano Common Expression Language (CEL); la configurazione avviene in Organization Settings > Security e gli scope dell'Admin API non sono assegnabili ai mapping.
Pochi giorni prima, il 19 maggio, OpenAI aveva introdotto per i clienti enterprise il Secure MCP Tunnel. Il tunnel consente a ChatGPT web, Codex, Responses API e AgentKit di raggiungere server MCP privati o on-prem tramite un tunnel-client ospitato dal cliente. Il collegamento è una connessione HTTPS solo in uscita. Il tunnel-client interroga in long-poll il lavoro in coda e lo inoltra al server locale, così che — come recita la guida — "the private MCP server does not need a public listener". Non servono porte in ingresso aperte; sono previsti mTLS opzionale, proxy in uscita e CA bundle personalizzati.
Perché conta
- LLM BUILDER/DEV: Per chi costruisce agenti e servizi, le credenziali effimere agganciate all'identità del workload tolgono dal codice e dai deploy le API key statiche da custodire e ruotare. Il Secure MCP Tunnel permette inoltre di collegare agli agenti server MCP privati o on-prem senza pubblicarli su Internet.
- INGEGNERI ICT / IT MANAGER: La federazione OIDC si aggancia all'infrastruttura già in uso (Kubernetes, AWS, Azure, GCP, GitHub Actions) e sposta il controllo dei segreti a livello di organizzazione, riducendo la superficie d'attacco delle credenziali a lunga durata. Il tunnel solo-uscita evita di aprire porte inbound per integrare sistemi interni, preservando il perimetro di rete.