L’aumento delle segnalazioni di bug grazie all’IA: un’arma a doppio taglio per il kernel Linux Con la pubblicazione della versione 7.1-rc4 del kernel Linux, Linus Torvalds ha condiviso alcune riflessioni critiche sull’uso degli strumenti...

🔗 Leggi il post completo

Il test di autonomia condotto da GSMArena sull’Xperia 1 VIII ha riservato una sorpresa: lo smartphone di Sony non solo migliora sensibilmente rispetto alle generazioni precedenti, ma riesce persino a superare il Galaxy S26 Ultra di Samsung nella resistenza alla batteria. Un risultato inaspettato per molti, che premia il lavoro di ottimizzazione compiuto da Sony.

17 ore e 47 minuti di Active Use Score

L’Active Use Score calcolato da GSMArena, che simula un utilizzo intensivo e variegato, si attesta su 17 ore e 47 minuti per l’Xperia 1 VIII. Il punteggio è il risultato di quattro prove distinte:

• Telefonate: 37 ore 43 minuti
• Navigazione web: 14 ore 43 minuti
• Riproduzione video: 26 ore 42 minuti
• Gaming: 10 ore 22 minuti

La riproduzione video è l’area che registra il miglioramento più marcato rispetto al passato, rendendo l’Xperia 1 VIII una scelta solida per chi consuma molti contenuti in mobilità.

Due ore in più rispetto all’Xperia 1 VII

Il confronto con il predecessore è netto: l’Xperia 1 VII si fermava a 15 ore e 32 minuti, quasi due ore e mezza in meno. Guardando alla storia recente della serie, l’Xperia 1 V era addirittura a 12 ore e 24 minuti, il che rende l’Xperia 1 VIII il modello con la migliore autonomia mai registrata nella serie Xperia 1.

Supera il Galaxy S26 Ultra, perde contro Xiaomi 17 Ultra

Il confronto con la concorrenza è ancora più interessante. Il Galaxy S26 Ultra si ferma a 16 ore e 23 minuti, nonostante monti anch’esso una batteria da 5.000 mAh: Xperia 1 VIII lo supera di oltre un’ora. Solo lo Xiaomi 17 Ultra, forte di una batteria da 6.000 mAh, fa meglio con 19 ore. Ma a parità di capacità della cella, Sony dimostra di avere un’ottimizzazione software e hardware di livello eccellente, superando uno dei rivali più temibili sul mercato Android premium.

Il Google Pixel 11 si preannuncia come uno degli smartphone Android più attesi del 2026. Con un lancio previsto intorno ad agosto, il nuovo flagship di Mountain View punta a fare un salto generazionale in termini di display, potenza di calcolo e funzionalità AI, riposizionandosi come diretto concorrente di iPhone 17 e Galaxy S26.

Display OLED M16: luminosità e colori di nuova generazione

Una delle novità più attese riguarda il pannello display. Il Pixel 11 monterebbe un pannello M16 OLED di Samsung, l’ultima generazione di materiali che garantisce luminosità più elevata rispetto agli M14 attualmente in uso sui modelli concorrenti. Il risultato pratico? Una migliore leggibilità all’aperto e una resa cromatica ancora più fedele, con un’esperienza visiva complessivamente superiore.

Tensor G6 a 2nm: potenza e sicurezza al top

Sul fronte prestazioni, il chip atteso è il Tensor G6, prodotto con processo a 2 nanometri e ottimizzato per l’elaborazione AI in locale. A fianco del Tensor G6 troverebbe posto il chip di sicurezza Titan M3, che offre protezione a livello hardware. Una novità interessante riguarda il modem: Google sembrerebbe intenzionata ad abbandonare le soluzioni Exynos in favore del modem MediaTek M90, con benefici attesi in termini di stabilità della connessione e consumi.

Torna il Pixel Glow: notifiche a colori sul retro

Tra le funzionalità più originali c’è il ritorno del Pixel Glow, il sistema di notifiche luminose integrate nel pannello posteriore. Stando ai leak, il nuovo Glow potrebbe supportare fino a 8 colori diversi (inclusi rosso, verde e blu), ognuno associabile a un tipo di notifica. Con l’integrazione di Gemini AI, si ipotizza anche una gestione intelligente delle notifiche stesse.

Fotocamera rinnovata con il sensore “chemosh” da 50MP

Sul versante fotografico, il Pixel 11 e il Pixel 11 Pro Fold potrebbero ricevere un nuovo sensore principale da 50MP, nome in codice “chemosh”. I modelli Pixel 11 Pro e Pro XL avrebbero invece aggiornamenti sia sul sensore principale che sul teleobiettivo. I dettagli completi sulle specifiche ottiche non sono ancora stati confermati, ma le premesse sono più che promettenti. L’attesa per l’annuncio ufficiale di Google cresce di giorno in giorno.

Google ha svelato una delle novità più originali in arrivo su Android 17: si chiama “Create My Widget” ed è una funzione basata sull’intelligenza artificiale che permette agli utenti di creare widget completamente personalizzati per la schermata Home, descrivendoli semplicemente a parole. L’annuncio è avvenuto durante The Android Show: I/O Edition, l’evento dedicato alle novità del sistema operativo Android.

Come funziona: basta scrivere cosa vuoi

Il funzionamento è estremamente intuitivo. L’utente descrive in linguaggio naturale il tipo di widget che desidera, e Gemini AI genera automaticamente un widget funzionale da aggiungere alla schermata. Google ha mostrato alcuni esempi pratici: si può chiedere di visualizzare “tre ricette proteiche da preparare in anticipo ogni settimana” oppure creare un widget meteo che metta in evidenza “vento e precipitazioni” per chi si sposta in bicicletta.

Integrazione con le app Google e il web

Create My Widget non si limita a mostrare informazioni statiche: grazie all’integrazione con le app Google e con i contenuti del web, è possibile generare widget dinamici. Chi sta pianificando un viaggio, ad esempio, potrebbe creare un pannello che raccoglie in un unico posto voli, hotel e prenotazioni ristorante. Un vero e proprio dashboard personale, aggiornato in tempo reale e costruito sulle esigenze di ciascun utente.

Prima disponibilità su Pixel e Galaxy

La funzione arriverà in prima battuta su Pixel e Samsung Galaxy a partire dalla prossima estate, per poi espandersi ad altri dispositivi Android. Si tratta di un segnale chiaro della direzione che Google vuole imprimere ad Android: un sistema operativo in cui l’AI non è uno strumento separato, ma parte integrante dell’esperienza quotidiana, in grado di adattarsi alle preferenze di ogni singolo utente. Il concetto stesso di “widget preconfezionato” potrebbe così diventare un ricordo del passato.

I rumor sul Galaxy Z Fold 8 Wide continuano ad arricchirsi di dettagli, e le ultime indiscrezioni riguardano in particolare il comparto fotografico. Il nuovo modello pieghevole di Samsung, pensato come alternativa più compatta e orientata alla versatilità rispetto al classico Z Fold 8, si differenzierà dal fratello maggiore anche nella configurazione delle fotocamere, con scelte che sorprendono.

Addio al teleobiettivo: una scelta controversa

La notizia che farà discutere è l’assenza del teleobiettivo da 10MP con zoom ottico 3x presente sul Galaxy Z Fold 7. Il Fold 8 Wide rinuncerebbe completamente alle capacità di zoom ottico, una scelta che potrebbe deludere chi utilizza il proprio smartphone anche per fotografia a distanza. Anche la fotocamera principale cambierebbe: si passerebbe dal sensore da 200MP con formato 1/1,3 pollici del Fold 7 a uno da 50MP, con ripercussioni sulla risoluzione disponibile per il crop digitale.

Anche l’apertura del diaframma del sensore principale è prevista in lieve calo: da f/1.7 a f/1.8. Un cambiamento minimo, ma che potrebbe avere un impatto in condizioni di scarsa illuminazione.

Il punto di forza: ultra-grandangolare da 50MP

A compensare l’assenza del tele ci pensa la fotocamera ultra-grandangolare, che subirebbe un aggiornamento notevole: si passerebbe dai 12MP con f/2.2 del Fold 7 a un sensore da 50MP con apertura f/1.9. Questo significa foto grandangolari nettamente più dettagliate, con migliore resa in ambienti chiusi e paesaggi. Samsung sembrerebbe puntare su un modello ottimizzato per l’uso quotidiano, dove il grandangolo è la focale più utilizzata, piuttosto che su un device fotografico tuttofare.

Un pieghevole pensato per sfidare l’iPhone Fold

Il Galaxy Z Fold 8 Wide è visto come una risposta all’atteso pieghevole di Apple, che dovrebbe avere dimensioni simili. Samsung sta quindi cercando di posizionare un foldable più maneggevole e con un design esterno più fruibile, capace di attrarre chi vuole il form factor pieghevole senza rinunciare alla compattezza. La presentazione ufficiale è attesa per il Galaxy Unpacked di luglio 2026.

Numerosi utenti dello smartphone AQUOS sense10 di Sharp stanno segnalando un fastidioso problema: il dispositivo si disconnette dal Wi-Fi senza alcun motivo apparente e passa automaticamente alla rete dati mobile, con conseguente consumo anomalo di traffico. Le segnalazioni si stanno moltiplicando sui forum italiani e giapponesi, tanto da far ipotizzare un bug di sistema legato ad Android 16.

La spia “Bassa qualità” che innesca la disconnessione

Il problema sembra seguire uno schema preciso: il telefono visualizza l’avviso “Bassa qualità” accanto alla connessione Wi-Fi a 2,4 GHz, dopodiché il sistema passa autonomamente alla rete 5G o 4G. Un utente ha riferito di aver consumato oltre 30 GB di dati mobili su Instagram senza accorgersene, convinto di essere connesso al Wi-Fi di casa.

Particolarmente significativo è il fatto che lo stesso router funzioni senza problemi con altri smartphone e PC: solo l’AQUOS sense10 mostra instabilità. Anche chi proveniva dall’AQUOS sense8 non aveva mai riscontrato questo comportamento con il modello precedente.

Il sospetto: Android 16 troppo aggressivo nel giudicare la qualità del Wi-Fi

Alcuni utenti e analisti ipotizzano che la causa non sia l’hardware dell’AQUOS sense10 in sé, ma piuttosto il sistema di valutazione automatica della qualità Wi-Fi introdotto con Android 16. Stando a questa teoria, l’algoritmo sarebbe troppo severo nel classificare le reti come “bassa qualità”, provocando il passaggio forzato ai dati mobili anche quando la connessione Wi-Fi sarebbe del tutto accettabile. Segnalazioni simili sono arrivate anche da utenti di AQUOS R10, suggerendo che il problema potrebbe riguardare altri dispositivi con lo stesso aggiornamento.

Come risolvere (in attesa di una patch ufficiale)

Nel frattempo, la community ha condiviso alcune possibili soluzioni temporanee da impostare nelle opzioni sviluppatore:

• Disattivare “Wi-Fi scan throttling”
• Disattivare “Usa la regolazione automatica della connessione”
• Disabilitare “Connessione dati mobili sempre attiva”

Non si tratta di soluzioni definitive, ma diversi utenti hanno riportato miglioramenti significativi dopo queste modifiche. Sharp e Google non hanno ancora rilasciato dichiarazioni ufficiali sul problema.

Sony ha annunciato il suo nuovo ammiraglia Xperia 1 VIII, e i dati ufficiali registrati nel database europeo EPREL (European Product Registry for Energy Labelling) ci offrono un confronto dettagliato con il predecessore Xperia 1 VII. I numeri raccontano un’evoluzione significativa su più fronti: efficienza energetica, autonomia, resistenza e facilità di riparazione.

Classe energetica A: il salto di qualità più evidente

Il cambiamento più visibile riguarda la classificazione energetica europea: l’Xperia 1 VIII ottiene la classe A, il livello massimo, mentre l’Xperia 1 VII si fermava alla classe B. Un risultato che dimostra come Sony abbia lavorato in profondità sulla gestione dell’energia del dispositivo, ottimizzando non solo il chipset ma l’intero ecosistema software e hardware.

Stessa batteria, ma 7 ore e mezza in più di autonomia

Sorprendente il dato sull’autonomia: entrambi i modelli montano una batteria da 4.850 mAh, ma l’Xperia 1 VIII riesce a estrarne molto di più. La durata per ciclo d’uso passa da 43 ore e 30 minuti (Xperia 1 VII) a 51 ore e 7 minuti (Xperia 1 VIII), con un miglioramento di circa 7 ore e mezza. La durata del ciclo di vita della batteria rimane invariata a 1.400 cicli di ricarica per entrambi.

Più resistente alle cadute

Anche la robustezza fa un balzo in avanti: nel test di caduta libera ripetuta, l’Xperia 1 VIII supera le 270 cadute senza guasti, contro le 181 dell’Xperia 1 VII. La resistenza all’acqua e alla polvere IP68 e la durezza del vetro (grado Mohs 6) rimangono invariate. Le specifiche legate alla riparabilità (indice 1,78) e al supporto software (5 anni di aggiornamenti dopo la fine della commercializzazione) sono invece stabili rispetto al modello precedente.

Un upgrade convincente sotto ogni aspetto

I dati EPREL confermano che Xperia 1 VIII non è un semplice aggiornamento cosmetico: Sony ha lavorato in modo serio sull’efficienza complessiva, portando risultati tangibili che si tradurranno in una maggiore autonomia quotidiana e in un device più affidabile nel lungo termine. Un passo avanti che renderà la scelta ancora più interessante per chi valutava già la serie Xperia 1.

La prossima serie Oppo Find X10 potrebbe essere la più articolata di sempre. Secondo il noto leaker Digital Chat Station, il produttore cinese starebbe testando quattro varianti diverse del flagship, con diagonali dello schermo che vanno dai 6,32 ai 6,89 pollici. Una lineup pensata per coprire ogni fascia di utenti, dal compatto al max-size.

Quattro display, quattro esperienze diverse

Stando alle ultime indiscrezioni, i quattro modelli confermati in fase di test sarebbero:

• 6,32 pollici – display 1.5K LTPS (modello compatto)
• 6,59 pollici – display 1.5K LTPO
• 6,78 pollici – display 1.5K LTPO
• 6,89 pollici – display 2K LTPO (modello top di gamma)

Rispetto alla generazione precedente (Find X9), la serie Find X10 sembra voler mantenere taglie simili ma con una segmentazione più precisa. Il modello da 6,32 pollici potrebbe rappresentare una versione “Pro compatta” o una nuova variante della lineup, e il suo posizionamento nel catalogo è ancora tutto da definire. Il modello più grande, quello da 6,89 pollici, potrebbe corrispondere alla variante Ultra o Pro Max.

Tecnologia LIPO e bordi ultra-sottili per tutta la gamma

Un elemento comune a tutti e quattro i modelli sarebbe l’adozione della tecnologia LIPO, che permette cornici ultra-sottili con un bilanciamento laterale migliorato. Insieme a questo, i device adotterebbero tutti angoli a grande raggio di curvatura, per un’estetica più morbida e moderna. Si parla anche di supporto al gamut BT.2020, la specifica che garantisce una riproduzione cromatica di livello professionale.

Quando arriverà?

Oppo non ha ancora comunicato una data ufficiale per la presentazione della serie Find X10. Considerando i tempi della serie Find X9, il lancio potrebbe avvenire tra la fine del 2026 e l’inizio del 2027. Nelle prossime settimane probabilmente emergeranno ulteriori dettagli su chipset, fotocamera e specifiche complete.

Xiaomi ha pubblicato un teaser ufficiale che mostra un auricolare wireless dal design completamente nuovo, stuzzicando la curiosità degli appassionati di audio mobile. La comunicazione parla esplicitamente di un “form factor del tutto inedito”, e dalle immagini emerge un profilo curvo che si discosta nettamente dai classici auricolari in-ear o a bastoncino.

Tutto fa pensare a un design clip-on open-ear

Analizzando il teaser, la forma dell’auricolare ricorda quella degli auricolari a clip (o open-ear), che si agganciano al padiglione auricolare senza entrare nel canale uditivo. Il case di ricarica presenta due alloggiamenti con una curvatura caratteristica che non lascia spazio a dubbi sulla silhouette del prodotto.

Questo tipo di auricolari sta conquistando una fetta sempre più ampia del mercato grazie a una serie di vantaggi rispetto agli in-ear tradizionali: comfort durante l’uso prolungato, nessuna pressione sul condotto uditivo, possibilità di sentire l’ambiente circostante in modo naturale e design adatto sia allo sport che all’uso quotidiano.

Presentazione possibile insieme allo Xiaomi 17 Max

Il teaser è stato diffuso attraverso canali legati al prossimo smartphone di punta Xiaomi 17 Max, il che fa pensare a una presentazione congiunta. Xiaomi è solita presentare i propri accessori audio in abbinamento ai nuovi flagship, puntando su un ecosistema integrato.

Va sottolineato che per il momento non sono stati rivelati né nome commerciale né specifiche tecniche: rimangono ignoti il supporto al cancellazione attiva del rumore, le specifiche Bluetooth, l’autonomia della batteria e la fascia di prezzo. Ulteriori dettagli sono attesi nelle prossime settimane. Restate sintonizzati.

Samsung starebbe pianificando il prossimo grande evento Galaxy Unpacked per il 22 luglio 2026 a Londra. Stando alle indiscrezioni provenienti dai media coreani, la presentazione della seconda metà dell’anno si terrà nella capitale britannica e potrebbe rivelarsi la più ambiziosa di sempre per la casa di Seoul, con una lineup che punta a stravolgere il mercato degli smartphone pieghevoli e dei wearable intelligenti.

Tre pieghevoli invece di due

Tradizionalmente, l’evento estivo di Samsung vede protagonisti due modelli: il Galaxy Z Fold e il Galaxy Z Flip. Quest’anno, però, i leak suggeriscono una lineup ampliata a tre dispositivi pieghevoli:

• Galaxy Z Flip 8
• Galaxy Z Fold 8
• Galaxy Z Fold 8 Wide – la vera novità

Il Galaxy Z Fold 8 Wide è il modello che sta attirando maggiore attenzione. Rispetto al classico Fold, si caratterizzerebbe per un formato più largo orizzontalmente e più compatto in altezza, avvicinandosi alle proporzioni di un tablet quando aperto. Chiuso, invece, il display esterno sarebbe più comodo da usare rispetto alle generazioni precedenti. Un design pensato per chi vuole massimizzare il multitasking e la visione video.

Galaxy Glasses con Android XR e Gemini AI

L’altro grande protagonista atteso all’Unpacked di luglio sarebbero i Galaxy Glasses, gli occhiali intelligenti sviluppati in collaborazione con Google e basati sulla piattaforma Android XR. Il prodotto integrerebbe le funzionalità AI di Gemini per offrire un assistente sempre a portata di sguardo.

A differenza dei classici AR glasses, i Galaxy Glasses potrebbero non disporre di un display integrato. Il focus sarebbe sull’assistenza AI contestuale: microfono, speaker e fotocamera ad alte prestazioni permetterebbero al dispositivo di analizzare l’ambiente circostante in tempo reale e rispondere alle esigenze dell’utente. Per il design esterno, Samsung starebbe collaborando con il brand di eyewear Gentle Monster, già noto per le sue forme originali e raffinate.

Un evento da non perdere

Se le indiscrezioni venissero confermate, il Galaxy Unpacked di Londra sarebbe uno degli eventi tech più importanti dell’estate 2026, capace di ridefinire sia il segmento foldable che quello dei wearable AI. Non ci resta che attendere la conferma ufficiale da parte di Samsung.

Poco sorprendentemente, dopo Copy Fail e Dirty Frag ecco arrivare l'ennesima vulnerabilità, con annessa PoC pubblica, collegata alla gestione della page cache del Kernel.
La parte peggiore è che probabilmente non sarà l'ultima.

🔗 Leggi il post completo

Il problema che non si vede finché è troppo tardi

C’è un pattern ricorrente nelle architetture a microservizi: tutto funziona in modo impeccabile per mesi, i test automatici sono verdi, il monitoraggio non mostra allarmi rilevanti, e il team è soddisfatto della solidità del sistema. Poi, spesso durante un picco di traffico ordinario o un evento previsto, qualcosa si inceppa. La latenza schizza verso l’alto, le code si allungano, i timeout si moltiplicano. Il problema non è stato causato dall’evento in sé — era già lì, nascosto sotto la superficie.

Questo articolo analizza i colli di bottiglia più insidiosi che affliggono i microservizi in produzione: quelli che non emergono nei test di carico standard e che vengono spesso diagnosticati troppo tardi.

1. Esaurimento del connection pool al database

Il problema del connection pool è forse il più comune e il meno visibile fino al momento critico. In un’architettura a microservizi, ogni istanza di ogni servizio apre e gestisce il proprio pool di connessioni al database. Il calcolo è semplice: se hai 10 microservizi con 5 istanze ciascuno e ogni istanza mantiene un pool di 10 connessioni, stai occupando 500 connessioni sul database. Scala orizzontalmente per gestire un picco di traffico, e quelle connessioni raddoppiano in pochi minuti.

La maggior parte dei database relazionali ha un limite fisico di connessioni concorrenti. PostgreSQL, per esempio, ha un default di 100 connessioni per il parametro max_connections. Superato il limite, nuove richieste di connessione falliscono con errori che spesso vengono nascosti da retry automatici, mascherando il problema effettivo fino a quando il sistema non collassa.

Come diagnosticarlo

-- PostgreSQL: connessioni attive per applicazione
SELECT application_name, count(*), state
FROM pg_stat_activity
GROUP BY application_name, state
ORDER BY count DESC;

-- Verifica il limite configurato
SHOW max_connections;


Come risolverlo

La soluzione più efficace per scenari ad alta concorrenza è l’uso di un connection pooler esterno come PgBouncer. PgBouncer opera in modalità transaction pooling: riusa le connessioni al database tra più client, riducendo drasticamente il numero di connessioni fisiche necessarie indipendentemente dal numero di istanze dei servizi.

# pgbouncer.ini — configurazione essenziale
[databases]
mydb = host=pg-primary port=5432 dbname=mydb

[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20
reserve_pool_size = 5


// Connection string con pool sizing esplicito
"Host=pgbouncer-host;Database=mydb;Username=app;Password=...;
 Maximum Pool Size=10;Minimum Pool Size=2;Connection Idle Lifetime=300"


2. Thread pool starvation nelle chiamate sincrone

Il thread pool starvation è un problema particolarmente subdolo nelle applicazioni ASP.NET Core o nelle applicazioni Spring Boot che mischiano codice asincrono e sincrono. Quando un thread del pool viene bloccato in attesa di un’operazione I/O (una query al database, una chiamata HTTP a un servizio dipendente, una lettura da file), quel thread non è disponibile per elaborare nuove richieste. Se questo accade su scala, il thread pool si esaurisce e le nuove richieste rimangono in coda indefinitamente.

Il sintomo tipico è una degradazione progressiva delle performance durante i picchi: il throughput crolla, i tempi di risposta salgono in modo apparentemente inspiegabile, ma il database e la CPU risultano ancora sotto carico normale.

Pattern da evitare in .NET

// ❌ SBAGLIATO: blocca un thread del pool
public IActionResult GetData()
{
    var result = _service.GetDataAsync().Result; // .Result blocca il thread
    return Ok(result);
}

// ❌ Altrettanto problematico
public IActionResult GetData()
{
    var result = _service.GetDataAsync().GetAwaiter().GetResult();
    return Ok(result);
}


// ✅ CORRETTO: il thread viene restituito al pool durante l'attesa
public async Task<IActionResult> GetData()
{
    var result = await _service.GetDataAsync();
    return Ok(result);
}


Come diagnosticare il thread pool starvation

In .NET, puoi monitorare lo stato del thread pool a runtime:

ThreadPool.GetAvailableThreads(out int workerThreads, out int completionPortThreads);
ThreadPool.GetMaxThreads(out int maxWorker, out int maxCompletionPort);

// Se workerThreads è vicino a 0 con carico moderato, sei in starvation
Console.WriteLine($"Available: {workerThreads}/{maxWorker}");


dotnet-counters monitor --counters System.Runtime[threadpool-thread-count,threadpool-queue-length] -p <PID>


3. Cascading failures per dipendenze lente o non responsive

In un’architettura a microservizi, ogni servizio dipende da altri servizi. Questa catena di dipendenze è la fonte di uno dei problemi più difficili da gestire in produzione: il cascading failure. Se il Servizio B risponde lentamente, il Servizio A che lo chiama accumula richieste in attesa. I thread del pool di A vengono occupati in attesa di B, la latenza di A aumenta, il Servizio C che dipende da A inizia a ricevere timeout, e nel giro di pochi minuti l’intera catena collassa.

La soluzione consolidata è il pattern Circuit Breaker, che interrompe temporaneamente le chiamate verso un servizio degradato e restituisce immediatamente un errore (o una risposta di fallback), permettendo al sistema di degradare in modo controllato invece di collassare a cascata.

Implementazione con Polly in .NET

// Configurazione circuit breaker con Polly v8
var circuitBreakerPolicy = new ResiliencePipelineBuilder()
    .AddCircuitBreaker(new CircuitBreakerStrategyOptions
    {
        FailureRatio = 0.5,              // Apre dopo il 50% di fallimenti
        SamplingDuration = TimeSpan.FromSeconds(10),
        MinimumThroughput = 10,          // Minimo 10 richieste nel campione
        BreakDuration = TimeSpan.FromSeconds(30), // Attende 30s prima di riprovare
        OnOpened = args =>
        {
            _logger.LogWarning("Circuit breaker aperto per {Service}", serviceName);
            return default;
        }
    })
    .AddTimeout(TimeSpan.FromSeconds(3)) // Timeout esplicito su ogni chiamata
    .Build();

// Uso
var result = await circuitBreakerPolicy.ExecuteAsync(async token =>
    await _httpClient.GetFromJsonAsync<OrderDto>("/api/orders/123", token),
    cancellationToken);


4. Mancanza di backpressure nei flussi di messaggi

I sistemi basati su message broker (Kafka, RabbitMQ, Azure Service Bus) introducono un’ulteriore classe di colli di bottiglia: quando il ritmo di produzione dei messaggi supera la capacità di elaborazione dei consumer, le code crescono indefinitamente. Questo può portare a latenza crescente nell’elaborazione, out-of-memory degli broker, e scenari in cui messaggi vengono elaborati con ore o giorni di ritardo rispetto alla loro produzione.

La soluzione è implementare la backpressure: i consumer controllano attivamente il ritmo di ricezione in base alla propria capacità di elaborazione. In Kafka, questo si gestisce configurando correttamente il numero di partizioni, il numero di consumer nel consumer group, e i parametri max.poll.records e fetch.max.bytes.

// Esempio: consumer con controllo esplicito del concurrency via MassTransit
services.AddMassTransit(x =>
{
    x.UsingRabbitMq((ctx, cfg) =>
    {
        cfg.ReceiveEndpoint("orders-queue", e =>
        {
            e.PrefetchCount = 10;        // Non prelevare più di 10 messaggi alla volta
            e.ConcurrentMessageLimit = 5; // Elabora al massimo 5 messaggi in parallelo
            e.ConfigureConsumer<OrderConsumer>(ctx);
        });
    });
});


5. N+1 queries non rilevate in produzione

Il problema delle N+1 queries è ben noto in teoria ma sorprendentemente comune in produzione, soprattutto dopo refactoring o l’aggiunta di nuove funzionalità. L’ORM carica una lista di entità (1 query), poi per ogni entità carica lazy una relazione (N query). In sviluppo, con 10 elementi nel database, il problema è invisibile. In produzione, con 10.000 elementi, si traducono in 10.001 query per ogni richiesta.

// ❌ N+1: per ogni ordine viene eseguita una query separata per i prodotti
var orders = await _context.Orders.ToListAsync();
foreach (var order in orders)
{
    // Lazy load: ogni accesso a order.Products genera una nuova query
    var productNames = order.Products.Select(p => p.Name);
}

// ✅ Eager loading: una sola query con JOIN
var orders = await _context.Orders
    .Include(o => o.Products)
    .ToListAsync();


// Program.cs
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString)
           .LogTo(Console.WriteLine, LogLevel.Information)
           .EnableSensitiveDataLogging(false) // Mai in produzione
           .ConfigureWarnings(w => w.Throw(RelationalEventId.MultipleCollectionIncludeWarning)));


Monitoraggio proattivo: gli indicatori chiave

Rilevare questi problemi prima che diventino incidenti richiede un set di metriche mirate. Oltre alle metriche standard (CPU, RAM, latenza), monitora attivamente:

• Connessioni attive al database per istanza e per servizio
• Thread pool queue length: una coda crescente anche sotto carico moderato è un segnale di allarme
• Circuit breaker state changes: ogni apertura di un circuit breaker è un evento da tracciare e analizzare
• Message lag sulle code Kafka/RabbitMQ: il ritardo tra produzione e consumo
• Slow queries: percentuale di query che superano una soglia prefissata (es. 500ms)

Strumenti come Prometheus + Grafana con i rispettivi exporter per PostgreSQL, RabbitMQ e .NET (via prometheus-net) permettono di costruire dashboard specifiche per questi pattern senza dipendere esclusivamente dai log.

Conclusione

I colli di bottiglia nascosti nei microservizi hanno una caratteristica comune: emergono sotto carico, in condizioni che i test standard non replicano fedelmente. Connection pool esauriti, thread in starvation, cascading failures, code in crescita incontrollata e N+1 queries sono problemi architetturali che richiedono attenzione già in fase di design, non solo quando il sistema è già in produzione e sotto stress.

Identificare preventivamente questi pattern, configurare correttamente i pool e i circuit breaker, e costruire un layer di osservabilità specifico per questi indicatori è l’investimento tecnico con il miglior ritorno in termini di stabilità per qualsiasi sistema distribuito di dimensioni non banali.

Fonte: The Hidden Bottlenecks That Break Microservices in Production – DZone

Cos’è la vulnerabilità CVE-2026-42897

Il 14 maggio 2026 Microsoft ha divulgato pubblicamente una vulnerabilità critica nei propri server Exchange on-premises, tracciata come CVE-2026-42897. La falla, classificata come Cross-Site Scripting (XSS), risiede nel componente Outlook Web Access (OWA) e permette a un attaccante di eseguire codice JavaScript arbitrario nel browser della vittima senza richiedere alcuna interazione complessa: è sufficiente che l’utente apra una email appositamente confezionata direttamente dalla webmail.

La vulnerabilità è già sfruttata attivamente in the wild: la CISA (Cybersecurity and Infrastructure Security Agency) degli Stati Uniti l’ha aggiunta al proprio catalogo di vulnerabilità note e sfruttate (Known Exploited Vulnerabilities) con scadenza obbligatoria di remediation al 29 maggio 2026 per le agenzie federali americane. Il rischio per le organizzazioni private è ugualmente elevato.

Versioni di Exchange Server interessate

La vulnerabilità colpisce esclusivamente i server Exchange installati on-premises. In particolare:

• Exchange Server 2016
• Exchange Server 2019
• Exchange Server Subscription Edition (SE)

Exchange Online non è interessato: le organizzazioni che utilizzano esclusivamente il servizio cloud Microsoft 365 non devono intraprendere alcuna azione. Il rischio è confinato a chi gestisce ancora infrastrutture Exchange on-premises, scenario ancora comune in contesti enterprise con requisiti di compliance, residenza del dato o integrazione con sistemi legacy.

Come funziona l’attacco

Il vettore di attacco è particolarmente insidioso perché non richiede configurazioni particolari lato vittima: l’attaccante invia una email con contenuto HTML appositamente costruito. Quando il destinatario apre il messaggio tramite OWA, il payload JavaScript viene eseguito nel contesto del browser dell’utente, con accesso alla sessione OWA attiva.

Le conseguenze possibili includono:

• Furto del cookie di sessione e hijacking dell’account
• Esecuzione di azioni per conto dell’utente (invio email, accesso a cartelle, lettura di allegati)
• Lateral movement verso altri sistemi integrati con Exchange (es. Active Directory, SharePoint)
• Esfiltrazione di dati sensibili contenuti nelle caselle di posta

In un ambiente enterprise, un attacco XSS riuscito contro OWA può essere il punto di ingresso per una compromissione ben più ampia, specialmente se la webmail è accessibile dall’esterno o da reti non completamente fidate.

Mitigazioni disponibili: come intervenire subito

Microsoft ha rilasciato mitigazioni di emergenza in attesa di una patch definitiva. Esistono due percorsi principali:

1. Exchange Emergency Mitigation Service (EM Service)

Il metodo preferito è affidarsi all’Exchange Emergency Mitigation Service, che applica automaticamente una configurazione di URL Rewrite sul server IIS per neutralizzare il vettore di attacco. Il servizio EM è abilitato per default nelle installazioni supportate di Exchange Server. Se non è stato disabilitato manualmente, la mitigazione potrebbe già essere attiva.

Per verificare lo stato della mitigazione, Microsoft raccomanda di eseguire il tool Exchange Health Checker:

# Scarica ed esegui Exchange Health Checker in una Exchange Management Shell elevata
. .\HealthChecker.ps1
Invoke-HealthChecker


2. Exchange On-Premises Mitigation Tool (EOMT) per ambienti air-gap

Per i server Exchange non connessi a internet o in ambienti con restrizioni di rete, Microsoft ha reso disponibile una procedura di mitigazione manuale tramite lo strumento EOMT (Exchange On-Premises Mitigation Tool):

# Download da: https://aka.ms/UnifiedEOMT
# Eseguire da una Exchange Management Shell con privilegi elevati

.\EOMTv2.ps1 -ExchangeVersion 2019


Impatto sulle funzionalità di OWA dopo la mitigazione

L’applicazione della mitigazione introduce alcune limitazioni funzionali che gli amministratori devono comunicare agli utenti:

• Immagini inline nelle email: potrebbero non essere visualizzate correttamente nel pannello di lettura di OWA. La soluzione alternativa è inviare le immagini come allegati o usare il client Outlook desktop.
• Stampa del calendario da OWA: la funzione potrebbe non operare. Gli utenti possono utilizzare screenshot o Outlook desktop come workaround.
• OWA Light (interfaccia legacy): già deprecata, potrebbe smettere di funzionare completamente. Non è una perdita significativa per la maggior parte delle organizzazioni.

Queste limitazioni sono accettabili rispetto al rischio rappresentato dalla vulnerabilità non mitigata.

Patch definitiva: cosa aspettarsi

Microsoft sta lavorando a un aggiornamento di sicurezza permanente. Un dettaglio importante per chi gestisce Exchange 2016 e 2019: le patch ufficiali saranno rilasciate solo per i clienti commerciali iscritti al programma ESU (Extended Security Update). Exchange 2016 ha raggiunto la fine del supporto mainstream nell’ottobre 2025, e Exchange 2019 raggiungerà la stessa condizione nell’ottobre 2025. Le organizzazioni che non hanno sottoscritto l’ESU si troveranno senza patch definitiva e dovranno affidarsi esclusivamente alla mitigazione di emergenza, con un rischio residuo crescente nel tempo.

Questo scenario rafforza l’urgenza di pianificare una migrazione verso Exchange Server SE o Exchange Online per chi è ancora su versioni precedenti.

Checklist di risposta per gli amministratori

Se gestisci un’infrastruttura Exchange on-premises, ecco le azioni da completare nell’ordine:

1. Verifica la versione di Exchange in uso: apri la Exchange Management Shell e lancia Get-ExchangeServer | Select Name,AdminDisplayVersion
2. Controlla se il servizio EM è attivo: Get-Service MSExchangeMitigation
3. Esegui Exchange Health Checker per verificare l’applicazione della mitigazione M2
4. Se l’EM Service è disabilitato o il server è air-gapped, applica EOMT manualmente
5. Comunica agli utenti le limitazioni temporanee di OWA
6. Monitora il blog ufficiale di Exchange (techcommunity.microsoft.com) per il rilascio della patch definitiva
7. Valuta l’iscrizione al programma ESU se stai usando Exchange 2016 o 2019

Conclusione

CVE-2026-42897 è un esempio concreto di come le infrastrutture on-premises legacy rimangano vettori di attacco critici anche in ambienti enterprise ben gestiti. La buona notizia è che Microsoft ha reagito rapidamente con mitigazioni di emergenza e ha reso la verifica dello stato accessibile tramite strumenti già noti come Exchange Health Checker. La cattiva notizia è che chi non ha ancora pianificato l’uscita da Exchange 2016/2019 si trova in una posizione sempre più rischiosa, non solo per questa vulnerabilità ma per tutte quelle future che non riceveranno patch ufficiali.

Applicare la mitigazione adesso, verificarne l’efficacia e pianificare la migrazione al più presto sono le tre priorità concrete da portare all’attenzione del management tecnico questa settimana.

Fonte: Microsoft Warns Exchange Server Flaw Lets Attackers Execute Code via OWA Emails – Petri IT Knowledgebase | Microsoft Tech Community – Addressing Exchange Server May 2026 vulnerability

Tra il 11 e il 14 maggio 2026, un attore di minacce tracciato come TeamPCP ha sferrato uno dei supply chain attack più sofisticati mai documentati nell’ecosistema open source: oltre 160 pacchetti npm e 2 pacchetti PyPI compromessi, tra cui componenti del popolare framework TanStack, librerie di Mistral AI e UiPath, e il fondamentale pacchetto node-ipc con 822.000 download settimanali. L’operazione, ribattezzata “Mini Shai-Hulud” dai ricercatori di Wiz, ha colpito le pipeline di sviluppo di migliaia di organizzazioni — inclusi due dipendenti di OpenAI — e ha dimostrato come un singolo punto debole nelle GitHub Actions possa trasformarsi in una bomba a orologeria lungo tutta la catena del software.

L’innesco: tre vulnerabilità GitHub Actions in sequenza

Il vettore iniziale dell’attacco non è stato una vulnerabilità nei pacchetti stessi, ma nell’infrastruttura CI/CD che li gestisce. TeamPCP ha sfruttato una catena di tre vulnerabilità nelle GitHub Actions, secondo quanto ricostruito dai ricercatori di Wiz e Orca Security. L’attaccante ha creato un fork del repository TanStack/router, ha aperto una pull request che ha innescato un workflow pull_request_target — una tipologia di workflow che, a differenza di pull_request, viene eseguita con i permessi completi del repository originale anche per PR da fork esterni — e ha avvelenato la cache pnpm di GitHub Actions con un payload malevolo.

Una volta avvelenata la cache, il malware si è auto-propagato: ogni volta che il workflow legittimo veniva eseguito, invece di scaricare le dipendenze originali recuperava le versioni compromesse dalla cache infetta. Questo meccanismo di auto-propagazione — il “worm” di Mini Shai-Hulud — ha permesso la compromissione a cascata di tutti i namespace associati al progetto.

I 373 pacchetti compromessi: la portata dell’operazione

La scala dell’attacco è stata eccezionale. In totale, 373 versioni malevole sono state pubblicate su npm, distribuite su 169 nomi di pacchetti distinti. I namespace colpiti includono @tanstack (83 voci: router, start, devtools e adapter packages), @uipath (66 voci), @squawk (87 voci), @mistralai, @tallyui, @beproduct e numerosi pacchetti non con scope. Su PyPI, i pacchetti colpiti sono stati guardrails-ai 0.10.1 e mistralai 2.4.6.

La natura cross-namespace dell’attacco è significativa: le organizzazioni che utilizzavano librerie di vendor diversi (UiPath per l’automazione, Mistral AI per i modelli LLM, TanStack per il routing frontend) erano tutte vulnerabili nello stesso intervallo temporale, senza che esistesse un singolo punto di allerta evidente.

node-ipc: il payload più insidioso

Parallelamente alla compromissione via GitHub Actions, TeamPCP ha eseguito un attacco separato ma correlato contro node-ipc, un pacchetto fondamentale di Node.js per la comunicazione inter-processo con oltre 10 milioni di download settimanali. Tre versioni malevole (9.1.6, 9.2.3 e 12.0.1) sono state pubblicate il 14 maggio 2026 tramite un account maintainer compromesso attraverso una tecnica di account takeover mirata.

L’attaccante aveva re-registrato il dominio atlantis-software.net — scaduto il 10 gennaio 2025 — il 7 maggio 2026 tramite Namecheap, e aveva utilizzato la procedura standard di reset password di npm per ottenere i permessi di pubblicazione senza che il maintainer originale venisse avvisato. Le versioni malevole contenevano un payload da 80 KB, fortemente offuscato, che veniva iniettato come IIFE (Immediately Invoked Function Expression) alla fine del file node-ipc.cjs.

Cosa rubava il malware: 90+ categorie di credenziali

Una volta caricato tramite require('node-ipc'), il payload eseguiva silenziosamente un harvesting massiccio di credenziali: chiavi AWS, Azure e GCP, chiavi SSH private, token Kubernetes, configurazioni GitHub CLI, impostazioni di Claude AI e dell’IDE Kiro, stati Terraform, password di database, cronologia della shell e molto altro — oltre 90 categorie di segreti in totale. I dati venivano compressi in un archivio gzip e esfiltrati verso un server controllato dagli attaccanti che si mascherava da infrastruttura Azure.

Prima di procedere, il payload effettuava un fingerprint SHA-256 dell’ambiente, confrontandolo con un hash hardcoded assemblato da otto frammenti offuscati presenti nel codice — presumibilmente per evitare l’esecuzione in sandbox di analisi. Le versioni malevole sono rimaste attive sul registry per circa due ore prima del rilevamento e della rimozione da parte di npm. Qualsiasi progetto che abbia eseguito npm install o aggiornato automaticamente le dipendenze in quella finestra temporale deve essere considerato potenzialmente compromesso.

OpenAI e Mistral AI tra le vittime: le implicazioni sistemiche

OpenAI ha confermato che due dispositivi di dipendenti nel suo ambiente aziendale sono stati compromessi nell’attacco. L’azienda ha ingaggiato una società di incident response, ha ruotato i certificati di firma del codice per le applicazioni macOS e ha dichiarato di non aver trovato evidenze di accesso a dati utente, sistemi di produzione o proprietà intellettuale. Mistral AI ha visto le sue librerie ufficiali compromise, sollevando preoccupazioni immediate tra gli sviluppatori che le utilizzano per integrare capacità AI nei loro applicativi.

Il fatto che TeamPCP abbia preso di mira specificamente pacchetti di aziende AI leader — Mistral AI, e indirettamente OpenAI attraverso i suoi sviluppatori — non è casuale: i developer che lavorano con questi strumenti hanno tipicamente accesso a chiavi API di alto valore, ambienti cloud critici e codice sorgente sensibile. I repo di Mistral AI rubati sono stati successivamente messi in vendita da TeamPCP, confermando la doppia finalità dell’operazione: furto di credenziali e esfiltrazione di proprietà intellettuale.

Difendersi dalla nuova generazione di supply chain attack

L’attacco di Mini Shai-Hulud rappresenta una nuova classe di minaccia per la quale molte organizzazioni non sono ancora attrezzate. La compromissione non avviene attraverso vulnerabilità nel codice stesso, ma nell’infrastruttura di distribuzione. Alcune misure pratiche per i difensori includono il pinning delle versioni esatte dei pacchetti (evitando range semver come ^1.2.3 o ~1.2.3), l’utilizzo di un lockfile verificato e mantenuto nel controllo versione, l’auditing regolare delle dipendenze con strumenti come npm audit o Snyk, e la verifica dell’integrità dei pacchetti tramite hash SHA-512 dove disponibili.

Sul fronte CI/CD, è fondamentale limitare i permessi dei workflow GitHub Actions, evitare l’uso di pull_request_target con checkout del codice della PR, e implementare cache poisoning prevention attraverso la verifica dell’integrità della cache. Le organizzazioni che hanno eseguito build tra il 11 e il 14 maggio 2026 utilizzando i namespace colpiti dovrebbero effettuare una revisione completa dei secret esposti.

Indicatori di Compromissione (IoC)

# Mini Shai-Hulud / TeamPCP Supply Chain Attack - Maggio 2026
# Fonti: Wiz, Orca Security, Snyk, StepSecurity

# Pacchetti npm malevoli (esempi principali)
node-ipc: 9.1.6, 9.2.3, 12.0.1
@tanstack/router: versioni pubblicate 11-14 maggio 2026
@mistralai/mistralai: 2.4.6 (correlato)

# Pacchetti PyPI malevoli
guardrails-ai==0.10.1
mistralai==2.4.6

# Account maintainer compromesso (node-ipc)
npm user: atiertant (a.tiertant@atlantis-software.net)
Dominio re-registrato: atlantis-software.net (7 maggio 2026)

# Tecniche MITRE ATT&CK
T1195.001 - Supply Chain Compromise: Compromise Software Dependencies
T1059.007 - Command and Scripting Interpreter: JavaScript
T1552.001 - Unsecured Credentials: Credentials in Files
T1041     - Exfiltration Over C2 Channel (verso infrastruttura Azure-like)

# Indicatori comportamentali
- Processi Node.js che effettuano richieste HTTP inattese post-installazione
- Archivi gzip creati in directory temporanee durante npm install
- Chiamate a endpoint Azure non riconosciuti da processi build

# Verifica hash (node-ipc versioni legittime)
SHA-256 v9.1.5 legittima: verificare su https://registry.npmjs.org/node-ipc/9.1.5

Un threat actor di altissimo livello, tracciato da Cisco Talos come UAT-8616, sta sfruttando attivamente una vulnerabilità critica nei controller Cisco Catalyst SD-WAN — la sesta zero-day sfruttata su questa piattaforma nel solo 2026. Con un CVSS di 10.0, la falla consente a un attaccante non autenticato di ottenere privilegi amministrativi completi su dispositivi SD-WAN esposti su internet, prendendo di mira settori governativi, diplomatici e della difesa in Europa e Asia Centrale.

La Sesta Zero-Day in Sei Mesi: CVE-2026-20182

Il 15 maggio 2026, la CISA (Cybersecurity and Infrastructure Security Agency) ha aggiunto CVE-2026-20182 al suo catalogo di vulnerabilità attivamente sfruttate (KEV — Known Exploited Vulnerabilities), imponendo alle agenzie federali civili statunitensi di applicare la patch entro il 17 maggio. La vulnerabilità risiede nel processo di handshake del controllo peering via protocollo DTLS sulla porta 12346 del Cisco Catalyst SD-WAN Controller e Manager.

In termini pratici, un attaccante remoto e non autenticato può autenticarsi come peer interno ad alto privilegio, bypassando completamente l’autenticazione e acquisendo controllo amministrativo sull’appliance bersaglio. Il punteggio massimo CVSS (10.0) riflette la semplicità di sfruttamento combinata alla gravità dell’impatto: nessuna credenziale, nessuna interazione utente richiesta.

Il Profilo di UAT-8616: Un Attore Sofisticato con Radici Profonde

Cisco Talos ha tracciato questa campagna sotto la denominazione UAT-8616, classificandolo con alta confidenza come un “highly sophisticated cyber threat actor”. Sebbene Talos non abbia ancora rilasciato un’attribuzione definitiva a uno stato-nazione specifico, diversi elementi indicativi emergono dall’analisi:

• Longevità operativa: le prime tracce di attività malevola risalgono al 2023, almeno tre anni prima della divulgazione pubblica — segnale che il gruppo operava con una zero-day tenuta segreta per molto tempo.
• Sovrapposizione con ORB network: l’infrastruttura di UAT-8616 si sovrappone a reti di relay operazionali (Operational Relay Boxes) precedentemente associate a operazioni di cyber-spionaggio di attori China-nexus, secondo quanto documentato da Mandiant/Google.
• Target geopoliticamente selettivi: il profilo dei bersagli — governo, diplomazia, difesa in Europa e Asia Centrale — è coerente con operazioni di intelligence offensiva state-sponsored.
• Connessione con endpoint Gamaredon (Aqua Blizzard): la CISA ha segnalato sovrapposizioni con endpoint già compromessi da Gamaredon, il gruppo russo legato all’FSB che storicamente prende di mira organizzazioni ucraine e dell’Europa orientale.

Anatomia dell’Attacco: Dal Bypass all’Esfiltrazione

Le tecniche post-compromissione documentate da Talos rivelano un playbook operativo sofisticato, progettato tanto per la persistenza quanto per l’evasione forense:

• SSH key injection: aggiunta di chiavi SSH nei file authorized_keys per garantire accesso permanente anche dopo il reboot o il cambio di credenziali.
• Escalation a root via CVE-2022-20775: sfruttamento di una tecnica di downgrade della versione software per scalare i privilegi fino a root.
• Manipolazione NETCONF: modifica delle configurazioni di rete tramite il protocollo NETCONF per alterare il traffico o creare tunnel nascosti.
• Creazione di account malevoli: creazione di utenti backdoor per accesso persistente.
• Anti-forensics sistematico: cancellazione di log da syslog, wtmp, lastlog, bash_history e cli-history per coprire le tracce dell’intrusione.

Un Pattern Preoccupante: Sei Zero-Day in Sei Mesi

CVE-2026-20182 non è un caso isolato. Come documenta SecurityWeek, si tratta della sesta vulnerabilità zero-day sfruttata attivamente sulle piattaforme Cisco SD-WAN nel corso del 2026, un dato che solleva interrogativi profondi sulla sicurezza dell’infrastruttura di rete enterprise. Gli SD-WAN sono sistemi critici che gestiscono il traffico di rete tra sedi aziendali distribuite, data center e cloud — la loro compromissione offre all’attaccante una visibilità strategica sull’intera architettura di rete della vittima.

La tendenza è chiara: i dispositivi di rete edge — firewall, VPN concentrator, SD-WAN controller — sono diventati il principale vettore di accesso iniziale per i gruppi APT più sofisticati al mondo. A differenza degli endpoint tradizionali, questi dispositivi raramente eseguono soluzioni EDR e spesso hanno cicli di aggiornamento lenti nelle organizzazioni.

Implicazioni Geopolitiche e per i Difensori

Il targeting di settori governativi e della difesa in Europa e Asia Centrale suggerisce una campagna di cyber-spionaggio strategico. Le sovrapposizioni infrastrutturali con attori Russia-linked come Gamaredon/Aqua Blizzard complicano ulteriormente l’attribuzione, un fenomeno sempre più comune nelle operazioni moderne dove la condivisione di infrastrutture (ORB network) oscura deliberatamente le responsabilità.

Per i team di sicurezza, le priorità immediate sono chiare:

• Patching urgente: applicare immediatamente le patch Cisco per CVE-2026-20182 su tutti i Catalyst SD-WAN Controller e Manager esposti.
• Audit delle authorized_keys: verificare l’integrità dei file SSH authorized_keys su tutti i sistemi SD-WAN.
• Revisione account: identificare e rimuovere eventuali account non autorizzati creati sui sistemi.
• Log integrity check: data la tendenza del gruppo a cancellare i log, implementare forwarding immediato su SIEM centralizzato.
• Network segmentation review: limitare l’accesso amministrativo ai controller SD-WAN tramite reti di gestione dedicate e isolate.

CVE e Riferimenti Tecnici

CVE-2026-20182 — Cisco Catalyst SD-WAN Controller / Manager
CVSS Score: 10.0 (Critico)
Tipo: Authentication Bypass
Vettore: DTLS porta 12346 (handshake peering)
Impatto: Accesso amministrativo non autenticato

CVE correlati campagna UAT-8616:
- CVE-2026-20127 (zero-day precedente, sfruttato da febbraio 2026)
- CVE-2022-20775 (privilege escalation, usato per escalation a root)

Indicatori di Compromissione (comportamentali):
- SSH keys non autorizzate in authorized_keys
- Account di sistema inattesi
- Assenza di voci nei log syslog/wtmp/lastlog (log wiping)
- Configurazioni NETCONF alterate
- Traffico anomalo su porta DTLS 12346

Negli ultimi giorni è emerso un risultato di grande interesse per la comunità GNU/Linux: l’applicazione fotografica Adobe Lightroom CC, normalmente disponibile solo per Windows e macOS, è stata avviata e resa realmente utilizzabile su...

🔗 Leggi il post completo

Si parla di:
Toggle

Il gruppo russo Secret Blizzard, operativo per conto dell’FSB (Federal Security Service) russo e meglio conosciuto come Turla, ha trasformato il proprio storico malware Kazuar in una botnet peer-to-peer modulare, progettata per mantenere accessi persistenti e praticamente invisibili nelle reti governative. La rivelazione arriva da Microsoft Security, che il 14 maggio 2026 ha pubblicato un’analisi approfondita dell’architettura del malware — descrivendo quello che è a tutti gli effetti un salto evolutivo nella sofisticazione operativa di uno dei gruppi APT più longevi al mondo.

Da backdoor tradizionale a ecosistema P2P

Kazuar è attivo almeno dal 2017 ed è stato impiegato in decine di campagne di cyberspionaggio contro governi, ambasciate e organizzazioni della difesa in Europa, Asia Centrale e Ucraina. La versione analizzata da Microsoft nel 2026 rappresenta però un cambio di paradigma: il malware non è più un semplice backdoor controllato centralmente, ma un ecosistema distribuito composto da tre moduli distinti che collaborano per garantire resilienza, persistenza e stealth.

La riorganizzazione è eloquente: non ogni macchina compromessa comunica con il server di comando e controllo (C2). Invece, un unico nodo “leader” — eletto dinamicamente dal modulo Kernel tra i sistemi infetti presenti nella stessa rete o segmento di rete — assume il ruolo di proxy verso l’infrastruttura esterna. Gli altri nodi entrano in modalità “silent”, eliminando quasi completamente il traffico verso l’esterno e riducendo drasticamente la superficie di rilevamento per i team di incident response.

Architettura modulare: Kernel, Bridge e Worker

Microsoft descrive tre componenti fondamentali della nuova architettura Kazuar:

• Modulo Kernel: È il coordinatore centrale. Gestisce i task, controlla gli altri moduli, elegge il nodo leader e orchestra le comunicazioni e il flusso di dati attraverso la botnet.
• Modulo Bridge: Agisce come proxy tra il nodo leader Kernel e il server C2 remoto. Filtra e instrada il traffico, permettendo ulteriore separazione tra i sistemi compromessi e l’infrastruttura degli attaccanti.
• Modulo Worker: È il componente operativo. Registra i tasti premuti (keylogging), aggancia gli eventi Windows, traccia i task, raccoglie informazioni di sistema, listing di file e dettagli MAPI — incluse caselle email di Exchange.

Questa separazione funzionale non è casuale: in caso di rilevamento di un Worker, i nodi Kernel restano inalterati e possono continuare a operare silenziosamente. L’architettura è progettata per sopravvivere a rimozioni parziali.

150 parametri di configurazione: granularità operativa senza precedenti

Uno degli aspetti più rilevanti della nuova versione è il sistema di configurazione esteso: Kazuar supporta ora più di 150 parametri che gli operatori possono personalizzare per ogni campagna o vittima specifica. Questi parametri controllano metodi di esecuzione e persistenza (scheduled task, servizi Windows, chiavi di registro), bypass di AMSI e ETW, timing dell’esfiltrazione e dimensione dei chunk di dati, process injection e tecniche di lateral movement, e protocolli di comunicazione multipli: HTTP, WebSocket ed Exchange Web Services (EWS).

L’uso di EWS per mascherare le comunicazioni C2 nel traffico legittimo di Exchange è particolarmente insidioso: in ambienti enterprise dove Exchange Server è ubiquo, questo canale risulta quasi impossibile da distinguere dal traffico normale senza ispezione profonda dei payload.

Targeting: governi, ambasciate e settore difesa in Europa e Ucraina

Secret Blizzard (alias Turla, Uroburos, Venomous Bear) è noto per campagne di spionaggio ad altissimo valore strategico. Le vittime documentate includono ministeri degli esteri, ambasciate diplomatiche, dipartimenti della difesa e organizzazioni governative in Europa Orientale, Asia Centrale e — con intensità crescente — Ucraina nel contesto del conflitto in corso.

L’evoluzione di Kazuar verso un’architettura P2P suggerisce che il gruppo abbia tratto lezione dalle operazioni di takedown condotte negli ultimi anni contro infrastrutture di malware centralizzate. La distribuzione del controllo rende un’eventuale disruption dell’infrastruttura C2 molto meno efficace: rimuovere il server C2 non smantella la botnet, poiché il leader può essere eletto nuovamente tra i nodi sopravvissuti.

Due righe per i difensori

Microsoft raccomanda di concentrare il rilevamento su indicatori comportamentali piuttosto che su signature statiche. I team di sicurezza dovrebbero monitorare attività IPC insolite tra processi non correlati, rilevare pattern di elezione del leader nella rete interna tramite comunicazioni laterali anomale, identificare esfiltrazione dati staged e frammentata con timing irregolare, e controllare accessi anomali a EWS da processi non di posta elettronica. Dato il targeting storico di Secret Blizzard su entità diplomatiche e governative europee, le organizzazioni in questi settori dovrebbero considerare una revisione urgente dei log di rete e degli endpoint.

Indicatori di Compromissione (IoC)

# Kazuar - Secret Blizzard (Turla) - Maggio 2026
# Fonte: Microsoft Security Blog, 14 maggio 2026

# Tecniche MITRE ATT&CK associate
T1574.001 - DLL Search Order Hijacking
T1055     - Process Injection
T1071.001 - Application Layer Protocol: Web Protocols (HTTP/WebSocket)
T1071.003 - Application Layer Protocol: Mail Protocols (EWS)
T1030     - Data Transfer Size Limits (staged exfiltration)
T1053.005 - Scheduled Task/Job (persistence)
T1562.001 - Impair Defenses: Disable/Modify Tools (AMSI/ETW bypass)

# Comportamenti anomali da monitorare
- Comunicazioni IPC anomale tra processi non correlati
- Accessi Exchange Web Services (EWS) da processi non di posta
- Traffico P2P laterale interno su porte non standard
- Esfiltrazione dati in chunk temporizzati verso IP non categorizzati
- Moduli .NET iniettati in processi di sistema legittimi

# Referenza completa IoC
https://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/

Con l’arrivo imminente di Xperia 1 VIII, il suo predecessore Xperia 1 VII sta iniziando a essere gradualmente eliminato dal listino ufficiale Sony. I segnali più chiari arrivano dal Sony Store giapponese, dove la colorazione Verde del modello 12 GB/256 GB risulta già esaurita e non rifornita.

Il pattern già visto con le versioni precedenti

Il modello 16 GB/512 GB di Xperia 1 VII è già stato rimosso dalla vendita in precedenza. Osservando le vendite passate dei modelli Xperia, il colore Verde tende sempre a esaurirsi per primo, seguito poi da Nero e Viola. Se si ripeterà lo stesso schema, anche le ultime colorazioni disponibili potrebbero raggiungere lo stato di “esaurito” nelle prossime settimane.

La produzione potrebbe essere già ferma

Secondo le analisi della situazione attuale, è probabile che Sony abbia già interrotto la produzione di Xperia 1 VII. La disponibilità residua nei negozi rappresenterebbe quindi l’ultimo stock rimasto in magazzino. Con il lancio del nuovo Xperia 1 VIII, è naturale che l’azienda sposti l’attenzione commerciale sul modello più recente.

Conviene ancora acquistare Xperia 1 VII?

Chi era interessato ad acquistare Xperia 1 VII, magari aspettando un calo di prezzo dopo l’uscita del successore, farebbe bene ad affrettarsi: la finestra di disponibilità si sta chiudendo rapidamente. Il dispositivo conserva ancora un ottimo profilo tecnico, con il suo schermo OLED 4K da 6,5 pollici, il sistema fotografico con ottica Zeiss e le funzioni avanzate per video e audio che caratterizzano la linea Xperia.

Per chi invece punta al meglio della gamma Sony, l’attesa per Xperia 1 VIII potrebbe valere la pena, considerando le probabili migliorie in termini di processore e fotocamera.

Manca ormai pochissimo alla presentazione ufficiale di Xiaomi 17T e Xiaomi 17T Pro: secondo le informazioni trapelate da materiali promozionali interni, il lancio globale dei due smartphone potrebbe avvenire già il 28 maggio 2026. Entrambi i modelli punteranno sul sistema fotografico Leica come elemento distintivo.

Promo di lancio: cuffie e smartband in regalo

Promo di lancio: cuffie e smartband in regalo

I materiali promozionali mostrano anche i bonus riservati a chi acquisterà i dispositivi al lancio:

• Xiaomi 17T: in omaggio le cuffie Redmi Headphones Neo
• Xiaomi 17T Pro: cuffie Redmi Headphones Neo più lo Smart Band 10

È tuttavia da chiarire se questi incentivi saranno disponibili in tutti i mercati o solo in alcune regioni selezionate.

Xiaomi 17T: il modello standard con Dimensity 8500 e fotocamera Leica

La versione base della serie monta il chip MediaTek Dimensity 8500, abbinato a un display da 6,59 pollici a 120 Hz e una batteria da 6.500 mAh. Il sistema fotografico adotta l’obiettivo Leica Summilux con zoom ottico 5x e digitale fino a 120x. Le funzioni AI girano su HyperOS sotto il nome di Xiaomi HyperAI.

Xiaomi 17T Pro: più potenza e ricarica ultraveloce

Il modello Pro si distingue per un processore ancora più performante e una ricarica rapida notevolmente superiore. Entrambi i modelli sono posizionati su una fascia di prezzo più accessibile rispetto alla serie Xiaomi 17 standard, con prezzi europei già praticamente definiti secondo i leak. L’annuncio ufficiale, se la data del 28 maggio verrà confermata, è ormai imminente.

Con Leica, specifiche hardware generose e un prezzo competitivo, Xiaomi 17T e 17T Pro si candidano a essere tra le proposte più interessanti della fascia media premium nella seconda metà del 2026.

Il team di sicurezza di Google, Project Zero, ha reso pubblica una catena di attacco di tipo zero-click che colpisce i dispositivi Google Pixel 10. Si tratta di un attacco che non richiede alcuna interazione da parte dell’utente e che, nelle condizioni giuste, può portare al controllo completo del dispositivo.

Come funziona l’attacco: due vulnerabilità concatenate

Il punto di partenza è una vulnerabilità nel framework Dolby Media (CVE-2025-54957), già scoperta sul Pixel 9 e risultata riproducibile anche su Pixel 10. Un attaccante può sfruttare due falle in sequenza per eseguire codice da remoto e scalare i privilegi fino al livello di root, ottenendo così il pieno controllo del sistema.

Nonostante Pixel 10 introduca nuovi meccanismi di protezione della memoria, i ricercatori sono riusciti a trovare metodi alternativi per aggirarli, confermando che il livello di difficoltà dell’attacco rimane basso.

Aggirato il sistema RET PAC di Pixel 10

Pixel 10 ha introdotto RET PAC (Return Address Pointer Authentication), una protezione avanzata contro gli attacchi basati sulla manipolazione dello stack. Tuttavia, i ricercatori hanno identificato una funzione alternativa (dap_cpdp_init) che permette di riscrivere il flusso di controllo del sistema senza attivare le protezioni, mantenendo stabile il dispositivo durante l’attacco.

Vulnerabilità nel driver VPU: scalata al kernel

Vulnerabilità nel driver VPU: scalata al kernel

La seconda fase dell’attacco sfrutta una falla critica nel nuovo driver VPU (/dev/vpu) introdotto con Pixel 10. Questo componente, responsabile dell’elaborazione video, conteneva una vulnerabilità che consentiva la compromissione del kernel, il cuore del sistema operativo.

I dispositivi non aggiornati rimangono vulnerabili

I Pixel non aggiornati con le patch di sicurezza di dicembre 2025 o successive sono rimasti esposti a questo tipo di attacco. Google ha già rilasciato le correzioni, quindi è fondamentale assicurarsi di avere il dispositivo aggiornato all’ultima versione disponibile. La divulgazione pubblica da parte di Project Zero serve a sensibilizzare il settore e a incentivare l’adozione tempestiva degli aggiornamenti di sicurezza.

Nuova puntata del podcast di Marco’s Box, questa volta dedicata a commentare le principali notizie dal mondo di linux e del software libero e open source. Trovate la puntata su Spotity, Google Podcasts, Anchor, Apple...

🔗 Leggi il post completo

Il progetto Fedora ha recentemente discusso una proposta denominata Fedora AI Developer Desktop Initiative, pensata per creare una versione dedicata della distribuzione GNU/Linux orientata agli sviluppatori e agli utenti che lavorano con l’intelligenza artificiale.Questa...

🔗 Leggi il post completo

Xiaomi sta esplorando un programma innovativo che potrebbe cambiare il modo in cui gli utenti gestiscono i propri smartphone dopo alcuni anni di utilizzo: la sostituzione della batteria originale con una versione a capacità superiore. Un’iniziativa che risponde alla crescente domanda di soluzioni di longevità per i dispositivi mobile.

Come funziona: stessa dimensione, più energia

Il servizio, già attivo in Cina per alcuni modelli, prevede l’utilizzo di batterie progettate con tecnologie ad alta densità energetica. Questo permette di aumentare la capacità pur mantenendo le stesse dimensioni fisiche del componente originale, senza quindi richiedere modifiche meccaniche alla scocca del telefono.

I modelli al momento coinvolti includono Xiaomi 13, Xiaomi 13 Pro e Xiaomi 13 Ultra. Il costo del servizio in Cina è di circa 189 yuan (circa 24 euro), comprensivo di manodopera.

Un invito esplicito ad aspettare prima di sostituire

La notizia è emersa da dichiarazioni pubbliche di un responsabile della linea REDMI di Xiaomi, il quale ha consigliato agli utenti che non hanno ancora pianificato un cambio di dispositivo di attendere le nuove opzioni di sostituzione batteria prima di procedere. Un segnale chiaro che il programma potrebbe ampliarsi ad altri modelli nelle prossime settimane.

Arriverà anche in Europa?

Al momento il servizio è disponibile esclusivamente in Cina e non ci sono conferme sull’espansione internazionale. Un’eventuale estensione in Europa richiederebbe la disponibilità di ricambi certificati e una rete di assistenza adeguata, il che potrebbe richiedere tempo.

L’iniziativa si inserisce in un trend più ampio verso la riparabilità degli smartphone, spinto anche dalle normative europee sul diritto alla riparazione. Per chi possiede ancora un Xiaomi 13 in buono stato ma con batteria degradata, questa potrebbe essere un’alternativa concreta al cambio di dispositivo.

Una voce che farà discutere: secondo un noto leaker del settore, Samsung starebbe valutando di abbandonare definitivamente la linea Galaxy Z Flip. Il Galaxy Z Flip 8, atteso per quest’anno, potrebbe essere l’ultimo modello della serie di smartphone pieghevoli a conchiglia del produttore coreano.

Il campanello d’allarme: nessuna traccia del Flip 9

La segnalazione arriva dal leaker cinese Instant Digital, specializzato in informazioni sulla catena di fornitura. Il ragionamento è semplice ma significativo: nell’industria degli smartphone, le pianificazioni avvengono con almeno un anno di anticipo, e normalmente emergono informazioni su componenti o forniture molto prima dell’annuncio ufficiale. Nel caso del Galaxy Z Flip 9, al momento non esiste alcuna traccia di questo tipo.

Le ragioni dietro il possibile addio

I motivi che vengono indicati per la possibile fine della serie Flip sono principalmente tre:

• Aumento dei costi dei display e dei componenti pieghevoli
• Design maturo: il form factor a conchiglia non offre più grandi margini di innovazione
• Spostamento della domanda verso i pieghevoli a libro come il Galaxy Z Fold

Samsung verso i pieghevoli “grandi”?

Se l’indiscrezione fosse confermata, significherebbe che Samsung concentrerebbe le proprie risorse sul formato Galaxy Z Fold, quello che si apre come un piccolo tablet e che sembra godere di una domanda crescente rispetto al più compatto Flip.

È importante sottolineare che si tratta al momento solo di voci non confermate. Lo stesso leaker ribadisce che il Galaxy Z Flip 8 è praticamente certo per il 2025, ma getta dubbi su quello che accadrà in seguito. Samsung non ha rilasciato alcun commento ufficiale in merito.

Il nuovo brand di laptop di Google, Googlebook, potrebbe presto espandersi con una versione ad alte prestazioni. Dati di spedizione risalenti a circa un anno fa rivelano l’esistenza di un prototipo denominato Felino, un notebook da 16 pollici equipaggiato con il chip Intel di nuova generazione Panther Lake.

Il prototipo “Felino”: 16 pollici e Intel Core Ultra Series 3

All’epoca della registrazione nei documenti di spedizione, il brand Googlebook non esisteva ancora, ma i ricercatori hanno ora collegato il dispositivo alla nuova linea di laptop di Google. Le specifiche emerse sono notevoli:

• Display da 16 pollici
• CPU Intel Core Ultra Series 3 (Panther Lake) con fino a 12 core GPU Xe3
• 32 GB di RAM LPDDR5X
• 1 TB di storage

Un Googlebook pensato per competere con MacBook

Panther Lake è la prossima generazione di CPU mobile Intel, caratterizzata da architettura avanzata, elevate prestazioni nell’elaborazione AI e GPU Xe3 integrata significativamente più potente rispetto alle generazioni precedenti. Si tratta di un profilo ben diverso dai chip tipicamente adottati sui Chromebook tradizionali.

Il posizionamento premium di Googlebook, già annunciato da Google come alternativa di fascia alta al Chromebook classico, sembra puntare direttamente ai laptop Apple MacBook, offrendo un’esperienza Google-first su hardware all’avanguardia.

Nessuna conferma ufficiale

Google non ha ancora confermato l’esistenza di questa variante ad alte prestazioni del Googlebook. I dati di spedizione indicano che il prototipo era già in fase di sviluppo avanzato, ma non è detto che corrisponda a un prodotto che verrà effettivamente commercializzato nella sua forma attuale. Nelle prossime settimane potrebbero emergere ulteriori dettagli in vista di un possibile annuncio ufficiale.

Con l’avanzare delle funzioni di intelligenza artificiale su Android, lo spazio di archiviazione degli smartphone rischia di diventare un collo di bottiglia sempre più critico. Al centro del problema c’è AICore, il servizio di sistema di Google che gestisce i modelli AI locali sul dispositivo.

Cos’è AICore e perché occupa così tanto spazio

AICore è il componente di Android che consente di eseguire l’elaborazione AI direttamente sul dispositivo, senza inviare dati ai server remoti. Questo approccio migliora la privacy e riduce la latenza, ma ha un costo: i modelli AI devono essere archiviati localmente nello smartphone.

Le funzioni che si appoggiano ad AICore sono numerose e in costante crescita:

• Rilevamento delle truffe nelle chiamate
• Trascrizione vocale
• Pixel Screenshots con ricerca semantica
• Assistente vocale e funzioni Gemini on-device

Il problema degli aggiornamenti: spazio temporaneamente raddoppiato

Google ha recentemente aggiornato la propria documentazione di supporto spiegando che, durante l’aggiornamento dei modelli AI, il sistema conserva contemporaneamente la versione vecchia e quella nuova per un massimo di tre giorni. Questo meccanismo serve a garantire un rollback rapido in caso di problemi, ma comporta un temporaneo aumento significativo dello spazio occupato.

Alcuni utenti hanno segnalato che AICore può arrivare a occupare oltre 10 GB durante queste fasi di transizione, rendendo difficile persino installare nuove applicazioni. Sui modelli con 256 GB di storage il disagio è limitato, ma su quelli da 128 GB la situazione può diventare critica.

128 GB sono ancora sufficienti nel 2026?

Questa vicenda riapre il dibattito sulla soglia minima di storage accettabile per uno smartphone Android moderno. Fino a qualche anno fa 128 GB erano considerati più che sufficienti per la maggior parte degli utenti, ma l’espansione dell’AI on-device sta cambiando rapidamente le carte in tavola.

La tendenza è chiara: man mano che Google e i produttori di smartphone integrano funzioni AI sempre più avanzate direttamente nel sistema operativo, la quantità di spazio richiesta non potrà che aumentare. Chi è alla ricerca di un nuovo smartphone farebbe bene a considerare almeno la variante da 256 GB, soprattutto se intende utilizzare le funzioni AI avanzate di Android.

Si arricchisce il quadro delle indiscrezioni su Xiaomi 17T, il prossimo smartphone premium di fascia media del produttore cinese. Oltre alla conferma di uno stile con finitura in gradiente per il nuovo colore bianco, i leak mostrano una scheda tecnica decisamente interessante.

Design: quattro colori con finitura sfumata

Dopo le precedenti indiscrezioni sui colori Blu, Viola e Nero, ora emerge anche una variante Bianco con finitura a gradiente sul pannello posteriore. La palette completa prevista sarà quindi di quattro colori, tutti con questa lavorazione che conferisce un aspetto premium alla scocca. Le configurazioni di memoria attese sono due: 12 GB/256 GB e 12 GB/512 GB.

Display POLED 1.5K e processore Dimensity 8500 Ultra

Lo schermo sarà un pannello POLED da 6,59 pollici con risoluzione 1.5K (1268×2756 pixel) e frequenza di aggiornamento a 120 Hz. Al suo interno troviamo il chip MediaTek Dimensity 8500 Ultra, abbinato a memorie LPDDR5X e storage UFS 4.1, per prestazioni di alto livello nella fascia media.

Tripla fotocamera con zoom 5x e sensore principale da 50 MP

Il comparto fotografico è tra i punti di forza del dispositivo. La configurazione prevede:

• 50 MP principale con sensore Light Fusion 800 e apertura f/1.77
• 50 MP teleobiettivo con zoom ottico 5x
• 12 MP grandangolare
• 32 MP fotocamera frontale

Batteria da 6.500 mAh con ricarica rapida a 67W

Sul fronte dell’autonomia, Xiaomi 17T dovrebbe montare una batteria da 6.500 mAh con supporto alla ricarica rapida cablata a 67W. Una dotazione generosa che promette un’ottima durata nella vita quotidiana. La presentazione ufficiale è attesa entro il prossimo mese.

Il progetto Fedora ha recentemente discusso una proposta denominata Fedora AI Developer Desktop Initiative il cui scopo, poco misteriosamente, visto il nome, è quello di creare una edizione specifica della distribuzione – di fatto una “Spin” basata su un sistema immutabile/Atomic – pensata per sviluppatori e utenti di intelligenza artificiale. Lo scopo è semplificare l...

🔗 Leggi il post completo

Il nome “Oppo Bubble” è circolato per mesi nelle indiscrezioni, ma ora ha una prova concreta della sua esistenza: il dispositivo ha ottenuto la certificazione TDRA negli Emirati Arabi Uniti, con numero di modello VBG06. Un passo importante che indica come il lancio commerciale sia ormai in fase avanzata di preparazione.

Cosa sappiamo dalla certificazione

La registrazione TDRA — datata 5 maggio 2026 — classifica Oppo Bubble come dispositivo Bluetooth, dunque un accessorio wireless stand-alone e non uno smartphone. Il numero di certificazione ER59163/26 e il modello VBG06 suggeriscono che si tratti di un prodotto già in uno stadio avanzato di sviluppo hardware, pronto per i test pre-lancio nei mercati internazionali.

Potrebbe avere un display integrato

Le indiscrezioni precedenti avevano già delineato alcune caratteristiche possibili di Oppo Bubble, tra cui la presenza di un piccolo schermo. Questo collocherebbe il prodotto in una categoria simile a quella degli smart accessory o wearable compatti, pensati per integrarsi con l’ecosistema degli smartphone Android OPPO. Non è ancora chiaro se si tratti di un tipo di auricolare, uno smartband, o un device completamente nuovo.

Lancio imminente?

Il fatto che Oppo Bubble abbia superato le certificazioni internazionali suggerisce che l’annuncio ufficiale potrebbe essere vicino. OPPO non ha ancora commentato, ma l’interesse attorno a questo accessorio misterioso è alto, soprattutto tra i fan del brand che attendono novità nell’ecosistema di wearable e accessori Android.

Samsung starebbe pianificando una modifica sostanziale nella progettazione dell’Exynos 2700, il chip destinato ai Galaxy S27. Secondo le ultime indiscrezioni, l’azienda avrebbe deciso di abbandonare la tecnologia di packaging FOWLP utilizzata a partire dall’Exynos 2400, in favore di una nuova struttura denominata SbS (Side-by-Side). L’obiettivo è migliorare significativamente la dissipazione del calore, da sempre tallone d’Achille dei chip Exynos.

Dal FOWLP al packaging SbS

Il FOWLP (Fan-Out Wafer-Level Packaging), introdotto con Exynos 2400, aveva lo scopo di migliorare le prestazioni termiche tramite un’architettura di impilamento verticale di processore e memoria DRAM. Tuttavia, questa soluzione si è rivelata complessa da produrre e non sempre in grado di soddisfare le aspettative in termini di gestione termica.

Il nuovo approccio SbS prevede invece di affiancare orizzontalmente AP e DRAM sulla stessa scheda, evitando l’impilamento verticale che tende a concentrare il calore in un punto specifico. Questa distribuzione dovrebbe migliorare la diffusione termica e ridurre i picchi di temperatura durante le sessioni intensive.

Anche la tecnologia HPB nel mix

Alla struttura SbS si affiancherebbe anche la tecnologia proprietaria Samsung HPB (Heat Pass Block), un sistema di dissipazione che aumenta ulteriormente l’efficienza nella dispersione del calore. La combinazione delle due soluzioni potrebbe finalmente permettere a Exynos di competere in modo credibile con Snapdragon in termini di temperatura e sustained performance.

La scommessa Exynos per il 2027

I Galaxy S27, attesi per inizio 2027, potrebbero rappresentare la svolta attesa da tempo per la linea Exynos. Con l’IA che spinge i consumi in alto e la concorrenza sempre più agguerrita, Samsung ha urgente necessità di dimostrare che il suo chip interno è all’altezza della sfida. Le novità sul fronte termico sono un passo cruciale in questa direzione.

Mancano pochi giorni alla presentazione ufficiale — attesa per il 19 maggio — ma praticamente tutto ciò che c’è da sapere sulle nuove cuffie Sony 1000X The ColleXion è già trapelato online. Si tratta di un modello premium che va oltre la tradizionale linea WH-1000XM, puntando a una fascia ultra-luxury con un prezzo stimato attorno ai 750 euro (circa 120.000 yen giapponesi).

Un passo avanti rispetto alle WH-1000XM6

Le 1000X The ColleXion non sono semplicemente una variante estetica delle WH-1000XM6, ma un nuovo segmento di prodotto. Sony sembra voler creare una sotto-categoria premium all’interno della propria gamma audio, con materiali più pregiati, finiture superiori e probabilmente funzionalità esclusive non presenti sui modelli standard.

Design elegante in colorazioni premium

Dalle immagini leaked emergono colorazioni sofisticate, tra cui una versione nera con finiture metalliche che trasmettono un senso di eleganza insolito per le cuffie wireless. Il form factor rimane quello over-ear pieghevole tipico della serie 1000X, ma con un livello di rifinizione chiaramente superiore.

Attesa per il 19 maggio

Sony dovrebbe svelare ufficialmente le 1000X The ColleXion il 19 maggio 2026. Con le specifiche tecniche complete ancora da confermare, ci si aspetta che l’azienda punti su un’esperienza audio di riferimento assoluto, combinando cancellazione attiva del rumore di nuova generazione, driver premium e connettività avanzata. Un accessorio pensato per chi non accetta compromessi — e ha un budget adeguato.

Una delle funzioni più attese per Xiaomi 18 — un sistema di accessori fotografici a sgancio magnetico simile a quanto visto con MagSafe su iPhone — sembra essere stata messa in pausa. A rivelarlo è il noto leaker cinese Digital Chat Station, secondo cui il progetto interno è attualmente bloccato a causa di risultati insufficienti nei test di qualità.

Cosa prevedeva il sistema magnetico

Xiaomi stava lavorando a un ecosistema di accessori agganciabili magneticamente allo smartphone tramite connettori PIN proprietari, che avrebbero consentito trasferimento dati ad alta velocità e alimentazione stabile. I prodotti in sviluppo includevano:

• Obiettivi fotografici a innesto magnetico
• Convertitore teleobiettivo snap-on
• Ventola di raffreddamento magnetica
• Sub-display esterno collegabile

Il nodo irrisolto: le lenti non passano i test

Secondo Digital Chat Station, la componente più problematica è proprio quella delle lenti fotografiche magnetiche. Nonostante i test condotti internamente, le ottiche non hanno raggiunto il livello qualitativo richiesto da Xiaomi per la commercializzazione. I problemi riguarderebbero la stabilità del collegamento, la qualità d’immagine effettiva, la latenza e la durabilità del sistema nel tempo.

Progetto in pausa, non cancellato

La notizia non implica che Xiaomi abbia definitivamente abbandonato l’idea: il leaker parla di “sospensione”, lasciando aperta la possibilità che il progetto venga ripreso in una fase successiva o su un modello futuro. Per il momento, tuttavia, gli utenti che attendevano questo tipo di accessori per Xiaomi 18 dovranno probabilmente aspettare ancora.

Xiaomi ha confermato ufficialmente che il suo prossimo SoC proprietario, battezzato XRING 03, sarà presentato entro la fine del 2026. L’annuncio arriva direttamente dal presidente del gruppo, Lv Weibing, che ha riconosciuto l’esistenza del chip durante una comunicazione pubblica. Tuttavia, le indiscrezioni sui processi produttivi adottati lasciano intendere che il chip potrebbe rimanere un passo indietro rispetto ai concorrenti sul piano della tecnologia di fabbricazione.

Il successore di XRING 01

Il chip XRING 01, primo SoC totalmente sviluppato da Xiaomi, aveva già dimostrato capacità interessanti grazie al processo produttivo TSMC N3E (3nm di seconda generazione). Con XRING 03, l’azienda punta a fare un ulteriore salto in avanti in termini di prestazioni ed efficienza energetica. L’architettura CPU e GPU dovrebbe ancora basarsi su design ARM under license.

Il problema: la concorrenza passa al 2nm

Secondo le informazioni trapelate, XRING 03 utilizzerà il processo TSMC N3P, una versione migliorata del 3nm già sfruttato da XRING 01. Il problema è che nello stesso periodo si prevede l’arrivo sul mercato di chip a 2nm come Snapdragon 8 Elite Gen 6 Pro, Dimensity 9600 e Apple A20. Questo significa che Xiaomi dovrà competere con processori prodotti con tecnologie più avanzate, il che potrebbe tradursi in un gap in termini di efficienza energetica e densità di transistor.

Un traguardo strategico comunque importante

Nonostante il divario sul processo produttivo, XRING 03 rappresenta un passo fondamentale nella strategia di indipendenza tecnologica di Xiaomi. Avere un chip proprietario — anche se non all’avanguardia assoluta — consente al gruppo cinese di differenziarsi, ottimizzare l’integrazione hardware-software e ridurre la dipendenza da fornitori terzi come Qualcomm. Il debutto di XRING 03 sarà con ogni probabilità su un futuro flagship della serie Xiaomi 15 Ultra o Xiaomi 16.