Si parla di:
Toggle

Il 22 aprile 2026 Docker, Inc. ha rilevato attività sospette sul repository ufficiale checkmarx/kics e ha allertato i ricercatori di Socket. L’analisi ha confermato il peggiore degli scenari per un vendor di security scanner: le immagini Docker ufficiali dello strumento open source KICS (Keeping Infrastructure as Code Secure) erano state sostituite con versioni trojanizzate, progettate per generare, cifrare ed esfiltrare i report di scansione completi insieme a token cloud, credenziali GitHub e chiavi SSH di ogni pipeline CI/CD che le eseguiva. Poche ore dopo, l’account @pcpcats rivendicava l’operazione: «Thank you OSS distribution for another very successful day at PCP inc.»

Non è la prima volta che Checkmarx finisce nel mirino di TeamPCP. A marzo 2026 lo stesso gruppo aveva compromesso due workflow GitHub Actions di Checkmarx e plugin distribuiti tramite OpenVSX, colpendo nella stessa ondata anche Trivy e LiteLLM. L’attacco di aprile rappresenta però un salto qualitativo: non si limita più al codice sorgente o agli action, ma colpisce direttamente i binary artifact distribuiti ufficialmente dal vendor, trasformando uno strumento che gli ingegneri installano proprio per cercare vulnerabilità in un vettore di furto di segreti su scala globale.

Che cos’è KICS e perché è un bersaglio ideale

KICS è uno scanner open source per Infrastructure-as-Code mantenuto da Checkmarx, ampiamente integrato nelle pipeline CI/CD per rilevare misconfiguration in Terraform, CloudFormation, Ansible, Kubernetes manifests e Dockerfile. Per sua stessa natura, viene eseguito con accesso di lettura all’intero repository, ai file di configurazione, ai secret dell’ambiente di build e spesso alle credenziali cloud a breve durata emesse dal provider di CI. Compromettere KICS significa ottenere, per ogni installazione infetta, una vista privilegiata sui crown jewels della pipeline.

Il vettore Docker Hub: tag sovrascritti e un v2.1.21 fantasma

Gli attaccanti hanno sovrascritto tag esistenti del repository checkmarx/kics — tra cui alpine, latest, debian, v2.1.20 e v2.1.20-debian — e hanno introdotto un tag v2.1.21 che non corrisponde ad alcun rilascio ufficiale del progetto. Questa tecnica è particolarmente insidiosa: ogni sistema che effettua docker pull checkmarx/kics:latest o che aggiorna l’immagine di base nei workflow di CI scarica silenziosamente la versione compromessa, senza allarmi da parte dei tool di dipendency scanning che si fidano del nome del repository ufficiale.

Il binario ELF di KICS all’interno dell’immagine è stato modificato per mantenere la funzionalità legittima (la scansione si completa senza errori, non ci sono segnali visibili di compromissione nei log) e aggiungere in parallelo una routine di raccolta dati che genera un report di scansione non censurato, lo cifra e lo invia a un endpoint esterno. In pratica, i file di configurazione che contengono password, token e connection string — normalmente redatti dai report pubblici di KICS — vengono esportati in chiaro verso l’infrastruttura dell’attaccante.

L’estensione VS Code e il payload mcpAddon.js

La campagna non si ferma alle immagini Docker. Socket ha identificato malware anche nelle estensioni Checkmarx per Visual Studio Code pubblicate sul marketplace Microsoft e su OpenVSX. Le versioni compromesse sono checkmarx.cx-dev-assist@1.17.0 e @1.19.0, oltre a checkmarx.ast-results@2.63.0 e @2.66.0 (la 1.18.0 risulta pulita, con il malware temporaneamente rimosso nel ciclo di release).

Il meccanismo è chirurgico: gli attaccanti hanno iniettato un commit retrodatato (68ed490b) nel repository Checkmarx/ast-vscode-extension contenente un file di circa 10 MB in modules/mcpAddon.js. Il modulo viene stageed per l’esecuzione runtime tramite l’interprete Bun, una scelta che riduce la probabilità di rilevazione rispetto all’esecuzione tradizionale in Node.js e permette di eseguire codice JavaScript con minore scrutinio da parte degli EDR endpoint.

Cosa ruba realmente mcpAddon.js

Il payload è un infostealer di caratura operativa avanzata. Esegue comandi nativi sulla macchina della vittima per raccogliere un dossier completo di credenziali:

• Token di autenticazione GitHub tramite gh auth token
• Credenziali AWS dai file di configurazione standard
• Token Azure tramite az account get-access-token e azd auth token
• Configurazioni Google Cloud tramite gcloud config config-helper
• Token npm dai file .npmrc dell’utente
• Chiavi SSH e file di configurazione
• File di configurazione di Claude Code e di altri MCP client
• Variabili d’ambiente selezionate del processo

L’inclusione esplicita dei file di configurazione MCP è un segnale che TeamPCP sta mappando non solo le supply chain tradizionali, ma anche l’ecosistema emergente degli agenti AI — che a loro volta conservano token per molteplici servizi di terze parti.

Esfiltrazione via repository GitHub pubblici: l’ingegno del «vocabolario Dune»

L’aspetto più creativo dell’operazione riguarda l’esfiltrazione. Invece di esfiltrare direttamente verso un C2 facilmente bloccabile, il malware crea repository GitHub pubblici con nomi casuali costruiti dal pattern <word>-<word>-<3 digits>, attingendo a un vocabolario ispirato all’universo di Dune — «gesserit», «melange», «fedaykin», «ornithopter», «atreides», «sandworm». Ogni repository ospita tre file: envelope con il payload cifrato, key con la chiave di decifratura (a sua volta cifrata), e token con un identificativo che lega il furto alla vittima.

I messaggi di commit incorporano token aggiuntivi secondo il pattern «LongLiveTheResistanceAgainstMachines:<encoded>», uno slogan ricorrente nel folklore di TeamPCP. Questa architettura rende la rilevazione molto più complessa: il traffico di esfiltrazione è indistinguibile dal normale uso di GitHub da parte di sviluppatori.

Il workflow format-check.yml e l’abuso di toJSON(secrets)

Nell’operazione di marzo, TeamPCP aveva già dimostrato padronanza dei GitHub Actions: il workflow maligno .github/workflows/format-check.yml sfruttava l’espressione ${{ toJSON(secrets) }} per serializzare tutti i segreti del repository e dell’organizzazione in un artefatto JSON scaricabile per 90 giorni. È una tecnica di supply chain attack elegante e sottovalutata, perché non richiede di esfiltrare alcunché verso infrastruttura esterna: GitHub stesso ospita il bottino, che diventa scaricabile con le sole credenziali dell’attaccante.

Propagazione npm via token rubati

Una volta ottenuti i token npm delle vittime, il malware cerca automaticamente pacchetti scrivibili interrogando l’endpoint /-/org/<user>/package e, in fallback, effettua ricerche con https://registry.npmjs.org/-/v1/search?text=maintainer:<user>&size=250. La logica è quella classica dei self-replicating npm worm già osservati in campagne come Shai-Hulud: ogni sviluppatore colpito diventa un potenziale vettore per nuove pubblicazioni malevoli.

Indicatori di Compromissione

== Hash ==
mcpAddon.js
  SHA256  24680027afadea90c7c713821e214b15cb6c922e67ac01109fb1edb3ee4741d9
  SHA1    2b12cc5cc91ec483048abcbd6d523cdc9ebae3f3
  MD5     d47de3772f2d61a043e7047431ef4cf4

kics (ELF binary trojanizzato)
  SHA256  2a6a35f06118ff7d61bfd36a5788557b695095e7c9a609b4a01956883f146f50
  SHA1    250f3633529457477a9f8fd3db3472e94383606a
  MD5     e1023db24a29ab0229d99764e2c8deba

== Docker tag compromessi (checkmarx/kics) ==
alpine, latest, debian, v2.1.20, v2.1.20-debian, v2.1.21 (fake)

== Index manifest digest ==
sha256:2588a44890263a8185bd5d9fadb6bc9220b60245dbcbc4da35e1b62a6f8c230d  (alpine/v2.1.20/v2.1.21)
sha256:222e6bfed0f3bb1937bf5e719a2342871ccd683ff1c0cb967c8e31ea58beaf7b  (debian variants)
sha256:a0d9366f6f0166dcbf92fcdc98e1a03d2e6210e8d7e8573f74d50849130651a0  (latest)

== Estensioni VS Code / OpenVSX ==
checkmarx.cx-dev-assist  1.17.0, 1.19.0   (malevole)
checkmarx.ast-results    2.63.0, 2.66.0   (malevole)

== C2 ==
audit.checkmarx[.]cx/v1/telemetry
94[.]154[.]172[.]43

== Pattern repository di staging ==
<word>-<word>-<3 digits> (vocabolario Dune: gesserit, melange, fedaykin,
ornithopter, atreides, sandworm, ...) con file envelope/key/token

== Pattern commit message ==
LongLiveTheResistanceAgainstMachines:<encoded>

Implicazioni e raccomandazioni

Il caso Checkmarx/KICS è un promemoria brutale: gli strumenti di security scanner sono essi stessi componenti della supply chain, spesso eseguiti con privilegi elevati dentro le pipeline più sensibili dell’organizzazione. Per chi gestisce ambienti che integrano KICS o altri scanner Checkmarx:

• Verificare le versioni pullate di checkmarx/kics negli ultimi 30 giorni e confrontare i digest con quelli pubblicati ufficialmente dal vendor dopo la rimediation.
• Effettuare il pin delle immagini Docker a digest SHA invece che a tag mutabili come latest o alpine.
• Controllare i log GitHub per workflow artefacts di dimensione anomala, in particolare quelli generati da workflow che referenziano toJSON(secrets).
• Ruotare tutti i token GitHub, npm, AWS, Azure e GCP che potrebbero essere stati esposti a sviluppatori con cx-dev-assist o ast-results nelle versioni compromesse.
• Monitorare la creazione di repository GitHub pubblici corrispondenti al pattern Dune descritto sopra.
• Bloccare o allertare sulle connessioni verso audit.checkmarx.cx (dominio di lookalike non legittimo di Checkmarx).

Il doppio colpo di TeamPCP a Checkmarx in meno di due mesi suggerisce che il gruppo conserva un accesso persistente o ricorrente agli ambienti di build del vendor, o quantomeno che alcune delle credenziali rubate nella prima ondata non sono state completamente invalidate. La security community attende risposte più dettagliate dal vendor su come il tag Docker ufficiale sia stato sovrascritto e su quale catena di fiducia debba essere ricostruita per i clienti che hanno integrato KICS nelle proprie pipeline negli ultimi mesi.

Framework Computer Inc, azienda statunitense specializzata in notebook modulari, riparabili e personalizzabili, presenta il Framework Laptop 13 Pro, una versione avanzata della sua linea di portatili da 13 pollici. Questo modello si propone come soluzione...

🔗 Leggi il post completo

Il team di TypeScript ha rilasciato la beta ufficiale di TypeScript 7.0, e non si tratta di un aggiornamento incrementale: il compilatore è stato riscritto in Go, con miglioramenti di performance che in molti scenari superano un fattore 10x. Dopo quasi un anno di anteprime tecniche sotto il nome TypeScript Native Preview, Microsoft porta la versione nativa del compilatore a un pubblico molto più ampio e la raccomanda per uso quotidiano, pur restando formalmente in beta.

Perché riscrivere il compilatore in Go

Il compilatore di TypeScript era storicamente scritto nello stesso linguaggio che compilava. Questa scelta, elegante dal punto di vista del bootstrapping, ha sempre comportato un costo: su codebase di grandi dimensioni il tsc può impiegare decine di secondi (o minuti) per il type-checking e il watch mode si appesantisce rapidamente all’aumentare dei file.

La riscrittura in Go non è un rewrite da zero: il team parla esplicitamente di un port metodico, mantenendo parità strutturale con la logica di type-checking di TypeScript 6.0. Questo approccio riduce il rischio di regressioni semantiche: la stessa base di casi di test, le stesse regole, ma con le velocità permesse da codice nativo e dal parallelismo reale a memoria condivisa.

Il risultato, secondo Microsoft, è che TypeScript 7.0 è circa 10 volte più veloce di TypeScript 6.0. Team come Bloomberg, Figma, Google, Slack e Vercel hanno riportato numeri comparabili durante la beta privata, con riduzioni drastiche dei tempi di build in CI.

Come provarlo oggi

L’installazione avviene come package separato per non rompere le pipeline esistenti. Basta un singolo comando:

npm install -D @typescript/native-preview@beta
npx tsgo --version
# Version 7.0.0-beta

Parallelismo configurabile

Una delle novità più sottili, ma con maggiore impatto pratico, è il parallelismo integrato nel compilatore:

• --checkers N: numero di worker dedicati al type-checking (default 4). I worker mantengono viste indipendenti per evitare ricalcoli ridondanti, ma i risultati restano deterministici.
• --builders N: abilita la compilazione parallela di più progetti referenziati (project references). Ha un effetto moltiplicativo quando combinato con --checkers, ed è particolarmente efficace nei monorepo.
• --singleThreaded: forza l’esecuzione sequenziale per debugging o ambienti con memoria limitata (container CI con poca RAM, ad esempio).

Alzare --checkers aumenta la velocità ma anche il consumo di memoria: su agenti CI piccoli conviene fare qualche prova empirica prima di spingerlo oltre 8.

Breaking changes: la pulizia annunciata

TypeScript 7.0 è anche l’occasione per rimuovere anni di retrocompatibilità. Chi mantiene progetti legacy dovrà prestare attenzione, perché molte opzioni di configurazione sono semplicemente scomparse:

• target: es5 non è più supportato.
• downlevelIteration, moduleResolution: node/node10/classic, e i moduli amd, umd, systemjs, none sono stati rimossi.
• baseUrl è stato eliminato: usare paths relativo alla root del progetto.
• esModuleInterop, allowSyntheticDefaultImports e alwaysStrict non possono più essere disattivati.

Cambiano anche diversi default: strict: true, module: esnext, target pari all’ultima versione ECMAScript stabile prima di esnext, noUncheckedSideEffectImports: true, e soprattutto types: []. Quest’ultimo è il cambiamento che più spesso romperà le build: prima @types/* venivano inclusi automaticamente, ora vanno dichiarati esplicitamente:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Convivenza con TypeScript 6.0

Per chi non può migrare subito tutte le pipeline, è possibile installare entrambe le versioni affiancate:

npm install -D typescript@npm:@typescript/typescript6

Roadmap e cosa aspettarsi

La beta è datata 21 aprile 2026; il rilascio stabile è previsto entro due mesi, con una release candidate alcune settimane prima. Nel frattempo arriveranno un --watch più efficiente, la parità di declaration file emit per JavaScript, miglioramenti all’editor (ricerca dei riferimenti ai file, comandi import/export più granulari) e una API programmatica stabile, attesa per TypeScript 7.1 o successiva.

Vale la pena migrare subito?

Per team che lavorano su codebase grandi e soffrono di type-check lenti, la risposta è “quasi sicuramente sì, almeno in parallelo”. Microsoft stessa dichiara il compilatore “altamente stabile e altamente compatibile” sulla base di test su codebase da milioni di righe. La strategia più prudente è: installare @typescript/native-preview come dev dependency aggiuntiva, introdurlo come job di CI opzionale accanto al tsc esistente, misurare i tempi reali e segnalare eventuali incompatibilità sul repository microsoft/typescript-go.

Le incompatibilità che emergeranno non saranno di natura logica ma di configurazione: soprattutto il nuovo default types: [] e la rimozione di baseUrl. Chi si è tenuto aggiornato con le versioni recenti dovrebbe cavarsela con poche modifiche al tsconfig.json.

Fonte: Announcing TypeScript 7.0 Beta di Daniel Rosenwasser sul blog ufficiale TypeScript (Microsoft DevBlogs).

Un nuovo capitolo si aggiunge alla vicenda della verifica dell’età nei sistemi operativi, e stabilire se sia un miglioramento o un peggioramento rispetto a quanto sinora visto è tutto da stabilire. Infatti se fino ad oggi la questione sembrava essere appannaggio solo di alcuni specifici stati americani, California e Colorado, oltre al Brasile, la notizia...

🔗 Leggi il post completo

La collaborazione tra Mozilla e Anthropic ha portato a un risultato straordinario: grazie all’accesso anticipato al modello Mythos Preview, sviluppato da Anthropic, il team di Firefox ha identificato e corretto 271 vulnerabilità di sicurezza...

🔗 Leggi il post completo

Quando una tabella PostgreSQL cresce oltre il milione di righe, query che prima restituivano risultati in millisecondi iniziano ad impiegare secondi — o peggio. La buona notizia è che PostgreSQL offre strumenti potenti per affrontare questo problema. La cattiva notizia è che molti sviluppatori conoscono solo una parte di questi strumenti.

In questo articolo passiamo in rassegna le 12 tecniche più efficaci per ottimizzare le query su grandi dataset, con esempi SQL concreti per ciascuna.

1. Creare indici sulle colonne frequentemente filtrate

Il consiglio più noto, ma non per questo meno importante. Un indice trasforma una scansione sequenziale (O(n)) in una ricerca B-tree (O(log n)). La differenza su una tabella da un milione di righe può essere di due ordini di grandezza.

-- Prima: full sequential scan su ordini
SELECT * FROM orders WHERE customer_id = 42;

-- Creazione dell'indice
CREATE INDEX idx_orders_customer_id ON orders(customer_id);

-- Dopo: index scan, da 240ms a pochi ms

2. Normalizzare il database in modo strategico

La normalizzazione riduce la ridondanza e migliora la coerenza dei dati, ma va applicata con giudizio. Una normalizzazione eccessiva crea decine di JOIN che possono diventare colli di bottiglia. La regola pratica: normalizzate i dati che cambiano spesso o che hanno alta cardinalità (liste di prodotti, clienti, categorie), denormalizzate i dati storici o di report dove la velocità di lettura è critica.

3. Evitare SELECT *

Selezionare tutte le colonne ha due costi nascosti: aumenta il volume di I/O e impedisce a PostgreSQL di soddisfare la query direttamente dall’indice (index-only scan). Specificate sempre le colonne necessarie:

-- Evitare
SELECT * FROM orders WHERE customer_id = 42;

-- Preferire
SELECT id, created_at, total_amount FROM orders WHERE customer_id = 42;

4. Ordinare i JOIN in modo efficiente

Il query planner moderno di PostgreSQL determina autonomamente l’ordine ottimale dei JOIN grazie al cost-based optimizer. Tuttavia, in scenari con molte tabelle o con join_collapse_limit ridotto, conviene strutturare i JOIN in modo che le tabelle più piccole (o più filtrate) vengano processate per prime, riducendo la cardinalità delle operazioni successive.

5. Usare LIMIT durante l’esplorazione dei dati

Apparentemente ovvio, ma spesso trascurato: se l’interfaccia utente mostra al massimo 50 risultati, non ha senso recuperarne un milione dal database.

SELECT id, name, email 
FROM customers 
ORDER BY created_at DESC 
LIMIT 50 OFFSET 0;

6. Indici parziali per subset frequenti

Un indice parziale indicizza solo le righe che soddisfano una condizione, riducendo dimensioni e costo di manutenzione:

-- Indice solo sugli ordini completati (subset più frequentemente interrogato)
CREATE INDEX idx_completed_orders
ON orders(customer_id)
WHERE status = 'Completed';

-- La query deve includere la stessa condizione per usare l'indice
SELECT id, total_amount 
FROM orders 
WHERE customer_id = 42 AND status = 'Completed';

7. Usare i tipi di dato più piccoli necessari

Ogni byte conta quando moltiplicato per milioni di righe. Preferite sempre il tipo più compatto che soddisfa il requisito:

• integer (4 byte) invece di bigint (8 byte) per chiavi primarie < 2 miliardi
• smallint (2 byte) per enumerazioni con pochi valori
• timestamp invece di timestamptz se il fuso orario è fisso
• varchar(n) con limite appropriato invece di text illimitato dove possibile

Tipi più piccoli significano pagine di dati più dense, quindi meno I/O per ogni query.

8. Non applicare funzioni sulle colonne indicizzate

Applicare una funzione a una colonna indicizzata invalida l’utilizzo dell’indice:

-- L'indice su name NON viene usato
SELECT * FROM customers WHERE LOWER(name) = 'mario rossi';

-- Soluzione: creare un indice funzionale
CREATE INDEX idx_customers_lower_name ON customers(LOWER(name));

-- Ora l'indice viene usato
SELECT * FROM customers WHERE LOWER(name) = 'mario rossi';

9. Partizionare le tabelle molto grandi

Il partizionamento divide una tabella logica in sotto-tabelle fisiche, permettendo a PostgreSQL di escludere partizioni irrilevanti (partition pruning) durante le query:

-- Tabella partizionata per anno
CREATE TABLE orders_partitioned (
    id         serial NOT NULL,
    customer_id integer,
    created_at  timestamp NOT NULL,
    CONSTRAINT pk_orders PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);

-- Creazione delle partizioni annuali
CREATE TABLE orders_2024 PARTITION OF orders_partitioned
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

CREATE TABLE orders_2025 PARTITION OF orders_partitioned
    FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

10. Usare le transazioni per operazioni bulk

PostgreSQL esegue un commit (e quindi una scrittura sincrona su WAL) dopo ogni statement. Raggruppare più operazioni in un’unica transazione riduce drasticamente i costi di I/O:

-- Lento: un commit per ogni INSERT
INSERT INTO log_events VALUES (...);
INSERT INTO log_events VALUES (...);
-- ... x 10.000

-- Veloce: un solo commit per tutto il batch
BEGIN;
INSERT INTO log_events VALUES (...);
INSERT INTO log_events VALUES (...);
-- ... x 10.000
COMMIT;

11. Evitare transazioni long-running

Il modello MVCC (Multi-Version Concurrency Control) di PostgreSQL mantiene versioni multiple delle righe per garantire la consistenza delle letture. Le transazioni long-running bloccano il processo di VACUUM dal rimuovere le versioni obsolete, causando table bloat: tabelle che crescono fisicamente anche quando i dati logici non aumentano.

Spezzettate le operazioni pesanti in batch più piccoli e monitorate le transazioni attive con:

SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
FROM pg_stat_activity
WHERE state != 'idle' AND query_start IS NOT NULL
ORDER BY duration DESC;

12. Gestire il bloat con VACUUM

Ogni UPDATE e DELETE lascia righe “morte” sul disco. VACUUM le recupera:

-- VACUUM standard: recupera spazio senza bloccare le letture
VACUUM orders;

-- VACUUM FULL: recupera tutto lo spazio ma blocca l'accesso alla tabella
-- Usare solo in finestre di manutenzione programmate
VACUUM FULL orders;

-- Verificare lo stato del bloat
SELECT relname, n_dead_tup, n_live_tup,
       round(n_dead_tup::numeric / NULLIF(n_live_tup + n_dead_tup, 0) * 100, 2) AS dead_pct
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

-- Verificare la configurazione autovacuum per una tabella specifica
SELECT reloptions FROM pg_class WHERE relname = 'orders';

Riepilogo operativo

Non tutte le tecniche si applicano a ogni scenario. Un approccio efficace inizia sempre dall’analisi con EXPLAIN (ANALYZE, BUFFERS) per identificare i reali colli di bottiglia, poi applica le ottimizzazioni in modo mirato. L’indice sbagliato o il partizionamento mal configurato possono peggiorare le prestazioni invece di migliorarle.

Il punto di partenza universale resta lo stesso: misurare prima, ottimizzare dopo.

Fonte: 12 practices for optimizing PostgreSQL queries for large datasets — elmah.io Blog

Mozilla Thunderbird è considerato uno dei client di posta elettronica più maturi e affidabili nel panorama del software libero. Nato come progetto della comunità Mozilla, oggi è sviluppato dal Thunderbird Council insieme a un team dedicato che...

🔗 Leggi il post completo

QEMU è un emulatore e virtualizzatore open source estremamente versatile, progettato per eseguire sistemi operativi e applicazioni destinati a un’architettura hardware su un host con architettura differente. Nato nel 2003 per iniziativa di Fabrice...

🔗 Leggi il post completo

Il Motorola Edge 70 Pro+ si mostra per la prima volta attraverso immagini di rendering trapelate online, attribuite al noto leaker Evan Blass. Il prossimo mid-range potenziato di Motorola rivela un design originale e diverse specifiche interessanti, che lo differenziano nettamente dai modelli precedenti della serie Edge.

Cinque colorazioni, ognuna con la sua texture unica

Una delle caratteristiche più originali del Edge 70 Pro+ è la varietà di finiture disponibili. Le cinque colorazioni previste — Bianco, Turchese, Blu Scuro, Rosso e Marrone — non si distinguono solo per il colore, ma anche per la texture della scocca posteriore. Il Blu e il Turchese adottano una finitura in tessuto, il Bianco imita il marmo, mentre il Marrone presenta un effetto legno. Una scelta estetica audace che punta a differenziarsi in un segmento spesso omologato. Il design conserva le curve laterali tipiche della serie Edge, sia sulla parte anteriore che su quella posteriore.

Fotocamera con teleobiettivo 3,5x

Dal punto di vista fotografico, il Edge 70 Pro+ dovrebbe montare un ultra-grandangolare equivalente a 12mm e un teleobiettivo con focale equivalente a 81mm, corrispondente a circa 3,5x di zoom ottico. Una dotazione più che rispettabile per un mid-range, e superiore a quanto offerto dal modello base Edge 70 Pro, che si ferma a specifiche inferiori.

Specifiche complete ancora in arrivo

Motorola non ha ancora fornito dettagli ufficiali su processore, batteria, display e prezzo del Edge 70 Pro+. Il modello Edge 70 Pro base dovrebbe però montare il chip Dimensity 8500 con display a 144Hz, il che lascia presagire per il Pro+ specifiche ancora più elevate. Un annuncio ufficiale è atteso nelle prossime settimane.

Xiaomi ha presentato ufficialmente in Cina il Redmi K90 Max, uno smartphone da gaming che punta a combinare specifiche di fascia alta con un prezzo più accessibile rispetto ai principali concorrenti del settore. La novità più eclatante è la presenza di una ventola di raffreddamento integrata nel corpo del dispositivo, una rarità nel panorama degli smartphone.

Raffreddamento attivo: la ventola cambia le regole

Il Redmi K90 Max è il primo smartphone della serie K di Xiaomi a integrare una ventola di raffreddamento attivo. Il sistema, dotato di alette di grandi dimensioni e un design del flusso d’aria ottimizzato, permette di mantenere temperature stabili anche durante sessioni di gioco prolungate. Per i giocatori che spingono al massimo il dispositivo, il raffreddamento attivo fa una differenza reale in termini di prestazioni sostenute nel tempo.

Dimensity 9500 e display AMOLED a 165Hz

Sotto la scocca batte il chip MediaTek Dimensity 9500, affiancato da un co-processore grafico proprietario D2 che ottimizza le prestazioni nei giochi. I benchmark mostrano numeri in linea con i migliori flagship attuali. Il display AMOLED da 165Hz offre una fluidità eccellente sia nei giochi che nella navigazione quotidiana, con supporto a un’ampia gamma cromatica e alta luminosità. Alcuni titoli sono stati ottimizzati per girare al massimo frame rate possibile su questo hardware.

Batteria da 8.550 mAh e prezzo competitivo

La batteria da 8.550 mAh con ricarica rapida a 100W garantisce una lunga autonomia anche in sessioni di gioco intensive. Il comparto fotografico, pur non essendo il focus del dispositivo, monta un sensore principale da 50 MP. Il prezzo di partenza è di 3.499 yuan (circa 440 euro) nella configurazione da 12 GB + 256 GB, significativamente inferiore a quello del RedMagic 11 Pro che il K90 Max vuole sfidare direttamente. Disponibile per ora solo in Cina, ma potrebbe arrivare in altri mercati nei prossimi mesi.

ASUS si prepara a lanciare un nuovo tablet Android, denominato semplicemente ASUS Pad, le cui immagini ufficiali e specifiche principali sono già trapelate online. La notizia è particolarmente interessante considerando che il produttore taiwanese ha annunciato di non avere in programma nuovi smartphone per il 2026, concentrando le proprie energie proprio sul settore tablet.

Design sottile con OLED da 12,2 pollici a 144Hz

Le immagini mostrano un dispositivo dall’aspetto elegante e minimalista: cornici sottili e uniformi su tutti i lati, telaio in metallo leggermente curvo e un semplice modulo fotocamera nell’angolo superiore sinistro del pannello posteriore. Nonostante le sue dimensioni da 12 pollici, l’ASUS Pad è sorprendentemente snello: spessore di circa 6,5 mm e peso intorno ai 523 grammi. Il display è un pannello OLED a doppio strato da 12,2 pollici con refresh rate fino a 144Hz e supporto alle tecnologie Dolby per la riproduzione video. Una scelta di pannello premium che lo posiziona decisamente nel segmento alto.

Batteria da 9.000 mAh e audio Dolby Atmos

Sul fronte dell’autonomia, il tablet monta una batteria da 9.000 mAh con ricarica rapida (velocità non ancora confermata). Gli altoparlanti stereo con supporto Dolby Atmos completano un’esperienza multimediale di tutto rispetto. È prevista anche una cover con stand integrato a geometria variabile, che funge sia da protezione per lo schermo che da supporto per diversi angoli di inclinazione.

Prezzo e disponibilità ancora da confermare

ASUS non ha ancora comunicato prezzi né date di lancio ufficiali per l’ASUS Pad. Guardando alle specifiche emerse, si tratta chiaramente di un prodotto di fascia alta destinato a competere con i migliori tablet Android sul mercato. Un annuncio formale dovrebbe arrivare nelle prossime settimane.

OPPO ha scelto di svelare in anticipo il sistema fotocamere del prossimo Find X9 Ultra, e i dettagli sono davvero straordinari. Il flagship del produttore cinese si propone come un punto di riferimento assoluto per la fotografia mobile, portando per la prima volta su smartphone una fotocamera zoom 10x con sensore da 50 MP.

Il teleobiettivo 10x reinventato: F3.5 e 5 prismi

La principale innovazione del Find X9 Ultra è la fotocamera periscopica con zoom ottico 10x abbinata a un sensore da 50 MP, una combinazione inedita per il mercato degli smartphone. OPPO ha sviluppato una struttura con 5 prismi interni che permette di mantenere un modulo compatto (appena 29 mm di lunghezza totale) pur garantendo un diaframma luminoso F3.5. Il risultato, secondo l’azienda, è una quantità di luce catturata triplicata rispetto ai precedenti teleobiettivi 10x. La precisione di montaggio è garantita da un sistema di calibrazione ottica automatizzata.

Sistema quad-camera con due sensori da 200 MP

Il resto del sistema fotografico non è da meno. La fotocamera principale monta il sensore Sony Lytia 901 da 1/1,12 pollici con apertura F1.5, molto vicino alle prestazioni di un sensore da 1 pollice. Il 3x periscopico da 50 MP permette anche di ottenere 6x effettivi con piena risoluzione grazie al crop in-sensor, e può scendere fino a 15 cm di distanza minima per la fotografia macro. La fotocamera ultra-grandangolare da 50 MP raccoglie il 56% di luce in più rispetto alla generazione precedente. A tutto questo si aggiunge una True Color Camera multi-spettrale che migliora l’accuratezza cromatica in collaborazione con gli altri obiettivi.

Accessori Hasselblad per arrivare a 30x

Per chi non si accontenta, OPPO offre un kit opzionale firmato Hasselblad: una custodia compatibile con filtri da 67mm e un teleconvertitore dedicato che porta il 3x a 13x ottico, estendibile fino a 30x combinando lo zoom in-sensor. Uno strumento che supera i confini tradizionali della fotografia mobile. Il Find X9 Ultra si annuncia come uno degli smartphone più ambiziosi dell’anno sul fronte fotografico.

In un mercato smartphone che fatica a crescere, Samsung riesce a sorprendere. Secondo i dati di Counterpoint Research, il Galaxy S26 ha registrato nelle prime tre settimane di vendita un incremento del 29% rispetto all’analogo periodo del Galaxy S25, confermando il successo del nuovo flagship sud-coreano.

Galaxy S26 Ultra il più venduto, conquista il 71% delle vendite

Il dato più interessante riguarda la distribuzione delle vendite all’interno della lineup: il Galaxy S26 Ultra ha rappresentato ben il 71% di tutti i dispositivi S26 venduti. Una percentuale altissima che riflette uno spostamento dell’utenza verso il modello top, anche a scapito del Galaxy S26+. Chi in passato optava per il Plus sembra ora preferire il salto di qualità verso l’Ultra, spingendo verso l’alto anche il prezzo medio di vendita dell’intera serie.

Promozioni degli operatori e nuove funzionalità

Alla base del successo commerciale ci sono anche le politiche promozionali degli operatori telefonici, in particolare AT&T e T-Mobile negli Stati Uniti, che hanno offerto sconti significativi sull’acquisto del Galaxy S26 Ultra. Anche le nuove funzionalità introdotte con la serie — tra cui miglioramenti legati alla privacy — hanno contribuito a stimolare la domanda. Il mercato complessivo degli smartphone, spinto anche dal lancio di iPhone 17e e Pixel 10a, ha registrato una crescita del 5% su base annua.

Prezzi in aumento all’orizzonte

Un’ombra si allunga però sul settore: le tensioni nella catena di fornitura di RAM e storage potrebbero spingere verso l’alto i prezzi dei futuri smartphone. Questo fattore potrebbe aver alimentato ulteriormente la domanda a breve termine, con molti consumatori che hanno scelto di anticipare l’acquisto per evitare rincari. Samsung comunque festeggia, e ora l’attenzione si sposta sui prossimi Galaxy Z Fold 8 e sulle evoluzioni della lineup Pixel.

Mozilla Firefox è un browser libero e open source sviluppato dalla Mozilla Foundation e dalla Mozilla Corporation. Nonostante non sia tra i browser più utilizzati a livello globale, rimane una scelta molto apprezzata dagli utenti delle distribuzioni GNU/Linux grazie alla...

🔗 Leggi il post completo

Si parla di:
Toggle

Una vulnerabilità elementare di tipo IDOR (Insecure Direct Object Reference) sull’API del portale governativo francese ANTS ha consentito a un attore di minaccia di estrarre fino a 19 milioni di record contenenti dati anagrafici e di identità dei cittadini francesi. La vicenda, emersa pubblicamente il 21 aprile 2026, solleva interrogativi profondi sulla sicurezza delle infrastrutture digitali dello Stato francese e sulla protezione dei dati biometrici e documentali alla base del sistema di identità nazionale.

Cos’è ANTS e perché la violazione è così grave

L’Agence Nationale des Titres Sécurisés (ANTS), operativa sotto il Ministero dell’Interno francese, gestisce le domande e il ciclo di vita dei documenti d’identità ufficiali dei cittadini: carte d’identità nazionale, passaporti, patenti di guida e permessi di soggiorno. Il portale ants.gouv.fr costituisce il punto di accesso centralizzato attraverso cui milioni di francesi richiedono, rinnovano o tracciano i propri documenti d’identità. Una violazione di questa piattaforma non riguarda quindi dati di servizio generici: tocca direttamente le informazioni anagrafiche certificate dallo Stato, quelle stesse che alimentano i sistemi di identità digitale e i processi di verifica dell’identità.

La timeline: dall’intrusione alla divulgazione

La ricostruzione cronologica dell’incidente è la seguente:

• 15 aprile 2026: ANTS rileva internamente un incidente di sicurezza sul portale istituzionale e avvia le procedure di risposta agli incidenti.
• 16 aprile 2026: Un attore di minaccia che opera sotto lo pseudonimo breach3d pubblica su forum underground di hacking la rivendicazione dell’attacco, affermando di essere in possesso di un dataset di 18-19 milioni di record esfiltrati dalla piattaforma ANTS.
• 19-20 aprile 2026: Il dato viene segnalato da ricercatori di sicurezza e giornalisti specializzati che accedono ai forum underground e verificano i campioni forniti dall’attore.
• 21 aprile 2026: Il Ministero dell’Interno francese e ANTS confermano ufficialmente l’incidente, notificano il CNIL (Commission Nationale de l’Informatique et des Libertés), la Procura di Parigi e l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information).

Il vettore d’attacco: IDOR, una vulnerabilità imbarazzante

Secondo quanto riferito da fonti vicine all’indagine e dalle dichiarazioni dello stesso attaccante, il vettore di compromissione è stato un difetto di tipo IDOR (Insecure Direct Object Reference) sull’API del portale ANTS. Lo stesso breach3d ha descritto la vulnerabilità come “really stupid” — stupida nella sua semplicità — rivelando che era sufficiente modificare un identificatore numerico nelle richieste HTTP all’API per accedere ai record di qualsiasi altro utente registrato sulla piattaforma.

L’IDOR è una vulnerabilità classificata nel OWASP Top 10 da oltre vent’anni (A01:2021 – Broken Access Control). Si verifica quando un’applicazione espone riferimenti diretti a oggetti interni — come ID di database, file o record — senza verificare che l’utente richiedente abbia effettivamente l’autorizzazione ad accedere a quell’oggetto. In questo caso, l’API governativa francese non implementava controlli di autorizzazione adeguati: un utente autenticato poteva iterare sugli ID numerici degli account per raccogliere massivamente i dati di tutti gli utenti registrati. Il processo di esfiltrazione risulta quindi altamente automatizzabile con script elementari.

I dati esposti e le implicazioni per i cittadini

Il Ministero dell’Interno francese ha confermato che i dati potenzialmente esposti includono: nome e cognome, indirizzo email, data di nascita, identificativi di account univoci e credenziali di accesso (login ID). Per un sottoinsieme di utenti, potrebbero essere stati esposti anche l’indirizzo postale, il luogo di nascita e il numero di telefono. ANTS ha precisato che i documenti caricati sul portale (immagini di passaporti o patenti, ad esempio) non risultano compromessi e che i dati esfiltrati non consentono l’accesso diretto agli account.

Tuttavia, la combinazione di dati anagrafici certificati dallo Stato con informazioni di contatto apre scenari di abuso estremamente preoccupanti per i difensori:

• Phishing e spear-phishing di alta precisione: con nome completo, email, data di nascita e luogo di nascita, gli attaccanti possono costruire comunicazioni altamente credibili che si spacciano per corrispondenza ufficiale del governo francese o di istituti finanziari.
• Furto di identità e creazione di identità sintetiche: la combinazione di dati anagrafici verificati dallo Stato costituisce una base ideale per aprire conti bancari fraudolenti, richiedere prestiti o commettere frodi fiscali.
• Sextortion e social engineering: messaggi personalizzati che dimostrano conoscenza di dati specifici (luogo di nascita, data esatta) aumentano drasticamente la credibilità degli schemi di estorsione.
• Credential stuffing: gli indirizzi email associati agli account ANTS vengono tipicamente testati su altri servizi, sfruttando il riutilizzo delle password.

Il profilo dell’attore: breach3d

L’attore breach3d non è nuovo alla scena underground. Prima di questa rivendicazione aveva già pubblicato dataset di altre organizzazioni su forum frequentati da broker di dati e operatori criminali. Non ci sono elementi pubblici che permettano di attribuire l’attività a un gruppo state-sponsored o a una gang ransomware strutturata: il profilo appare più coerente con quello di un opportunista focalizzato sulla monetizzazione dei dati piuttosto che su obiettivi di intelligence. Il dataset sarebbe stato messo in vendita a un prezzo non divulgato pubblicamente.

La risposta istituzionale e le notifiche

ANTS ha comunicato che non è richiesta alcuna azione immediata da parte degli utenti, invitandoli tuttavia a mantenere alta la vigilanza nei confronti di messaggi sospetti. L’agenzia ha notificato l’incidente alla CNIL, alla Procura di Parigi e all’ANSSI, che coordineranno le indagini e valuteranno la conformità al GDPR (Regolamento Generale sulla Protezione dei Dati). La violazione, se confermata nelle proporzioni dichiarate da breach3d, configurerebbe uno degli incidenti più gravi mai registrati nell’ambito dei sistemi di identità statale europei.

Pavel Durov, fondatore di Telegram, ha pubblicamente commentato l’incidente sottolineando i rischi sistemici legati alla centralizzazione dei dati d’identità governativi su piattaforme web esposte a Internet, alimentando il dibattito sulla progettazione sicura dei portali di e-government.

Cosa possono fare i difensori

Per le organizzazioni che gestiscono portali ad alta sensibilità e per i team di sicurezza che devono valutare il rischio residuo per i propri utenti alla luce di questo dataset circolante, si raccomanda di:

• Implementare sistematicamente controlli di autorizzazione lato server su ogni endpoint API che restituisce dati associati a un identificatore: verificare sempre che l’utente autenticato sia il proprietario del record richiesto.
• Adottare test di sicurezza specifici per IDOR e Broken Access Control nei cicli di sviluppo (SAST, DAST, penetration testing con focus su API).
• Per le organizzazioni che gestiscono dipendenti o clienti francesi: alzare il livello di allerta anti-phishing e considerare campagne di sensibilizzazione mirate sull’utilizzo di questo tipo di dataset per attacchi personalizzati.
• Monitorare i propri indirizzi email aziendali su servizi di threat intelligence e breach monitoring per rilevare tempestivamente la comparsa del dataset in nuovi marketplace underground.
• Valutare l’abilitazione di autenticazione multi-fattore su tutti i servizi esposti che accettano email come username, poiché la disponibilità degli indirizzi email alimenta attacchi di account takeover.

La violazione ANTS è l’ennesima dimostrazione che le vulnerabilità più banali — note, documentate e prevenibili — continuano ad affliggere sistemi governativi critici. Una API senza controlli di accesso adeguati, su un portale che gestisce l’identità di decine di milioni di cittadini, rappresenta un rischio sistemico di proporzioni difficilmente accettabili in un’era in cui il furto d’identità digitale alimenta ecosistemi criminali globali.

Da sempre, creare addon nativi per Node.js significava entrare nel mondo di C++ e node-gyp, con la necessità di installare Python, Visual Studio Build Tools e una serie di dipendenze che trasformavano il setup dell’ambiente in un’impresa. Il team di C# Dev Kit di Microsoft ha trovato una soluzione elegante: usare .NET Native AOT per produrre librerie condivise compatibili con l’interfaccia N-API di Node.js, scritte interamente in C#.

In questo articolo vediamo come funziona questa tecnica, analizzando la struttura del progetto, il meccanismo di interop e i punti critici da tenere d’occhio in produzione.

Perché Node.js supporta addon scritti in qualsiasi linguaggio

Un addon nativo per Node.js è semplicemente una libreria condivisa (.dll su Windows, .so su Linux, .dylib su macOS) che esporta un punto di ingresso preciso: la funzione napi_register_module_v1. Node.js carica la libreria, chiama questa funzione e da quel momento il modulo è disponibile per JavaScript.

L’interfaccia che rende tutto questo possibile è N-API (Node-API), una API C stabile e ABI-compatibile tra le versioni di Node.js. Questo significa che qualsiasi linguaggio in grado di produrre una shared library ed esportare una funzione C può diventare un addon Node.js — incluso C# compilato con Native AOT.

Configurazione del progetto .NET

Il file di progetto è sorprendentemente minimale:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <PublishAot>true</PublishAot>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
  </PropertyGroup>
</Project>

• PublishAot: abilita la compilazione Ahead-of-Time, producendo una shared library nativa invece di un assembly IL.
• AllowUnsafeBlocks: necessario per l’interop con N-API tramite function pointer e tipi non gestiti.

Il punto di ingresso del modulo

L’entry point usa l’attributo [UnmanagedCallersOnly], che istruisce il compilatore a generare una funzione C-callable con la firma esatta attesa da Node.js:

[UnmanagedCallersOnly(
    EntryPoint = "napi_register_module_v1",
    CallConvs = [typeof(CallConvCdecl)])]
public static nint Init(nint env, nint exports)
{
    // Registrazione delle funzioni esposte
    return exports;
}

Risoluzione delle funzioni N-API a runtime

Le funzioni N-API (come napi_create_string_utf8 o napi_get_cb_info) sono esportate direttamente da node.exe, non da una DLL separata. Per fare in modo che P/Invoke le risolva correttamente, si registra un custom resolver:

private static void Initialize()
{
    NativeLibrary.SetDllImportResolver(
        System.Reflection.Assembly.GetExecutingAssembly(),
        ResolveDllImport);
}

private static nint ResolveDllImport(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
{
    if (libraryName == "node")
        return NativeLibrary.GetMainProgramHandle();
    return IntPtr.Zero;
}

Marshalling delle stringhe UTF-8

Uno dei punti più delicati è la conversione tra stringhe JavaScript (UTF-16 internamente in V8, UTF-8 via N-API) e stringhe .NET. La strategia ottimale prevede:

• Uso dello stack per stringhe piccole (≤512 byte) tramite stackalloc
• Uso di ArrayPool<byte> per stringhe più grandi, evitando allocazioni sull’heap

private static string GetStringArg(nint env, nint info, int argIndex)
{
    // Recupera l'handle dell'argomento
    nint value = GetArgument(env, info, argIndex);
    
    // Prima chiamata: ottieni la dimensione necessaria
    nuint byteCount;
    napi_get_value_string_utf8(env, value, null, 0, out byteCount);
    
    // Allocazione efficiente in base alla dimensione
    if (byteCount <= 512)
    {
        Span<byte> buffer = stackalloc byte[(int)byteCount + 1];
        napi_get_value_string_utf8(env, value, buffer, (nuint)buffer.Length, out _);
        return Encoding.UTF8.GetString(buffer[..^1]);
    }
    else
    {
        byte[] buffer = ArrayPool<byte>.Shared.Rent((int)byteCount + 1);
        try
        {
            napi_get_value_string_utf8(env, value, buffer, (nuint)buffer.Length, out _);
            return Encoding.UTF8.GetString(buffer, 0, (int)byteCount);
        }
        finally
        {
            ArrayPool<byte>.Shared.Return(buffer);
        }
    }
}

Implementazione di una funzione reale: lettura dal Registry

L’esempio concreto mostrato dal team di Microsoft è un lettore del Windows Registry, che sostituisce il precedente addon C++:

private static nint ReadStringValue(nint env, nint info)
{
    try
    {
        var keyPath = GetStringArg(env, info, 0);
        var valueName = GetStringArg(env, info, 1);
        
        using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);
        
        return key?.GetValue(valueName) is string value
            ? CreateString(env, value)
            : GetUndefined(env);
    }
    catch (Exception ex)
    {
        // CRITICO: le eccezioni non gestite in [UnmanagedCallersOnly] crashano il processo
        ThrowError(env, $"Registry read failed: {ex.Message}");
        return 0;
    }
}

Integrazione con TypeScript

Dopo dotnet publish, il file prodotto viene rinominato con estensione .node (convenzione Node.js) e caricato normalmente da TypeScript:

interface RegistryAddon {
    readStringValue(keyPath: string, valueName: string): string | undefined;
}

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;

const sdkPath = registry.readStringValue(
    'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
    'InstallLocation'
);
console.log(`SDK installato in: ${sdkPath}`);

Limiti e considerazioni

Questa tecnica ha un limite importante: Native AOT non supporta la cross-compilazione. Per ogni piattaforma target (Windows x64, Linux x64, macOS ARM64…) è necessario un ambiente di build separato. In pratica, questo si risolve con pipeline CI che eseguono la build su runner del sistema operativo corrispondente.

Esiste anche un’alternativa di più alto livello, node-api-dotnet, che astrae molti dei dettagli mostrati qui e supporta scenari più complessi come l’esposizione di interi namespace .NET a JavaScript. L’approccio “thin wrapper” descritto in questo articolo è preferibile quando si vuole controllo totale e dipendenze minime.

Conclusioni

L’integrazione tra .NET Native AOT e N-API apre uno scenario interessante per i team che già lavorano con C# e devono interfacciarsi con l’ecosistema Node.js. Eliminare Python e node-gyp dal setup semplifica notevolmente l’ambiente di sviluppo e unifica le competenze necessarie intorno a un unico SDK.

Il risultato è codice nativo con prestazioni paragonabili al C++, scritto con la produttività e la type safety di C# moderno, deployabile su Windows, Linux e macOS.

Fonte: Writing Node.js addons with .NET Native AOT — Microsoft .NET Blog, Drew Noakes

Xiaomi sta preparando una svolta importante per la sua serie Note di fascia media. Il Redmi Note 17 Pro Max 5G, atteso per giugno-luglio 2026, punta su scelte tecniche inedite per il segmento: un cambio di chip inaspettato, un comparto fotografico ridisegnato e una batteria da numeri quasi incredibili.

Da Snapdragon a Dimensity: una scelta strategica

La novità più significativa è il passaggio da Qualcomm a MediaTek. I modelli precedenti della serie Note Pro si affidavano spesso ai chip Snapdragon, ma il Note 17 Pro Max adotterà il Dimensity 7500. Una scelta che risponde a logiche di costo e competitività sul mercato mid-range, dove la pressione sui prezzi è altissima. Le prestazioni del Dimensity 7500 sono comunque adeguate per la fascia di riferimento.

Fotocamera semplificata ma più efficace

Xiaomi ha scelto di abbandonare il setup a tripla fotocamera in favore di un sistema duale. Il sensore principale da 200 MP sarà affiancato da una fotocamera ultra-grandangolare, eliminando le fotocamere macro spesso considerate di puro riempimento. Un approccio che privilegia la qualità pratica rispetto al numero di obiettivi. Il sensore frontale sarà da 32 MP, più che sufficiente per foto e videochiamate.

Batteria da 10.100 mAh: numeri da record

Il dato che fa più scalpore è quello della batteria. La variante per il mercato cinese monterà un accumulatore da 10.100 mAh, un valore mai visto su uno smartphone mainstream. La versione globale scenderà a circa 9.200 mAh per rispettare le normative europee, ma resta comunque ai vertici assoluti della categoria. Entrambe le versioni supporteranno la ricarica rapida a 100W. Un’autonomia potenzialmente di due giorni pieni, che potrebbe diventare il punto di forza più convincente per la sua commercializzazione in Europa.

OPPO ha presentato ufficialmente due nuovi tablet che puntano a coprire segmenti di mercato diversi: il Pad 5 Pro, un top di gamma dalle specifiche impressionanti, e il Pad Mini, un modello compatto ma tutt’altro che rinunciatario. Entrambi saranno disponibili in Cina a partire dal 24 aprile 2026.

OPPO Pad 5 Pro: potenza e schermo enorme

Il Pad 5 Pro si posiziona come il dispositivo di punta della gamma tablet di OPPO. Il cuore è lo Snapdragon 8 Elite Gen 5, affiancato da fino a 16 GB di RAM LPDDR5X e 512 GB di storage UFS 4.1. Il display LCD da 13,2 pollici offre una risoluzione di 3392×2400 con refresh rate fino a 144 Hz e luminosità di picco a 1000 nit, con supporto a Dolby Vision e HDR Vivid. La batteria è da 13.380 mAh con ricarica rapida a 67W, e il sistema audio conta ben 8 altoparlanti. Non manca il supporto per stilo e tastiera opzionali, che lo rendono adatto anche al lavoro e alla creatività.

OPPO Pad Mini: compatto ma con schermo AMOLED

Il Pad Mini punta invece sulla portabilità senza rinunciare alle prestazioni. Il display AMOLED da 8,8 pollici con risoluzione 2520×1680 e refresh rate fino a 144 Hz è il punto di forza della scheda tecnica. Il processore è lo Snapdragon 8 Gen 5, con fino a 12 GB di RAM e 512 GB di storage. La batteria da 8.000 mAh supporta la ricarica rapida a 67W. Un equilibrio ben riuscito tra dimensioni ridotte e specifiche di fascia alta.

Prezzi e disponibilità

In Cina, il Pad 5 Pro parte da circa 99.000 yen equivalenti fino a 126.000, mentre il Pad Mini si posiziona tra 85.000 e 103.000 yen equivalenti. Al momento non ci sono conferme su una disponibilità per il mercato europeo, ma OPPO ha spesso portato i propri tablet anche fuori dalla Cina con qualche mese di ritardo.

OPPO ha avviato il rilascio del suo aggiornamento mensile per ColorOS 16, l’interfaccia basata su Android sviluppata dal produttore cinese. L’aggiornamento di aprile 2026 è in distribuzione graduale in India e porta con sé alcune novità interessanti, concentrate soprattutto sull’app Foto.

Watermark UEFA Champions League nell’app Foto

La novità più curiosa di questo aggiornamento è l’aggiunta di filigrane dedicate alla UEFA Champions League direttamente nell’editor fotografico. Gli utenti potranno sovrapporre i loghi della competizione alle proprie immagini, ideale per chi vuole personalizzare le foto scattate durante le partite o condividere contenuti a tema calcistico sui social. Una funzione stagionale, ma sicuramente apprezzata dagli appassionati di calcio.

Velocità di riproduzione video regolabile a 4 livelli

L’altra aggiunta degna di nota riguarda la riproduzione video: nell’app Foto è ora possibile modificare la velocità di playback tra 0,5x, 1x, 1,5x e 2x direttamente dall’interfaccia nativa, senza dover ricorrere ad app di terze parti. Una comodità soprattutto per chi vuole rivedere al rallentatore momenti importanti o scorrere rapidamente clip più lunghe.

Dispositivi compatibili e tempistiche

L’aggiornamento è partito l’8 aprile e sarà disponibile per tutti i dispositivi supportati entro il 30 aprile 2026. I modelli inclusi in questa prima tornata sono OPPO Find X9, Find X9 Pro, Find X8, Find X8 Pro, Reno15 Pro 5G, Reno15 5G, Reno14 Pro 5G e Reno14 5G. Chi possiede uno di questi smartphone può verificare manualmente la disponibilità dell’aggiornamento dal menu Impostazioni → Aggiornamento software.

Xiaomi amplia la sua gamma entry-level con due nuovi smartphone economici: Redmi A7 e Redmi A7 Pro 4G. Presentati ufficialmente per il mercato indiano, i due dispositivi puntano tutto sul rapporto qualità-prezzo, offrendo caratteristiche che vanno ben oltre le aspettative della loro fascia di prezzo.

Display ampio e fluido a 120Hz

Entrambi i modelli si distinguono per display di grandi dimensioni con refresh rate a 120Hz, una specifica che si trova di rado in questa fascia di prezzo. Il Redmi A7 monta un pannello LCD da 6,88 pollici, mentre l’A7 Pro 4G arriva a 6,9 pollici. Il touch sampling rate è di 240Hz su entrambi, garantendo una risposta rapida al tocco. La risoluzione si ferma all’HD+, ma per un uso quotidiano il compromesso è accettabile.

Processore Unisoc e fotocamere essenziali

Sotto la scocca troviamo il chip Unisoc T7250, con fino a 4 GB di RAM e 64 GB di storage espandibile via microSD. Il comparto fotografico è semplice ma funzionale: 13 MP posteriore e 8 MP frontale. La differenza principale tra i due modelli si trova nel software: il Redmi A7 gira su HyperOS 2 basato su Android 15, mentre l’A7 Pro 4G porta già HyperOS 3 con Android 16. Quest’ultimo offre anche un supporto aggiornamenti più lungo: 4 anni di OS e 6 di patch di sicurezza contro i 2+4 del modello base.

Batteria generosa e ricarica inversa

Sul fronte dell’autonomia, il Redmi A7 monta una batteria da 5.200 mAh, mentre il Pro raggiunge i 6.300 mAh. Entrambi supportano la ricarica a 15W e — sorprendentemente per questa fascia — anche la ricarica inversa cablata a 7,5W. Non mancano il jack audio da 3,5mm, il lettore di impronte laterale, la certificazione IP52 e il dual SIM. Il prezzo di partenza è di circa 10-12 euro equivalenti sul mercato indiano, con disponibilità dal 24 aprile.

L’attesa per il prossimo flagship di Sony si fa sempre più breve. Xperia 1 VIII, il nuovo top di gamma del produttore giapponese, non è ancora stato annunciato ufficialmente, ma il suo design sembra ormai un capitolo chiuso: una cover a libro dedicata al dispositivo è comparsa su Rakuten, uno dei principali marketplace giapponesi, rivelando importanti dettagli sul look del futuro smartphone.

Un modulo fotocamera completamente rinnovato

La notizia più rilevante riguarda la fotocamera posteriore. Le immagini della cover mostrano chiaramente un modulo di forma quadrata, una rottura netta con il design verticale allungato che ha contraddistinto i precedenti modelli della serie Xperia 1. Questa evoluzione era già stata anticipata da leak apparsi su Weibo e Facebook nelle scorse settimane, ma la presenza di un accessorio ufficiale in vendita rafforza notevolmente la credibilità di queste informazioni.

Accessori in vendita prima ancora dell’annuncio

Il fatto che una cover dedicata a Xperia 1 VIII sia già disponibile all’acquisto è un segnale importante. I produttori di accessori ricevono solitamente i dati CAD ufficiali del dispositivo con qualche settimana di anticipo rispetto all’annuncio, il che suggerisce che Sony sia già in fase avanzata di preparazione per il lancio. Si tratta di immagini non ufficiali basate sui dati di progetto, ma la corrispondenza con i leak precedenti rende il tutto molto convincente.

Annuncio atteso entro poche settimane

Seguendo il calendario delle edizioni precedenti, Xperia 1 VIII dovrebbe essere annunciato ufficialmente entro poche settimane, con una commercializzazione prevista tra fine maggio e inizio giugno 2026. Il cambiamento nel design della fotocamera potrebbe segnare un punto di svolta per la serie, avvicinandola visivamente alle scelte estetiche di altri produttori che hanno adottato moduli quadrati o rettangolari di grandi dimensioni. L’attesa per la presentazione ufficiale è dunque alta.

Quando all’inizio dello scorso marzo abbiamo pubblicato l’articolo “Il futuro di Debian secondo il Project Leader: più diversità, grazie ai collaboratori e utilizzo strumentale dell’AI“, avevamo riportato la menzione che Andreas Tille, all’epoca DPL (Debian Project Leader), aveva fatto a proposito dell’importanza di candidarsi per questo ruolo. Tille, pur ri...

🔗 Leggi il post completo

Il 7 aprile 2026, sei agenzie federali statunitensi — tra cui CISA, FBI e NSA — hanno pubblicato l’advisory congiunto AA26-097A, confermando che CyberAv3ngers, gruppo di cyberoffensiva direttamente controllato dall’IRGC-CEC (Islamic Revolutionary Guard Corps Cyber-Electronic Command) iraniano, ha condotto attacchi contro infrastrutture critiche americane sfruttando una vulnerabilità critica nei Programmable Logic Controller di Rockwell Automation. L’aspetto più preoccupante: per questa vulnerabilità non esiste alcuna patch del vendor.

Il gruppo: CyberAv3ngers e la struttura del comando IRGC

CyberAv3ngers è un threat group state-directed attivo almeno dal 2020, tracciato dalla comunità di threat intelligence con molteplici denominazioni: Storm-0784 (Microsoft), Bauxite (Dragos), Hydro Kitten, UNC5691 (Mandiant) e classificato da MITRE ATT&CK come G1027. Il gruppo opera come persona ufficiale dell’IRGC-CEC, distinguendosi per la focalizzazione sulle Operational Technology (OT) e i sistemi di controllo industriale (ICS), un dominio in cui pochi gruppi APT hanno sviluppato capacità analoghe.

La traiettoria evolutiva del gruppo è significativa: da attacchi opportunistici con credenziali di default su PLC Unitronics di fabbricazione israeliana nel 2023, alla distribuzione della piattaforma malware ICS custom IOCONTROL nel 2024, fino alla campagna 2026 contro i controller Rockwell Automation, che rappresenta un salto qualitativo nell’ambito delle capacità offensive ICS.

Il contesto geopolitico: rappresaglia cyber dopo gli attacchi del febbraio 2026

La campagna si inserisce in un contesto geopolitico estremamente teso. Il 28 febbraio 2026, USA e Israele hanno condotto un’operazione militare congiunta contro obiettivi iraniani, innescando una campagna di rappresaglia cyber multi-vettore che Unit 42 di Palo Alto Networks ha tracciato come cluster CL-STA-1128. In questo contesto, CyberAv3ngers ha intensificato le operazioni contro infrastrutture critiche americane, spostando il focus dai precedenti target israeliani verso obiettivi statunitensi.

CVE-2021-22681: la vulnerabilità senza patch al centro degli attacchi

Il vettore tecnico primario della campagna è CVE-2021-22681, una vulnerabilità di authentication bypass con CVSS score 9.8 che affligge i controller Logix di Rockwell Automation. La vulnerabilità permette a un attaccante di bypassare l’autenticazione e ottenere accesso ai PLC senza credenziali valide. Il problema strutturale: Rockwell Automation non ha rilasciato una patch, indicando invece misure di difesa in profondità come unica mitigazione disponibile.

I prodotti vulnerabili includono un ampio portfolio:

• RSLogix 5000 (versioni 16-20)
• Studio 5000 Logix Designer (versione 21 e successive)
• Famiglie di controller: CompactLogix, ControlLogix, GuardLogix, DriveLogix, SoftLogix

Secondo la scansione Cortex Xpanse di Palo Alto, risultano esposti su internet globalmente 5.600 indirizzi IP con servizi Rockwell Automation o Allen-Bradley SCADA, inclusi FactoryTalk e vari PLC — una superficie di attacco di proporzioni allarmanti.

Le TTPs operative: preparazione con FactoryTalk su VPS

L’analisi di Unit 42 rivela che gli attaccanti hanno adottato un approccio metodico nella preparazione. Con moderata confidenza, i ricercatori ritengono che CL-STA-1128 abbia installato il software FactoryTalk di Rockwell Automation su infrastruttura VPS per abilitare le proprie attività di exploitation, sviluppando internamente la capacità di interagire con il protocollo CIP (Common Industrial Protocol) prima di colpire i target reali. La mappatura delle porte utilizzate dai dispositivi esposti ha permesso al gruppo di identificare i target mediante pattern statici caratteristici dei prodotti Rockwell.

I settori colpiti confermati dall’advisory federale comprendono Water and Wastewater Systems (WWS), Energy e Government Services and Facilities. L’advisory CISA AA26-097A, primo caso in cui sei agenzie federali attribuiscono congiuntamente un’operazione all’IRGC, conferma interruzioni operative e perdite economiche in organizzazioni multiple.

Escalation della minaccia: dall’hacktivism all’OT warfare

La progressione di CyberAv3ngers illustra una tendenza preoccupante nel panorama delle minacce state-sponsored: la convergenza tra capacità IT e OT in un unico gruppo APT. Nelle prime operazioni del 2023, il gruppo si limitò a modificare i display HMI dei Unitronics PLC presso impianti idrici israeliani e americani, un’azione prevalentemente dimostrativa. Con IOCONTROL nel 2024, il gruppo ha sviluppato malware custom per dispositivi IoT e OT. La campagna del 2026, che sfrutta una vulnerabilità critica senza patch in uno dei vendor di automazione industriale più diffusi al mondo, rappresenta una capacità offensiva significativamente più matura.

Mitigazioni: nessuna patch disponibile, solo difesa in profondità

In assenza di una patch per CVE-2021-22681, le organizzazioni che utilizzano controller Rockwell Automation devono implementare le seguenti misure di difesa in profondità raccomandate dall’advisory federale:

• Segmentazione di rete: isolare i PLC e i sistemi OT in zone di rete separate, con firewall tra IT e OT, eliminando qualsiasi esposizione diretta a internet
• Isolamento delle engineering workstation: le workstation che comunicano con i PLC devono essere dedicate e segregate dalla rete corporate generale
• Abilitazione di CIP Security: configurare il protocollo CIP Security per autenticazione e cifratura delle comunicazioni tra EWS e PLC dove supportato
• Physical mode switch: impostare i PLC in modalità fisica protetta dove applicabile, impedendo modifiche al firmware via software
• Monitoraggio anomalie CIP-IP: deployare soluzioni di monitoraggio OT (es. Dragos, Claroty, Nozomi) in grado di rilevare download anomali e cambi di modalità sui PLC tramite protocollo CIP
• Rimozione dell’esposizione internet: verificare con Shodan o Censys la presenza di dispositivi Rockwell/Allen-Bradley esposti e rimuoverli immediatamente

Implicazioni strategiche

La campagna di CyberAv3ngers evidenzia la crescente militarizzazione del cyberspazio nelle operazioni di rappresaglia tra stati. La scelta di colpire infrastrutture idriche, energetiche e governative — settori con potenziale impatto diretto sulla popolazione civile — segnala una volontà di massimizzare l’effetto psicologico e operativo degli attacchi. Il fatto che Rockwell Automation non abbia rilasciato una patch per CVE-2021-22681 pone interrogativi seri sul modello di sicurezza dei vendor OT: in un settore dove i device lifecycle si misurano in decenni, l’assenza di aggiornamenti di sicurezza per vulnerabilità critiche è un rischio sistemico che va affrontato con urgenza a livello regolatorio.

Con 5.600 dispositivi Rockwell Automation esposti su internet a livello globale e nessuna patch in vista, la superficie di attacco rimane aperta. Le organizzazioni che operano infrastrutture critiche devono trattare l’advisory AA26-097A come una priorità assoluta e avviare immediatamente una revisione dell’esposizione OT.

Motorola sta cambiando passo sul fronte degli aggiornamenti software. L’azienda ha ampliato il programma beta di Android 17 includendo alcuni dei suoi modelli di punta, tra cui smartphone pieghevoli e flagship, con distribuzione in più paesi. Un segnale che la storica lentezza di Motorola negli aggiornamenti OS potrebbe appartenersi al passato.

I modelli inclusi nel beta

Il programma beta di Android 17 è ora disponibile per Motorola Razr Plus 2025, Motorola Razr Plus 2024 e Motorola Edge 50 Ultra. Si tratta di una selezione significativa che copre sia la gamma foldable che quella flagship, dimostrando un approccio più strutturato alla gestione degli aggiornamenti.

La partecipazione al beta non è aperta a tutti: richiede la registrazione su una community dedicata, la fornitura dell’IMEI e l’iscrizione a una rete di feedback. L’accesso viene approvato individualmente, quindi non è garantito per tutti i richiedenti.

Distribuzione globale in più aree

Il beta è attivo in USA, India, Europa e America Latina, coprendo un’area geografica ampia rispetto ai programmi di test solitamente più circoscritti. Anche questo è un segnale di una struttura di sviluppo software più matura rispetto al passato.

Motorola si riscatta sugli aggiornamenti

Per anni Motorola è stata criticata per i tempi lunghi e la scarsa continuità negli aggiornamenti Android, con alcuni modelli che ricevevano solo un major update. Nell’ultimo periodo l’azienda ha esteso le finestre di supporto e accelerato le distribuzioni. La partecipazione anticipata al beta di Android 17, ancora in sviluppo, è la conferma più concreta di questo cambio di rotta.

Il futuro top di gamma Sony si mostra indirettamente attraverso le cover. Alcune immagini che mostrano una custodia trasparente progettata per lo Xperia 1 VIII montata su modelli precedenti della serie permettono di dedurre informazioni importanti sul formato del display, che manterrebbe il rapporto d’aspetto 19.5:9 già visto sugli ultimi modelli.

Il metodo del leak: le cover sui vecchi modelli

La tecnica è già nota nella comunità degli appassionati: quando una cover per un modello futuro viene prodotta in anticipo, montarla su dispositivi esistenti permette di confrontare i punti di riferimento fisici, come i fori per la fotocamera e le aperture per i pulsanti, e ricavare indicazioni sulle dimensioni e sul layout del nuovo dispositivo.

Nel caso dello Xperia 1 VIII, le immagini suggeriscono che il form factor allungato tipico della serie venga mantenuto. Il rapporto 19.5:9 sarebbe confermato, in continuità con i modelli VI e VII della serie, contrariamente all’ipotesi che Sony potesse tornare al classico 21:9 delle generazioni precedenti.

Xperia 1 VIII: cosa sappiamo finora

Oltre al formato dello schermo, i dettagli ufficiali sullo Xperia 1 VIII rimangono ancora scarsi. Sony è tradizionalmente restia a rivelare informazioni in anticipo e presenta i suoi flagship quasi sempre nel corso della prima metà dell’anno. Gli appassionati del brand attendono di scoprire se la nuova generazione porterà novità importanti sul fronte fotografico, da sempre il punto di forza della serie Xperia 1.

Il fenomeno del Green Line torna a colpire Samsung. Questa volta tocca al Galaxy S26 Ultra, il top di gamma più recente della casa coreana, che secondo le prime segnalazioni degli utenti starebbe manifestando la comparsa di linee verticali verdi sullo schermo. Un problema già visto su molti modelli precedenti e che torna ciclicamente a creare preoccupazioni.

Una storia che si ripete

Il problema del Green Line su Samsung non è una novità: nel corso degli anni è stato segnalato su Galaxy S21 Ultra, S21 FE, S22 Ultra, S23 e Z Fold 4, tra gli altri. La caratteristica comune è la comparsa improvvisa di sottili righe verticali sullo schermo senza una causa esterna apparente — nessuna caduta, nessun impatto fisico — il che ha sempre alimentato il dibattito sulla natura del difetto, se hardware o software.

Il Galaxy S26 Ultra non fa eccezione

Le prime segnalazioni sul Galaxy S26 Ultra mostrano casi simili a quelli del passato, con alcuni utenti che riportano la comparsa di una linea verde spessa e persistente sul display. Trattandosi di un telefono di fascia altissima dal costo superiore ai 1000 euro, ritrovarsi con un display difettoso è particolarmente frustrante.

Cosa fare se si verifica il problema

Chi si trova in questa situazione dovrebbe contattare il supporto Samsung il prima possibile, soprattutto se il dispositivo è ancora in garanzia. In passato Samsung ha sostituito i display difettosi in alcuni mercati, ma le politiche variano da paese a paese. È consigliabile documentare il problema con foto e video prima di contattare l’assistenza, per avere prove concrete del difetto.

Il prossimo anno potrebbe portare uno Xiaomi ancora più ambizioso. Le prime indiscrezioni sullo Xiaomi 18 Pro Max delineano un flagship da record: display piatto da 6,9 pollici, il futuro Snapdragon 8 Elite Gen 6 Pro, una batteria da 8500 mAh e una configurazione fotografica con sensori da 200 megapixel. Tutto basato su HyperOS 4 con Android 17.

Snapdragon di nuova generazione al debutto

Secondo il leaker Digital Chat Station, tra i più affidabili nel settore, è in corso il testing di un dispositivo con chip Qualcomm SM8975, che nella versione commerciale diventerà probabilmente lo Snapdragon 8 Elite Gen 6 Pro. Le caratteristiche tecniche individuate puntano allo Xiaomi 18 Pro Max come candidato principale a ospitare questo processore.

200 megapixel su due ottiche, audio e haptic migliorati

Sul fronte fotografico, si parla di un sensore principale da 200 megapixel (1/1.28″) e un teleobiettivo periscopico anch’esso da 200 megapixel, una configurazione che punterebbe alla massima qualità anche con lo zoom ottico. La fotocamera ultrawide sarebbe da 50 megapixel. Il comparto audio prevede speaker duali simmetrici, mentre il motore aptico lineare sull’asse X garantirebbe un feedback tattico più preciso.

Batteria da 8500 mAh e HyperOS 4

La batteria da 8500 mAh con ricarica rapida da 100W cablata e 50W wireless sarebbe il punto di maggiore discontinuità rispetto ai flagship precedenti. Il sistema operativo sarà HyperOS 4 basato su Android 17, con possibile display secondario AI sul retro come già visto su Xiaomi 15 Ultra. Il lancio è previsto per il 2026 inoltrato.

I prossimi occhiali smart di Samsung si avvicinano, almeno stando alle tracce trovate nel codice interno di One UI 8.5. L’icona di un dispositivo riconducibile agli smart glasses è stata individuata all’interno del SystemUI, confermando che lo sviluppo del progetto è in corso e probabilmente prossimo a una fase più concreta.

La scoperta nel codice di One UI 8.5

Il ritrovamento è opera di un noto leaker che ha analizzato le componenti interne dell’interfaccia Samsung. Nell’area riservata del SystemUI è emersa un’icona che raffigura quello che sembra un paio di occhiali smart, distinta da qualsiasi altro dispositivo già in commercio sotto il marchio Galaxy. Non si tratta di un design definitivo del prodotto, ma è un segnale chiaro che lo sviluppo ha raggiunto un punto avanzato.

Collaborazione con Google e i brand dell’eyewear

Samsung ha già confermato ufficialmente di lavorare a un dispositivo di questo tipo, e di farlo in collaborazione con Google. Il progetto prevede anche partnership con marchi di occhiali come Warby Parker e Gentle Monster, con l’obiettivo di creare un dispositivo che sia accettabile come accessorio quotidiano, non solo come gadget tecnologico.

La piattaforma software alla base sarà Android XR, lo stesso sistema operativo che alimenta il visore Galaxy XR già presentato da Samsung. Gli smart glasses rappresenterebbero però un approccio molto più leggero e portabile.

Un mercato in fermento

Il settore degli occhiali smart sta attraversando un momento di rinascita: i Ray-Ban Meta hanno dimostrato che un approccio più discreto e fashion può funzionare commercialmente. Con Samsung e Google che lavorano insieme, e Apple che si dice stia sviluppando qualcosa di simile, il segmento degli eyewear smart potrebbe diventare una delle grandi battaglie tecnologiche del biennio 2026-2027.

Un cambiamento epocale si avvicina per il mondo degli smartphone. La normativa europea che entrerà in vigore nel febbraio 2027 imporrà ai produttori di progettare dispositivi la cui batteria possa essere sostituita dall’utente finale con semplici strumenti domestici. Una rivoluzione che potrebbe ridisegnare l’intero settore.

Cosa prevede il nuovo regolamento UE

La normativa dell’Unione Europea non chiede un ritorno alle batterie completamente rimovibili degli anni ’90, ma qualcosa di più equilibrato: gli smartphone in vendita dopo il febbraio 2027 dovranno permettere la sostituzione della batteria usando strumenti di base come un cacciavite, senza necessità di assistenza tecnica specializzata.

Non è una misura isolata: già a partire da giugno 2025 era entrata in vigore la prima fase della normativa, che obbligava i produttori a garantire aggiornamenti software e fornitura di pezzi di ricambio per almeno 10 anni dalla commercializzazione del dispositivo.

Standard di durata per le batterie

La normativa fissa anche requisiti minimi per la longevità delle batterie: dopo almeno 800 cicli di ricarica, la cella dovrà conservare almeno l’80% della capacità originale. I produttori saranno inoltre tenuti a rendere disponibili manuali di riparazione e a non ostacolarne l’accesso da parte di officine indipendenti.

Impatto globale, non solo europeo

Sebbene si tratti di una normativa europea, le ricadute potrebbero essere globali. Produrre versioni diverse dello stesso smartphone per mercati distinti non è conveniente per i produttori, quindi è probabile che le specifiche pensate per l’UE vengano adottate anche nei modelli destinati ad altri mercati, inclusa l’Italia e il resto del mondo. Uno smartphone più riparabile e durevole potrebbe diventare lo standard universale entro il 2027.

Con C# 12, Microsoft ha introdotto i primary constructors per tutte le classi e le struct — non solo per i record come in precedenza. Per chi lavora quotidianamente con ASP.NET Core e il pattern di dependency injection, questa feature merita attenzione: riduce il boilerplate in modo significativo, ma nasconde un'insidia che è bene conoscere prima di adottarla sistematicamente.

Il problema: il boilerplate del costruttore classico

Chi ha scritto servizi ASP.NET Core sa bene come appare il costruttore tradizionale con dependency injection:

public class OrderService
{
    private readonly IOrderRepository _orderRepository;
    private readonly ILogger<OrderService> _logger;
    private readonly IEventBus _eventBus;
    private readonly IValidator<Order> _validator;

    public OrderService(
        IOrderRepository orderRepository,
        ILogger<OrderService> logger,
        IEventBus eventBus,
        IValidator<Order> validator)
    {
        _orderRepository = orderRepository;
        _logger = logger;
        _eventBus = eventBus;
        _validator = validator;
    }
}

La soluzione con primary constructors

Con i primary constructors di C# 12, lo stesso servizio si scrive così:

public class OrderService(
    IOrderRepository orderRepository,
    ILogger<OrderService> logger,
    IEventBus eventBus,
    IValidator<Order> validator)
{
    public async Task<Order?> GetOrderAsync(Guid id)
    {
        logger.LogInformation("Fetching order {OrderId}", id);
        return await orderRepository.GetByIdAsync(id);
    }

    public async Task PlaceOrderAsync(Order order)
    {
        await validator.ValidateAndThrowAsync(order);
        await orderRepository.SaveAsync(order);
        await eventBus.PublishAsync(new OrderPlacedEvent(order.Id));
    }
}

L'insidia della mutabilità: perché Milan Jovanović era inizialmente scettico

Il motivo di resistenza di molti sviluppatori esperti è legittimo: i parametri del primary constructor non sono campi readonly. Il compilatore non impedisce la riassegnazione accidentale:

public class OrderService(IOrderRepository orderRepository)
{
    public void SomeMethod()
    {
        orderRepository = null!;  // Compila senza warning
    }
}

Mitigazione: assegnazione esplicita a readonly field

Quando la garanzia di immutabilità è critica, si può assegnare esplicitamente il parametro a un campo readonly:

public class CriticalService(IRepository repository)
{
    private readonly IRepository _repository = repository;

    // Da qui in poi si usa _repository, mai repository direttamente
}

Quando usare i primary constructors

La valutazione pragmatica è che i primary constructors offrono il massimo vantaggio nelle classi di servizio DI tipiche di ASP.NET Core, dove i parametri vengono usati ma raramente riassegnati. In questi scenari, il rischio di mutabilità accidentale è basso e i benefici di leggibilità sono immediati.

Vale la pena usarli anche per entity e value object dove i parametri di costruzione diventano proprietà read-only:

public class Order(Guid customerId, Money total)
{
    public Guid Id { get; } = Guid.NewGuid();
    public Guid CustomerId { get; } = customerId;
    public Money Total { get; } = total;
    public DateTime CreatedAt { get; } = DateTime.UtcNow;
}

Quando evitarli

Tre scenari in cui i primary constructors non sono la scelta giusta:

• Logica di validazione nel costruttore: se il costruttore deve eseguire guard clause o validazioni prima dell'assegnazione, il corpo esplicito del costruttore tradizionale è necessario.
• Multiple signature di costruttore: i primary constructors supportano una sola firma. Con overload multipli (es. per serializzazione), la sintassi tradizionale è l'unica opzione.
• Cinque o più dipendenze: se una classe richiede molte dipendenze, il problema non è la sintassi del costruttore ma il design della classe. Il segnale che suggerisce un refactoring verso interfacce più coese o il pattern Facade.

Conclusione: adottarli con consapevolezza

I primary constructors di C# 12 non sono una rivoluzione, ma un'evoluzione pragmatica del linguaggio. Per la maggior parte delle classi di servizio in ASP.NET Core, il tradeoff è favorevole: meno boilerplate, codice più leggibile, rischio di mutabilità basso nel contesto DI. L'importante è conoscere il comportamento del compilatore e scegliere consapevolmente quando la garanzia di readonly è effettivamente necessaria.

Come sempre con le feature di C#, il consiglio è adottarle dove migliorano la leggibilità del codice reale, non per seguire una moda sintattica.

Fonte originale: Why I Switched to Primary Constructors for DI in C# di Milan Jovanović.

OPPO svela le specifiche ufficiali del Find X9 Ultra prima del lancio. Il nuovo flagship dell’azienda cinese punta in alto su tutti i fronti: processore di ultima generazione, display da competizione e una batteria che rompe i confini della categoria. E per l’Italia, la distribuzione è già prevista per l’estate.

Snapdragon 8 Elite Gen 5 e display 2K a 144 Hz

La scheda tecnica è di tutto rispetto: a bordo del Find X9 Ultra troviamo il nuovo Snapdragon 8 Elite Gen 5 di Qualcomm, accoppiato alle ottimizzazioni software proprietarie di OPPO per massimizzare efficienza energetica e prestazioni. Il display è un pannello 2K con refresh rate fino a 144 Hz, luminosità minima da 1 nit per la visione notturna, e correzione gamma per pixel per una fedeltà cromatica elevata.

Batteria da 7050 mAh con ricarica rapida e wireless

La batteria in silicio-carbonio da 7050 mAh è uno dei punti di forza più significativi: per un flagship, è una capacità sorprendente. La ricarica cablata arriva a 100W, mentre quella wireless si ferma a 50W: in entrambi i casi, i tempi di attesa sono ridotti al minimo nonostante la grande capacità.

Resistenza all’acqua e connettività satellitare

Il Find X9 Ultra punta anche sulla robustezza, con una certificazione IP di fascia alta, e integra la connettività satellitare, una funzione sempre più comune tra i top di gamma 2026. Per il mercato italiano, OPPO ha già anticipato una distribuzione prevista per l’estate 2026, confermando l’interesse del brand per il nostro mercato.

Samsung potrebbe finalmente fare il grande passo verso le batterie in silicio-carbonio con la gamma Galaxy S27. Una tecnologia che l’azienda studia da anni e che potrebbe portare a un aumento significativo della capacità energetica, superando per la prima volta in modo deciso la soglia dei 5000 mAh nei flagship della serie S.

Cos’è la batteria in silicio-carbonio

La tecnologia silicio-carbonio sostituisce il grafite tradizionale nell’anodo della batteria con una miscela di silicio e carbonio, capace di immagazzinare una quantità molto maggiore di ioni di litio. Il risultato è una densità energetica superiore che consente di aumentare la capacità senza ingrandire fisicamente la cella, o di ridurre le dimensioni mantenendo la stessa autonomia.

Il nodo della durata: ora vicino alla soluzione

Il principale ostacolo all’adozione di questa tecnologia è sempre stato il degrado accelerato dopo i cicli di ricarica. Samsung ha ritenuto per anni che la tecnologia non fosse matura abbastanza, mentre altri produttori come Xiaomi e OPPO l’avevano già adottata. Ora, grazie a miglioramenti nel separatore, nella struttura delle celle e nel software di gestione della batteria, l’obiettivo dei 1500 cicli di ricarica con degrado minimo sarebbe quasi raggiunto.

Galaxy S27 Ultra come primo modello candidato

Secondo le indiscrezioni, il Galaxy S27 Ultra sarà il primo della gamma a beneficiare della nuova tecnologia. Le stime parlano di capacità significativamente superiori agli attuali 5000 mAh, sebbene i test con configurazioni estreme da 12.000-18.000 mAh siano stati ridimensionati per garantire sicurezza e praticità. Il Galaxy S27 Ultra è atteso nella prima parte del 2027.

I Google Pixel 10 stanno facendo i conti con un nuovo problema: il GPS. Molti utenti segnalano comportamenti anomali del sistema di geolocalizzazione, con la posizione che tende a “saltare” in modo irregolare anziché aggiornarsi con fluidità. Un inconveniente che rischia di rendere inaffidabile l’uso del navigatore.

Cosa sta succedendo con il GPS

Il problema descritto dagli utenti è caratteristico: il punto sulla mappa non si sposta in modo continuo, ma compie salti bruschi da una posizione all’altra, con indicazioni sulla direzione e sulla velocità che non corrispondono alla realtà. Chi usa app di navigazione come Google Maps o Waze si trova di fronte a percorsi confusi e istruzioni errate.

L’aspetto più insidioso è che il GPS non smette del tutto di funzionare: chi non usa attivamente la navigazione potrebbe non accorgersi del problema, ma per chi guida o si sposta in zone poco conosciute l’impatto è concreto.

Android 16 potrebbe essere coinvolto

Le segnalazioni si concentrano sul Pixel 10, ma gli analisti non escludono che il problema possa avere origine software piuttosto che hardware. Android 16 ha introdotto alcune modifiche al sistema di gestione della posizione, e queste potrebbero aver introdotto regressioni non ancora risolte.

Se così fosse, la questione potrebbe non limitarsi ai Pixel 10 ma interessare potenzialmente altri dispositivi aggiornati ad Android 16. Un aggiornamento software potrebbe essere sufficiente a risolvere il tutto.

Google non ha ancora risposto ufficialmente

Al momento Google non ha rilasciato dichiarazioni ufficiali sul problema. La community degli utenti Pixel monitora la situazione con attenzione, sperando in una patch rapida. Trattandosi di una funzione fondamentale per l’uso quotidiano, una risposta tempestiva da parte di Google sarebbe auspicabile.

La nuova generazione di Motorola Razr non aspetterà fino a maggio. Un teaser ufficiale pubblicato dall’azienda sui social suggerisce che la presentazione avverrà il 29 aprile 2026, con settimane di anticipo rispetto alle previsioni. Il video anticipa anche un design coraggioso dominato dal colore viola.

Annuncio anticipato rispetto alle aspettative

L’indiscrezione sulla data del 29 aprile emerge da un teaser breve che Motorola ha diffuso sui suoi canali ufficiali. Fino a poco tempo fa, le voci davano per probabile un lancio a fine maggio: l’accelerazione del calendario sorprende, ma potrebbe essere una mossa strategica per posizionarsi sul mercato prima di altri competitor nel segmento dei foldable.

Il nome del modello non è ancora ufficiale, ma si prevede che la gamma includa almeno un modello standard e un Razr Ultra, ovvero il successore del top di gamma attuale.

Design viola e lavorazione trapuntata

Dal teaser video emerge chiaramente una colorazione viola intensa come scelta di punta, con una finitura che ricorda una texture trapuntata, un riferimento estetico già visto su alcune edizioni speciali precedenti. Anche mocha, nero e verde farebbero parte della palette disponibile.

Lo stile fashionista che da sempre contraddistingue i Razr sembra confermato anche per questa generazione, con un occhio di riguardo all’aspetto visivo come elemento differenziante rispetto ai foldable di Samsung.

Prezzi in aumento: fino a 1500 dollari per il top

La nota meno positiva riguarda il prezzo. Secondo le indiscrezioni, il modello Razr Ultra potrebbe partire da circa 1500 dollari, mentre il modello base si attesterebbe intorno agli 800 dollari. Cifre in aumento rispetto alla generazione precedente, probabilmente dovute al costo crescente dei componenti. Il rapporto qualità-prezzo sarà quindi sotto esame al momento della presentazione ufficiale, ormai prossima.

Google Foto introduce una nuova funzionalità di ritocco del volto basata sull’intelligenza artificiale. Lo strumento, ora disponibile in distribuzione ufficiale, permette di migliorare i ritratti con un semplice tocco sullo schermo, offrendo risultati naturali senza dover ricorrere ad applicazioni dedicate.

Cosa fa il nuovo strumento di ritocco

La nuova funzione si attiva toccando il volto di una persona all’interno di una foto. A quel punto compare un pannello con diverse opzioni di correzione, tra cui la levigatura della pelle, la riduzione di imperfezioni come brufoli o macchie, la luminosità degli occhi e lo sbiancamento dei denti. È anche possibile agire separatamente su sopracciglia e labbra.

Ogni parametro è accompagnato da un cursore per regolare l’intensità del ritocco, così da evitare risultati artefatti e mantenere un aspetto autentico. Google ha spiegato che l’obiettivo dello strumento non è trasformare il soggetto, ma “riflettere nella foto l’umore e l’impressione del momento”.

Una funzione in sviluppo da tempo

La novità non è arrivata senza preavviso: da tempo gli analisti del codice di Google Foto avevano individuato riferimenti a questa funzionalità all’interno dell’app, con voci come “riduzione delle occhiaie”, “whitening dei denti” e “correzione brufoli”. Ora la funzione è finalmente disponibile agli utenti reali.

Disponibilità e compatibilità

La distribuzione è progressiva e, come spesso accade con le novità di Google Foto, potrebbe non essere disponibile immediatamente per tutti. Il rollout dovrebbe estendersi nelle prossime settimane. La funzione è accessibile all’interno degli strumenti di modifica dell’app, senza richiedere abbonamenti aggiuntivi.

Nova Launcher, tra i launcher Android più popolari e longevi, si prepara a un’evoluzione significativa. Dall’analisi della versione beta 8.6.8 emergono i contorni di Nova AI, un assistente basato sull’intelligenza artificiale integrato direttamente nell’app, accompagnato da un piano in abbonamento chiamato Nova Plus.

Nova AI: un assistente chat nel launcher

Nova AI si presenta come un assistente conversazionale integrato nel launcher, accessibile senza uscire dalla schermata home. Gli utenti potranno porre domande e interagire con l’IA in stile chat, con la possibilità di visualizzare la cronologia delle conversazioni, eliminarla o condividerla tramite link.

Una caratteristica interessante è la presenza delle fonti citate nelle risposte dell’assistente, un elemento che aumenta la trasparenza dei risultati forniti. La funzione sembra voler competere con soluzioni già integrate a livello di sistema come Google Assistant e Gemini.

Nova Plus: il modello in abbonamento si avvicina

Insieme a Nova AI, il codice del beta rivela l’esistenza di Nova Plus, un piano a pagamento che probabilmente darà accesso alle funzionalità premium inclusa l’intelligenza artificiale. Questo segna una svolta nella strategia di Nova Launcher, che fino ad ora ha seguito il modello del pagamento unico per sbloccare le funzioni avanzate.

Un launcher che si trasforma

Nova Launcher è da anni una scelta di riferimento per gli utenti Android che vogliono personalizzare l’interfaccia del proprio smartphone. L’integrazione dell’AI rappresenta un cambio di passo notevole, trasformando quello che era fondamentalmente uno strumento di personalizzazione estetica in qualcosa di più simile a una piattaforma di produttività. Resta da vedere come reagirà la base di utenti consolidata, spesso legata al modello classico senza abbonamento.

POCO ha annunciato ufficialmente il nuovo M8s 5G, un dispositivo di fascia entry-level che punta a ridefinire gli standard della categoria. Con una batteria da 7000 mAh e un display da 6,9 pollici a 144 Hz, l’M8s 5G si presenta come un’opzione allettante per chi cerca autonomia e fluidità senza spendere una fortuna.

Batteria da 7000 mAh: autonomia da record per la fascia

Il punto di forza principale del POCO M8s 5G è senza dubbio la batteria da 7000 mAh, che secondo il produttore garantisce fino a due giorni di utilizzo anche con un uso intensivo. La cella è progettata per mantenere l’80% della capacità originale anche dopo 1600 cicli di ricarica, un dato che promette longevità nel tempo.

La ricarica rapida da 33W permette di ricaricare il dispositivo in tempi ragionevoli, e non manca la ricarica inversa via cavo da 18W, che consente di usare il telefono come un vero e proprio power bank per altri dispositivi.

Display da 6,9 pollici con 144 Hz

Lo schermo FHD+ da 6,9 pollici supporta un refresh rate massimo di 144 Hz, garantendo uno scorrimento fluido per giochi, social e navigazione. Il pannello include anche una tecnologia per il riconoscimento del tocco anche con le dita bagnate, una comodità apprezzabile nella vita di tutti i giorni.

Snapdragon 6s Gen 3 e connettività 5G

Sotto la scocca lavora il processore Snapdragon 6s Gen 3, una soluzione orientata all’efficienza piuttosto che alle prestazioni pure, adeguata per l’uso quotidiano. La connettività 5G è inclusa, così come NFC. Il POCO M8s 5G rappresenta un aggiornamento concreto per chi cerca un telefono affidabile con grande autonomia nella fascia economica del mercato Android.

Quando si utilizzano più formati di pacchetti software nelle distribuzioni GNU/Linux, può diventare complicato ricordare come è stata installata una determinata applicazione. Potrebbe provenire da APT (Advanced Package Tool), essere stata installata come Snap,...

🔗 Leggi il post completo

Si parla di:
Toggle

• Il profilo del gruppo: RaaS ad alta velocità
• La scoperta della botnet SystemBC
• La kill chain: da accesso iniziale a cifratura domain-wide in poche ore
• Evasione difensiva: preparazione metodica alla cifratura
• Schema crittografico ibrido: X25519 + XChaCha20
• Indicatori di compromissione (IoC)
• Raccomandazioni per i difensori

Un’indagine di Check Point Research ha portato alla luce l’infrastruttura operativa di The Gentlemen, uno dei gruppi ransomware-as-a-service (RaaS) a crescita più rapida del 2026. L’analisi forense di un singolo incidente ha disvelato una botnet SystemBC con oltre 1.570 host aziendali compromessi, un arsenale di post-exploitation maturo e un modello operativo che spiega la rapidità con cui il gruppo ha raggiunto 320 vittime rivendicate, 240 delle quali concentrate nei primi mesi di quest’anno.

Il profilo del gruppo: RaaS ad alta velocità

Emerso intorno alla metà del 2025, The Gentlemen si è rapidamente affermato come uno dei programmi RaaS più aggressivi nel panorama del cybercrime organizzato. Il modello economico è generoso per gli affiliati: 90% dei proventi ai partner, 10% agli operatori. Questo split ha attratto affiliati con elevate competenze tecnico-operative, capaci di orchestrare intrusioni complesse nelle reti enterprise. Il gruppo opera una piattaforma di doppia estorsione con leak site Tor e countdown di 7 giorni prima della pubblicazione dei dati esfiltrati. Le comunicazioni avvengono tramite Tox, Session e l’account X @TheGentlemen25. Tra le vittime documentate: Oltenia Energy Complex (Romania) e Adaptavist Group.

La scoperta della botnet SystemBC

L’elemento più allarmante emerso dall’analisi è la presenza di una botnet SystemBC con 1.570 host compromessi, prevalentemente in ambienti aziendali distribuiti tra Stati Uniti, Regno Unito, Germania, Australia e Romania. SystemBC è un malware proxy che stabilisce tunnel SOCKS5 all’interno della rete vittima, comunicando con il C2 tramite un protocollo custom cifrato RC4. La botnet non è di proprietà esclusiva di The Gentlemen: indica che gli affiliati si integrano in un ecosistema più ampio di tooling condiviso, amplificando l’impatto operativo ben oltre le vittime rivendicate pubblicamente. I settori più colpiti sono manifatturiero e tecnologico, con healthcare in crescita come terzo target.

La kill chain: da accesso iniziale a cifratura domain-wide in poche ore

Il processo di attacco documentato rivela una kill chain estremamente efficiente. Dopo l’accesso iniziale — vettore non ancora determinato nell’incidente analizzato — gli attaccanti procedono con la compromissione del Domain Controller tramite Mimikatz per credential harvesting, seguita dal deploy di Cobalt Strike via RPC per il controllo remoto. Una volta ottenuti i privilegi di Domain Admin, viene attivata la propagazione via Group Policy Objects (GPO) per una detonazione sincronizzata sull’intera rete.

Per il lateral movement, il gruppo implementa sei vettori simultanei: PsExec con credenziali esplicite, WMI tramite wmic /node: process call create, Scheduled Tasks remoti, Windows Services, PowerShell Remoting via WinRM e accesso alle SMB Admin Shares (ADMIN$ e C$\Temp). L’uso parallelo di tutti i vettori massimizza la velocità di propagazione e rende difficile il contenimento.

Evasione difensiva: preparazione metodica alla cifratura

Prima dell’avvio della cifratura, il ransomware esegue una sequenza di operazioni per neutralizzare le difese:

# Disabilita Windows Defender real-time
powershell -Command Set-MpPreference -DisableRealtimeMonitoring $true -Force

# Disabilita Windows Firewall
netsh advfirewall set allprofiles state off

# Elimina le Shadow Copy
vssadmin delete shadows /all /quiet

# Cancella i log di sistema
wevtutil cl System
wevtutil cl Application
wevtutil cl Security

Schema crittografico ibrido: X25519 + XChaCha20

Il payload Windows è scritto in Go, quello ESXi/Linux in C. Lo schema crittografico è progettato per massimizzare la velocità. Per ogni file viene generata una chiave privata effimera random a 32 byte; l’algoritmo X25519 (Curve25519) effettua lo scambio ECDH e i primi 24 byte del segreto condiviso diventano il nonce per XChaCha20. File inferiori a 1 MB vengono completamente cifrati; file più grandi subiscono cifratura parziale (1%, 3% o 9% del contenuto) per ottimizzare la velocità. Il footer apposto ai file è del tipo: --eph--[base64_key]--marker--GENTLEMEN.

La variante ESXi gestisce le VM tramite vim-cmd vmsvc/power.off e esxcli vm process kill --type=force, con persistenza tramite /etc/rc.local.d/local.sh e crontab @reboot, mascherandosi come /bin/.vmware-authd.

Indicatori di compromissione (IoC)

# Cobalt Strike C2
91.107.247[.]163

# SystemBC C2
45.86.230[.]112

# SystemBC SHA-256
992c951f4af57ca7cd8396f5ed69c2199fd6fd4ae5e93726da3e198e78bec0a5

# Leak site Tor
tezwsse5czllksjb7cwp65rvnk4oobmzti2znn42i43bjdfd2prqqkad.onion

# Contatto operatori
@TheGentlemen25 (X/Twitter)

Raccomandazioni per i difensori

Le priorità difensive si concentrano su tre fronti. Credential protection: implementare Windows Credential Guard, monitorare l’esecuzione di Mimikatz e lsass dumps, imporre MFA su tutti gli account privilegiati e in particolare su quelli con accesso al Domain Controller. GPO e lateral movement: allertare su modifiche non autorizzate ai Group Policy Objects, monitorare la creazione di scheduled task con contesto SYSTEM su host remoti, disabilitare SMB1 dove non strettamente necessario e bloccare PsExec non autorizzato. Detection comportamentale: correlare l’esecuzione parallela di PsExec, WMI e PowerShell Remoting su più host in breve tempo; monitorare la disabilitazione di Windows Defender e la cancellazione massiva di log come precursori di un evento ransomware. Check Point ha rilasciato una YARA rule specifica che rileva campioni compilati in Go tramite le stringhe caratteristiche del gruppo.

The Gentlemen rappresenta l’evoluzione moderna del RaaS: affiliati specializzati, infrastruttura condivisa con altri threat actor, velocità operativa che comprime la finestra di rilevamento a poche ore. La scoperta di 1.570 host aziendali compromessi nella botnet correlata suggerisce che l’impatto reale del gruppo superi significativamente le 320 vittime rivendicate pubblicamente — e che l’ecosistema criminale che supporta le sue operazioni sia molto più vasto di quanto finora documentato.