Il Patch Tuesday di giugno 2026 ha stabilito un nuovo record assoluto: Microsoft ha rilasciato aggiornamenti di sicurezza per ben 208 CVE, superando il precedente record e portando con sé 6 zero-day, di cui uno attivamente sfruttato in attacchi reali. Per i sistemisti, questo ciclo di patch è tra i più critici dell’anno: ci sono falle wormable nel kernel, bypass multipli di BitLocker, RCE su Hyper-V, AKS e DHCP, e una vulnerabilità Exchange già sfruttata in produzione.

Il quadro generale

Delle 208 vulnerabilità corrette, 33 sono classificate Critical. La distribuzione per tipologia:

• 65 Elevation of Privilege
• 55 Remote Code Execution
• 30 Information Disclosure
• 27 Spoofing
• 19 Security Feature Bypass
• 7 Denial of Service

Il conteggio esclude le 360 CVE ereditate da Chromium/Edge e le falle in servizi cloud come Exchange Online e Microsoft Graph, già patchate in precedenza nel mese.

I sei zero-day

CVE-2026-42897 — Exchange Server Spoofing (attivamente sfruttata)

L’unica zero-day già in uso attivo. Un attaccante invia una email costruita ad hoc: se la vittima la apre in Outlook Web Access, viene eseguito JavaScript arbitrario nel browser. Microsoft ha distribuito mitigazioni tramite il servizio Exchange Emergency Mitigation (EEMS). Verificare che EEMS sia abilitato di default; la patch completa è in lavorazione. Azione immediata richiesta.

CVE-2026-45586 — Windows CTFMON GreenPlasma (EoP)

Divulgata da Nightmare Eclipse, permette di ottenere un shell SYSTEM sfruttando una link following errata nel Windows Collaborative Translation Framework. Prima di una serie di zero-day rilasciate dallo stesso ricercatore in protesta contro il bug bounty Microsoft.

CVE-2026-45585 — BitLocker YellowKey (Security Feature Bypass)

Con accesso fisico al dispositivo, un attaccante inserisce file costruiti su USB o partizione EFI e, avviando in WinRE tenendo CTRL, ottiene accesso illimitato al disco cifrato. Colpisce sistemi con BitLocker in modalità TPM-only. Mitigazione: abilitare TPM+PIN.

CVE-2026-50507 — BitLocker bitskrieg (Security Feature Bypass)

Secondo bypass BitLocker, divulgato da Jonas Lykkegaard. La patch potrebbe causare l’errore “A required file couldn’t be accessed because your BitLocker key wasn’t loaded correctly”. Il fix:

reagentc /disable
reagentc /enable

CVE-2020-17103 — Cloud Files Mini Filter Driver Mini-Plasma (EoP)

CVE originariamente del 2020, segnalata da James Forshaw (Google Project Zero). Sembrava già corretta nel dicembre 2020, ma Nightmare Eclipse ha dimostrato che la vulnerabilità era ancora sfruttabile. L’update di giugno 2026 la chiude definitivamente.

CVE-2026-49160 — HTTP/2 Bomb DoS su HTTP.sys

Abusa della compressione degli header HTTP/2 per forzare il server ad allocare quantità sproporzionate di memoria con pochissimi dati in ingresso. Microsoft ha introdotto la chiave di registro MaxHeadersCount per limitare il numero di header accettati (KB5102602):

; HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
; DWORD: MaxHeadersCount = 100

Le CVE Critical più rilevanti per l’infrastruttura

CVE-2026-45657 — Windows Kernel RCE (CVSS 9.8, wormable)

È la vulnerabilità che preoccupa di più. Una use-after-free nel kernel legata all’elaborazione del traffico TCP/IP permette a un attaccante non autenticato di eseguire codice da remoto, senza interazione utente. Il vettore CVSS (AV:N/AC:L/PR:N/UI:N) e la classificazione wormable significa che un exploit funzionante potrebbe autopropag arsi tra macchine sulla stessa rete. Sistemi colpiti: Windows 11 (23H2, 24H2, 25H2, 26H1) e Windows Server 2022/2025 incluso Server Core. I ricercatori stimano la finestra per un exploit pubblico in giorni, non settimane. Priorità assoluta.

CVE-2026-32193 — Azure Kubernetes Service Container Escape (Critical)

Path traversal in AKS che permette a un container configurato con hostNetwork: true di evadere il container e ottenere il controllo del worker node. Chi gestisce cluster AKS deve verificare aggiornamenti disponibili:

az aks upgrade --resource-group myRG --name myCluster --kubernetes-version latest

CVE-2026-44815 — DHCP Client Service RCE (Critical)

RCE nel client DHCP di Windows, sfruttabile da un attaccante che controlla un server DHCP malevolo in rete. Rischio elevato in ambienti con BYOD o reti ospiti non segregate.

CVE-2026-45641 / CVE-2026-47652 — Hyper-V RCE (Critical)

Due falle di esecuzione di codice in Hyper-V. Su hypervisor il patching è prioritario: una compromissione può portare all’escape delle VM e alla compromissione dell’host.

CVE-2026-45648 — Active Directory Domain Services RCE (Critical)

RCE nei Domain Controller. Qualunque falla RCE su DC va trattata con la massima urgenza: una compromissione equivale a quella dell’intero dominio.

CVE-2026-47291 — HTTP.sys RCE (Critical)

RCE nel driver HTTP.sys, separata dalla HTTP/2 Bomb. Colpisce tutti i sistemi che espongono servizi HTTP inclusi IIS e applicazioni che usano direttamente HTTP.sys.

Strategia di deployment

Con 208 CVE e sei zero-day, non c’è spazio per ritardi. Alcune linee guida pratiche:

1. Controllare ADV990001: verificare che il Servicing Stack Update (SSU) sia installato. È il prerequisito per l’installazione corretta di tutti gli altri aggiornamenti.
2. Exchange prima: CVE-2026-42897 è attivamente sfruttata. Applicare le mitigazioni EEMS immediatamente.
3. Domain Controller: CVE-2026-45648 su AD DS è Critical. Test in ambiente non-prod, poi deployment rapido su DC.
4. BitLocker — leggere le release notes: CVE-2026-50507 può richiedere il fix manuale con reagentc. Testare prima del rollout su larga scala.
5. Hotpatch su Azure VM: Microsoft ha reso generalmente disponibile l’hotpatching per Azure VM (Linux e Windows Server), che applica le patch kernel senza riavvio. Nei workload Azure, è la modalità preferita per ridurre i downtime.

Conclusione

Il Patch Tuesday di giugno 2026 non è un mese da rimandare. La CVE-2026-45657 (kernel wormable CVSS 9.8), la zero-day Exchange in produzione, i doppi bypass BitLocker e la falla AKS compongono un quadro che richiede azione rapida e pianificata. Scaricare gli update, verificare l’SSU, prioritizzare Exchange e DC, e monitorare per eventuali regressioni post-patch, specialmente per il caso BitLocker/reagentc.

Fonte: BleepingComputer — Microsoft June 2026 Patch Tuesday fixes 6 zero-days, 200 flaws | Zero Day Initiative — June 2026 Security Update Review

Perché NTLM è ancora vivo (e quanto è difficile eliminarlo)

In ambienti Active Directory, Kerberos è il protocollo di autenticazione preferito da Microsoft da oltre vent’anni. Eppure, NTLM continua a essere presente in quasi ogni infrastruttura Windows perché esistono tre scenari in cui Kerberos non funziona e il sistema ricade inevitabilmente su NTLM:

• Il client non ha visibilità di rete diretta su un Domain Controller (DC)
• L’autenticazione coinvolge un account locale invece di un account di dominio
• L’ambiente è un workgroup o una macchina standalone, senza infrastruttura di dominio

Sono esattamente questi tre gap che Microsoft sta affrontando con IAKerb e LocalKDC, due funzionalità oggi in public preview su Windows Insider (Canary Channel) e previste in disponibilità generale su Windows 11 24H2 e Windows Server 2025 nella seconda metà del 2026.

IAKerb: Kerberos anche senza visibilità sul Domain Controller

IAKerb (Initial and Pass-Through Authentication using Kerberos) è un meccanismo definito nella bozza IETF draft-ietf-kitten-iakerb-03. Si implementa come sotto-meccanismo GSS-API, inserendosi nel protocollo SPNEGO che Windows già utilizza per la negoziazione dell’autenticazione.

Nel flusso Kerberos standard, il client deve contattare direttamente il KDC (Key Distribution Center, il servizio che gira su ogni DC) sulla porta TCP/UDP 88 per ottenere un ticket prima di potersi autenticare su un servizio. Se nessun DC è raggiungibile, Kerberos fallisce e Windows scade su NTLM.

IAKerb risolve questo problema rendendo il server di destinazione un proxy trasparente per i messaggi Kerberos. Il client tunnel i messaggi Kerberos all’interno della connessione esistente verso il server applicativo (ad esempio, sulla porta TCP 445 per SMB), e il server li inoltra al DC per conto del client. Il server non vede mai la password o l’hash: si limita a fare da relay ai messaggi di protocollo.

Il risultato pratico è che l’autenticazione rimane su percorso Kerberos anche quando:

• Il client si trova in una subnet segmentata senza accesso diretto ai DC
• L’accesso avviene via VPN o accesso remoto con routing limitato
• L’architettura cloud restringe la connettività diretta ai controller di dominio

LocalKDC: Kerberos anche per gli account locali

LocalKDC affronta il secondo grande limite: gli account locali. Kerberos richiede un KDC per emettere i ticket, e gli account locali (quelli nel SAM della macchina) non hanno nessun KDC a cui rivolgersi. Di conseguenza, qualunque autenticazione remota che coinvolgesse un account locale era storicamente vincolata a NTLM.

LocalKDC è un KDC leggero integrato direttamente in Windows, che opera esclusivamente sugli account del SAM locale. Emette ticket Kerberos basati su AES per le identità locali, abilitando l’autenticazione Kerberos anche in ambienti workgroup, macchine standalone e qualsiasi scenario con credenziali locali.

Stato attuale e configurazione via registro

Le due funzionalità hanno default diversi nel preview corrente:

• IAKerb: abilitato per default
• LocalKDC: disabilitato per default

La configurazione avviene tramite valori di registro di tipo REG_DWORD:

• DisableIAKerb: impostare a 0 per abilitare, 1 per disabilitare
• DisableLocalKDC: impostare a 0 per abilitare, 1 per disabilitare

Group Policy e gestione tramite MDM (Intune incluso) saranno aggiunti quando le funzionalità usciranno dalla fase di preview.

Prima di testare: auditing NTLM

Prima di attivare IAKerb e LocalKDC in produzione, è fondamentale capire dove NTLM viene ancora usato nell’ambiente. Windows 11 24H2 e Windows Server 2025 includono log operativi NTLM migliorati, accessibili in Event Viewer sotto:

Applications and Services Logs > Microsoft > Windows > NTLM > Operational

Gli Event ID rilevanti sono:

• 4020, 4021: eventi client (includono nome processo, IP di destinazione, codice motivo per cui Kerberos non è stato usato)
• 4022, 4023: eventi server (nome processo e IP client)
• 4030–4033: eventi sui domain controller (dettagli client e server)

I log client sono i più informativi perché riportano il motivo del fallback a NTLM, permettendo di identificare i workload che richiedono intervento prima di pensare a disabilitare NTLM.

L’abilitazione del logging si gestisce via Group Policy:

• Per client e server: Administrative Templates > System > NTLM > NTLM Enhanced Logging
• Per i domain controller: Administrative Templates > System > Netlogon > Log Enhanced Domain-wide NTLM Logs

Limiti attuali e roadmap Microsoft

IAKerb e LocalKDC non eliminano ogni dipendenza da NTLM. Rimangono scenari che continuano a richiedere NTLM:

• Applicazioni con NTLM hardcoded nel codice
• Infrastrutture che assumono NTLM come default nella loro logica di autenticazione
• Alcune interazioni tra account di dominio e account locali sulla stessa macchina

La roadmap Microsoft per la disabilitazione di NTLM si articola in tre fasi:

• Fase 1 (già in produzione): miglioramenti all’auditing NTLM
• Fase 2 (H2 2026): disponibilità generale di IAKerb e LocalKDC
• Fase 3 (~2027–2028): NTLM disabilitato per default nella prossima versione major di Windows Server

Cosa fare adesso

Per un amministratore di sistema che vuole prepararsi al cambiamento in anticipo, il percorso consigliato è: abilitare i log NTLM migliorati oggi (già disponibili su 24H2/Server 2025), analizzare gli event ID nei prossimi mesi per mappare i workload con dipendenza NTLM, e pianificare i test con IAKerb e LocalKDC su ambienti non produttivi non appena la disponibilità generale sarà confermata. Affrontare questa transizione gradualmente è molto più gestibile che trovarsi a fare remediation d’emergenza quando NTLM verrà disabilitato per default.

Fonte originale: Reducing NTLM fallback with IAKerb and LocalKDC in Windows – 4sysops.com

Samsung starebbe testando sui modelli cinesi del Galaxy S26 una nuova modalità di gestione delle prestazioni chiamata “Adaptive”, che si posiziona tra il profilo Standard e quello Leggero. La notizia arriva dal leaker Ice Universe e potrebbe anticipare una novità destinata al rilascio globale.

Cos’è la modalità Adaptive

Secondo la descrizione trovata nell’interfaccia del Galaxy S26 cinese, la modalità Adaptive si basa sul profilo Standard ma applica aggiustamenti intelligenti delle prestazioni per prolungare la durata della batteria. In pratica, il sistema monitorerebbe il carico di lavoro in tempo reale: nelle operazioni leggere (navigazione, messaggistica) limita le risorse per risparmiare energia, mentre in situazioni più impegnative (fotografia, AI, gaming) si porta vicino alle prestazioni massime.

Un approccio già visto, ma fatto meglio?

L’idea di un profilo “intelligente” non è nuova nel mondo Android — molti produttori ci hanno già provato con risultati altalenanti. Il rischio principale è che la gestione aggressiva del background finisca per limitare le notifiche e le app in esecuzione. Samsung dovrà trovare il giusto equilibrio per non frustrare gli utenti con comportamenti inattesi.

Possibile arrivo globale in futuro

Ice Universe ha ipotizzato che questo Adaptive mode potrebbe evolversi fino a sostituire il profilo Standard sul lungo periodo, diventando la modalità predefinita dei Galaxy. Al momento è solo una funzione in test su una variante regionale, ma se le prime valutazioni fossero positive, un’espansione globale — inclusa l’Italia — potrebbe arrivare con un aggiornamento software futuro.

Un prototipo di OnePlus con batteria da 10.000 mAh è emerso dai leak più recenti. Secondo il noto leaker Digital Chat Station, il dispositivo è già in fase di test e potrebbe includere anche il prossimo chip Snapdragon 8 Gen 6 e un display con refresh rate a 185 Hz.

Un’autonomia record per la gamma OnePlus

Con 10.000 mAh, il prototipo si posizionerebbe tra i dispositivi con la maggiore autonomia sul mercato Android. OnePlus non è estranea alle grandi batterie, ma questo salto sarebbe significativo anche rispetto agli smartphone più autonomi della concorrenza. Il display flat da 1,5K con refresh rate massimo a 185 Hz e tecnologia LTPS suggerirebbe una scelta orientata alla fluidità visiva piuttosto che alla massima efficienza energetica.

Possibile identità: un futuro OnePlus 16R

Sebbene il nome ufficiale non sia ancora noto, le speculazioni indicano che potrebbe trattarsi di una variante dell’Ace series per il mercato cinese, poi rilabellata per il mercato globale come OnePlus 16R — seguendo la tradizione già vista con l’Ace 6T diventato 15R. Tuttavia, la situazione commerciale di OnePlus nei mercati occidentali resta incerta.

Lancio non prima del quarto trimestre 2026

Il dispositivo è ancora in una fase di sviluppo iniziale e le specifiche potrebbero cambiare considerevolmente prima della commercializzazione. L’uscita, secondo le stime, non avverrà prima dell’ultimo trimestre 2026. Nel frattempo, OnePlus si prepara al lancio imminente dei Turbo 6X e Turbo 6X Pro, previsto per il 10 giugno in Cina, prodotti distinti da questo misterioso prototipo.

La corsa alla grande batteria si intensifica

La tendenza verso batterie sempre più capienti sui top di gamma Android è in forte crescita. Xiaomi, Vivo e altri brand hanno già superato la soglia dei 6.000-7.000 mAh. Se OnePlus dovesse portare un dispositivo con 10.000 mAh su scala globale a un prezzo competitivo, potrebbe ridefinire le aspettative di autonomia per l’intera categoria.

Xiaomi si prepara a entrare nel segmento dei foldable a schermo largo? Un leak proveniente dall’interfaccia interna di HyperOS suggerisce che il brand cinese stia sviluppando uno smartphone pieghevole con form factor “wide” — diverso dai classici modelli a libro verticale.

Cosa rivela HyperOS

Le schermate trapelate mostrano un layout UI ottimizzato per un display orizzontalmente più ampio rispetto agli attuali Xiaomi Mix Fold. Alcuni appassionati hanno sovrapposto queste schermate a immagini del Huawei Pura X Max — un foldable wide già sul mercato — ottenendo una corrispondenza convincente. Questo non è ancora una conferma ufficiale, ma indica che lo sviluppo è già in una fase avanzata.

Un mercato in rapida evoluzione

Il formato wide per i pieghevoli è al centro dell’attenzione del settore: Samsung sta preparando il Galaxy Z Fold Wide come alternativa al Fold8 tradizionale, mentre Apple dovrebbe debuttare nel mondo dei foldable proprio con un modello a schermo largo chiamato iPhone Ultra. Xiaomi entrerebbe quindi in un segmento competitivo ma in forte crescita, con il vantaggio di poter proporre soluzioni a prezzi potenzialmente più accessibili rispetto ai rivali coreani e americani.

Specifiche attese: Leica, 200 MP e chip Xring O3

Le indiscrezioni parlano di un sistema fotografico triplo sviluppato con Leica e sensore principale da 200 megapixel. Per il processore, si vocifera l’adozione dell’Xring O3, il chip proprietario di Xiaomi che ha già dimostrato le sue ambizioni nel settore dei semiconduttori. Le funzioni multi-tasking di HyperOS verrebbero potenziate per sfruttare al meglio il grande schermo.

Lancio possibile ad agosto in Cina

La finestra di lancio più probabile, stando alle ultime informazioni, è l’agosto 2026 per il mercato cinese. Il nome commerciale non è ancora definito: tra le ipotesi circolano Xiaomi Mix Fold 5, Xiaomi 18 Fold o Xiaomi 17 Fold. La disponibilità globale rimane incerta. Da seguire con attenzione nei prossimi mesi.

Con iOS 27 e macOS 27, Apple rimuoverà una delle barriere più frustranti tra iPhone e Android: la condivisione degli album su Apple Foto diventerà accessibile anche agli utenti Android e Windows. L’annuncio è arrivato durante il WWDC 2026 e il rilascio è previsto per l’autunno.

Fino ad oggi un muro tra iOS e Android

Da anni, chi possiede un iPhone può condividere facilmente album fotografici con altri utenti Apple, ma chi ha uno smartphone Android ne è rimasto di fatto escluso. In famiglia o tra amici con dispositivi diversi, questo significava dover ricorrere a soluzioni alternative come Google Foto, WhatsApp o servizi di terze parti. Questa limitazione è ora in via di superamento.

Come funzionerà la condivisione con Android

Con il prossimo aggiornamento, gli utenti iPhone potranno creare album condivisi visibili e accessibili anche da dispositivi Android. La condivisione supporterà immagini ad alta risoluzione, eliminando la perdita di qualità che spesso affligge altri metodi di invio. Anche la compatibilità con Windows viene migliorata, ampliando la connettività dell’ecosistema Apple verso ambienti non-Apple.

Un passo verso Google Foto

Google Foto ha da sempre offerto una condivisione trasversale tra sistemi operativi, diventando lo standard di riferimento per le famiglie con dispositivi misti. Apple si avvicina ora a quel modello, con un’implementazione che promette di essere nativa e integrata — senza richiedere app aggiuntive sul lato Android. Per chi ha in famiglia sia iPhone che Android, sarà una novità molto apprezzata.

Disponibile dall’autunno 2026

La funzione sarà inclusa negli aggiornamenti di iOS 27 e macOS 27, attesi per l’autunno 2026. Non sono stati ancora comunicati dettagli su eventuali limitazioni di compatibilità lato Android, né se sarà necessaria un’app dedicata di Apple o se tutto avverrà tramite browser e link condivisi.

KDE Frameworks è una raccolta di oltre 70 librerie software libere (attualmente 72) basate su Qt, il noto toolkit multipiattaforma per lo sviluppo di interfacce grafiche. Queste librerie forniscono API stabili e coerenti (le API sono insiemi di funzioni e componenti pronti...

🔗 Leggi il post completo

Le distribuzioni GNU/Linux offrono numerosi lettori video, ma Cine si distingue per un obiettivo preciso: proporre un’applicazione moderna, essenziale e perfettamente integrata con l’ambiente desktop GNOME, grazie all’utilizzo combinato di MPV, GTK4 e libadwaita....

🔗 Leggi il post completo

A volte le vulnerabilità più efficaci spuntano fuori da funzionalità che fanno esattamente quello che è previsto. È questo il caso di HTTP/2 Bomb, un attacco denial-of-service (DoS) remoto pubblicato dal gruppo di ricerca Calif che colpisce le configurazioni predefinite dei principali web server: nginx, Apache httpd, Microsoft IIS, Envoy e Cloudflare Pingora. Partiamo subito...

🔗 Leggi il post completo

Buone notizie in arrivo per gli scontenti dell’interfaccia grafica di LibreOffice. A partire dal LibreOffice 26.8, il cui rilascio è previsto per il prossimo mese di agosto, sarà possibile personalizzare dando un tocco di colore all’interfaccia a schede (la Notebookbar). L’anteprima ci arriva dal profilo Mastodon del Design Team di Libreoffice. Come potete vedere è […]
L...

🔗 Leggi il post completo

NTT Docomo ha annunciato il lancio dell’Arrows We3 F-52G per il 25 giugno 2026. Lo smartphone, prodotto da FCNT, è pensato per chi cerca un dispositivo compatto, affidabile e con un’autonomia superiore alla media, senza rinunciare a un design robusto adatto alla vita quotidiana.

Compatto ma con batteria da 5.000 mAh

Arrows We3 misura 6,1 pollici, con una larghezza di circa 73 mm che lo rende facile da usare con una mano. Nonostante le dimensioni contenute, monta una batteria da 5.000 mAh che, secondo Docomo, garantisce fino a due giorni di utilizzo con una singola carica. Un’autonomia notevole per un dispositivo di questo ingombro.

Fotocamera Sony LYTIA 600 da 50 megapixel

Sul fronte fotografico, Arrows We3 monta il sensore Sony LYTIA 600 da circa 50,3 megapixel, lo stesso tipo adottato su alcuni modelli premium. La fotocamera è progettata per offrire buoni risultati anche in condizioni di scarsa luce e per ritratti con sfocatura naturale dello sfondo. Le foto e i video possono essere archiviati su microSD fino a 2 TB.

Resistenza certificata MIL e display Gorilla Glass 7i

Fedele alla tradizione della serie arrowss, We3 è certificato secondo 23 standard MIL-SPEC ed è dotato di resistenza all’acqua IP68/IP69 e alla polvere IP6X. Il display è protetto dal Corning Gorilla Glass 7i, resistente ai graffi, e la struttura del telefono è progettata per sopportare cadute da 1,5 metri senza rottura del vetro. Le prenotazioni sono aperte dal 11 giugno, con il pre-acquisto online disponibile dal 23 giugno.

Ore dopo che Microsoft ha distribuito il Patch Tuesday di giugno 2026 — correggendo tra l’altro due zero-day dello stesso ricercatore — Nightmare Eclipse ha rilasciato pubblicamente RoguePlanet, un nuovo exploit che sfrutta una race condition in Microsoft Defender per elevare i privilegi a SYSTEM su sistemi completamente patchati. Il gesto è l’ultimo atto di una guerra a distanza tra il ricercatore e Redmond su pratiche di divulgazione e bug bounty, e solleva interrogativi scomodi sulla gestione delle vulnerabilità da parte della più grande azienda di software al mondo.

La saga Nightmare Eclipse: cinque zero-day, una disputa irrisolta

RoguePlanet è il quinto exploit zero-day pubblicamente rilasciato da Nightmare Eclipse negli ultimi mesi, dopo BlueHammer, RedSun, GreenPlasma e YellowKey. I precedenti exploit hanno colpito Microsoft Defender, BitLocker e componenti core di Windows; GreenPlasma e YellowKey sono stati corretti proprio nel Patch Tuesday del 9 giugno 2026.

Il ricercatore sostiene che Microsoft abbia sistematicamente rimosso i repository GitHub e GitLab che ospitavano i PoC, costringendolo a creare una piattaforma self-hosted (projectnightcrawler.dev). Microsoft ha risposto nel maggio 2026 con un comunicato del MSRC in cui avvertiva che avrebbe collaborato con le autorità in caso di “attività dannose che causano reale danno ai clienti” — una formulazione che la comunità della sicurezza ha ampiamente interpretato come una velata minaccia legale verso il ricercatore. L’effetto è stato controproducente: la tensione si è intensificata, e RoguePlanet ne è la diretta conseguenza.

Meccanica dell’exploit: dalla RCE alla LPE via Defender

RoguePlanet nasce originariamente come vulnerabilità di Remote Code Execution. L’idea iniziale sfruttava il modo in cui Microsoft Defender gestisce file ospitati su share SMB remoti: un attaccante poteva indurre una vittima ad aprire un file .vhd(x) su un server SMB controllato, ottenendo che Defender sovrascrivesse i propri file — con conseguente RCE.

A metà maggio 2026, Microsoft ha effettuato un hardening silenzioso dell’API mpengine!SysIO*, bloccando gli attacchi basati su junction point. Il ricercatore ha dovuto riscrivere l’exploit da zero, riuscendo a preservare solo la componente di Local Privilege Escalation. Nella forma attuale:

• L’exploit sfrutta una race condition nella logica di processing interno di Defender.
• Un utente non privilegiato reindirizza un’operazione su file eseguita da Defender (che gira come SYSTEM) verso codice controllato dall’attaccante.
• Il risultato è l’apertura di un command prompt con privilegi SYSTEM — la shell più privilegiata su Windows.
• La percentuale di successo è variabile: il ricercatore riporta “100% su alcune macchine, meno su altre”, essendo una race condition dipendente dal timing.

ThreatLocker ha confermato la riproducibilità dell’exploit su Windows 11 con la patch KB5094126 installata. Il CEO Danny Jenkins ha dichiarato a BleepingComputer: “La nostra analisi iniziale conferma che l’exploit RoguePlanet è valido e funziona come descritto. Le organizzazioni che utilizzano application allowlisting possono prevenire l’esecuzione dell’exploit.”

Sistemi affetti e stato attuale

Al momento della pubblicazione di questo articolo, non esiste una patch ufficiale Microsoft per RoguePlanet. I sistemi vulnerabili includono:

• Windows 11 (build Official e Canary) con gli aggiornamenti di giugno 2026 installati
• Windows 10 con gli aggiornamenti di giugno 2026 installati

Non sono stati rilevati casi di sfruttamento attivo in the wild al momento della scrittura. Tuttavia, l’exploit è pubblicamente disponibile su un repository self-hosted, il che abbassa significativamente la barriera per attori motivati.

Il paradosso della divulgazione: quando il vendor diventa il problema

La vicenda Nightmare Eclipse tocca un nervo scoperto dell’ecosistema della sicurezza: cosa succede quando un vendor di dimensioni planetarie risponde ai ricercatori indipendenti con minacce legali anziché con correzioni tempestive e riconoscimento equo?

Il modello di coordinated disclosure — già fragile — mostra le sue crepe: il ricercatore ha seguito le procedure inizialmente, ma la risposta di Microsoft (rimozione dei repository, silenzio sul bug bounty, comunicato quasi legalistico) ha spinto verso la full disclosure non coordinata. Il risultato è una serie di zero-day pubblici su uno dei sistemi operativi più diffusi al mondo, senza patch disponibili.

Va notato che la comunità della sicurezza rimane divisa: alcuni vedono Nightmare Eclipse come un ricercatore che agisce nell’interesse pubblico esponendo pratiche scorrette; altri ritengono che rilasciare exploit senza patch metta in pericolo utenti comuni. La verità è che entrambe le posizioni hanno una base legittima — e che il vero problema risiede nel comportamento di Microsoft.

Indicatori e due righe per i difensori

In assenza di patch, le misure di mitigazione disponibili sono:

• Application allowlisting: come confermato da ThreatLocker, blocca l’esecuzione del payload. Soluzioni come Windows Defender Application Control (WDAC) o AppLocker possono essere efficaci.
• Principio del minimo privilegio: l’exploit richiede l’esecuzione di codice come utente locale. Ridurre la superficie d’attacco limitando i diritti degli utenti finali.
• Monitoraggio dei processi sospetti: alert su processi figlio spawned da MsMpEng.exe (il processo principale di Defender) con privilegi elevati.
• EDR e XDR: monitorare comportamenti anomali legati a race condition sulle operazioni di file di Defender.

# Processo da monitorare
MsMpEng.exe → cmd.exe / powershell.exe (child process con TOKEN SYSTEM)
# Percorsi sensibili coinvolti
C:\ProgramData\Microsoft\Windows Defender\*
mpengine!SysIO* API calls con reindirizzamento anomalo
# Fonti di intelligence
projectnightcrawler.dev (self-hosted repo Nightmare Eclipse)
CVE: non ancora assegnato al momento della pubblicazione

WhatsApp ha presentato una richiesta di contempt order al tribunale federale contro NSO Group, accusando la società israeliana di spyware di aver continuato a colpire gli utenti della piattaforma nonostante un’ingiunzione permanente emessa in ottobre che le vietava esplicitamente di farlo. La vicenda riapre il dibattito sul mercato degli spyware commerciali e sull’efficacia degli strumenti legali contro chi li produce.

Il Contesto: sette anni di battaglia legale

La storia tra WhatsApp e NSO Group inizia nell’ottobre 2019, quando la piattaforma di Meta ha citato in giudizio la società israeliana per aver sfruttato una vulnerabilità del servizio per installare il suo spyware Pegasus su circa 1.400 dispositivi di attivisti per i diritti umani, giornalisti e dissidenti in tutto il mondo attraverso attacchi zero-click. Bastava che il bersaglio ricevesse una chiamata WhatsApp — anche senza risponderla — per compromettere il dispositivo.

Il procedimento giudiziario si è concluso con una vittoria storica per WhatsApp: nel maggio 2026 una giuria ha inizialmente assegnato 167 milioni di dollari di danni punitivi, successivamente ridotti a 4,4 milioni dal giudice federale che presiedeva il caso. A ottobre 2025, lo stesso giudice ha emesso un’ingiunzione permanente che vietava a NSO di utilizzare WhatsApp come vettore d’attacco.

NSO aveva risposto all’ingiunzione dichiarando che avrebbe potuto “mettere a rischio l’intera impresa NSO” e “costringere NSO a chiudere i battenti”, mentre il giudice respingeva le sue richieste di sospensione dell’ordine. La società ha presentato appello a novembre 2025, con un procedimento ancora in corso.

Le nuove violazioni: spearphishing in spregio al tribunale

Nonostante l’ingiunzione, WhatsApp ha rilevato nuova attività malevola attribuita a NSO Group dopo che utenti hanno segnalato comportamenti sospetti. Secondo il blog post pubblicato da Meta l’8 giugno 2026, gli attacchi avrebbero usato tecniche di social engineering per indurre gli utenti a cliccare su link malevoli verso siti web esterni fuori da WhatsApp, una metodologia simile alle campagne di 1-click phishing già in precedenza collegate a NSO.

La tecnica rappresenta un’evoluzione rispetto agli attacchi zero-click del 2019: non sfruttando più una vulnerabilità tecnica della piattaforma (impossibile dopo le patch e l’ingiunzione), NSO avrebbe adottato un approccio di spearphishing che richiede l’interazione dell’utente ma aggira il divieto tecnico di sfruttamento diretto dell’app. NSO avrebbe anche creato account e gruppi test su WhatsApp che la piattaforma ha rimosso.

WhatsApp ha condiviso pubblicamente gli indicatori di compromissione associati alle campagne e incoraggia gli utenti a verificare se siano stati bersaglio di metodi di social engineering collegati a NSO su più piattaforme, inclusi SMS ed email.

Le implicazioni: NSO sotto nuova proprietà, stessa operatività

Un elemento di contesto importante: lo scorso anno un gruppo di investitori americani ha acquisito NSO Group con l’ambizione dichiarata di rientrare nel mercato statunitense, da cui la società era stata di fatto esclusa dopo l’inserimento nella Entity List del Dipartimento del Commercio USA nel novembre 2021. L’acquisizione non sembra aver cambiato le pratiche operative della società.

Il mercato degli spyware commerciali continua a operare in una zona grigia normativa: i produttori si definiscono fornitori di strumenti legittimi per forze dell’ordine e intelligence, mentre le evidenze mostrano sistematicamente usi contro giornalisti, attivisti e dissidenti politici. Casi come quello di NSO Group dimostrano che anche quando una corte impone restrizioni operative esplicite, la compliance può essere ignorata.

La richiesta di contempt: cosa succede adesso

Con la richiesta di contempt of court, WhatsApp chiede al tribunale di sanzionare NSO per aver violato l’ingiunzione permanente di ottobre. Se il giudice dovesse riconoscere la violazione, NSO potrebbe essere soggetta a sanzioni finanziarie aggiuntive e a misure coercitive più severe, con potenziale impatto sull’appello ancora pendente.

Il caso stabilisce un precedente rilevante per l’intero settore dello spyware commerciale: per la prima volta un’azienda tecnologica è riuscita a ottenere non solo una vittoria risarcitoria ma un’ingiunzione permanente di portata operativa contro un vendor di sorveglianza. La risposta del tribunale alla presunta violazione di quell’ingiunzione determinerà se tali strumenti legali abbiano effettiva capacità deterrente.

Indicatori e raccomandazioni

WhatsApp ha pubblicato indicatori di minaccia collegati alle campagne di NSO. Chi ritiene di poter essere un bersaglio ad alto rischio — giornalisti, attivisti, operatori umanitari, funzionari governativi — dovrebbe:

• Verificare i propri dispositivi con strumenti come Mobile Verification Toolkit (MVT) di Amnesty International, che analizza artefatti forensi associati a Pegasus
• Trattare con massima sospetto qualsiasi link ricevuto su WhatsApp che rimandi a siti esterni, soprattutto da contatti non verificati o messaggi non attesi
• Controllare i propri account WhatsApp per rilevare accessi da dispositivi o sessioni non riconosciute
• Monitorare i threat indicators pubblicati da WhatsApp/Meta per verificare la presenza di domini o IP associati alle campagne negli access log dei propri sistemi

Il caso NSO-WhatsApp non è solo una vicenda legale tra due aziende: è uno dei fronti principali della battaglia globale per definire i limiti dell’industria dello spyware commerciale e la responsabilità legale dei suoi protagonisti.

Sharp ha ufficializzato la data del prossimo evento di presentazione: il 16 giugno 2026 verranno svelati i nuovi prodotti a marchio AQUOS per l’estate. Oltre al nuovo flagship smartphone AQUOS R11, l’evento si preannuncia storico per il brand giapponese: per la prima volta potrebbe essere lanciato uno smartwatch AQUOS.

Il teaser svela uno smartwatch con display circolare

L’immagine teaser pubblicata da Sharp riporta chiaramente la dicitura “Smartphone | Wearables 2026”, confermando che l’evento non si limiterà ai soli telefoni. Nell’immagine si intravede un dispositivo con cassa rotonda, lancette e quello che sembra un selettore laterale simile alla corona di un orologio tradizionale. Se confermato, sarebbe il debutto di AQUOS nel segmento dei wearable, un segmento finora non esplorato dal brand.

AQUOS R11: atteso il nuovo top di gamma

Il protagonista principale dell’evento sarà l’AQUOS R11, nuovo flagship dello storico brand giapponese. La serie R è da sempre la linea più avanzata di Sharp, con caratteristiche come display ad alta frequenza di aggiornamento, fotocamere con ottiche Leica (in alcuni mercati) e costruzione premium. Non sono ancora stati divulgati i dettagli tecnici ufficiali, ma le aspettative sono elevate, specialmente sul fronte del display e del comparto fotografico.

AQUOS entra nel mondo dei wearable

L’ingresso nel mercato degli smartwatch rappresenta una svolta strategica per Sharp. Il segmento è dominato da Apple Watch, Samsung Galaxy Watch e Google Pixel Watch, ma c’è ancora spazio per proposte differenziate. Un AQUOS Watch potrebbe puntare sull’integrazione profonda con gli smartphone AQUOS e su caratteristiche di resistenza tipiche del brand, come la certificazione IP68 e la robustezza strutturale. L’evento del 16 giugno chiarirà tutti i dettagli.

I foldable sono ancora considerati prodotti di lusso, ma di tanto in tanto emergono occasioni che li rendono accessibili a un pubblico molto più ampio. È il caso del nubia Flip 2, uno smartphone a conchiglia verticale attualmente disponibile sull’Y!mobile Online Store giapponese a soli 19.800 yen (circa 120 euro), grazie a una promozione di liquidazione scorte per cambio operatore.

Da 85.000 a 19.800 yen: un crollo del prezzo clamoroso

Al lancio, nubia Flip 2 aveva un prezzo consigliato di circa 85.680 yen. Il prezzo di listino è già stato ridotto a 41.472 yen, e con gli sconti aggiuntivi riservati ai clienti che effettuano un cambio operatore, si arriva alla cifra di 19.800 yen. Una riduzione di oltre il 75% rispetto al prezzo iniziale, che rende questo foldable uno dei più convenienti mai proposti sul mercato giapponese.

Cosa offre il nubia Flip 2

Il nubia Flip 2 è un pieghevole a conchiglia (clamshell), quindi si chiude verticalmente riducendo le dimensioni a metà. Non compete con i top di gamma come il Samsung Galaxy Z Flip 6, ma offre l’esperienza base del form factor foldable a un prezzo ora decisamente accessibile. Per chi è curioso di provare uno smartphone pieghevole senza spendere cifre elevate, questa potrebbe essere un’occasione da non perdere, anche se la disponibilità delle unità in liquidazione è tipicamente limitata.

Nonostante le capacità delle batterie degli smartphone siano aumentate sensibilmente negli ultimi anni, il problema dell’autonomia è ancora ben presente. Un sondaggio condotto da Android Authority con oltre 6.000 partecipanti rivela che più di quattro utenti su dieci non riesce a coprire un’intera giornata con una singola carica.

I numeri del sondaggio

Il sondaggio di Android Authority ha raccolto più di 6.000 risposte, dipingendo un quadro eloquente sull’esperienza degli utenti Android con l’autonomia dei dispositivi. Oltre il 40% degli intervistati ha dichiarato di non riuscire a coprire una giornata intera senza ricorrere a una ricarica. Un dato che emerge nonostante molti smartphone attuali montino batterie da 5.000 mAh o più.

Perché più mAh non bastano

La risposta è nel cambiamento delle abitudini digitali. Schermi sempre più luminosi e ad alta frequenza di aggiornamento, connettività 5G, streaming video, gaming mobile e l’uso crescente di funzioni AI on-device consumano molta più energia rispetto a qualche anno fa. Il risultato è che l’aumento della capacità delle batterie non riesce a tenere il passo con la crescita dei consumi energetici delle applicazioni e del sistema operativo.

La soluzione? Non solo più mAh

Gli esperti concordano che la soluzione non risiede solo nell’aumento della capienza, ma anche nell’ottimizzazione software e nella gestione energetica dei processori. Chip come lo Snapdragon 8 Elite e il Tensor G5 di Google hanno migliorato l’efficienza rispetto alle generazioni precedenti, e si prevede che i futuri SoC possano invertire la tendenza. Nel frattempo, la ricarica rapida rimane la risposta più immediata per chi non arriva a fine giornata.

FCNT ha ufficializzato Arrows We3, l’ultimo smartphone della storica serie arrows destinata al mercato giapponese. Tuttavia, un confronto tra i chip utilizzati nei due modelli più recenti solleva una domanda insolita: il nuovo Arrows We3 è davvero meno potente del precedente Arrows We2?

Dimensity 6300 vs Dimensity 7025: i numeri non mentono

Arrows We3 è equipaggiato con il MediaTek Dimensity 6300, mentre il predecessore We2 montava il Dimensity 7025. Nonostante i numeri suggeriscano il contrario, i benchmark pubblicamente disponibili su nanoreview.net mostrano che il Dimensity 7025 del We2 supera il Dimensity 6300 del We3 sia in single-core che in multi-core su Geekbench 6. In altre parole, il modello più recente avrebbe prestazioni inferiori rispetto a quello del 2024.

Non è la prima volta che succede

Sebbene insolito, questo tipo di scelta non è senza precedenti nell’industria mobile. I produttori a volte scelgono chip di generazione più recente ma fascia inferiore per contenere i costi o per altre ragioni legate alla disponibilità dei componenti, alla gestione termica o all’efficienza energetica. Il Dimensity 6300 potrebbe offrire vantaggi in termini di autonomia o calore generato, anche se le prestazioni pure risultano inferiori.

Cosa significa per gli acquirenti

Per chi usa lo smartphone principalmente per chiamate, messaggistica e applicazioni quotidiane, la differenza di prestazioni difficilmente sarà percepibile. Arrows We3 è chiaramente pensato per un pubblico che privilegia la durata della batteria, la resistenza e la semplicità d’uso rispetto alle prestazioni brute. Chi invece cerca un dispositivo pronto per il gaming o le app più esigenti dovrebbe valutare altre opzioni nel mercato Android.

Oppo K15, il modello base della serie K15 di Oppo, ha fatto la sua comparsa nel database della certificazione cinese TENAA, rivelando design e specifiche principali. I modelli superiori K15 Pro e K15 Pro+ erano già stati annunciati ad aprile, e ora si completa il quadro dell’intera famiglia.

Design coerente con i modelli Pro

Dal punto di vista estetico, Oppo K15 segue le linee della serie: isola fotocamera quadrata con angoli arrotondati sul retro, un design che richiama i modelli superiori e conferisce alla gamma un’identità visiva uniforme. Le dimensioni sono 158,3 × 75,13 × 8,27 mm per un peso di 205 grammi, valori nella norma per uno smartphone di questa fascia.

Display AMOLED da 6,59 pollici con lettore impronte in-display

Lo schermo sarà un AMOLED da 6,59 pollici con risoluzione 1256 × 2760 pixel. La certificazione TENAA conferma anche la presenza del sensore per le impronte digitali integrato nel display, una caratteristica che si sta diffondendo anche nella fascia media. Non sono ancora noti i dettagli completi su processore, RAM e batteria, ma ulteriori informazioni dovrebbero emergere nelle prossime settimane in vista dell’annuncio ufficiale.

Una nuova indiscrezione sul Sony Xperia 1 VIII riguarda la catena di produzione dello smartphone. Analizzando il numero seriale del dispositivo, che inizia con le lettere “HQ”, alcuni appassionati hanno ipotizzato che la produzione sia stata affidata a Huaqin Technology, azienda cinese già incaricata della manifattura dello Xperia 1 VII.

Il codice “HQ” come indizio

La teoria si basa sull’interpretazione delle prime due lettere del numero seriale, che in molti prodotti elettronici indicano il produttore in conto terzi (ODM o EMS). “HQ” farebbe riferimento proprio a Huaqin Technology (华勤技术), una delle principali aziende di manifattura di smartphone in Cina. Se confermato, sarebbe la continuazione di una scelta già fatta da Sony per il modello precedente, a conferma di una collaborazione consolidata.

Cosa cambia per gli utenti

In linea generale, il fatto che la produzione sia affidata a un partner esterno non influisce sulla qualità finale del prodotto, che resta progettato e certificato da Sony. Il brand giapponese mantiene il controllo su software, design e standard qualitativi. Xperia 1 VIII rimane uno dei flagship Android più attesi dell’anno, apprezzato dai fan per il display 4K, l’orientamento cinematografico della fotocamera e la costruzione premium. Maggiori dettagli ufficiali dal brand sono attesi nei prossimi mesi.

Sony ha scelto il mercato cinese come palcoscenico per anticipare l’arrivo di due nuovi sensori fotografici sotto il brand LYTIA. Le immagini teaser pubblicate ufficialmente mostrano due grandi sensori con la dicitura “Dual Core Technology”, lasciando intravedere un salto generazionale nelle capacità di acquisizione immagine per smartphone.

Cosa si sa finora

Dal teaser emergono poche informazioni certe, ma significative: verranno lanciati due nuovi modelli di sensore in contemporanea, entrambi basati sulla tecnologia Dual Core. Questa soluzione, che prevede due core di elaborazione all’interno del sensore stesso, mira a migliorare la velocità di readout, ridurre il rumore nelle riprese in condizioni di scarsa illuminazione e aumentare la precisione del messa a fuoco. Non sono stati ancora rivelati i nomi commerciali dei sensori.

Il successore del LYTIA LYT-828 potrebbe essere vicino

Secondo le indiscrezioni, uno dei due sensori potrebbe essere il successore del LYT-828, attualmente uno dei più apprezzati tra i produttori di smartphone premium. I sensori LYTIA di Sony sono adottati da marchi come Xiaomi, Oppo, Vivo e Honor per i loro modelli di punta. Con i nuovi sensori Dual Core, Sony punta a mantenere la leadership nel segmento dell’imaging mobile, un ambito sempre più competitivo grazie alla concorrenza di Samsung e dei produttori cinesi.

Dopo mesi di segnalazioni da parte degli utenti, Google ha finalmente comunicato una risposta concreta al problema del bootloop che ha colpito alcuni smartphone Pixel a partire da marzo 2026. Chi si trova ancora in questa situazione può ora contattare il supporto ufficiale per ricevere assistenza personalizzata.

Un problema che persiste da mesi

Il bug è emerso dopo l’installazione degli aggiornamenti software distribuiti tra marzo e maggio 2026. I sintomi variano da dispositivo a dispositivo: alcuni Pixel rimangono bloccati sul logo di avvio, altri si riavviano in loop continuo dopo l’inserimento del PIN. In certi casi era possibile accedere al menu di recupero, ma il ripristino ai dati di fabbrica comporta la perdita di tutti i contenuti salvati, rendendolo una soluzione di ultima istanza.

La risposta ufficiale di Google

Sul forum di supporto ufficiale, Google ha confermato di aver sviluppato nuove procedure di risoluzione per i dispositivi affetti. Poiché il problema si manifesta in modo diverso a seconda dell’hardware e del software installato, non esiste un’unica procedura valida per tutti: ogni caso richiede una valutazione individuale. L’azienda invita gli utenti a contattare il Pixel Customer Support specificando il sintomo esatto, come “loop di riavvio dopo l’aggiornamento software di marzo/aprile/maggio”, per essere indirizzati al team competente.

Come ottenere assistenza

Se il tuo Pixel si riavvia continuamente o resta bloccato sulla schermata di avvio dopo un aggiornamento recente, contatta il supporto Pixel tramite il sito ufficiale Google o l’app Google One. Descrivendo con precisione il problema e il periodo in cui è comparso, il team di assistenza potrà guidarti verso la soluzione più adatta al tuo caso specifico, che potrebbe includere procedure di ripristino avanzate senza la perdita dei dati.

I leak sul Google Pixel 11 si moltiplicano e cominciano a delineare un quadro abbastanza dettagliato di quella che sarà la prossima famiglia di flagship di Google. Design evolutivo, nuovo chip Tensor G6 e un forte investimento nelle funzionalità AI sono i temi principali che emergono dalle indiscrezioni.

Quattro modelli in arrivo

La lineup del Pixel 11 dovrebbe comprendere quattro varianti: Pixel 11 standard con display OLED da 6,3 pollici a 120Hz, Pixel 11 Pro con pannello LTPO da 6,3 pollici, Pixel 11 Pro XL con schermo tra i 6,7 e 6,8 pollici, e il Pixel 11 Pro Fold, la versione pieghevole della serie. Tutti i modelli gireranno su Android 17 fin dal lancio.

Tensor G6: il nuovo chip di Google

Il cuore pulsante del Pixel 11 sarà il Tensor G6, il nuovo processore sviluppato in collaborazione tra Google e Samsung. Le aspettative sono alte: il chip dovrebbe migliorare significativamente sia le prestazioni computazionali che quelle della NPU dedicata all’intelligenza artificiale, che è sempre più al centro dell’esperienza Pixel. Si parla di capacità avanzate per la trascrizione in tempo reale, la traduzione istantanea e le funzioni di editing fotografico.

AI e fotografia al centro

Come da tradizione per i Pixel, la fotografia e l’intelligenza artificiale saranno i punti di forza del nuovo modello. Ci si aspetta un ulteriore salto qualitativo nella computational photography, con nuove modalità di scatto e miglioramenti all’elaborazione notturna. Le funzioni Gemini, già presenti su Pixel 9, dovrebbero espandersi ulteriormente, con capacità multimodali più sofisticate. Il lancio è atteso per l’autunno 2026, in linea con il tradizionale ciclo di rilascio dei Pixel.

TLS su Nginx: perché il tuning fa la differenza su HTTPS

Quando si parla di prestazioni web, l’ottimizzazione del TLS è spesso trascurata in favore di interventi più vistosi come la cache applicativa o l’indicizzazione del database. Eppure, su un server Nginx esposto in HTTPS, ogni handshake TLS non ottimizzato aggiunge latenza misurabile a ogni connessione nuova. Questa guida raccoglie le configurazioni che un sistemista esperto dovrebbe avere presenti per tenere basso il TTFB (Time To First Byte) e ridurre l’overhead delle connessioni sicure.

Una premessa importante: il tuning TLS non salva un’applicazione lenta. Se la generazione della pagina richiede 800ms, ottimizzare il TLS porterà al massimo qualche decina di millisecondi in meno. Il vero valore di queste configurazioni emerge su backend già veloci, dove l’overhead del protocollo diventa la variabile dominante.

TLS 1.2 o TLS 1.3: quale usare?

Dal 30 giugno 2018 il PCI Security Standards Council richiede la disabilitazione di SSL 3.0, TLS 1.0 e TLS 1.1. Ad oggi, la configurazione raccomandata è supportare esclusivamente TLS 1.2 e TLS 1.3:

ssl_protocols TLSv1.2 TLSv1.3;

ssl_protocols TLSv1.3;

Abilitare HTTP/2 e HTTP/3 (QUIC)

HTTP/2 è diventato lo standard de facto e Nginx lo supporta nativamente. Dalla versione 1.25.1, la direttiva è cambiata: non va più in listen ma come direttiva separata nel blocco server:

listen 443 ssl;
http2 on;

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    http2 on;

    ssl_certificate     /path/to/your/certificate.pem;
    ssl_certificate_key /path/to/your/key.pem;

    # Comunica al client il supporto HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

# Verifica HTTP/2
curl --http2 -I https://tuo-dominio.com/

# Verifica HTTP/3
curl --http3 -I https://tuo-dominio.com/

Session cache e session tickets: differenze chiave

La session cache lato server permette di riutilizzare i parametri crittografici di una sessione TLS precedente, evitando il full handshake per connessioni successive dello stesso client. In Nginx si configura così:

ssl_session_cache shared:SSL:10m;  # ~40.000 sessioni per MB
ssl_session_timeout 1d;

ssl_session_tickets off;

OCSP Stapling: eliminare la latenza di validazione del certificato

Senza OCSP Stapling, ogni nuovo client deve contattare la CA (Certificate Authority) per verificare che il certificato non sia stato revocato. Questo aggiunge una richiesta di rete esterna al percorso critico dell’handshake. Con lo stapling, è Nginx stesso a interrogare periodicamente la CA e a includere la risposta firmata direttamente nell’handshake TLS:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Ridurre ssl_buffer_size

Il valore predefinito di ssl_buffer_size in Nginx è 16KB, dimensionato per throughput massimo. Questo significa però che il primo byte del payload arriva al client solo dopo che il primo chunk da 16KB è stato riempito e cifrato. Per siti dove il TTFB è critico (landing page, API), ridurre il buffer abbassa la latenza percepita:

ssl_buffer_size 4k;

Configurazione completa raccomandata

Di seguito la configurazione consolidata che integra tutti i punti trattati, da inserire nel blocco http o nel blocco server di Nginx:

http2 on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_buffer_size 4k;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

nginx -t
nginx -s reload

HSTS: forzare HTTPS a livello di browser

HTTP Strict Transport Security istruisce i browser a non tentare mai connessioni HTTP plain verso il dominio, riducendo anche la superficie d’attacco da downgrade. L’intestazione si aggiunge così:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Conclusione

Il tuning TLS su Nginx non è un’operazione una tantum ma una configurazione che vale la pena standardizzare nei propri template di deployment. HTTP/2 abilitato, session cache attiva, OCSP Stapling e buffer ridotto sono quattro interventi a costo zero che si traducono in un’esperienza più reattiva per l’utente finale e in una postura di sicurezza più moderna. Per ambienti con requisiti di latenza estrema o traffico prevalentemente mobile, HTTP/3 con QUIC rappresenta il passo successivo logico, anche se richiede una build di Nginx con supporto esplicito.

Fonte originale: Nginx tuning tips: HTTPS/TLS – Turbocharge TTFB/Latency – linuxblog.io

Docker ha rilasciato Docker Desktop 4.77.0 l’8 giugno 2026, portando funzionalità attese da chi lavora quotidianamente con container in ambienti di sviluppo su Windows, Mac e Linux. Il punto di forza di questa release è il miglioramento della gestione dei log, la sicurezza nella distribuzione delle estensioni Marketplace e nuovi comandi per la gestione sicura dei segreti con docker pass.

Novità principali

Export dei log dalla Logs view

È ora possibile esportare i dati di log direttamente dalla Logs view di Docker Desktop. Fino a questa release, visualizzare e copiare manualmente i log di un container era l’unica opzione nell’interfaccia grafica; ora è possibile esportarli in modo strutturato, utile per condividere output di debug o alimentare strumenti di analisi esterni.

Insieme all’export, è stato aggiunto un toggle per la sensibilità alle maiuscole nella barra di ricerca dei log: la ricerca è case-insensitive per default, ma può essere commutata in case-sensitive per trovare identificatori o messaggi di errore specifici.

Estensioni Marketplace installate tramite digest OCI fisso

Un miglioramento significativo per la sicurezza della supply chain: le estensioni del Marketplace di Docker Desktop vengono ora installate e aggiornate usando il digest del manifest OCI (hash crittografico SHA256), invece del tag. Questo protegge contro attacchi di tipo tag mutation, in cui un’immagine pubblicata con un determinato tag viene successivamente sostituita con una versione malevola dopo la pubblicazione.

Il principio è lo stesso già consigliato in produzione per i Dockerfile:

# Più sicuro: riferimento per digest immutabile
FROM mcr.microsoft.com/dotnet/aspnet@sha256:a1b2c3d4...

# Meno sicuro: il tag può cambiare dopo la pubblicazione
FROM mcr.microsoft.com/dotnet/aspnet:10.0

Nuovi comandi docker pass

docker pass è lo strumento di Docker Desktop per la gestione dei segreti. Con questa release riceve due nuovi comandi:

• docker pass run — inietta i segreti salvati come variabili d’ambiente in comandi eseguiti sull’host, eliminando la necessità di esporre segreti permanentemente nella shell
• docker pass plugins — permette la gestione dinamica dei plugin di docker pass

Esempio d’uso:

# Senza docker pass: segreto esposto nella shell
export DATABASE_URL="postgres://utente:password@host/db"
./myapp

# Con docker pass run: segreto iniettato solo durante l'esecuzione
docker pass run -- ./myapp

Supporto OAuth per MCP server in Gordon

Gordon, l’assistente AI integrato in Docker Desktop, riceve i pulsanti Authenticate e Cancel per i flussi OAuth dei server MCP. I team che usano MCP server con autenticazione OAuth possono ora completare o rifiutare il flusso direttamente dalla chat bubble di Gordon.

Componenti aggiornati

• Docker Engine v29.5.3
• containerd v2.2.4
• Docker Buildx v0.34.1
• Docker Offload v0.6.3
• Docker Agent v1.70.0
• Docker MCP gateway v0.42.2
• docker pass v0.1.2
• DHI CLI (dhictl) v0.0.4

Bug fix rilevanti

• Windows/WSL: risolto un blocco su “Starting the Docker Engine…” dopo una registrazione WSL fallita che lasciava un VHDX orfano su disco
• Windows Containers mode: risolto un hang allo shutdown che causava uscite lente o incomplete
• ECI (Enhanced Container Isolation): corretta una regressione per cui docker cp con ECI abilitato impostava erroneamente la proprietà dei file a nobody:nogroup
• Shutdown: corretto il codice di uscita 150 su shutdown via SIGINT/SIGTERM, che generava falsi segnali di errore nei sistemi di supervisione

Come aggiornare

Docker Desktop si aggiorna automaticamente nella maggior parte delle configurazioni. Per aggiornare manualmente:

# Linux (.deb)
sudo apt-get update && sudo apt-get install --only-upgrade docker-desktop

Fonte: Docker Desktop Release Notes — docs.docker.com

Le union types sono finalmente arrivate in C#. Disponibili in anteprima a partire da .NET 11 Preview 2, C# 15 introduce la parola chiave union che consente di dichiarare un tipo che può contenere esattamente uno tra un insieme fisso di tipi, con conversioni implicite e pattern matching esaustivo garantito dal compilatore.

È una delle funzionalità più richieste dalla community da anni, e capire come funziona — e soprattutto perché è stata progettata in questo modo — fa la differenza tra usarla correttamente o incappare negli stessi antipattern che esistevano prima.

Il problema che le union types risolvono

Prima di C# 15, quando un metodo doveva restituire uno tra diversi tipi possibili, le opzioni disponibili erano tutte imperfette:

• object: nessun vincolo sui tipi effettivamente memorizzati; il chiamante doveva gestire logica difensiva per valori inattesi.
• Interfacce marcatore o classi base astratte: più sicure, ma non “chiuse” — chiunque poteva implementare l’interfaccia o derivare dalla classe base, quindi il compilatore non poteva mai considerare l’insieme completo dei tipi possibili.
• Librerie di terze parti come OneOf: funzionali, ma senza supporto diretto del compilatore per l’esaustività.

Un caso tipico è il risultato di un’operazione che può restituire un valore di successo oppure un errore: si potrebbe usare object, un’eccezione, oppure un tipo result wrapper. Nessuna di queste opzioni è soddisfacente perché manca la garanzia statale che tutti i casi siano gestiti.

Le union types risolvono questi problemi dichiarando un insieme chiuso di “case types”: non devono essere correlati tra loro, nessun altro tipo può essere aggiunto, e il compilatore garantisce che le espressioni switch che gestiscono la union siano esaustive — senza aver bisogno di un ramo _ o default.

Sintassi di base

La dichiarazione è minimalista:

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

Pet pet2 = new Cat("Whiskers");
Console.WriteLine(pet2.Value); // Cat { Name = Whiskers }

Pattern matching esaustivo

Quando si usa un’istanza di un tipo union non nulla, il compilatore conosce l’insieme completo dei case types, quindi un’espressione switch che li copre tutti è esaustiva — senza bisogno del _ finale:

string name = pet switch
{
    Dog d => d.Name,
    Cat c => c.Name,
    Bird b => b.Name,
};

I pattern si applicano alla proprietà Value della union, non alla union struct stessa. Questo “unwrapping” è automatico — si scrive Dog d e il compilatore verifica Value internamente. Le eccezioni sono var e _, che si applicano al valore della union stessa.

Per gestire il valore di default (null):

Pet pet = default;

var description = pet switch
{
    Dog d => d.Name,
    Cat c => c.Name,
    Bird b => b.Name,
    null => "nessun animale",
};
// description è "nessun animale"

Union con corpo e metodi helper

È possibile aggiungere membri helper alla union tramite un corpo, proprio come per qualsiasi altra dichiarazione di tipo. Un esempio pratico è OneOrMore<T>, utile per API che accettano sia un singolo elemento che una collezione:

public union OneOrMore<T>(T, IEnumerable<T>)
{
    public IEnumerable<T> AsEnumerable() => Value switch
    {
        T single => [single],
        IEnumerable<T> multiple => multiple,
        null => []
    };
}

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
    Console.Write($"[{tag}] ");
// [dotnet]

foreach (var tag in moreTags.AsEnumerable())
    Console.Write($"[{tag}] ");
// [csharp] [unions] [preview]

Compatibilità con librerie esistenti e scenari avanzati

Per le librerie che già forniscono tipi union-like con proprie strategie di storage (come quelle basate su OneOf), C# 15 prevede un meccanismo di compatibilità: qualsiasi classe o struct con l’attributo [System.Runtime.CompilerServices.Union] viene riconosciuta come tipo union dal compilatore, purché segua il pattern base — costruttori pubblici a parametro singolo e proprietà Value pubblica.

Per scenari ad alte prestazioni dove i case types includono tipi valore, le librerie possono implementare il pattern di accesso non-boxing aggiungendo una proprietà HasValue e metodi TryGetValue. Il tipo union generato dal compilatore usa object? internamente e quindi fa boxing dei tipi valore — per hot path critici conviene valutare i custom union types.

Come provare le union types oggi

Le union types sono disponibili a partire da .NET 11 Preview 2. I passaggi per iniziare sono:

1. Installare il .NET 11 Preview SDK
2. Creare o aggiornare un progetto che punta a net11.0
3. Impostare <LangVersion>preview</LangVersion> nel file di progetto

Poiché UnionAttribute e IUnion non sono ancora inclusi nel runtime nel Preview 2, vanno dichiarati manualmente nel progetto:

namespace System.Runtime.CompilerServices
{
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
        AllowMultiple = false)]
    public sealed class UnionAttribute : Attribute;

    public interface IUnion
    {
        object? Value { get; }
    }
}

Il quadro più ampio: la roadmap dell’esaustività

Le union types fanno parte di una strategia più ampia del team C# per portare la verifica dell’esaustività direttamente nel compilatore. Le proposte correlate attualmente in discussione sono:

• Closed hierarchies: il modificatore closed su una classe impedisce la dichiarazione di classi derivate al di fuori dell’assembly di definizione, consentendo al compilatore di considerare esaustive le espressioni switch sulla gerarchia.
• Closed enums: un closed enum impedisce la creazione di valori diversi dai membri dichiarati, risolvendo il problema dei valori enum “numerici” inattesi.

Insieme, questi tre meccanismi danno a C# un percorso completo verso la verifica statica dell’esaustività: union types per insiemi chiusi di tipi, closed hierarchies per gerarchie sigillate, closed enums per insiemi fissi di valori.

Conclusione

Le union types in C# 15 non sono un semplice porting delle discriminated union di F#: sono state progettate come aggiunta nativa all’ecosistema C#, composte da tipi esistenti, integrate con il sistema di pattern matching già consolidato, e compatibili con le librerie union-like già diffuse. La garanzia di esaustività del compilatore è il beneficio più concreto: i casi mancanti diventano avvisi a tempo di compilazione, non bug a runtime.

La feature è in preview e il team accetta feedback attivamente su GitHub. Vale la pena esplorarla ora per contribuire alla forma definitiva della feature, prevista per la release di novembre 2026 con .NET 11.

Fonte: Explore union types in C# 15 – .NET Blog

Si parla di:
Toggle

Un server IIS abbandonato con .NET Framework obsoleto da un decennio, settantacinque giorni di paziente ricognizione e poi un’offensiva fulminea: questo è il modus operandi di OP-512, un nuovo cluster di cyberspionaggio di presunta origine cinese scoperto da ReliaQuest grazie alla propria piattaforma di AI agentiva. La scoperta aggiunge un quarto attore al già affollato panorama degli APT cinesi che prendono di mira i server IIS aziendali, ma con un livello di sofisticazione che supera significativamente i gruppi precedentemente documentati.

La scoperta: quando l’AI vede ciò che l’analista non riesce a collegare

Il 5 giugno 2026, ReliaQuest ha pubblicato un’analisi dettagliata di un’intrusione rilevata nell’ambiente di un cliente. L’elemento distintivo non è stato solo l’attacco in sé, ma il modo in cui è stato scoperto: la piattaforma GreyMatter Agentic AI ha correlato automaticamente decine di eventi apparentemente scollegati — creazione di web shell, query DNS anomale, caricamento riflessivo di assembly .NET, esecuzione di comandi da processi del web server — ricostruendo in pochi minuti l’intera catena d’attacco che un analista umano avrebbe impiegato ore o giorni a ricostituire manualmente.

Il cluster, denominato “OP-512”, è stato attribuito con moderata-alta confidenza alla Cina, sulla base di indicatori tattici, tecnici e procedurali (TTP) che si sovrappongono parzialmente ad altri gruppi noti come CL-STA-0048, GhostRedirector e DragonRank. Tuttavia, OP-512 presenta caratteristiche uniche che ne fanno un’entità distinta: un framework di web shell costruito su misura, con crittografia per-deployment, che rende inefficace qualsiasi rilevamento basato su firme.

Il bersaglio: infrastruttura legacy come porta d’ingresso

Il server compromesso eseguiva Windows Server 2016 con .NET Framework 4.0, una versione priva di aggiornamenti di sicurezza dal 2016. I server IIS in zona demilitarizzata (DMZ) rappresentano un bersaglio prediletto per gli operatori di cyberspionaggio: si trovano al confine tra la rete esposta a Internet e la rete interna, ricevono meno monitoraggio rispetto all’infrastruttura core e fungono da pivot point ideale per muoversi lateralmente.

La telemetria EDR mostrava attività sospetta sullo stesso host già 75 giorni prima dell’attacco principale, con query DNS verso il dominio ashx.lhlsjcb[.]com. Questa prima fase — probabilmente ricognizione e test delle capacità di accesso — è tipica degli cluster di spionaggio state-sponsored, che non hanno fretta e possono permettersi di aspettare il momento più opportuno.

La fase offensiva: pochi minuti per stabilire il controllo

Quando OP-512 ha deciso di agire, ha operato con velocità e metodo. In un arco temporale di pochi minuti, il processo worker di IIS (w3wp.exe) ha scritto nella directory di upload dell’applicazione tre web shell, ciascuna con una funzione specifica:

• File manager .aspx con canale C2 self-reporting: alla prima visita, la shell codifica il proprio URL in esadecimale e lo trasmette come query DNS verso il dominio controllato dagli attaccanti (hcgos[.]com, con pattern a.<hex>.c.hcgos[.]com). Se la query DNS fallisce, attiva un canale di fallback HTTP verso un server C2 separato. Il server di fallback è stato collegato da ricercatori indipendenti a infrastrutture Meterpreter.
• Due command handler .ashx con autenticazione crittografica: ciascuno gated da autenticazione RSA+RC4 con chiavi diverse tra i due handler. Il processo di esecuzione segue quattro fasi sequenziali: decodifica Base64 del corpo della richiesta HTTP, decifratura RC4 del payload, verifica della firma RSA contro la chiave pubblica embedded, esecuzione del comando solo se la verifica ha successo.

L’elemento più sofisticato è la generazione crittograficamente unica per ogni deployment: un builder automatizzato produce istanze dal medesimo template, randomizzando i nomi di variabili e metodi e iniettando variabili morte e commenti spazzatura. Il risultato sono file che eseguono la stessa operazione ma producono hash completamente diversi, rendendo inutile il rilevamento basato su firme.

Privilege Escalation: la suite “Potato” caricata direttamente in memoria

Con le web shell operative, OP-512 ha caricato direttamente nella memoria del processo w3wp.exe quattro toolkit di post-exploitation, senza scrivere nulla su disco:

• BadPotato, SweetPotato, EfsPotato: la “Potato Suite”, una raccolta documentata di exploit Windows che abusano di servizi integrati per elevare i privilegi da un account di servizio limitato a SYSTEM. La presenza di questi strumenti in OP-512 aggiunge un dato di attribuzione, poiché compaiono anche in CL-STA-0048 e GhostRedirector.
• GhostKit: un toolkit non documentato pubblicamente, probabilmente un’etichetta vendor-specifica della telemetria EDR piuttosto che un tool consolidato.

I comandi di verifica post-escalation (whoami e whoami /priv) sono stati eseguiti come stringhe base64-encoded — una codifica identica carattere per carattere a quella documentata nel compromesso ArcGIS di Flax Typhoon, suggerendo tooling o playbook condivisi nell’ecosistema degli APT cinesi.

Il problema del loop: quando la prevenzione non basta

Un aspetto particolarmente istruttivo dell’incidente è ciò che è accaduto dopo l’intervento dell’endpoint protection: il sistema ha terminato il processo malevolo, ma IIS riavvia automaticamente i worker process dopo un crash o una terminazione forzata. Il risultato è stato un loop in cui la protezione si attivava ripetutamente mentre l’attività malevola continuava. Bloccare un processo senza isolare l’host crea esattamente questa finestra di vulnerabilità che gli attaccanti sfruttano intenzionalmente.

Un ulteriore problema per i responder è la persistenza delle DLL compilate da ASP.NET: quando le web shell vengono eseguite per la prima volta, il runtime .NET le compila in librerie DLL e le salva in una directory temporanea. Queste DLL sopravvivono alla cancellazione dei file originali e possono essere riattivate. La risposta all’incidente deve quindi includere la pulizia delle directory di compilazione temporanea di ASP.NET.

Timestomping: nascondersi nel passato

OP-512 implementa una tecnica di timestomping automatizzato particolarmente raffinata: le web shell analizzano ogni file e sottodirectory circostante, calcolano il timestamp mediano di ultima modifica e sovrascrivono i propri timestamp di creazione e modifica per allinearsi. Una web shell scritta nel 2026 tra file del 2022 sembrerebbe vecchia di anni. La funzione accetta anche un timestamp esplicito come input, permettendo all’operatore di retrodatare un file a uno specifico evento o finestra di patch.

OP-512 nel panorama degli APT cinesi su IIS

ReliaQuest posiziona OP-512 come quarto cluster cinese documentato nell’ultimo anno a colpire server IIS, ma con caratteristiche che lo distinguono dagli altri tre:

• CL-STA-0048 (l’overlap più significativo): usa query DNS con subdomain esadecimali per esfiltrare dati — OP-512 usa lo stesso encoding ma per segnalare la propria posizione, non per esfiltrare. Dipende da tool commodity come PlugX e Cobalt Strike, diversamente dal framework custom di OP-512.
• GhostRedirector e DragonRank: motivati da frodi SEO, non da spionaggio. Usano alcune delle stesse tecniche di privilege escalation ma con obiettivi completamente diversi.

IOC e Indicatori comportamentali

ReliaQuest enfatizza che gli IOC specifici di questa intrusione non saranno necessariamente presenti nelle future operazioni OP-512, data la natura generata proceduralmente del framework. I rilevamenti comportamentali sono la strada maestra:

# IOC specifici dell'intrusione
Dominio C2 primario:     ashx.lhlsjcb[.]com (attività precedente, ~75 giorni prima)
Dominio C2 secondario:   hcgos[.]com
Pattern DNS:             a.<hex>.c.hcgos[.]com
Server Meterpreter C2:   43.160.202[.]246:8053
Connessione outbound:    140.206.161[.]227:443
Source IP interazione:   124.156.129[.]151 (User-Agent: python-requests/2.33.0)

# Pattern comportamentali da monitorare
- w3wp.exe che genera query DNS con subdomain esadecimali lunghi
- Caricamento riflessivo di componenti crittografici in w3wp.exe
- Creazione di DLL in directory temporanee ASP.NET fuori dai cicli di deployment
- Risposte HTTP cifrate da endpoint .ashx che dovrebbero restituire contenuto standard

Due righe per i difensori

Per i team di sicurezza che gestiscono ambienti con server IIS legacy, le priorità immediate sono: ritirare o isolare i server con .NET Framework end-of-life esposti a Internet; disabilitare l’esecuzione di script nelle directory di upload via handler IIS per estensioni .aspx, .ashx, .asp e .asmx; monitorare le directory di compilazione temporanea ASP.NET per creazione di DLL fuori dai cicli di deployment normali; e — fondamentalmente — non chiudere un incidente senza aver identificato e rimediato la vulnerabilità di accesso iniziale. OP-512 dimostra che gli operatori di spionaggio contano esattamente su questa superficialità per tornare dopo che l’allerta è rientrata.

Si parla di:
Toggle

Undici pacchetti npm malevoli, un singolo package con oltre 2,7 milioni di download, un’infrastruttura di comando e controllo ancorata alla blockchain Ethereum: questa è la mappa di una campagna di supply chain attack che i ricercatori di Cyfirma hanno identificato e documentato nel dettaglio, prendendo di mira sviluppatori blockchain, progetti Web3 e operatori di wallet crypto.

La trappola nel registro npm

Il registro npm — il più grande ecosistema di pacchetti JavaScript con oltre due milioni di moduli disponibili — si conferma ancora una volta un bersaglio privilegiato per gli attori malevoli. Questa campagna ha sfruttato una combinazione di tecniche consolidate e innovazioni notevoli, a partire dal typosquatting: i pacchetti malevoli mimicavano fedelmente nomi di librerie legittime e ampiamente utilizzate nell’ecosistema blockchain, come ethers.js, le SDK di Moralis, le utility Coinbase e i tool di sviluppo Stellar.

Il pacchetto più distribuito, moralis-sdk, ha raggiunto la cifra di 2,7 milioni di download prima della rimozione — un numero che rende l’entità potenziale della compromissione difficile da quantificare con precisione. Gli altri dieci pacchetti identificati includono ethers-jss, coinbase-wallet-utils, Ganach (typosquatting di Ganache), Solidty (typosquatting di Solidity), Stelar-sdk, oltre a hardhat-deploy-utils, web3-deploy-helper, defi-sdk-core, ethers-compat ed ethereum-dev-utils.

Meccanismo di esecuzione: lifecycle hooks come vettore d’attacco

Il vettore di infezione primario si basa sull’abuso degli script di ciclo di vita npm (postinstall e preinstall). Quando uno sviluppatore esegue npm install, il codice malevolo viene attivato automaticamente, senza alcuna interazione ulteriore. Questo approccio è particolarmente insidioso perché sfrutta funzionalità native del gestore di pacchetti, difficili da bloccare senza compromettere la funzionalità legittima.

Il pacchetto moralis-sdk fungeva da downloader multi-stadio: recuperava payload aggiuntivi da servizi di hosting remoto come Pastefy e GitHub, realizzando un’architettura di distribuzione del malware altamente resiliente. I pacchetti coinbase-wallet-utils e ethers-jss erano invece dedicati principalmente alle fasi di ricognizione ed esfiltrazione, con focus specifico sul furto di wallet crypto.

Blockchain come infrastruttura C2: l’innovazione più significativa

L’elemento tecnico più rilevante della campagna è l’utilizzo della blockchain Ethereum come meccanismo di command and control. Gli attori malevoli hanno impiegato smart contract Ethereum e transazioni on-chain sia per il recupero della configurazione dell’infrastruttura sia per l’esfiltrazione di credenziali. Questo approccio rende il C2 estremamente difficile da bloccare: non esistono domini da eliminare, non esistono IP da inserire in blacklist, e le transazioni on-chain sono immutabili e pseudoanonime.

Gli indirizzi Ethereum identificati nella campagna come target per la configurazione e l’esfiltrazione includono 0xa1b40044EBc2794f207D45143Bd82a1B86156c6b, 0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84 e 0xCBbecC5E5Eb88582e6305cF6ab688f03e02Ce16f.

Tipologia di dati rubati

L’obiettivo principale era la raccolta di segreti ad alto valore economico e operativo dagli ambienti di sviluppo compromessi. Il malware prendeva di mira: chiavi private di wallet crypto e frasi mnemoniche (seed phrase), chiavi SSH, credenziali cloud (AWS, Azure, GCP), token di autenticazione API (NPM_TOKEN, GITHUB_TOKEN), chiavi di servizi blockchain come Infura e Alchemy, oltre a file di configurazione di ambienti di sviluppo specifici come secrets.json, hardhat.config.js e foundry.toml.

Mappatura MITRE ATT&CK

La campagna copre un ampio spettro di tecniche MITRE, tra cui T1195.002 (Supply Chain Compromise), T1204.002 (Malicious File Execution), T1036.005 (Masquerading), T1552 (Unsecured Credentials), T1528 (Steal Application Access Token) e T1583.006 (Acquire Infrastructure via Web Services).

Indicatori di Compromissione (IoC)

# Pacchetti npm malevoli
moralis-sdk, ethers-jss, coinbase-wallet-utils
Ganach, Solidty, Stelar-sdk
hardhat-deploy-utils, web3-deploy-helper, defi-sdk-core, ethers-compat, ethereum-dev-utils

# Hash SHA256
d94a2444268b339dfda2615f7800322fb318e0a484414bb17016cfcd5eb07c44
6585ca0d3e26c20ced638f46f4a89eea924d411b8753d3fcf434663593c7cf0b
17bad5ae5b2ac262f5f18854853869840245c344105aa38c7f550ef51d2e5f26

# Hash SHA1
53b91117db931d3acbbfd15aa8400bb6691e023d
63154cd9c79f9d14eb9be6c4efc2a778d31646ec
74d3d5ab6d0fa4c6a5860598231728a6a893ecf7

# URL infrastruttura
pastefy.app/RhPBKGli/raw
http://193.233.201.21:3001

# Indirizzi Ethereum (C2 on-chain)
0xa1b40044EBc2794f207D45143Bd82a1B86156c6b
0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84
0xCBbecC5E5Eb88582e6305cF6ab688f03e02Ce16f

Due righe per i difensori

Questa campagna evidenzia come i supply chain attack sul registro npm stiano diventando sempre più sofisticati. I difensori e i team di sicurezza DevOps dovrebbero implementare: verifica sistematica dell’integrità dei pacchetti prima dell’installazione; utilizzo di strumenti come npm audit e analizzatori comportamentali di pacchetti (Socket.dev, Snyk, Phylum); monitoraggio delle connessioni di rete generate durante npm install in ambienti di build CI/CD isolati; blocco preventivo dei lifecycle hook di terze parti nelle pipeline di produzione; audit periodico delle dipendenze con specifico focus su pacchetti con nomi simili a librerie popolari. L’uso della blockchain come infrastruttura C2 rappresenta una frontiera che richiede approcci di difesa diversi dal tradizionale blocco DNS/IP: è necessario monitorare le chiamate RPC verso nodi Ethereum non autorizzati nelle reti aziendali.

La ricerca completa di Cyfirma è disponibile su: cyfirma.com

Si parla di:
Toggle

Il 5 giugno 2026, il worm Miasma — variante della famiglia Shai-Hulud attribuita al gruppo TeamPCP — ha raggiunto le organizzazioni GitHub di Microsoft. In 105 secondi, il sistema automatico di enforcement di GitHub ha disabilitato 73 repository tra Azure, Azure-Samples, microsoft e MicrosoftDocs. L’attacco introduce un cambio di paradigma nei supply chain attack: il trigger non è più l’installazione di un pacchetto, ma l’apertura di una cartella nel proprio editor o AI coding agent.

La catena di infezione: dal PyPI al repository injection

Per comprendere l’incidente del 5 giugno è necessario risalire al 19 maggio 2026, quando la stessa campagna Miasma aveva compromesso il pacchetto PyPI durabletask di Microsoft. In quell’occasione, un attaccante aveva caricato tre versioni malevole del pacchetto in una finestra di 35 minuti, usando un token di publishing compromesso, bypassando completamente la pipeline CI/CD. Il payload — un file rope.pyz da 28KB — rubava credenziali da AWS, Azure, GCP, Kubernetes e oltre 90 configurazioni di developer tool.

Il 5 giugno, lo stesso account contributor compromesso è stato usato per iniettare un commit direttamente nel repository GitHub Azure/durabletask. Il commit (5f456b8) riportava il messaggio “Switched DataConverter to OrchestrationContext [skip ci]” — ma non modificava alcun file sorgente. Aggiungeva invece 5 file di configurazione, con un timestamp retrodatato al 2020 per eludere il rilevamento, e il flag [skip ci] per sopprimere l’esecuzione della pipeline.

Quattro vettori, un payload: come Miasma abusa degli AI coding agent

L’attacco è notevole per la sua copertura trasversale degli strumenti di sviluppo più diffusi. I cinque file iniettati puntano tutti allo stesso payload (.github/setup.js, un file JavaScript da 4,6 MB altamente offuscato), attivandolo con meccanismi diversi:

• .claude/settings.json: hook SessionStart per Claude Code — esegue il payload all’avvio di qualsiasi sessione Claude nel repository.
• .gemini/settings.json: hook identico per Gemini CLI.
• .cursor/rules/setup.mdc: prompt injection per Cursor AI — istruisce l’agente a eseguire il payload spacciandolo per “inizializzazione obbligatoria del progetto”. Il flag alwaysApply: true garantisce l’attivazione indipendentemente dal file su cui si sta lavorando.
• .vscode/tasks.json: task con runOptions.runOn: "folderOpen" — eseguito automaticamente da VS Code all’apertura della cartella, senza alcun coinvolgimento di AI agent.

Il punto critico: clonare il repository è sicuro, aprirlo nell’editor non lo è. Questo inverte l’assunzione di sicurezza su cui si basano la maggior parte dei workflow di sviluppo.

73 repository in 105 secondi: l’automazione di GitHub come ultima linea di difesa

Ore dopo il commit malevolo, il sistema automatico di abuse detection di GitHub ha disabilitato 73 repository in due ondate distinte, separate da un gap di 56 secondi:

• Wave 1 (16:00:50 → 16:01:28 UTC): 39 repository in 38 secondi
• Wave 2 (16:02:24 → 16:02:35 UTC): 34 repository in 11 secondi

Tutti i repository restituiscono HTTP 403 con "reason": "tos". Tra quelli colpiti figurano repository critici come azure-functions-host, azure-functions-core-tools, l’intera famiglia dei worker (.NET, Node.js, Python, Java, PowerShell, Go) e — con conseguenze immediate — Azure/functions-action, la GitHub Action ufficiale per il deployment di Azure Functions.

La disabilitazione di functions-action ha rotto immediatamente ogni pipeline CI/CD che referenziava Azure/functions-action@v1. Un thread su Microsoft Learn ha raccolto oltre 20 segnalazioni di pipeline bloccate in poche ore. Microsoft ha inizialmente classificato l’evento come “violazione delle policy GitHub”, salvo poi ricaratterizzarlo come “internal management issue under investigation”.

Attributione: TeamPCP e il nexus Shai-Hulud/Miasma

L’incidente si inserisce nella campagna più ampia del gruppo TeamPCP, attivo da almeno la primavera 2026. Il payload del 19 maggio conteneva un C2 secondario (t.m-kosche[.]com) già noto come infrastruttura TeamPCP. Il gruppo ha una storia di attacchi supply chain di ampia portata: TanStack (42 pacchetti npm, CVE-2026-45321, CVSS 9.6), Mistral AI, l’ecosistema @antv (639 versioni su 323 pacchetti npm), @redhat-cloud-services (32 pacchetti), LiteLLM, Telnyx e Checkmarx.

Miasma è valutata come una variante evoluta del worm Mini Shai-Hulud: Wave 1 (giugno 1) usava hook preinstall npm; Wave 2 (giugno 3) ha introdotto la tecnica Phantom Gyp — file binding.gyp malevoli che eludono le difese supply chain tradizionali; Wave 3 (giugno 5) ha abbandonato il package manager del tutto, puntando direttamente al repository e all’editor.

Indicatori di compromissione

# Domini C2
check.git-service[.]com      # C2 primario payload maggio
t.m-kosche[.]com             # Infrastruttura TeamPCP (C2 secondario)

# Hash commit malevolo
5f456b8  (Azure/durabletask, 2026-06-05)

# File sospetti da cercare nei repository
.claude/settings.json        # Hook SessionStart
.gemini/settings.json        # Hook SessionStart
.cursor/rules/setup.mdc      # Prompt injection alwaysApply
.vscode/tasks.json           # runOn: folderOpen
.github/setup.js             # Payload principale (4.6 MB offuscato)

Due righe per i difensori

Chi ha clonato repository Azure/microsoft dopo il 2 giugno 2026 e li ha aperti in un editor deve considerare il sistema compromesso e ruotare immediatamente tutte le credenziali accessibili: GitHub token, npm token, AWS keys, Azure service principal, GCP service account, SSH key, Kubernetes secrets, Docker config, variabili d’ambiente e shell history.

Per prevenire incidenti analoghi: ispezionare i repository clonati per i file sopra elencati prima di aprirli; pinnare le GitHub Actions a commit SHA specifici invece di tag mutabili; abilitare branch protection con revisione obbligatoria dei PR; usare PyPI Trusted Publishing (OIDC) al posto di token long-lived; monitorare le connessioni outbound dai runner CI/CD verso domini sconosciuti.

L’attacco Miasma su Microsoft rappresenta un salto qualitativo nella minaccia supply chain: non bastano più le difese sul package manager se gli attaccanti possono iniettare hook direttamente nell’editor dello sviluppatore. La superficie d’attacco si è spostata dall’installazione all’apertura — e le difese devono adeguarsi di conseguenza.

Una distribuzione GNU/Linux, spesso chiamata distro, è un sistema operativo completo costruito attorno al kernel Linux, il componente centrale che gestisce la comunicazione tra hardware e software. Quando si afferma di utilizzare Linux, in...

🔗 Leggi il post completo

Il progetto Asahi Linux, che porta il supporto per GNU/Linux sui Mac equipaggiati con chip Apple Silicon (famiglia di processori sviluppati da Apple per sostituire i tradizionali chip Intel nei propri computer Mac), ha...

🔗 Leggi il post completo

La serie Xiaomi 17 ha raggiunto un traguardo storico nel mercato cinese: secondo i dati di vendita aggiornati alla settimana 22 del 2026, le unità vendute hanno superato i 5 milioni di pezzi, per la precisione circa 508.000 unità. Si tratta del risultato migliore mai ottenuto da Xiaomi con la sua linea flagship in Cina.

Una gamma premium che convince il mercato

La serie Xiaomi 17 si compone di più varianti: Xiaomi 17, Xiaomi 17 Pro, Xiaomi 17 Pro Max, Xiaomi 17 Ultra e altri modelli aggiunti dopo il lancio iniziale. Tutti condividono il processore Qualcomm Snapdragon 8 Elite Gen 5, uno dei chip più potenti attualmente disponibili per smartphone Android. Xiaomi ha puntato su questo segmento premium con una strategia chiara, e i numeri confermano che la strategia sta funzionando.

Xiaomi sfida i top brand nel fascia alta

Il risultato di 5 milioni di unità è particolarmente significativo considerando che si parla di smartphone ad alto prezzo, un segmento tradizionalmente dominato da Samsung e Apple in molti mercati. In Cina, Xiaomi è riuscita a ritagliarsi uno spazio importante anche nel premium, grazie a un buon rapporto qualità-prezzo rispetto ai concorrenti diretti. Il successo di Xiaomi 17 apre la strada alla prossima generazione, che potrebbe puntare ancora più in alto.

I prossimi smartphone Redmi si avvicinano al debutto. La serie Redmi 17 e la linea Redmi Note 17 hanno ottenuto le prime certificazioni internazionali, segnalando che il lancio commerciale è previsto per il terzo trimestre del 2026. Tra le novità più interessanti, l’arrivo confermato in Giappone del Redmi 17 lascia sperare in una distribuzione anche in Europa.

Redmi 17: certificazione IMDA a Singapore

Il database dell’autorità regolatoria singaporiana IMDA ha registrato due nuovi modelli: 2606FRN72Y e 26012RN62Y, riconducibili alla serie Redmi 17. Il modello base monterà un chip Qualcomm Snapdragon 6s 4G Gen 2, posizionandosi nella fascia entry-level. Sono previste varianti per diversi mercati geografici, e le certificazioni IEECE indicano esplicitamente la sigla “JP” per il mercato giapponese.

Versione POCO e distribuzione capillare

Come spesso accade con i modelli Redmi, è probabile anche una versione POCO: in questo caso si parlerebbe di POCO C95 Pro, con le stesse specifiche di base ma personalizzazioni estetiche e di prezzo differenti. In Giappone, il Redmi 17 potrebbe essere distribuito da tutti e quattro i principali operatori (NTT Docomo, au, SoftBank, Rakuten Mobile) oltre che in versione SIM free, una copertura raramente vista per un modello Redmi.

Redmi Note 17: la fascia media si aggiorna

Anche la linea Redmi Note 17 è in fase di certificazione, con un modello europeo identificato come 26081RA18G già registrato presso l’EEC (Commissione economica eurasiatica). Questo suggerisce che la distribuzione europea dei Redmi Note 17 è in programma, con possibile arrivo anche in Italia entro la fine dell’anno. Maggiori dettagli sulle specifiche complete sono attesi nelle prossime settimane.

Google ha distribuito Android 17 QPR1 Beta 4 per i dispositivi Pixel compatibili, a partire dal Pixel 6 in poi. L’aggiornamento è disponibile via OTA dal 10 giugno 2026 e, a differenza delle versioni precedenti, punta soprattutto alla correzione di bug piuttosto che all’introduzione di nuove funzionalità.

Un aggiornamento orientato alla qualità

I QPR (Quarterly Platform Release) sono rilasci periodici che Google distribuisce tra un aggiornamento principale e l’altro, con l’obiettivo di migliorare stabilità e prestazioni. La Beta 4 di Android 17 QPR1 segue questa logica: le grandi novità sono già state introdotte nelle versioni precedenti, e ora il team di Mountain View si concentra sulla rifinitura del sistema in vista del rilascio stabile.

Corretti bug fastidiosi, incluso il Quick Tap

Tra i problemi risolti spicca un malfunzionamento legato alla funzione Quick Tap, che permette di eseguire azioni toccando il retro dello smartphone. In alcuni dispositivi, il tocco sul retro non attivava correttamente il blocco schermo, rendendo la feature inaffidabile. Google ha risolto questo inconveniente con il nuovo aggiornamento, insieme ad altri bug segnalati dalla community.

La versione stabile di Android 17 QPR1 è vicina

Il fatto che questa beta si concentri quasi esclusivamente sulla correzione di errori indica che lo sviluppo è entrato nella fase conclusiva. Gli utenti che partecipano al programma beta possono ricevere l’aggiornamento manualmente tramite le impostazioni di sistema. La versione pubblica definitiva di Android 17 QPR1 dovrebbe arrivare nelle prossime settimane, completando il ciclo di aggiornamenti del sistema operativo prima dell’annuncio di Android 18.

Samsung sta accelerando lo sviluppo di One UI 9.0, la prossima grande interfaccia basata su Android 17. Dopo i test iniziali sui modelli di fascia alta, l’azienda ha ora esteso le prove anche ai dispositivi della serie Galaxy A, a conferma che il rollout sarà capillare e coinvolgerà un’ampia gamma di smartphone.

Galaxy A57, A34 e A17 5G nel mirino

I leaker Tarun Vats e Mohammed Khatri hanno individuato sui server OTA di Samsung nuovi firmware di test per Galaxy A57, Galaxy A34 e Galaxy A17 5G. Si tratta di build basate su Android 17 con One UI 9.0, a conferma che Samsung non limiterà il nuovo aggiornamento ai soli top di gamma, ma lo estenderà a un portafoglio molto più ampio di dispositivi, inclusi quelli di fascia media.

One UI 8.5 ha già completato il rollout

L’avvio dei test su One UI 9.0 arriva dopo che il rollout di One UI 8.5 si è quasi concluso. Samsung segue un ciclo di aggiornamenti sempre più aggressivo, con versioni intermedie (.5) che introducono nuove funzionalità tra un major update e l’altro. Con One UI 9.0, il colosso coreano punta ad aggiornare sia i flagship Galaxy S26 che i modelli più accessibili della linea A entro il 2026.

Cosa aspettarsi da One UI 9.0

One UI 9.0 porterà le novità di Android 17 integrate nell’ecosistema Samsung, con miglioramenti attesi nelle funzionalità AI di Galaxy, nell’interfaccia utente e nella gestione della privacy. La data di lancio ufficiale non è ancora stata comunicata, ma i test su più categorie di prodotti lasciano intuire che Samsung voglia farsi trovare pronta non appena Google rilascerà la versione stabile di Android 17.

Dal Computex 2026 arriva uno dei dispositivi più originali dell’anno: Ayaneo Pocket Play, uno smartphone Android che incorpora un gamepad fisico a scorrimento. Un design che riporta alla memoria il leggendario Sony Ericsson Xperia Play del 2011, reinterpretato con hardware moderno da fascia alta.

Design a scorrimento: il gamepad si nasconde sotto il display

Il Pocket Play adotta un meccanismo a scorrimento orizzontale: tenendo il telefono in modalità landscape e facendo scivolare il display verso l’alto, emerge un controller fisico completo di D-pad, tasti azione, quattro tasti dorsali e due touchpad circolari al posto degli analogici. Secondo chi ha provato il dispositivo in anteprima al Computex, i touchpad funzionano meglio del previsto e rappresentano un’alternativa valida agli stick tradizionali per i giochi Android e i servizi di cloud gaming.

Specifiche tecniche di alto livello

Nonostante il form factor insolito, l’Ayaneo Pocket Play non scende a compromessi sulla potenza:

• Processore MediaTek Dimensity 9300
• Display OLED da 6,8 pollici con refresh rate fino a 165 Hz
• Sistema operativo Android

Come prevedibile, il meccanismo a scorrimento e il controller integrato rendono il dispositivo più spesso di uno smartphone tradizionale. La sezione fotografica non è una priorità per questo prodotto, che si rivolge chiaramente agli appassionati di gaming mobile.

Prezzo e disponibilità ancora ignoti

Ayaneo non ha ancora comunicato né il prezzo né la data di lancio del Pocket Play. Considerando i componenti premium e la lavorazione meccanica del corpo, il costo finale sarà probabilmente elevato. Per gli appassionati di retrogaming, emulatori e cloud gaming su Android, potrebbe tuttavia rappresentare un’opzione unica nel suo genere.

Un fenomeno curioso sta emergendo nel mercato degli smartphone usati: l’Xperia 5 V, modello tecnicamente inferiore nella gamma Sony del 2023, supera l’Xperia 1 V in termini di prezzo nell’usato certificato. Una vera inversione di valori che racconta molto sul mercato attuale degli smartphone Android compatti.

I numeri del paradosso

Sui principali marketplace come Amazon, le versioni ricondizionate mostrano una situazione inattesa: l’Xperia 1 V si trova a circa 63.162 yen, mentre l’Xperia 5 V viene proposto a 63.980 yen. La differenza è minima, ma il fatto che il modello “inferiore” costi di più è di per sé un fenomeno degno di nota. Al lancio, la differenza di prezzo tra i due era di oltre 50.000 yen (circa 300 euro), con l’Xperia 1 V nettamente più costoso.

Perché l’Xperia 5 V è così ricercato?

La risposta è semplice: Sony ha abbandonato il segmento degli smartphone Android compatti e ad alte prestazioni. Dopo l’Xperia 5 V non è mai arrivato un successore, e con la tendenza del mercato verso dispositivi sempre più grandi, trovare un flagship con schermo da 6,1 pollici e Snapdragon 8 Gen 2 è diventato praticamente impossibile. Gli utenti che amano i telefoni maneggevoli si sono riversati sull’usato, facendo salire i prezzi.

Un mercato di nicchia sempre più prezioso

Il caso Xperia 5 V dimostra che esiste una domanda reale e insoddisfatta per smartphone Android compatti di fascia alta. Con quasi nessun produttore che offre oggi questa combinazione, chi vuole una schermata sotto i 6,3 pollici abbinata a prestazioni top si ritrova con poche opzioni. Un’opportunità che qualche brand potrebbe cogliere in futuro, magari proprio Sony stessa.

Il progetto aMule, uno dei client più apprezzati per la rete eD2k (acronimo di eDonkey2000, un protocollo peer-to-peer per la condivisione di file), torna in grande stile con una nuova versione, aMule 3.0.0, la...

🔗 Leggi il post completo

Dove eravate trent’anni fa? Usavate già Linux? Vi sorprenderà sapere che a dispetto di quello che voi stavate facendo (e chissà qualche lettore nemmeno era ancora nato), nel 1996 il progetto KDE era appena stato creato. In quell’anno Matthias Ettrich ha infatti annunciato la creazione del progetto Kool Desktop Environment (KDE), un’interfaccia grafica per i...

🔗 Leggi il post completo