Nuove immagini trapelate mostrano il prossimo Galaxy Z Fold 8 da angolazioni inedite, confermando la voce più insistente delle ultime settimane: Samsung ha allargato il display principale, avvicinando il pieghevole a un formato più simile a un tablet compatto che a uno smartphone verticale. Le foto, condivise dal leaker Roland Quandt, arrivano a due giorni dal Galaxy Unpacked di Londra, dove il dispositivo sarà presentato ufficialmente insieme a Galaxy Z Fold 8 Ultra e Galaxy Z Flip 8.

Un formato più largo per contenuti orizzontali

Secondo le indiscrezioni, il display interno di Galaxy Z Fold 8 adotterà un rapporto d’aspetto vicino al 4:3 da aperto, mentre il pannello di copertina passerà a un più pratico 16:10 da circa 5,5 pollici. Un cambio di proporzioni pensato per favorire video, giochi e multitasking, superando uno dei limiti più criticati della serie: lo schermo esterno troppo stretto per un uso quotidiano confortevole.

Fotocamera doppia e nuove colorazioni

Le immagini confermano anche il comparto fotografico posteriore con doppia fotocamera e un nuovo design del cover display. Sul fronte colori, la gamma standard dovrebbe includere le tonalità Graphite, Cream e Lavender, mentre una variante Pistachio sarebbe riservata alla vendita esclusiva online, e non compare negli scatti diffusi finora.

Uno spessore ai minimi storici

Non manca l’attenzione allo spessore: da aperto, Galaxy Z Fold 8 dovrebbe fermarsi a circa 4,5 mm, un valore che, se confermato, lo renderebbe uno dei pieghevoli più sottili mai realizzati da Samsung. Resta inteso che si tratta ancora di indiscrezioni pre-lancio, e le specifiche definitive arriveranno solo con la presentazione ufficiale del 22 luglio.

L’appuntamento di Londra si preannuncia denso di novità per l’intera gamma pieghevole Samsung, con Galaxy Z Fold 8 che punta a convincere anche chi finora aveva storto il naso davanti al formato più stretto dei modelli precedenti.

Gopeed è un download manager open source multipiattaforma con supporto HTTP, BitTorrent, Magnet, ED2K, estensioni JavaScript e API RESTStai leggendo Gopeed: il download manager open source che supporta HTTP, BitTorrent, Magnet ed ED2K, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

GNOME riduce da 90 a 30 giorni il periodo di riservatezza per le vulnerabilità di sicurezza, aggiornando le procedure in risposta all'aumento delle segnalazioni generate con l'IA.Stai leggendo GNOME riduce a 30 giorni il periodo di riservatezza per le vulnerabilità di sicurezza, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Devsy crea ambienti di sviluppo riproducibili con Docker, Kubernetes e cloud. Scopri funzionalità e installazione Linux.Stai leggendo Devsy porta ambienti di sviluppo uniformi su Linux, Docker, Kubernetes e cloud, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Firefox 153 migliora HDR, editor PDF, condivisione tramite QR Code, privacy, Firefox Labs e introduce nuove funzionalità dedicate agli sviluppatori.Stai leggendo Firefox 153 migliora PDF, QR Code, privacy e introduce il supporto ai video HDR, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Quando un bug colpisce uno dei più popolari software per blog del mondo le conseguenze possono essere devastanti.
Queste due CVE producono un effetto combo che consente a chiunque, anche senza alcun account configurato all'interno della piattaforma, di ottenere una shell sul sistema che ospita il sito.
Lo spettro potenziale di applicazione del bug? Più o meno 500 milioni di siti web!

🔗 Leggi il post completo

Si parla di:
Toggle

Per quasi due anni un gruppo criminale ha pubblicato su Steam videogiochi apparentemente innocui — tra cui BlockBlasters, Dashverse, Lunara e PirateFi — che nascondevano malware capace di svuotare i portafogli cripto delle vittime. Il 15 luglio 2026 l’FBI ha arrestato il primo membro pubblicamente noto dell’operazione: Zyaire Dontaevious Zamarion Wilkins, 21 anni, di North Lauderdale, Florida, noto online come Sibel.eth. A incastrarlo non è stata un’indagine sulla blockchain, ma un dettaglio molto più terreno: un ordine di cibo a domicilio pagato con una gift card comprata con Bitcoin rubato.

Uno schema attivo da maggio 2024

Secondo la denuncia penale di 15 pagine depositata a Seattle — sede scelta non a caso, essendo la città più vicina al quartier generale di Valve a Bellevue — lo schema ha infettato circa 8.000 dispositivi e sottratto almeno 220.000 dollari da circa 80 portafogli di criptovalute, tra maggio 2024 e febbraio 2026. Il tasso di successo, poco sopra l’1% dei dispositivi infettati, non è casuale: gli otto giochi elencati nell’atto d’accusa venivano promossi su Discord, Telegram, X e LinkedIn, e i complici usavano bot per identificare utenti con portafogli cripto consistenti e contattarli direttamente, invece di affidarsi alla sola diffusione di massa.

Wilkins, secondo l’accusa, non ha scritto il malware ma ne ha finanziato lo sviluppo e curato la promozione. Chat Signal sequestrate a casa dello sviluppatore del malware — non identificato nell’atto d’accusa e a oggi non incriminato — collegano Wilkins, sotto lo pseudonimo Sibel.eth, a un pagamento di 10.000 dollari per l’acquisto di un trojan ad accesso remoto (RAT) e a discussioni su come indurre le vittime ad approvare transazioni che ne svuotavano i portafogli.

Il precedente di BlockBlasters e i fondi di beneficenza rubati

Non è la prima volta che questo cluster di giochi malevoli fa notizia. I ricercatori ZachXBT e il collettivo vx-underground avevano già stimato che il solo BlockBlasters avesse sottratto oltre 150.000 dollari a un numero di vittime compreso tra 261 e 478, incluso un episodio particolarmente odioso nel settembre 2025: 32.000 dollari donati per curare un tumore, rubati dal portafoglio di una streamer Twitch che stava raccogliendo fondi per le proprie cure oncologiche. L’FBI aveva iniziato a cercare pubblicamente le vittime di questi giochi infetti a marzo 2026, e Steam negli ultimi due anni ha visto una serie costante di incidenti simili, incluso il caso Chemia, un gioco in accesso anticipato che nascondeva tre ceppi di malware diversi: cryptojacking, infostealer e una backdoor per installare ulteriore malware in futuro.

Dalla blockchain a Uber Eats: come è stato individuato

La parte più istruttiva del caso, dal punto di vista investigativo, è la catena di tracciamento. Gli inquirenti hanno seguito i Bitcoin rubati fino a un portafoglio dello schema che li ha convertiti in oltre 150 gift card tramite Bitrefill, un servizio che permette di acquistare buoni regalo con criptovalute. Una parte consistente di quelle gift card è stata spesa su Uber Eats. Una richiesta formale (subpoena) inviata a Uber ha permesso di collegare le gift card a un account che riceveva consegne proprio all’abitazione della famiglia Wilkins a North Lauderdale e agli indirizzi frequentati dall’indagato all’Università della Florida Occidentale.

Quando gli agenti hanno perquisito l’abitazione, una settimana prima dell’arresto, hanno sequestrato diversi dispositivi e tre seed phrase di portafogli cripto, una delle quali relativa a un wallet Monero — la criptovaluta privacy-oriented spesso usata proprio per rendere più difficile questo tipo di tracciamento. La cronologia delle transazioni di Wilkins, secondo l’atto d’accusa, mostra un flusso complessivo di 382.000 dollari in criptovalute inviate o ricevute, ben oltre i 220.000 dollari attribuiti direttamente allo schema contestato.

Timeline

• Maggio 2024 – febbraio 2026: periodo di attività dello schema, otto giochi infetti distribuiti su Steam
• Settembre 2025: BlockBlasters svuota il portafoglio di una streamer Twitch che raccoglieva fondi per cure oncologiche (32.000 dollari)
• Marzo 2026: l’FBI rende pubblica la ricerca di vittime dei giochi Steam infetti
• Inizio luglio 2026: perquisizione dell’abitazione di Wilkins a North Lauderdale, sequestro di dispositivi e seed phrase
• 15 luglio 2026: arresto di Zyaire Wilkins e deposito della denuncia penale presso il tribunale federale di Seattle

Cosa resta aperto

Wilkins deve rispondere di cospirazione per l’ottenimento di informazioni tramite computer a scopo di profitto privato, un capo d’accusa che prevede fino a dieci anni di carcere. Ma la parte tecnica dell’operazione resta scoperta: lo sviluppatore del RAT e del malware che infettava i giochi non è nominato nell’atto d’accusa e, a oggi, non risulta incriminato, nonostante la sua abitazione sia già stata perquisita. È un pattern comune nelle indagini su cybercrime organizzato attorno alle criptovalute: chi finanzia e promuove viene identificato per primo, spesso tramite un errore operativo banale, mentre chi scrive il codice — più attento all’anonimato tecnico ma non necessariamente a quello finanziario — richiede più tempo.

Per i difensori, il caso conferma due lezioni già note ma sistematicamente ignorate: primo, la promozione mirata via bot verso utenti con portafogli consistenti rende inefficaci le difese basate solo sul volume di download o sulle recensioni Steam; secondo, ogni conversione di criptovaluta rubata in un servizio che tocca il mondo reale — gift card, delivery, e-commerce — riapre una superficie di tracciamento che l’uso di Monero a monte non riesce a chiudere del tutto. Per chi acquista giochi indie su Steam, resta valida la raccomandazione di isolare il portafoglio cripto su un dispositivo separato da quello usato per il gaming, e di trattare con sospetto qualsiasi titolo nuovo che chieda permessi di sistema non giustificati dal gameplay.

Indicatori e riferimenti del caso

Indagato: Zyaire Dontaevious Zamarion Wilkins, 21 anni, North Lauderdale (FL)
Alias online: Sibel.eth
Capo d'imputazione: cospirazione per ottenimento di informazioni tramite computer
                     a scopo di profitto privato (fino a 10 anni)
Foro competente: Tribunale federale di Seattle, WA

Giochi Steam associati allo schema:
BlockBlasters, Dashverse, Lunara, PirateFi (+ 4 titoli aggiuntivi non ancora resi noti)

Canali di promozione: Discord, Telegram, X, LinkedIn
Servizio di conversione: Bitrefill (BTC -> gift card, 150+ carte, prevalenza Uber Eats)
Wallet sequestrati: 3 seed phrase, incl. 1 wallet Monero
Flusso cripto totale osservato sul conto dell'indagato: ~382.000 USD
Perdite attribuite allo schema: ~220.000 USD da ~80 wallet, ~8.000 dispositivi infetti

Si parla di:
Toggle

Per la prima volta un fornitore di infrastruttura AI ammette pubblicamente di essere stato violato da un attacco condotto end-to-end da un agente AI autonomo, senza un operatore umano al comando durante l’intrusione vera e propria. Hugging Face, il più grande repository al mondo di modelli e dataset open source, ha reso noto il 16 luglio di aver rilevato e contenuto un’intrusione nella propria infrastruttura di produzione partita da un dataset malevolo e proseguita per un intero weekend attraverso migliaia di azioni automatizzate. L’ironia non è sfuggita a nessuno: la piattaforma che ospita gran parte dell’ecosistema AI open source è stata compromessa da un attacco reso possibile proprio dall’AI agentica.

Il vettore: la pipeline di elaborazione dataset

Il punto di ingresso non è stato un endpoint applicativo generico, ma il cuore stesso del business di Hugging Face: la pipeline che processa i dataset caricati dagli utenti. Un dataset predisposto ad hoc ha sfruttato due distinti code-execution path nel sistema di elaborazione: un remote-code dataset loader (una funzionalità che consente l’esecuzione di codice personalizzato durante il caricamento di certi formati di dataset) e una vulnerabilità di template injection nella configurazione del dataset stesso. La combinazione ha permesso l’esecuzione di codice arbitrario su un processing worker — il classico “primo piede nella porta” che qualunque red teamer riconoscerebbe, solo che qui a orchestrare i passi successivi non c’era una persona.

Da quel singolo worker compromesso, l’attaccante ha scalato privilegi fino ad accesso a livello di nodo, raccolto credenziali cloud e di cluster, e si è mosso lateralmente in diversi cluster interni nell’arco di un intero fine settimana — la finestra temporale preferita da chi attacca infrastrutture aziendali, quando il personale di sicurezza è ridotto e la reattività cala. Hugging Face ha successivamente confermato l’accesso non autorizzato a un insieme limitato di dataset interni e a diverse credenziali di servizio, ma nessuna evidenza di manomissione di modelli, dataset o Spaces pubblici, e la supply chain software (immagini container, pacchetti pubblicati) è risultata pulita.

Uno sciame di sandbox, non uno script

Ciò che distingue questo incidente da un normale attacco automatizzato è la scala e l’autonomia dell’orchestrazione. Secondo Hugging Face, la campagna è stata condotta da un framework di agenti autonomi — verosimilmente costruito su un harness da security research agentico, anche se il modello linguistico usato dall’attaccante resta sconosciuto — capace di eseguire migliaia di azioni individuali distribuite su uno sciame di sandbox effimere, con un’infrastruttura di comando e controllo self-migrating ospitata su servizi pubblici legittimi (una tecnica di “living off trusted services” che rende il traffico C2 difficile da distinguere da normale attività cloud). È esattamente lo scenario dell'”agentic attacker” che l’industria della sicurezza discute da mesi come previsione teorica, qui osservato per la prima volta in produzione contro un target reale.

La caccia forense: quando i guardrail bloccano i difensori

La parte più istruttiva della disclosure riguarda la risposta all’incidente. Il rilevamento iniziale è arrivato da una pipeline di anomaly-detection che usa LLM per il triage della telemetria di sicurezza: è stata la correlazione automatica dei segnali a far scattare l’allarme. Per ricostruire cosa avesse fatto realmente lo sciame di azioni automatizzate, il team ha fatto girare agenti di analisi LLM sull’intero log delle azioni dell’attaccante — oltre 17.000 eventi registrati — per ricostruire la timeline, estrarre indicatori di compromissione, mappare le credenziali toccate e separare l’impatto reale dalle attività diversive. Un lavoro che con metodi tradizionali avrebbe richiesto giorni, completato in poche ore.

Ma è qui che Hugging Face ha incontrato un ostacolo inatteso, e potenzialmente rilevante per ogni team di incident response che lavora con modelli commerciali “hosted”: i primi tentativi di analisi con modelli frontier dietro API commerciali sono falliti, perché le richieste — che necessariamente contenevano comandi di attacco reali, exploit payload e artefatti C2 — venivano bloccate dai guardrail di sicurezza dei provider, incapaci di distinguere un incident responder legittimo da un attaccante. La soluzione è stata spostare l’analisi forense su GLM 5.2, modello open-weight del laboratorio cinese Z.ai, eseguito sull’infrastruttura interna dell’azienda: un doppio vantaggio, perché ha sbloccato l’analisi e ha evitato che dati dell’attaccante e credenziali compromesse uscissero dal perimetro aziendale.

L’asimmetria che nessuno aveva pianificato

Hugging Face descrive questo come “un gap su cui vale la pena pianificare”: non si sa quale modello alimentasse gli agenti dell’attaccante — un modello hosted jailbreakato o uno open-weight senza restrizioni — ma in ogni caso l’attaccante non era vincolato da alcuna policy d’uso, mentre il lavoro forense legittimo dei difensori è stato bloccato proprio dai guardrail dei modelli hosted inizialmente scelti. La lezione pratica che l’azienda condivide con il settore: avere già pronto e validato, prima che scoppi un incidente, un modello capace eseguibile sulla propria infrastruttura, sia per evitare il lockout dei guardrail sia per mantenere dati e credenziali sensibili entro il proprio perimetro. Non è, precisano, un argomento contro le misure di sicurezza sui modelli hosted — è un feedback che l’azienda dice di aver già condiviso con i provider coinvolti.

Timeline dell’incidente

• Settimana del 6 luglio 2026: rilevamento dell’intrusione nella pipeline di elaborazione dataset tramite anomaly-detection basata su LLM.
• Weekend successivo al primo accesso: escalation di privilegi, raccolta di credenziali cloud/cluster, movimento laterale su più cluster interni condotto dallo sciame di agenti autonomi.
• 16 luglio 2026: pubblicazione della disclosure ufficiale sul blog Hugging Face, con dettaglio tecnico del vettore e delle contromisure adottate.
• Contestualmente: chiusura dei code-execution path usati come accesso iniziale, rotazione precauzionale di credenziali e token, rafforzamento degli admission control sui cluster, coinvolgimento di specialisti forensi esterni e notifica alle forze dell’ordine.

Due righe per i difensori

Questo incidente non è solo una curiosità tecnica: ridefinisce cosa significa “superficie di attacco” per qualunque piattaforma che elabora contenuti generati da utenti tramite pipeline automatizzate, AI o non AI.

• Trattare ogni pipeline di data processing che esegue codice fornito dall’utente (loader personalizzati, plugin, configurazioni con logica di templating) come superficie di attacco di prima classe, non come funzionalità di prodotto neutra.
• Validare in anticipo — prima di un incidente — un modello LLM eseguibile on-premise o in ambiente isolato per l’analisi forense, così da non dipendere da provider commerciali i cui guardrail possono bloccare legittime attività di incident response.
• Assumere che attacchi “a sciame” con orchestrazione agentica possano operare a velocità e scala superiori a quelle di un operatore umano, e dimensionare di conseguenza i tempi di detection e risposta: Hugging Face cita l’obiettivo di allertare un responder “in pochi minuti, in qualsiasi giorno della settimana”.
• Segmentare rigorosamente i processing worker dal resto del cluster e limitare il raggio d’azione di credenziali cloud raccolte da un singolo nodo compromesso, per contenere il movimento laterale anche quando l’accesso iniziale non può essere prevenuto al 100%.

Indicatori e dettagli tecnici noti

Target: infrastruttura di produzione Hugging Face (dataset processing pipeline)
Vettore iniziale: dataset malevolo caricato dall'utente
Tecniche di code execution: remote-code dataset loader + template injection in dataset config
Escalation: da worker compromesso a node-level access
Post-exploitation: raccolta credenziali cloud/cluster, movimento laterale multi-cluster
Durata campagna attiva: un intero weekend
Orchestrazione: framework di agenti autonomi, presumibile harness di security-research agentico
Infrastruttura C2: self-migrating, ospitata su servizi pubblici legittimi
Eventi registrati nel log dell'attaccante: 17.000+
Impatto confermato: accesso non autorizzato a dataset interni limitati e a credenziali di servizio
Impatto escluso: nessuna manomissione di modelli/dataset/Spaces pubblici; supply chain software verificata pulita
Strumento di analisi forense: GLM 5.2 (Z.ai, open-weight), eseguito su infrastruttura interna
Contatto per segnalazioni: security@huggingface.co

Chi gestisce ambienti SQL Server on-premises conosce bene il problema: la migrazione verso il cloud richiede quasi sempre di mettere insieme tool diversi per la valutazione, il trasferimento dei dati, il monitoraggio e infine il cutover. Ogni fase ha strumenti propri, competenze diverse e margini di errore che si sommano. Con l’annuncio della disponibilità generale (GA) della migrazione a SQL Server su macchine virtuali Azure tramite Azure Arc, Microsoft porta l’intero ciclo di vita della migrazione dentro un’unica esperienza guidata nel portale Azure, lo stesso modello già usato per le migrazioni verso Azure SQL Managed Instance.

Per chi amministra data center misti, con carichi legacy e SQL Server sparsi su fisico e virtuale, questa novità merita attenzione: non è solo un annuncio di marketing, ma un cambio concreto di flusso di lavoro operativo.

Cos’è cambiato con la GA

Fino a poco tempo fa, chi voleva spostare un’istanza SQL Server su una VM Azure doveva combinare Azure Migrate, Database Migration Service e strumenti di backup/restore manuali, gestendo ciascuno con logiche e dashboard separate. Con la funzionalità di migrazione integrata in Azure Arc, il processo si consolida in quattro fasi accessibili da un singolo pannello, il Database Migration, associato all’istanza SQL Server abilitata da Arc:

• Assess source instance — valutazione di leggibilità e readiness dell’istanza sorgente
• Select target — scelta o creazione della VM SQL Server di destinazione
• Migrate data — trasferimento effettivo dei database
• Monitor and cutover — monitoraggio della sincronizzazione e passaggio finale in produzione

La discovery delle istanze e la generazione dei report di readiness avvengono automaticamente ogni fine settimana, ma possono essere lanciate anche manualmente, senza configurazioni aggiuntive: la funzione è disponibile di default per tutte le istanze SQL Server abilitate da Arc a partire da SQL Server 2012 (11.x).

Copilot integrato nel flusso di migrazione

Una parte interessante della nuova esperienza è l’integrazione di Microsoft Copilot direttamente nel pannello di migrazione. Non si tratta di un chatbot generico: interroga la knowledge base Microsoft nel contesto specifico della vostra migrazione e risponde a richieste operative come:

Come vengono eseguite le valutazioni?
Aiutami a confrontare le opzioni di destinazione
Avvia la migrazione
Aiutami a scegliere il metodo di migrazione corretto
Monitora la migrazione in corso
Completa la migrazione

Come funziona la migrazione via backup e restore

Il meccanismo sotto il cofano non è nuovo per chi ha familiarità con le migrazioni SQL Server classiche: si basa su backup e restore con log shipping continuo, pensato per supportare scenari di migrazione online con downtime minimo.

1. Viene eseguito un backup completo del database sorgente
2. Il backup viene caricato su un account di Azure Blob Storage intermedio
3. Il backup viene ripristinato sull’istanza SQL Server target sulla VM Azure
4. I backup dei log delle transazioni vengono caricati in continuo sullo stesso storage e applicati automaticamente al database target, mantenendolo sincronizzato
5. Al momento del cutover, Azure Arc applica l’ultimo backup caricato e porta online il database target

Un vincolo operativo da tenere a mente in fase di progettazione: l’account di Azure Blob Storage e la VM SQL Server target devono trovarsi nella stessa region Azure. È un dettaglio facile da trascurare se si pianifica la migrazione partendo dalla region “storica” dell’organizzazione invece che da quella scelta per il nuovo carico.

Prerequisiti pratici

• Una subscription Azure attiva
• L’istanza SQL Server deve essere abilitata da Azure Arc con l’estensione più recente installata (l’estensione si aggiorna indipendentemente da SQL Server, quindi va controllata separatamente)
• L’ambiente sorgente preparato secondo le linee guida ufficiali, incluso l’upload iniziale dei backup nello storage account

Per verificare rapidamente la versione dell’istanza sorgente prima di avviare l’assessment, un semplice controllo T-SQL è sempre un buon punto di partenza:

SELECT SERVERPROPERTY('ProductVersion') AS Versione,
       SERVERPROPERTY('Edition') AS Edizione,
       SERVERPROPERTY('EngineEdition') AS TipoMotore;

Cosa considerare prima di partire

Il pannello di monitoraggio e cutover mostra in tempo reale quali database sono migrati con successo, quali sono ancora in corso, il metodo di migrazione scelto, la durata della sincronizzazione e i log dettagliati. Quando lo stato passa a “Ready for cutover”, si può decidere il momento esatto del passaggio in produzione selezionando Cutover, con opzioni diverse in base al metodo di migrazione utilizzato.

Va detto che, come per ogni migrazione basata su backup/restore, restano da valutare a parte gli aspetti di sizing della VM di destinazione (storage, IOPS, memoria per il buffer pool), la licenza SQL Server (Hybrid Benefit se applicabile) e la strategia di alta disponibilità post-migrazione, che questo strumento non copre direttamente ma per cui l’assessment fornisce indicazioni.

Conclusione

Portare discovery, assessment, migrazione e monitoraggio in un’unica dashboard riduce sensibilmente l’attrito operativo delle migrazioni SQL Server verso Azure, soprattutto per i team che gestiscono ambienti ibridi complessi con decine o centinaia di istanze. Non elimina la necessità di pianificazione — region, sizing e licensing restano decisioni da prendere a monte — ma consolida in un solo posto ciò che prima richiedeva più tool scollegati tra loro. Per chi ha già istanze abilitate da Azure Arc, vale la pena aggiornare l’estensione e lanciare un primo assessment anche solo per farsi un’idea della readiness del proprio parco macchine.

Fonte: Petri IT Knowledgebase e documentazione Microsoft Learn.

Ogni tanto una vulnerabilità ricorda quanto la nostra infrastruttura digitale dipenda da librerie fondamentali che diamo per scontate. È il caso di HollowByte, una falla di tipo Denial of Service scoperta dal team di ricerca di Okta in OpenSSL: con un payload malevolo di appena 11 byte, un attaccante remoto e non autenticato può costringere un server ad allocare quantità di memoria completamente sproporzionate, prima ancora che l’handshake di sicurezza abbia inizio.

Per chi gestisce server web, database o qualsiasi servizio che parla TLS — quindi, in pratica, quasi tutti i sistemisti — vale la pena capire come funziona e, soprattutto, cosa fare subito.

Fidarsi ciecamente dell’header

L’handshake TLS comincia con un messaggio ClientHello incapsulato in un record. Ogni messaggio di handshake porta un header di 4 byte che dichiara quanto sarà grande il corpo del messaggio in arrivo.

Nelle versioni vulnerabili di OpenSSL, il buffer di ricezione viene allocato sulla base di quella lunghezza dichiarata dall’attaccante, prima ancora che i dati siano effettivamente arrivati. La catena di chiamate è semplice quanto pericolosa:

Lettura header (4 byte)
  → grow_init_buf()
    → OPENSSL_clear_realloc()
      → malloc(dimensione_dichiarata_dall_attaccante)

L’effetto moltiplicatore: la frammentazione della memoria

Tenere connessioni aperte per esaurire i thread è un trucco vecchio quanto Slowloris. Quello che rende HollowByte più insidioso è l’interazione con la gestione della memoria di glibc (GNU C Library).

Quando una connessione dell’attaccante si chiude, OpenSSL libera il buffer — ma glibc non restituisce immediatamente al sistema operativo le allocazioni di dimensione piccola o media: le trattiene per un possibile riutilizzo. Lanciando ondate di connessioni con dimensioni dichiarate casuali, un attaccante impedisce all’allocatore di riutilizzare in modo efficiente quei blocchi liberati. L’heap si frammenta pesantemente e la Resident Set Size (RSS) del processo cresce in modo continuo.

Il punto critico è questo: anche dopo che l’attaccante si è disconnesso, il processo resta con un footprint di memoria permanentemente gonfiato. L’unico modo per recuperarla davvero è riavviare il servizio.

I numeri dei test

Il team di Okta ha testato istanze OpenSSL patchate e non patchate dietro NGINX, sotto diverse condizioni di carico:

• In un ambiente con 1 GB di RAM, il server non patchato è stato terminato dall’OOM killer dopo aver accumulato 547 MB di memoria frammentata e inutilizzabile
• In un ambiente con 16 GB di RAM, l’attacco ha bloccato il 25% della memoria totale del sistema, restando sotto la soglia massima di connessioni consentite — il che significa che le classiche difese basate su rate limiting delle connessioni non fermano questo attacco

Dato che OpenSSL è incorporato ovunque, l’impatto potenziale copre web server (Apache, NGINX), runtime di linguaggi (Node.js, Python, Ruby, PHP) e database (MySQL, PostgreSQL) che si appoggiano alla libreria per TLS.

La correzione: crescita incrementale del buffer

Il team OpenSSL ha risolto il problema passando a una crescita incrementale del buffer (merge delle pull request #30792, #30793 e #30794): invece di fidarsi della lunghezza dichiarata nell’header, il buffer cresce solo quando i byte arrivano effettivamente sulla connessione. Una dichiarazione senza seguito ora non costa più nulla al server.

Il fix è stato incluso silenziosamente nella release OpenSSL 4.0.1, con backport altrettanto silenziosi sulle versioni:

3.6.3
3.5.7
3.4.6
3.0.21

Cosa fare subito

Alcune azioni concrete da mettere in pratica sui vostri sistemi:

• Verificate la versione di OpenSSL su tutti i server esposti:

openssl version -a

• Aggiornate i pacchetti di sistema alla versione patchata più recente disponibile per la vostra distribuzione:

# Debian/Ubuntu
apt update && apt list --upgradable | grep -i openssl
apt install --only-upgrade openssl libssl3

# RHEL/Fedora/Alma
dnf check-update openssl
dnf update openssl

• Non fermatevi al pacchetto di sistema: controllate anche runtime e linguaggi che incorporano una propria build di OpenSSL (build statiche di Node.js, alcune distribuzioni Python, container con immagini “slim” che a volte portano versioni di OpenSSL più vecchie di quelle dell’host)
• Monitorate la RSS dei processi che terminano connessioni TLS, non solo il numero di connessioni attive: un aumento di memoria residente senza corrispondente crescita del traffico è un segnale d’allarme
• Irrigidite i timeout di handshake lato reverse proxy, ad esempio su NGINX:

ssl_handshake_timeout 10s;
client_header_timeout 10s;

• Valutate regole di rate limiting sulle nuove connessioni TLS per IP a livello di firewall o WAF, anche se — come mostrato dai test — da sole non bastano contro questa specifica tecnica

Conclusione

HollowByte è un buon esempio di come un bug apparentemente piccolo — la fiducia cieca in un header di pochi byte — possa diventare un vettore di Denial of Service difficile da rilevare con le metriche di monitoraggio standard, perché resta sotto le soglie di allarme sulla banda e sulle connessioni. La buona notizia è che la correzione è già disponibile e il percorso di mitigazione è chiaro: aggiornare OpenSSL su tutta la superficie esposta, non fidarsi solo dei database CVE per capire se si è vulnerabili, e aggiungere il monitoraggio della memoria residente ai controlli già in essere sui vostri servizi TLS.

Fonte: BleepingComputer e Okta Security.

kAppIcon permette di cambiare le icone delle applicazioni su KDE Plasma e altri desktop Linux senza permessi di root e senza modificare il temaStai leggendo kAppIcon: personalizza le icone delle applicazioni su Linux senza modificare il tema, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Tuistore è un app store TUI open source che permette di cercare, installare e gestire oltre 740 applicazioni da terminale con un solo tastoStai leggendo Tuistore porta un vero app store nel terminale Linux, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Hyprland è un compositor Wayland, il protocollo moderno che sostituisce il tradizionale sistema X11 per la gestione grafica nei sistemi GNU/Linux, dinamico e altamente personalizzabile, progettato per offrire un’esperienza desktop moderna, reattiva e visivamente accattivante. Nato nel 2022, il...

🔗 Leggi il post completo

Mentre diversi produttori Android stanno abbracciando design semi-trasparenti ispirati alle ultime tendenze estetiche, OPPO ha scelto di andare controcorrente. L’azienda ha infatti chiarito ufficialmente che ColorOS 17, la nuova interfaccia basata su Android 17 attualmente in sviluppo, non adotterà le cosiddette “card trasparenti” per gli elementi dell’interfaccia.

Leggibilità prima dell’estetica

A motivare la scelta è stato Chen Xi, design director di ColorOS, che ha spiegato come le card trasparenti, pur risultando visivamente gradevoli, tendano a compromettere la leggibilità dei contenuti quando si sovrappongono a sfondi o icone di app particolarmente elaborati. Testo e informazioni rischiano infatti di risultare poco distinguibili, un compromesso che OPPO non è disposta ad accettare.

Nell’interfaccia di ColorOS, le card svolgono un ruolo centrale: mostrano meteo, appuntamenti e altre informazioni a colpo d’occhio. Per questo motivo, secondo OPPO, la chiarezza visiva deve avere la priorità sull’estetica pura.

Uno sguardo alle funzioni future

OPPO ha aggiunto un’ulteriore motivazione dietro la scelta: le card sono destinate, con il tempo, a ospitare sempre più informazioni e funzioni. Un design trasparente limiterebbe la libertà di impaginazione e la quantità di dati visualizzabili, mentre uno sfondo opaco e ad alto contrasto garantisce maggiore flessibilità per gli sviluppi futuri dell’interfaccia.

• Card opache per garantire leggibilità costante
• Maggiore libertà di layout per future funzioni
• Nessuna dipendenza dallo sfondo o dal wallpaper scelto dall’utente

La trasparenza non è del tutto esclusa

Chen Xi non ha comunque chiuso del tutto la porta agli effetti trasparenti: per alcuni elementi dell’interfaccia che non veicolano informazioni critiche, l’azienda potrebbe sperimentare in futuro soluzioni parzialmente trasparenti. Al momento, però, non ci sono piani concreti né tempistiche definite, e nella versione stabile di ColorOS 17 non sono previste card o widget trasparenti.

La scelta di OPPO si distingue nettamente dalla direzione intrapresa da altri produttori Android, sempre più orientati verso interfacce in stile “vetro” e semi-trasparente. Per chi privilegia la praticità d’uso quotidiana rispetto alle mode del momento, l’approccio di ColorOS 17 potrebbe rivelarsi particolarmente gradito.

A pochi giorni dalla presentazione ufficiale, arrivano nuovi dettagli sui piani produttivi della serie Galaxy Z Fold 8. Secondo il leaker Ice Universe, Samsung avrebbe rivisto la strategia di produzione, aumentando in modo significativo il numero di unità destinate al modello “Wide” rispetto a quanto pianificato inizialmente.

Il modello Wide guida la produzione

Secondo le cifre riportate, la produzione della serie Galaxy Z Fold 8 sarebbe così ripartita:

• Galaxy Z Fold 8 Wide: circa 2,8 milioni di unità
• Galaxy Z Fold 8 Ultra: circa 2 milioni di unità
• Galaxy Z Flip 8: circa 1,5 milioni di unità

Inizialmente Samsung avrebbe pianificato una produzione più equilibrata, con circa 2 milioni di unità per ciascuna delle due varianti book-style. La revisione al rialzo di circa 800.000 unità per il modello Wide suggerisce che l’azienda coreana punti con decisione su un pubblico più ampio, probabilmente attratto da un prezzo di ingresso più accessibile rispetto alla variante Ultra.

La sfida della piega: Samsung punta sul titanio

Il 2026 si preannuncia un anno chiave per il segmento pieghevole, complice l’atteso debutto del primo iPhone pieghevole di Apple. Entrambe le aziende starebbero lavorando per ridurre la visibilità della piega centrale del display, ma con approcci molto diversi tra loro.

Per Galaxy Z Fold 8, Samsung sostituirebbe il tradizionale strato di supporto in resina con una pellicola in lega di titanio, spessa circa un terzo di un capello umano ma circa 20 volte più rigida rispetto ai materiali polimerici precedenti. Sotto questo strato troverebbe posto una piastra in titanio microforata, pensata per garantire flessibilità nel punto di piega mantenendo al contempo un adeguato supporto strutturale su tutto il display.

Apple, invece, punta sul vetro ultrasottile

Secondo le indiscrezioni, Apple seguirebbe una strada differente per il suo primo pieghevole, affidandosi a un vetro ultrasottile (UTG) lavorato specificamente nel punto di piega, a una cerniera stampata in 3D con meno componenti e a un adesivo trasparente speciale pensato per ridurre l’avvallamento visibile quando il dispositivo è aperto.

Presentazione ormai imminente

La serie Galaxy Z Fold 8 sarà presentata ufficialmente il 22 luglio in occasione del Galaxy Unpacked. Se le informazioni sulla revisione della produzione dovessero essere confermate, ciò indicherebbe che Samsung si aspetta una domanda particolarmente elevata per il modello Wide ancora prima del lancio sul mercato.

Sono trapelate online le specifiche dettagliate dello Snapdragon 4 Gen 6, il prossimo SoC entry-level firmato Qualcomm. Il processore di nuova generazione, destinato alla fascia più accessibile del mercato Android, continuerà a essere prodotto con il processo a 4 nm di TSMC, ma introdurrà miglioramenti significativi sul fronte GPU e memoria.

GPU e memoria protagoniste dell’aggiornamento

Secondo le informazioni trapelate, il nuovo chip porterebbe la sigla interna “SM4875”. Sul fronte CPU, la configurazione rimarrebbe pressoché invariata rispetto alla generazione precedente, con un’architettura a 8 core così composta:

• 2 core Kryo Gold basati su Cortex-A78
• 6 core Kryo Silver basati su Cortex-A55
• Cache L3 condivisa da 1 MB

Il salto in avanti più interessante riguarda invece la GPU, che passerebbe dalla serie Adreno 4 alla nuova serie Adreno 6, con conseguente miglioramento delle prestazioni grafiche e videoludiche. Anche la gestione della memoria verrebbe aggiornata: oltre al supporto per LPDDR4X, il nuovo chip introdurrebbe il supporto alla LPDDR5 dual-channel a 3200 MHz, garantendo trasferimenti dati più rapidi e una migliore efficienza energetica. I produttori manterrebbero comunque la possibilità di scegliere LPDDR4X per contenere i costi.

Processo produttivo confermato a 4 nm

Sul fronte produttivo, Qualcomm continuerebbe ad affidarsi al processo a 4 nm di TSMC, già utilizzato per la generazione precedente. Pur non rappresentando un salto verso nodi produttivi più avanzati, il potenziamento di GPU e memoria dovrebbe comunque tradursi in un miglioramento complessivo delle prestazioni e dell’efficienza energetica, mantenendo un buon equilibrio tra costi e prestazioni.

Connettività e sicurezza più robuste

Anche il comparto connettività riceverebbe un aggiornamento, con i produttori che potranno scegliere i moduli wireless più adatti alle proprie esigenze. Le configurazioni di fascia più alta supporteranno il Wi-Fi 6 (802.11ax) e il Bluetooth 5.2. Sul fronte sicurezza, sono attese diverse novità:

• Autenticazione hardware basata su crittografia a curva ellittica (ECC)
• Supporto al DRM Widevine L1
• Sicurezza rafforzata grazie al Trust Management Engine

In arrivo su Xiaomi, Redmi e POCO

Posizionato al di sotto della serie Snapdragon 7, il nuovo Snapdragon 4 Gen 6 dovrebbe debuttare su smartphone Xiaomi, Redmi e POCO di fascia economica, con base Android 14 o successiva e, nel caso dei dispositivi Xiaomi, integrazione con HyperOS. Le informazioni circolate finora non sono ancora ufficiali, ma il quadro delinea un chip pensato per rafforzare la competitività di Qualcomm nella fascia entry-level e medio-bassa del mercato.

Dal lancio di Xperia 1 VIII, l’ultimo flagship di Sony, gli utenti si sono divisi tra chi elogia l’autonomia del dispositivo e chi lamenta un consumo della batteria decisamente peggiore rispetto al modello precedente. Ora, grazie a una segnalazione emersa sul portale giapponese Kakaku.com, sappiamo che almeno in alcuni casi il problema non era immaginario: Sony ha riconosciuto un difetto di fabbrica e ha proceduto alla sostituzione del terminale.

Dal 100% al 20% in poche ore

Secondo quanto raccontato dall’utente che ha aperto la discussione, il suo Xperia 1 VIII caricato al 100% alle 5 del mattino si è ritrovato al 25% già nel tardo pomeriggio, con un utilizzo giudicato del tutto normale. Un comportamento che, a suo dire, non si era mai verificato con il precedente Xperia 1 VI in condizioni d’uso simili. Nei momenti più critici, il calo ha raggiunto ritmi ancora più rapidi, fino a far scattare automaticamente la modalità di risparmio energetico.

Non tutti gli utenti, però, riportano la stessa esperienza. Alcuni commenti alla discussione sottolineano anzi il contrario:

• La batteria di Xperia 1 VIII dura più a lungo rispetto a Xperia 1 V
• Era semmai Xperia 1 VI ad avere un’autonomia fuori dal comune

Un quadro contrastante che, di fatto, conferma le divisioni emerse fin dal debutto del dispositivo sul mercato.

Sony conferma: è un difetto di fabbrica

Prima di rivolgersi all’assistenza, l’utente ha provato le soluzioni più comuni, come la cancellazione della cache dei servizi Google Play e il controllo delle app in background, senza però ottenere miglioramenti. A quel punto è entrato in gioco il servizio clienti Sony, che dopo aver analizzato il caso ha classificato l’anomalia come difetto di fabbrica, procedendo alla sostituzione del terminale.

Il problema, tuttavia, non sembra completamente risolto: anche dopo il cambio, il nuovo esemplare è passato dal 100% delle 7 del mattino a circa il 20% nel primo pomeriggio, spingendo l’utente a sperare in un correttivo software nelle prossime settimane.

Segnalati anche casi di surriscaldamento

Nella stessa discussione è emersa un’altra testimonianza interessante: un secondo utente ha raccontato di aver riscontrato surriscaldamento anomalo e un consumo estremamente rapido della batteria fin dai primi giorni di utilizzo, ottenendo la sostituzione gratuita tramite NTT Docomo. Anche sul nuovo dispositivo, però, si sarebbero verificati episodi di spegnimento improvviso quando la carica scendeva sotto il 18-20%, un comportamento che lascia aperti dubbi sulla reale origine del problema, forse più legata al software che all’hardware.

Per chi possiede uno Xperia 1 VIII e riscontra sintomi simili, la strada suggerita resta quella di contattare l’assistenza Sony per verificare se il proprio esemplare rientri tra quelli interessati dal difetto, in attesa di eventuali chiarimenti ufficiali o aggiornamenti software correttivi.

Xiaomi si prepara a lanciare la serie Xiaomi 18, e con essa arriverà anche HyperOS 4, la nuova versione dell’interfaccia proprietaria dell’azienda cinese. In queste ore sono trapelati online i primi screenshot che mostrerebbero l’interfaccia ancora in fase di sviluppo, offrendo un primo sguardo su alcune delle novità estetiche e funzionali in arrivo.

Le immagini arrivano da Weibo

Gli scatti, pubblicati sul social cinese Weibo, mostrerebbero nuove icone di sistema e funzioni di gestione dei widget rinnovate rispetto a HyperOS 3. Dalle informazioni di identificazione presenti nelle immagini, il dispositivo utilizzato per i test sarebbe il modello di punta della serie Xiaomi 18, noto internamente con il nome in codice “HONGKONG”.

Il fatto che il modello top di gamma sia già utilizzato per testare la nuova versione del sistema operativo suggerisce che Xiaomi stia procedendo speditamente nello sviluppo, in vista di un lancio che dovrebbe accompagnare il debutto della serie Xiaomi 18.

Cosa cambia rispetto a HyperOS 3

Al momento le informazioni condivise online sono ancora parziali, ma gli screenshot lasciano intravedere un restyling delle icone di sistema e nuove modalità di interazione con i widget della schermata Home. Non è ancora chiaro se questi elementi rappresentino l’aspetto definitivo di HyperOS 4 o se si tratti di una build ancora sperimentale, soggetta a ulteriori modifiche prima del rilascio pubblico.

• Nuove icone di sistema
• Gestione rinnovata dei widget
• Test in corso sul modello di punta di Xiaomi 18

Cosa aspettarsi dal lancio

Xiaomi non ha ancora fornito una tempistica ufficiale per la presentazione di HyperOS 4, ma è plausibile che il debutto avvenga in concomitanza con il lancio della serie Xiaomi 18, atteso nei prossimi mesi. Come da tradizione, il nuovo sistema dovrebbe poi estendersi progressivamente ad altri modelli del catalogo Xiaomi, Redmi e POCO tramite gli aggiornamenti software.

Continueremo a seguire gli sviluppi sulla nuova interfaccia, aggiornando l’articolo non appena emergeranno ulteriori dettagli ufficiali o nuove indiscrezioni sulle funzioni di HyperOS 4.

Un nuovo smartphone OPPO ancora inedito è comparso nel database dell’ente cinese TENAA, l’organismo che certifica i dispositivi prima della loro commercializzazione. Il modello, identificato dalla sigla PYZ110, non mostra ancora immagini ufficiali, ma le specifiche tecniche trapelate rivelano un dettaglio che salta subito all’occhio: una batteria da circa 8000 mAh.

Una batteria da record

Secondo i dati della certificazione, OPPO PYZ110 monta una batteria dalla capacità nominale di 7.780 mAh, che nella tipica arrotondata commerciale corrisponde a circa 8.000 mAh. Si tratta di una capacità decisamente superiore alla media del mercato Android attuale, pensata evidentemente per offrire un’autonomia estesa a scapito, probabilmente, di un design più compatto.

Le dimensioni riportate, infatti, sono di 166,47 x 78,23 x 8,88 mm, per un peso di 224 grammi: numeri che confermano come il dispositivo punti tutto sulla resistenza della batteria più che sulla leggerezza.

Specifiche orientate alla fascia entry-level

Il resto della scheda tecnica delinea un prodotto pensato per la fascia economica del mercato. Il display sarebbe un pannello LCD da 6,75 pollici con risoluzione HD+ (720 x 1570 pixel), mentre il processore, ancora non identificato con precisione, opererebbe a una frequenza massima di 2,4 GHz.

• Memoria RAM: 6 GB o 8 GB
• Storage: 128 GB, 256 GB o 512 GB
• Sensore di impronte digitali laterale
• Fotocamera anteriore da 8 megapixel
• Fotocamera posteriore singola da 50 megapixel

La presenza di un’unica fotocamera posteriore conferma l’impostazione del dispositivo: priorità all’autonomia piuttosto che al comparto fotografico.

Non è OPPO K15: probabile modello della serie A

Un chiarimento importante riguarda l’identità del dispositivo: secondo le prime analisi, PYZ110 non corrisponderebbe al prossimo OPPO K15, atteso ufficialmente il 24 luglio, che sarebbe invece associato alla sigla PYD110, già passata da TENAA lo scorso giugno. È quindi più probabile che il nuovo modello con batteria maxi vada ad arricchire la serie OPPO A, dedicata al segmento entry-level del brand.

Il nome commerciale definitivo non è ancora stato reso noto: per saperne di più bisognerà attendere ulteriori documenti di certificazione o un annuncio ufficiale da parte di OPPO.

Simple Taskbar trasforma il pannello di GNOME in una barra delle applicazioni completa, con menu Start, anteprime finestre e ampia personalizzazioneStai leggendo Simple Taskbar trasforma il pannello di GNOME in una barra delle applicazioni completa, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

La dettatura vocale è ormai una funzione comune sui principali sistemi operativi desktop, ma nel mondo Linux le alternative integrate sono sempre state piuttosto limitate. Vocalinux punta a colmare questa lacuna offrendo un’applicazione open source dedicata esclusivamente alla trascrizione della voce in testo, con un approccio orientato alla privacy e all’elaborazione locale. L’...

🔗 Leggi il post completo

Il controverso rapporto di Mr. Space X, Tesla e, per l'appunto, X con l'open-source parrebbe essere arrivato al capolinea. La volontà di Elon Musk è quella di pubblicare l'interezza del codice di X in forma open-source.
Ma, sempre che questo dovesse accadere, chi sarà in grado di verificarlo?

🔗 Leggi il post completo

Nessun login richiesto

Il 17 luglio 2026 il team di sicurezza di WordPress ha rilasciato in silenzio, e con qualche ora di anticipo condiviso solo con i principali fornitori di infrastruttura, la patch per due vulnerabilità che insieme formano una catena di attacco particolarmente pericolosa: una SQL injection e una remote code execution non autenticata. Nessuna delle due richiede che l’attaccante possieda credenziali o interagisca con un utente reale: basta una richiesta HTTP costruita ad arte contro l’endpoint batch della REST API.

Se gestisci anche un solo sito WordPress — e in Italia sono milioni, molti dei quali proprio su blog tecnici o aziendali come questo — questa è una di quelle vulnerabilità da trattare come priorità operativa immediata, non come lettura per il weekend.

Le due CVE, in breve

Le vulnerabilità colpiscono punti diversi della catena di elaborazione di una richiesta:

• CVE-2026-60137 — SQL injection. Presente da WordPress 6.8 in poi. Un input malformato riesce ad alterare una query verso il database. Severità: Alta.
• CVE-2026-63030 — Remote Code Execution non autenticata. Presente da WordPress 6.9 in poi, e collegata direttamente alla SQL injection precedente. Sfrutta l’endpoint batch della REST API quando il sito non utilizza una cache a oggetti persistente (persistent object cache). Severità: Critica.

La combinazione delle due — nella comunità di sicurezza già ribattezzata informalmente “wp2shell” — permette a un attaccante di passare da un parametro malformato a esecuzione di codice arbitrario sul server, senza autenticazione e senza alcuna interazione da parte di amministratori o utenti.

Perché la object cache fa la differenza

Il dettaglio tecnico più interessante per chi amministra WordPress è che la RCE si manifesta specificamente quando manca una cache a oggetti persistente (tipicamente basata su Redis o Memcached). Molte installazioni WordPress “di default” — senza un livello di caching applicativo esterno a PHP — si affidano a una cache in memoria che vive solo per la durata della singola richiesta: è proprio l’assenza di persistenza a lasciare aperta la finestra che l’endpoint batch della REST API sfrutta per concatenare SQL injection ed esecuzione di codice. In altre parole, i siti più “semplici”, senza uno stack di caching avanzato, sono paradossalmente più esposti di quelli con un’infrastruttura più sofisticata.

La risposta di WordPress

Trattandosi della classe di severità più alta prevista dal team di sicurezza di WordPress, il rilascio della patch è stato accompagnato da aggiornamento automatico forzato per la maggior parte dei siti, un meccanismo che WordPress riserva solo alle emergenze più critiche. Le versioni corrette sono:

• 7.0.2 — release principale, corregge entrambe le vulnerabilità
• 6.9.5 — backport, corregge entrambe le vulnerabilità
• 6.8.6 — backport, corregge solo la SQL injection (la RCE non è presente su questo ramo)
• 7.1 Beta 2 — corregge entrambe

Le versioni precedenti alla 6.8 non risultano affette. Anche con l’aggiornamento automatico attivo, è buona norma verificare manualmente la versione installata:

# Da riga di comando, con WP-CLI
wp core version

# Oppure dalla dashboard: Bacheca → Aggiornamenti

Il ruolo del WAF: difesa in profondità, non sostituto della patch

Cloudflare, informata in anticipo dal team WordPress, ha distribuito due regole WAF dedicate alle 17:03 UTC del 17 luglio, attive automaticamente per tutti i clienti — inclusi quelli su piano gratuito — il cui traffico passa attraverso il proxy Cloudflare:

La prima regola intercetta i valori dei parametri malformati prima che raggiungano WordPress; la seconda blocca le richieste dirette verso il percorso di esecuzione del codice. Insieme coprono due punti distinti della catena di attacco. Cloudflare è però esplicita su un punto che vale la pena ribadire: le regole WAF riducono l’esposizione, non sostituiscono la patch. Chi utilizza Cloudflare su piano Pro, Business o Enterprise dovrebbe verificare che il Managed Ruleset sia attivo e che non vi siano override che trasformano l’azione da “Block” a “Log” — una configurazione non rara in ambienti dove si è voluto in passato ridurre i falsi positivi.

Checklist operativa

Per chi amministra siti WordPress, indipendentemente dal fatto che si usi o meno Cloudflare, questi sono i passi concreti da seguire subito:

• Verificare la versione di WordPress su tutte le installazioni gestite (non solo quella principale — anche i sotto-siti, gli ambienti di staging e i multisite dimenticati).
• Forzare l’aggiornamento a 7.0.2, 6.9.5 o 6.8.6 se l’auto-update non è ancora scattato:

  wp core update --version=7.0.2
  wp core update-db

• Se dietro Cloudflare: controllare in dashboard che le due regole (ID gestito 7dfb2bd4708d4b88b9911dc0550664b6 per la RCE e 1c060d3a371549219ee290d7ed933fcc per la SQLi) siano impostate su Block, e monitorare i Security Events per richieste bloccate su questi ID.
• Se non si usa un WAF: valutare regole custom su ModSecurity con OWASP CRS mirate all’endpoint /wp-json/*/batch, oppure disabilitare temporaneamente il batch endpoint tramite un mu-plugin, in attesa che l’aggiornamento venga completato su tutta la flotta:

  <?php
  // mu-plugins/disable-rest-batch.php
  add_filter('rest_pre_dispatch', function ($result, $server, $request) {
      if (strpos($request->get_route(), '/batch') !== false) {
          return new WP_Error('batch_disabled', 'Endpoint batch temporaneamente disabilitato', ['status' => 403]);
      }
      return $result;
  }, 10, 3);

• Abilitare una object cache persistente (Redis o Memcached) come mitigazione indiretta aggiuntiva, oltre ai benefici di performance che porta comunque.
• Controllare i log delle ultime settimane per richieste sospette verso gli endpoint REST batch, prima di considerare l’incidente chiuso.

In conclusione

Questa vicenda è un promemoria utile su due fronti. Il primo è tecnico: un endpoint REST pensato per efficienza (il batching di più operazioni in un’unica chiamata) può diventare superficie di attacco se la validazione dei parametri non è sufficientemente rigorosa lungo tutta la catena. Il secondo è organizzativo: la differenza tra un incidente e un mancato incidente, in casi come questo, si misura in ore — quelle tra la disclosure coordinata e la disponibilità pubblica dei dettagli, durante le quali chi ha automatizzato patching e monitoraggio dorme sonni più tranquilli di chi deve intervenire manualmente su decine di installazioni.

Fonte: The Cloudflare Blog.

Il 28 luglio 2026 entra in vigore la nuova revisione della specifica Model Context Protocol (MCP), lo standard aperto introdotto da Anthropic che permette ai modelli AI di collegarsi in modo sicuro a strumenti e sorgenti dati esterne. Non si tratta di un aggiornamento cosmetico: la revisione 2026-07-28 ridisegna il nucleo del protocollo, passando da un modello con stato a uno completamente stateless, e introduce cambiamenti che toccano direttamente chi progetta, ospita o consuma server MCP in produzione.

Per chi lavora con agenti AI e integrazioni enterprise, questa è una di quelle revisioni che vale la pena capire in dettaglio prima che arrivi la versione finale, perché tocca scalabilità, autenticazione e compatibilità con le versioni precedenti.

Dal protocollo con stato al core stateless

Nelle versioni precedenti di MCP, un client doveva eseguire un handshake initialize prima di poter fare qualsiasi cosa: il server rispondeva con un identificatore di sessione da includere in ogni richiesta successiva. Chi ha provato a mettere in produzione un server MCP dietro un load balancer conosce il problema: il client restava “incollato” a una specifica istanza, e scalare orizzontalmente richiedeva sticky session o uno store di sessione condiviso.

La revisione 2026-07-28 elimina sia l’handshake initialize sia il concetto stesso di sessione a livello di protocollo. Ogni richiesta è ora autosufficiente: versione del protocollo, informazioni sul client e capability dichiarate viaggiano in ogni singola chiamata invece di essere negoziate una volta sola all’apertura della connessione. Un nuovo metodo, server/discover, permette al client di recuperare le capability del server solo quando gli servono davvero.

La conseguenza pratica è che, non esistendo più un identificatore di sessione, qualsiasi richiesta può essere instradata verso qualunque istanza del server. Diventa possibile piazzare un server MCP dietro un banale load balancer round-robin, senza sticky session né store condiviso. Se un’applicazione ha comunque bisogno di mantenere uno stato tra una chiamata e l’altra, la soluzione prevista è restituire un handle esplicito (ad esempio un ID di un “carrello” o di una sessione applicativa) da uno strumento, e far sì che il client lo passi indietro come un normale argomento nelle chiamate successive. È lo stesso pattern usato da anni nelle API REST stateless: lo stato non sparisce, si sposta semplicemente dal trasporto al payload applicativo.

Multi Round-Trip Requests: confermare senza tenere aperta una connessione

Un protocollo stateless ha comunque bisogno di un modo per gestire i casi in cui un server deve chiedere qualcosa al client a metà di una chiamata, per esempio una conferma dell’utente prima di eseguire un’operazione sensibile. Nelle versioni precedenti questo richiedeva tenere aperto uno stream Server-Sent Events per tutta la durata dell’interazione. La nuova revisione sostituisce questo meccanismo con le Multi Round-Trip Requests (MRTR).

Quando un server ha bisogno di input dall’utente durante l’esecuzione di uno strumento, restituisce un oggetto InputRequiredResult contenente le domande da porre e un blob requestState. Il client raccoglie le risposte e riemette la chiamata originale includendo sia le risposte sia lo stato “echoed” ricevuto in precedenza. Poiché tutto ciò che serve al server è contenuto nel payload, qualunque istanza del server può gestire il retry, anche se è diversa da quella che ha generato la richiesta iniziale. È un dettaglio che semplifica enormemente il deployment di server MCP dietro infrastrutture di bilanciamento del carico stateless.

Header instradabili e caching esplicito

Due modifiche più contenute a livello di trasporto rendono il traffico MCP molto più facile da osservare e instradare in produzione. Il trasporto Streamable HTTP richiede ora un header Mcp-Method su ogni richiesta, mentre l’header Mcp-Name è obbligatorio solo per tipi di richiesta specifici, come tools/call, resources/read e prompts/get. Un gateway o un load balancer può leggere questi header per instradare il traffico senza dover analizzare il corpo della richiesta, un vantaggio non trascurabile per chi gestisce infrastrutture MCP a scala aziendale. I server rifiutano le richieste in cui header e corpo non sono coerenti tra loro.

In secondo luogo, i risultati di liste e letture di risorse ora includono i campi ttlMs e cacheScope, modellati sul comportamento dell’header HTTP Cache-Control. I client sanno esattamente per quanto tempo una risposta a tools/list resta valida e se può essere condivisa tra utenti diversi. Non è più necessario mantenere uno stream a lungo termine solo per scoprire che una lista è cambiata: un pattern di polling con cache esplicita è sufficiente.

Autenticazione più rigorosa, allineata a OAuth 2.0

La revisione stringe le regole di autorizzazione per allinearle più da vicino a OAuth 2.0 e OpenID Connect. I client devono ora validare il parametro iss nelle risposte di autorizzazione secondo la RFC 9207, una mitigazione contro i “mix-up attack”, una classe di attacchi più rilevante nel pattern tipico di MCP in cui un singolo client dialoga con molti server diversi.

I client devono inoltre dichiarare il proprio application_type durante la Dynamic Client Registration, così gli authorization server non assumono più di default che i client desktop o CLI siano applicazioni “web”, evitando il rifiuto ingiustificato dei redirect URI su localhost. Le credenziali vengono vincolate all’authorization server che le ha emesse, e la specifica chiarisce come richiedere i refresh token durante l’autenticazione step-up.

Funzionalità deprecate: cosa cambia per chi ha già integrato MCP

Tre funzionalità core vengono formalmente deprecate: Roots, Sampling e Logging. Roots permetteva a un client di dichiarare i confini del filesystem a un server; Sampling permetteva a un server di chiedere al modello del client di generare testo per suo conto; Logging forniva notifiche a livello di protocollo dal server al client.

La deprecazione non significa rimozione immediata: questi metodi, tipi e capability flag continuano a funzionare in questa release e in ogni versione della specifica pubblicata entro un anno da essa. Da qui in poi, però, sono su un orologio di rimozione. Le alternative consigliate sono parametri degli strumenti o URI di risorse al posto di Roots, integrazione diretta con le API dei provider LLM al posto di Sampling, e OpenTelemetry per l’osservabilità strutturata al posto del Logging di protocollo. Chi mantiene librerie o server MCP dovrebbe iniziare a pianificare la migrazione già da ora.

Schema degli strumenti, codici di errore ed estensioni

Gli schema di input e output degli strumenti utilizzano ora JSON Schema 2020-12 completo. Gli schema di input mantengono il vincolo della radice type: "object" ma ora permettono composizione con oneOf, anyOf e allOf, oltre a condizionali e riferimenti. Gli schema di output non hanno più restrizioni, e structuredContent può essere qualsiasi valore JSON, non solo un oggetto.

Il codice di errore per una risorsa mancante cambia dal valore custom MCP -32002 allo standard JSON-RPC -32602 (Invalid Params). Chi ha client che fanno pattern matching sul valore letterale -32002 deve aggiornare quel codice prima del 28 luglio.

Le estensioni, già presenti nella release precedente ma senza un processo formale, ricevono ora una struttura definita: sono identificate da ID reverse-DNS, negoziate tramite una mappa extensions, e vivono in repository indipendenti con maintainer dedicati, versionando separatamente dalla specifica principale. Due estensioni ufficiali arrivano con questa release: MCP Apps, che permette ai server di fornire interfacce HTML interattive renderizzate dagli host in un iframe sandboxed, e Tasks, promossa da funzionalità sperimentale a estensione ufficiale, che fornisce un modello stateless per lavori a lunga esecuzione: un server può rispondere a tools/call con un task handle, e il client lo gestisce con tasks/get, tasks/update e tasks/cancel.

SDK beta disponibili da subito

Sono già disponibili release beta degli SDK Python, TypeScript, Go e C#. Python v2 rinomina FastMCP in MCPServer ma mantiene l’API a decoratori. TypeScript v2 divide l’SDK monolitico in pacchetti focalizzati come @modelcontextprotocol/server e @modelcontextprotocol/client, ed è ora ESM-only. Go integra il supporto alla revisione 2026-07-28 in v1.7.0-pre.1 sullo stesso module path. C# rilascia la versione 2.0.0-preview.1 dei pacchetti ModelContextProtocol.

Per chi ha già server e client in produzione, la buona notizia è che nulla si rompe automaticamente il giorno del rilascio: i nuovi client che parlano la revisione 2026-07-28 tornano automaticamente all’handshake initialize quando raggiungono un server che implementa una versione precedente o uguale al 2025-11-25. Chi però pubblica librerie che dipendono dal pacchetto Python mcp dovrebbe aggiungere un limite superiore esplicito, per esempio mcp>=1.27,<2, in modo che il passaggio alla v2 stabile non colga di sorpresa gli utenti del proprio pacchetto.

Conclusione

La revisione 2026-07-28 di MCP è un cambiamento strutturale, non un semplice aggiornamento incrementale. Il core stateless elimina la necessità di session affinity e semplifica scaling orizzontale e load balancing di server MCP in produzione. I nuovi pattern come le MRTR e gli header instradabili rendono il protocollo più facile da operare su larga scala. L’irrigidimento delle regole di autorizzazione allinea MCP alle pratiche standard di OAuth e OpenID Connect, riducendo la superficie di attacco tipica delle integrazioni multi-server. Le funzionalità deprecate restano funzionanti per ora, ma vanno sostituite secondo un piano preciso prima che scada la finestra di un anno.

Chi sviluppa o ospita server MCP dovrebbe testare gli SDK beta contro i propri carichi di lavoro prima della data finale del 28 luglio, verificando in particolare la gestione dei codici di errore, la compatibilità dei client con l’handshake legacy e l’impatto delle nuove regole di autorizzazione sulle integrazioni desktop e CLI esistenti.

Fonte: 4sysops.com

Chi sta integrando agenti AI in pipeline CI/CD si scontra presto con un problema pratico: come si testano in modo affidabile le “skill” di un agente (le istruzioni locali che gli insegnano quando e come usare una capacità) senza colpire API reali, senza costi imprevedibili e senza risultati non deterministici? La risposta che sta emergendo nella comunità DevOps combina due strumenti complementari: Dev Proxy di Microsoft per simulare le API a livello di rete, e Promptfoo per valutare in modo strutturato se una skill funziona meglio di un’altra.

Vale la pena approfondire entrambi gli approcci, perché il problema che risolvono — testare comportamento non deterministico in modo ripetibile — è ormai centrale per chiunque gestisca agenti AI in produzione, non solo per chi scrive skill per Claude o Codex.

Perché i mock server tradizionali falliscono con gli agenti AI

L’approccio classico al test di un’integrazione API è il mock server: si sostituisce l’endpoint reale con uno fittizio, spesso puntando l’applicazione a localhost. Con gli agenti AI questo approccio introduce un problema sottile ma serio: cambiare l’URL di una skill per puntare a un server di test altera il contesto di token visto dal modello. Il modello che si sta testando non è più identico, a livello di token, a quello che verrà effettivamente distribuito in produzione. Questa discrepanza introduce una variabile nascosta che può invalidare i risultati della valutazione e produrre comportamenti inattesi una volta in produzione, quando la skill torna a puntare agli URL reali.

Un approccio più efficace consiste nell’usare un proxy leggero che intercetta il traffico HTTP e restituisce dati predefiniti letti da file JSON locali, senza mai modificare gli URL che l’agente chiama. È esattamente il compito per cui è nato Dev Proxy: l’agente continua a chiamare gli URL di produzione, ma riceve risposte deterministiche senza che avvenga alcuna chiamata di rete reale né alcuna gestione di server. I dati si azzerano a ogni esecuzione, il contesto di token resta identico a quello di produzione, e diventa possibile eseguire test di regressione rigorosi all’interno di pipeline CI/CD.

Dev Proxy: simulare le API senza toccare il codice

Dev Proxy è uno strumento a riga di comando, open source e gratuito, che funziona su qualsiasi piattaforma e con qualsiasi stack tecnologico, perché intercetta le richieste di rete invece di agganciarsi al codice dell’applicazione. Le funzionalità principali coprono scenari che vanno ben oltre il semplice mocking:

• Simulare errori delle API senza modificare una riga di codice, per verificare che l’app non perda dati dei clienti quando una dipendenza esterna fallisce
• Simulare rate limiting per verificare che l’applicazione gestisca correttamente il throttling
• Simulare latenza e risposte lente per validare le protezioni lato UX
• Generare rapidamente mock API CRUD senza scrivere codice destinato a non essere mai distribuito
• Fornire guida contestuale su permessi e best practice, in particolare per chi integra Microsoft Graph

Per il caso specifico degli agenti AI, Dev Proxy include funzionalità dedicate ai language model che permettono di simulare scenari realistici e tracciare l’uso delle risorse, oltre a un tool integrato nel proprio server MCP che fornisce agli agenti di coding raccomandazioni su come costruire le configurazioni. In pratica, un team che sviluppa una skill che chiama un’API esterna può configurare Dev Proxy per intercettare quelle chiamate specifiche e restituire fixture JSON versionate insieme al codice, garantendo che ogni esecuzione della pipeline CI/CD parta da uno stato pulito e riproducibile.

Promptfoo: valutare quale versione di una skill funziona meglio

Simulare le API risolve solo metà del problema. L’altra metà è capire, in modo misurabile, se una skill fa il proprio lavoro correttamente e se una nuova versione è effettivamente migliore della precedente. È qui che entra in gioco Promptfoo, un framework di valutazione che permette di confrontare due versioni della stessa skill eseguendo gli stessi task fianco a fianco.

Il pattern di base è semplice: si mantengono identici il modello, i file di task e i permessi, cambiando solo il file SKILL.md tra una versione e l’altra. Una struttura tipica per confrontare due versioni di una skill review-standards è organizzata così:

skill-eval/
├── promptfooconfig.yaml
└── fixtures/
    ├── v1/
    │   ├── .claude/skills/review-standards/SKILL.md
    │   └── src/auth.ts
    └── v2/
        ├── .claude/skills/review-standards/SKILL.md
        └── src/auth.ts

providers:
  - id: anthropic:claude-agent-sdk
    label: review-standards-v1
    config:
      model: claude-sonnet-4-6
      working_dir: ./fixtures/v1
      setting_sources: ['project']
      skills: ['review-standards']
      append_allowed_tools: ['Read', 'Grep', 'Glob']
  - id: anthropic:claude-agent-sdk
    label: review-standards-v2
    config:
      model: claude-sonnet-4-6
      working_dir: ./fixtures/v2
      setting_sources: ['project']
      skills: ['review-standards']
      append_allowed_tools: ['Read', 'Grep', 'Glob']

Tre livelli di asserzioni per un confronto solido

Una valutazione utile si costruisce a strati. Il primo verifica semplicemente che la skill sia stata invocata:

defaultTest:
  assert:
    - type: skill-used
      value: review-standards

Il secondo livello valuta la qualità del lavoro svolto, per esempio calcolando quanti problemi attesi sono stati effettivamente individuati in una revisione di codice, con una soglia di recall minima. Il terzo livello aggiunge segnali secondari come costo e latenza, utili quando due versioni sono entrambe corrette ma una è molto più lenta o costosa dell’altra:

defaultTest:
  assert:
    - type: cost
      threshold: 0.50
    - type: latency
      threshold: 120000

Mettere insieme i due strumenti in CI/CD

La combinazione pratica è: Dev Proxy intercetta le chiamate API reali fatte durante l’esecuzione della skill e restituisce fixture deterministiche, mentre Promptfoo esegue lo stesso set di task contro versioni diverse della skill e assegna un punteggio ai risultati. L’eval si lancia con un semplice comando:

npx promptfoo@latest eval -c promptfooconfig.yaml

Conclusione

Il punto centrale di entrambi gli strumenti è lo stesso: eliminare le variabili nascoste che rendono inaffidabile il test di un comportamento non deterministico. Dev Proxy garantisce che il contesto visto dal modello in test sia identico a quello di produzione, eliminando la variabile del cambio di URL. Promptfoo garantisce che il confronto tra due versioni di una skill sia equo, isolando l’unica variabile che conta — il testo della skill stessa — e fornendo asserzioni misurabili su invocazione, qualità, costo e latenza.

Per un team che già gestisce pipeline CI/CD tradizionali, l’investimento per aggiungere questo livello di test alle proprie skill AI è relativamente contenuto: entrambi gli strumenti sono open source, si integrano con gli SDK di Claude, Codex e OpenCode, e restituiscono risultati confrontabili senza richiedere infrastruttura dedicata oltre a quella già in uso per il testing tradizionale.

Fonti: 4sysops.com, Microsoft Learn – Dev Proxy, Promptfoo – Test Agent Skills

Uno sviluppatore di GNOME Calendar critica Linux Mint per la distribuzione di una versione modificata e datata dell'applicazioneStai leggendo GNOME Calendar: uno sviluppatore critica Linux Mint per la gestione della versione inclusa nella distribuzione, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

ClassicImageViewer 2.0 è un visualizzatore immagini open source con editing, effetti, slideshow, macro e strumenti avanzati.
Stai leggendo ClassicImageViewer combina visualizzazione rapida e strumenti di editing su Linux, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Linux Soundboard è una soundboard nativa per Linux con PipeWire, microfono virtuale, normalizzazione LUFS e scorciatoie globali per Wayland e X11Stai leggendo Arriva la soundboard nativa per Linux con PipeWire e microfono virtuale, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Ogni settimana, il mondo del software libero e open source ci offre una moltitudine di aggiornamenti e nuove versioni di software. Anche se non tutti sono di grande rilevanza, molti di questi possono risultare...

🔗 Leggi il post completo

Il prossimo smartwatch di punta di Samsung, il Galaxy Watch 9, segnerà una svolta importante nella storia della gamma: al posto del consueto chip Exynos, il dispositivo monterà per la prima volta un processore Qualcomm, lo Snapdragon Wear Elite. A confermarlo è un’immagine promozionale trapelata online.

L’immagine trapelata conferma il chip Qualcomm

A diffondere l’immagine è stato il noto leaker Evan Blass, da sempre una fonte affidabile su materiali promozionali non ancora ufficiali. Nello scatto compare la dicitura “Powered by Snapdragon Wear Elite” accanto al nome Galaxy Watch 9, un dettaglio che elimina ogni dubbio residuo sulle indiscrezioni circolate nelle scorse settimane.

Va precisato che il riferimento allo Snapdragon Wear Elite riguarda il modello standard del Galaxy Watch 9: per la variante Ultra 2, invece, l’immagine trapelata non fornisce indicazioni.

Una prima volta per la gamma Galaxy Watch

Da quando ha debuttato, la linea Galaxy Watch si è sempre affidata a chip Exynos progettati internamente da Samsung. Il passaggio allo Snapdragon Wear Elite rappresenta quindi una discontinuità significativa nella strategia dell’azienda coreana per il segmento indossabili.

Qualcomm ha presentato lo Snapdragon Wear Elite nel corso di quest’anno come nuova piattaforma di riferimento per smartwatch di fascia alta. Il chip è realizzato con processo produttivo a 3 nanometri e promette, secondo l’azienda, miglioramenti sensibili sia sul fronte delle prestazioni sia su quello dell’efficienza energetica, con un’attenzione particolare alle funzioni basate sull’intelligenza artificiale.

Più intelligenza artificiale a bordo del polso

Il salto generazionale sul fronte del silicio dovrebbe tradursi in un miglior supporto alle funzionalità AI direttamente sullo smartwatch, un ambito su cui Samsung punta sempre più anche per differenziare la propria offerta rispetto alla concorrenza. Resta da vedere se il produttore coreano riuscirà a sfruttare appieno la nuova piattaforma con funzioni esclusive legate al software.

• Primo chip Qualcomm su un Galaxy Watch, al posto di Exynos
• Processo produttivo a 3 nanometri
• Maggiore efficienza energetica ed elaborazione AI più rapida
• Variante Ultra 2 ancora senza conferme sul chip

Con la presentazione ufficiale ormai attesa a breve, sarà interessante scoprire quali novità software Samsung riserverà per sfruttare al meglio le potenzialità del nuovo Snapdragon Wear Elite sul Galaxy Watch 9.

Frame è un server X11 innovativo per l’ecosistema GNU/Linux, sviluppato interamente da zero in Assembly x86-64 dal programmatore Geir Isene. A differenza dei server X11 tradizionali come X.Org, che si basano su librerie esterne,...

🔗 Leggi il post completo

Xiaomi si avvicina sempre di più alla presentazione della serie Xiaomi 18, e un nuovo indizio arriva direttamente dagli enti di certificazione cinesi. Uno smartphone non ancora annunciato, con numero di modello “M154FF”, è comparso nel database dell’ente SRRC, mostrando tra le altre cose il supporto alla tecnologia UWB, una caratteristica tipicamente riservata ai modelli di punta.

Certificazione SRRC e supporto UWB confermato

A segnalare la registrazione è stato il leaker Digital Chat Station, fonte spesso affidabile sulle novità hardware Xiaomi. Secondo quanto riportato, il dispositivo supporta le reti 5G in banda N79 ed è inoltre dotato di UWB (Ultra Wideband), tecnologia che consente localizzazione di precisione e comunicazione rapida tra dispositivi, utilizzata ad esempio per chiavi digitali e tag smart.

Poiché l’UWB viene solitamente riservato ai modelli più costosi di una gamma, il leaker ritiene probabile che il dispositivo certificato corrisponda proprio a Xiaomi 18 Pro, e non alla variante standard della serie.

Snapdragon 8 Elite Gen 6 e doppia fotocamera da 200 megapixel

Le indiscrezioni più recenti diffuse dallo stesso leaker indicano che Xiaomi 18 Pro dovrebbe montare lo Snapdragon 8 Elite Gen 6, prodotto con processo a 2 nanometri e atteso in presentazione ufficiale a settembre: il flagship Xiaomi potrebbe quindi essere tra i primissimi smartphone a debuttare con il nuovo chip Qualcomm.

Sul fronte del display, si vocifera di un pannello con cornici particolarmente sottili e uniformi sui quattro lati, oltre a bordi arrotondati più marcati. Per quanto riguarda le fotocamere, le voci parlano di una configurazione doppia da 200 megapixel, sia per il sensore principale che per il teleobiettivo.

Batteria da 7.000 mAh e altre novità attese

Tra le altre indiscrezioni circolate figura una batteria da circa 7.000 mAh, con supporto sia alla ricarica rapida cablata da 100W sia a quella wireless. Il dispositivo dovrebbe inoltre integrare altoparlanti stereo, un motore di vibrazione più grande e una funzione di privacy per il display simile a quella già vista su alcuni modelli Samsung.

• Supporto UWB confermato dalla certificazione SRRC
• Probabile Snapdragon 8 Elite Gen 6 a 2 nm
• Doppia fotocamera da 200 megapixel
• Batteria da 7.000 mAh con ricarica rapida da 100W

Xiaomi non ha ancora confermato ufficialmente una data di presentazione, ma seguendo lo schema dello scorso anno, con Xiaomi 17 Pro annunciato a settembre 2025, è probabile che anche la serie Xiaomi 18 debutti nello stesso periodo. Come sempre, si tratta per ora di indiscrezioni non confermate ufficialmente da Xiaomi.

La serie Oppo Find X10, prossimo flagship dell’azienda cinese, ha ottenuto una nuova certificazione in Cina, segno che i preparativi per il lancio ufficiale procedono senza intoppi. Alle indiscrezioni già emerse nelle scorse settimane si aggiungono ora nuovi dettagli condivisi da un noto leaker.

Certificazione SRRC e presentazione a fine settembre

Il dispositivo, identificato con il numero di modello “PMW110”, è comparso nel database dell’ente cinese SRRC, l’autorità che rilascia le autorizzazioni necessarie per la commercializzazione dei prodotti radio in Cina. Secondo il leaker Digital Chat Station, il modello appartiene proprio alla serie Find X10 e supporta le reti 5G in banda N79.

La stessa fonte riporta che Oppo starebbe puntando a una presentazione entro la fine di settembre, e che nelle prossime settimane potrebbero emergere ulteriori certificazioni e i primi materiali promozionali ufficiali.

Chip Dimensity a 2 nanometri e fotocamera da 200 megapixel

Tra le specifiche anticipate figura un chipset Dimensity 9600 Pro, realizzato con processo produttivo a 2 nanometri, abbinato a un display piatto e a un sistema fotografico con sensore HPC da 200 megapixel.

Le indiscrezioni più datate parlano di una gamma composta da fino a quattro modelli, con diagonali dello schermo comprese tra 6,32 e 6,89 pollici, tutti realizzati con tecnologia di packaging LIPO per ridurre al minimo le cornici.

Il modello Pro punta su un sensore più grande

Per la variante Find X10 Pro si vocifera di un sensore principale da 200 megapixel di grandi dimensioni (1/1.3 pollici), affiancato da un teleobiettivo sempre da 200 megapixel e da un sensore multispettrale da 3 megapixel. La versione base, invece, dovrebbe puntare su una batteria generosa da 8.000 mAh.

Il top di gamma assoluto, Find X10 Pro Max, potrebbe spingersi oltre con una fotocamera principale da 200 megapixel abbinata a un teleobiettivo periscopico.

Chipset differenziati tra i modelli della gamma

Secondo le indiscrezioni, Oppo differenzierà i chipset all’interno della gamma: il modello standard dovrebbe montare il Dimensity 9500 Plus, mentre i modelli Pro punteranno sulla nuova generazione Dimensity 9600 a 2 nanometri.

• Certificazione SRRC ottenuta per il modello “PMW110”
• Presentazione attesa entro fine settembre
• Dimensity 9600 Pro a 2 nm per i modelli Pro
• Fotocamere fino a 200 megapixel su tutta la gamma

Come sempre in questi casi, si tratta di informazioni non confermate ufficialmente da Oppo, quindi le specifiche definitive potrebbero subire variazioni prima del lancio.

Sono trapelate in rete le prime foto di un dispositivo reale che sarebbe il prossimo Xiaomi MIX Fold 5, il pieghevole di prossima generazione del produttore cinese. Le immagini, diffuse online, mostrano la schermata delle informazioni di sistema del telefono, in cui compaiono riferimenti a HyperOS 4 e ad Android 17, confermando così alcune indiscrezioni circolate nelle scorse settimane.

Si tratta ancora di un leak non ufficiale, ma i dettagli visibili negli scatti sembrano confermare diverse specifiche che erano già state anticipate da fonti vicine all’azienda.

Cosa rivelano le foto trapelate

Le immagini pubblicate mostrano sia la schermata di blocco del dispositivo pieghevole a libro, sia la pagina con le informazioni di sistema. Da quest’ultima è possibile leggere alcuni dettagli tecnici che sembrano confermare l’identità del terminale.

• Nome in codice di sviluppo “lhasa”
• Versione software che parte da “4.0”, corrispondente a HyperOS 4
• Sistema operativo basato su Android 17
• Design a libro tipico dei pieghevoli MIX Fold

Il nome in codice “lhasa” non era mai emerso prima, ma si aggiunge oggi come ulteriore indizio a conferma dell’identità del prodotto: Xiaomi MIX Fold 5.

MIX Fold 5, il primo pieghevole con HyperOS 4?

Le voci che circolano da tempo indicano proprio il MIX Fold 5 come il primo dispositivo Xiaomi a debuttare con HyperOS 4, la nuova interfaccia basata su Android 17. Le foto trapelate sembrano confermare questo scenario, dal momento che il terminale fotografato risulta già in fase di test interno con il nuovo software.

Per un pieghevole, l’ottimizzazione software è un fattore particolarmente delicato rispetto a un normale smartphone: le pieghe multiple dello schermo, la gestione delle finestre e la continuità tra le due configurazioni (chiuso e aperto) richiedono un lavoro approfondito lato interfaccia. Non stupisce quindi che Xiaomi possa aver scelto proprio questo modello di punta per mostrare le potenzialità della nuova HyperOS 4.

Cosa aspettarsi da HyperOS 4

Tra le novità attese per la nuova versione dell’interfaccia figurano miglioramenti nella gestione del multitasking, un’integrazione più profonda con l’intelligenza artificiale e ottimizzazioni delle prestazioni generali del sistema, oltre ad affinamenti grafici pensati per valorizzare gli schermi pieghevoli di ultima generazione.

Al momento Xiaomi non ha confermato ufficialmente né il nome del dispositivo né una data di presentazione, ma la combinazione di leak, certificazioni e foto reali suggerisce che il MIX Fold 5 sia ormai in una fase di sviluppo avanzata. Continueremo a seguire gli aggiornamenti su questo pieghevole nelle prossime settimane.

Un nuovo confronto diretto mette a nudo il potenziale dei chip Qualcomm nel mondo del gaming portatile. Il canale YouTube Dame Tech ha messo a confronto un tablet Android con Snapdragon 8 Elite Gen 5 e una console portatile PC basata su AMD Ryzen AI Z2 Extreme, con risultati che aprono interessanti prospettive anche per il futuro Snapdragon 8 Elite Gen 6.

Prestazioni quasi identiche, consumi dimezzati

Il test ha messo a confronto il tablet Android REDMAGIC Astra 2, equipaggiato con Snapdragon 8 Elite Gen 5, e la console portatile ROG Xbox Ally X, basata su Ryzen AI Z2 Extreme. Facendo girare titoli PC piuttosto pesanti come GTA V e Red Dead Redemption 2, i due dispositivi hanno fatto segnare framerate praticamente sovrapponibili.

Il dato più sorprendente riguarda però i consumi: il tablet con Snapdragon ha retto il confronto assorbendo circa la metà dell’energia rispetto alla console con chip AMD, nonostante un design decisamente più sottile.

Il raffreddamento a liquido come possibile spiegazione

Parte del merito potrebbe essere attribuita al sistema di raffreddamento a liquido di cui è dotato il REDMAGIC Astra 2, pensato appositamente per il gaming e capace di mantenere il chip Qualcomm entro temperature di esercizio ottimali anche sotto carico prolungato, permettendo di sfruttare al meglio l’efficienza energetica della piattaforma Snapdragon.

Cosa significa per Snapdragon 8 Elite Gen 6

Se il chip di attuale generazione riesce già a competere ad armi pari con una soluzione pensata specificamente per il gaming PC portatile, le aspettative per il prossimo Snapdragon 8 Elite Gen 6 crescono ulteriormente. Il nuovo SoC Qualcomm, atteso nei prossimi mesi su diversi flagship Android, dovrebbe portare in dote ulteriori miglioramenti sia lato prestazioni sia lato efficienza.

• Framerate comparabili a un chip PC dedicato al gaming portatile
• Consumi energetici dimezzati rispetto a Ryzen AI Z2 Extreme
• Design del dispositivo Android più compatto
• Prospettive ancora migliori per il successivo Snapdragon 8 Elite Gen 6

Il test conferma quindi come i chip Qualcomm stiano guadagnando terreno anche in un ambito, quello del gaming portatile ad alte prestazioni, tradizionalmente dominato da soluzioni x86. Per gli utenti Android, questo si traduce in prospettive sempre più interessanti in termini di prestazioni videoludiche sui prossimi smartphone e tablet di fascia alta.

Firestudio è un client desktop open source per Firebase con gestione Firestore, Storage e Authentication tramite interfaccia grafica.
Stai leggendo Firestudio porta una GUI open source per gestire Firebase dal desktop Linux, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Cinque anni e mezzo di carcere ciascuno. È questa la cifra con cui la giustizia britannica ha chiuso, almeno sul fronte penale, uno degli attacchi informatici più dirompenti mai subiti da un’infrastruttura critica del Regno Unito: l’intrusione del 2024 in Transport for London, l’authority che gestisce la mobilità dell’intera Londra. Owen Flowers, 18 anni, e Thalha Jubair, 20, sono stati condannati il 16 luglio 2026 dalla Woolwich Crown Court. Sono, secondo l’accusa, i primi ad essere condannati per la Section 3ZA del Computer Misuse Act — la fattispecie più grave della legge britannica sui crimini informatici — e la National Crime Agency (NCA) definisce il loro caso il più grande procedimento per cybercrime mai affrontato dai tribunali del Paese.

Chi sono Flowers e Jubair, e cosa hanno fatto

I due sono descritti dalla NCA come membri di primo piano di Scattered Spider, il collettivo criminale tracciato anche come Octo Tempest, UNC3944 e 0ktapus, responsabile secondo gli inquirenti di centinaia di attacchi tra il 2022 e il 2025. La Crown Prosecution Service (CPS) è più cauta nell’attribuzione diretta, notando che gli imputati hanno rivendicato in vari momenti l’appartenenza al gruppo senza che questo costituisse, di per sé, la base dell’accusa.

L’intrusione in TfL è avvenuta tra il 31 agosto e il 3 settembre 2024. L’attacco ha reso inutilizzabili 148 sistemi dell’authority, costringendo tutti i 27.000 dipendenti a recarsi fisicamente in un ufficio per il reset delle credenziali — non essendo più possibile farlo da remoto in sicurezza. Sono stati compromessi anche il sistema di rimborsi Oyster (inclusi, per circa 5.000 persone, numeri di conto bancario e codici sort code), il servizio Dial-a-Ride per i cittadini con disabilità, il canale dei pagamenti digitali e le domande per le Oyster photocard agevolate per bambini e giovani. NCA e CPS stimano il danno complessivo, tra perdite e costi di ripristino, in 29 milioni di sterline.

Un rischio sistemico da 56 miliardi di sterline

Il dato più inquietante emerso dal processo riguarda ciò che sarebbe potuto succedere e non è successo. Secondo la ricostruzione dell’accusa, le conversazioni tra i due imputati suggerivano l’intenzione di cancellare l’accesso al termine dell’operazione, ma nessuno può dire con certezza cosa avessero realmente pianificato. La NCA stima che uno shutdown riuscito della rete di TfL — che gestisce in media 9 milioni di spostamenti al giorno — avrebbe potuto costare all’economia britannica fino a 56 miliardi di sterline. Uno scenario rimasto ipotetico solo perché TfL, rendendosi conto della compromissione, ha scelto di disattivare preventivamente la propria rete per contenere gli attaccanti.

I due si sono dichiarati colpevoli il 22 giugno 2026, il primo giorno del processo, evitando così il dibattimento. Hanno ammesso il reato sulla base di aver agito in modo “reckless” — sconsiderato — rispetto al rischio di causare o creare un pericolo significativo per il benessere umano, elemento costitutivo della Section 3ZA.

Come sono stati identificati

Flowers è stato arrestato per la prima volta il 6 settembre 2024, tre giorni dopo la fine dell’intrusione in TfL, nella sua abitazione a Walsall. Al momento dell’arresto, gli agenti NCA lo hanno sorpreso mentre era ancora attivo su due ulteriori obiettivi: le reti delle organizzazioni sanitarie statunitensi SSM Health Care Corporation e Sutter Health. Tra i dispositivi sequestrati — laptop, computer desktop, hard disk e chiavette USB — un portatile Acer conteneva uno screenshot della connettività di rete verso l’infrastruttura TfL e diversi video, registrati dallo stesso Flowers, che mostravano Jubair muoversi all’interno dei sistemi dell’authority londinese durante l’attacco. I due comunicavano in tempo reale su Telegram e condividevano uno spazio di lavoro online.

L’accusa ha dimostrato che Flowers era collegato al server remoto usato per lanciare tutte e tre le intrusioni, con prove ricavate dai suoi stessi dispositivi. Le informazioni che collegano Jubair all’attacco TfL sono state invece ottenute all’estero, con la collaborazione di autorità giudiziarie di altri Paesi — un dettaglio che la CPS non ha specificato ulteriormente. Jubair, arrestato il 16 settembre 2025, ha un secondo procedimento ancora aperto negli Stati Uniti: un atto d’accusa depositato nel New Jersey lo collega a circa 120 intrusioni di rete e almeno 47 vittime statunitensi tra maggio 2022 e settembre 2025, per oltre 115 milioni di dollari in riscatti pagati, incluse violazioni ai danni di un’infrastruttura critica USA e dei tribunali federali. Su questo fronte rischia fino a 95 anni di carcere; nessuna delle comunicazioni ufficiali diffuse finora affronta il tema dell’estradizione.

Scattered Spider è davvero finita?

La NCA sostiene che l’azione contro i due abbia “sostanzialmente fermato” il gruppo, citando una valutazione di Microsoft secondo cui gli arresti ne avrebbero degradato in modo significativo la capacità operativa. Ma la stessa agenzia ammette che altri criminali potrebbero continuare a usare il marchio “Scattered Spider” per rivendicare nuovi attacchi. Non è un’ipotesi remota: a gennaio 2026 Mandiant ha documentato l’espansione di un’operazione di estorsione a marchio ShinyHunters che replica lo stesso modello — vishing verso i dipendenti, pagine di phishing per rubare credenziali SSO e codici MFA, enrollment di un dispositivo dell’attaccante per bypassare l’autenticazione multifattore.

È proprio questo il punto debole che accomuna la maggior parte dei casi riconducibili a Scattered Spider: non un exploit tecnico sofisticato, ma la manipolazione dei processi di help desk — reset password, gestione dei dispositivi MFA — con tecniche di social engineering telefonico mirate e ben documentate.

Due righe per i difensori

Il caso TfL resta un caso di scuola su come un’infrastruttura critica possa essere messa in ginocchio non da uno zero-day, ma da processi organizzativi vulnerabili al fattore umano. Alcune indicazioni pratiche per ridurre l’esposizione a gruppi con TTP simili a Scattered Spider:

• Verificare sempre l’identità con procedure fuori banda (callback su numero verificato, verifica video) prima di eseguire reset password, modifiche MFA o enrollment di nuovi dispositivi richiesti telefonicamente all’help desk.
• Limitare la possibilità per il personale di help desk di eseguire reset critici senza approvazione di un secondo operatore (four-eyes principle).
• Monitorare enrollment MFA anomali, specialmente se avvengono subito dopo un reset password.
• Coinvolgere le forze dell’ordine tempestivamente in caso di incidente: secondo la NCA, la collaborazione precoce di TfL è stata determinante per l’esito del procedimento.
• Segmentare le reti operative critiche (biglietteria, pagamenti, servizi per l’utenza vulnerabile) da quelle amministrative, per limitare l’impatto di una compromissione laterale.

Fonti: The Hacker News, National Crime Agency.

Non serve colpire una centrale elettrica per mettere in ginocchio una filiera critica: basta un ransomware ben piazzato nei sistemi produttivi di un’azienda che imbottiglia latte. Il 16 luglio 2026 Coca-Cola ha comunicato alla SEC che la sua controllata Fairlife ha sospeso la produzione negli Stati Uniti dopo un attacco ransomware che ha colpito i sistemi legati alla produzione stessa. Un episodio che, al netto delle dimensioni del marchio coinvolto, racconta molto sullo stato di sicurezza dell’OT nel settore alimentare.

Cosa è successo

Fairlife, con sede a Chicago, è il marchio di latte ultrafiltrato di proprietà di Coca-Cola, noto anche per le linee Core Power Protein Shakes e Nutrition Plan. Nel filing 8-K depositato presso la Securities and Exchange Commission, Coca-Cola ha dichiarato che soggetti non autorizzati hanno avuto accesso a una parte dei sistemi di Fairlife, inclusi quelli legati alla produzione, in un attacco che l’azienda descrive esplicitamente come ransomware. Le operazioni negli stabilimenti statunitensi sono state temporaneamente sospese; la produzione in Canada, gestita separatamente, non risulta invece impattata.

Coca-Cola ha attivato i protocolli di incident response e business continuity, coinvolto consulenti esterni e notificato le forze dell’ordine, precisando che qualità e sicurezza del prodotto non sono state compromesse. Al momento della scrittura, la società non ha reso noto quale gruppo ransomware sia responsabile, se siano stati sottratti dati né se sia stata ricevuta una richiesta di riscatto. Nessuna gang ransomware nota ha ancora rivendicato l’attacco, un silenzio che nel settore viene letto come tipico delle prime fasi di un negoziato, prima che gli estorsori tornino a farsi vivi minacciando la pubblicazione di eventuali dati sottratti.

Non è un caso isolato: la filiera alimentare nel mirino

L’attacco a Fairlife arriva in un contesto in cui il comparto food & beverage è bersaglio ricorrente del ransomware, spesso proprio perché la convergenza IT/OT nelle linee di produzione rende gli impianti fragili: basta bloccare i sistemi SCADA o MES che orchestrano il confezionamento per fermare intere linee, anche senza toccare la sicurezza alimentare in senso stretto. Il precedente più noto resta l’attacco del 2021 a JBS, il colosso mondiale della carne, costretto a fermare impianti in Nord America e Australia e a pagare 11 milioni di dollari di riscatto al gruppo REvil. Nella sola finestra delle ultime 48 ore, la stessa dinamica si è ripetuta altrove: in Giappone, un attacco informatico a un operatore logistico ha svuotato le cucine di migliaia di ristoranti per un blocco nelle consegne di prodotti alimentari, mentre il colosso giapponese dei surgelati Nichirei ha segnalato la disruzione delle proprie operazioni per un incidente informatico separato.

Il filo comune è la dipendenza di filiere alimentari globalizzate da sistemi IT centralizzati per pianificazione della produzione, gestione ordini e logistica: quando quei sistemi vengono cifrati o resi inaccessibili, l’impatto si propaga rapidamente dagli scaffali dei supermercati alle cucine dei ristoranti, ben oltre il perimetro aziendale colpito.

Perché conta anche per chi non produce latte

Il caso Fairlife è interessante per i difensori non tanto per i dettagli tecnici, che Coca-Cola non ha ancora reso pubblici, quanto per la dinamica di disclosure e per l’esposizione di un brand multimiliardario a un rischio operativo concreto tramite una controllata. Il filing SEC evidenzia un punto spesso sottovalutato nei risk assessment: la segmentazione tra rete IT aziendale e rete OT di produzione, quando esiste, va verificata regolarmente, perché un attacco che compromette “solo” i sistemi IT può comunque paralizzare la produzione se i due domini condividono directory service, credenziali o piattaforme di orchestrazione.

Per le aziende manifatturiere, specialmente nel food & beverage dove i margini di tolleranza su tempi di fermo sono minimi per ragioni di deperibilità delle materie prime, le priorità restano quelle già emerse dai casi JBS e Nichirei: backup offline testati e realmente isolati (non solo replicati su un secondo datacenter raggiungibile dalla stessa rete), piani di failover manuale per le linee di produzione critiche, segmentazione rigorosa tra reti corporate e reti OT/ICS, e accordi di incident response pre-negoziati con forze dell’ordine e consulenti forensi, in modo da non partire da zero quando il tempo conta più di ogni altra cosa.

• Verificare che i backup dei sistemi MES/SCADA siano realmente air-gapped e non solo “logicamente separati”
• Testare periodicamente scenari di failover manuale per le linee di produzione più critiche
• Mappare le dipendenze condivise (Active Directory, VPN, orchestrazione cloud) tra rete IT e rete OT
• Predisporre in anticipo contatti con FBI/law enforcement locale e retainer di incident response per ridurre i tempi di reazione

Cosa manca ancora al quadro

Al momento della pubblicazione, mancano ancora elementi chiave per una piena attribuzione: nome della gang ransomware, vettore di accesso iniziale, eventuale esfiltrazione di dati e ammontare della richiesta di riscatto. Continueremo a seguire l’evoluzione del caso Fairlife, aggiornando l’articolo qualora emergano rivendicazioni o dettagli tecnici da fonti di threat intelligence.

Stato indicatori al 18/07/2026:
- Gruppo ransomware responsabile: non identificato pubblicamente
- Vettore di accesso iniziale: non divulgato
- Esfiltrazione dati: non confermata
- Richiesta di riscatto: non divulgata
- Sistemi impattati: infrastrutture di produzione Fairlife (solo USA)
- Sistemi non impattati: produzione Fairlife Canada, qualita/sicurezza prodotto

Riferimento normativo: SEC Form 8-K depositato da The Coca-Cola Company il 16/07/2026

MKVToolNix è una suite software open source per la creazione, modifica, analisi e manipolazione di file Matroska (MKV). Sviluppata da Moritz Bunkus e distribuita sotto licenza GNU GPL, MKVToolNix si rivolge sia a utenti...

🔗 Leggi il post completo