Aggiornamento. Questo articolo aggiorna quanto pubblicato il 29 settembre: Apple corregge una falla in CoreGraphics forse sfruttata contro persone mirate. Lì trovi le versioni corrette e il quadro generale; qui ci occupiamo di ciò che è cambiato dopo.

Lo sviluppo nuovo è tecnico e ha conseguenze pratiche: il 30 settembre 2026 i ricercatori di Calif hanno pubblicato un'analisi dettagliata e un proof-of-concept pubblico per la CVE-2026-86950, la falla di CoreGraphics che Apple ha corretto il 28 settembre e che, secondo la nota di sicurezza del produttore, potrebbe essere stata sfruttata in un attacco estremamente sofisticato contro individui specifici. La falla era stata segnalata da Meta Product Security. Secondo le fonti, CISA l'ha inserita nel catalogo KEV il 29 settembre, con scadenza per le agenzie federali statunitensi il 2 ottobre.

Che cosa è stato pubblicato, e che cosa no

La causa, secondo l'analisi riportata dalle fonti, è una conversione numerica non controllata nel rendering dei font. CoreGraphics converte le coordinate dei glifi da virgola mobile a virgola fissa (un fattore 4096) in una funzione chiamata aa_double_to_fixed. Quando il valore esce dal range di un intero a 32 bit, il comportamento in C è indefinito, e due funzioni adiacenti del rasterizzatore, compilate in modo diverso, trattano il caso in modo diverso: una satura il risultato, l'altra lo tronca. Le due stime del riquadro di delimitazione del glifo divergono, il sistema alloca un buffer troppo piccolo e la scrittura successiva finisce fuori dai limiti.

Il PoC è un PDF con un font TrueType manipolato che provoca un crash affidabile su macOS e iOS. Il repository include, a quanto riferito, gli script per generare il font e un harness di test. Ciò che non c'è è un exploit funzionante: le stesse fonti precisano che trasformare questa primitiva di corruzione di memoria in esecuzione di codice è un lavoro distinto, non dimostrato pubblicamente. Su un punto le fonti sono prudenti, e lo siamo anche noi: l'ipotesi che il vettore di consegna sia stato WhatsApp deriva da nuovi controlli sui font malformati comparsi nel parser dei PDF di Meta, un indizio circostanziale e non una conferma. Resta aperta anche la questione se l'attacco fosse davvero senza interazione (zero-click) o richiedesse altre falle per raggiungere il parser.

Cosa significa per le aziende italiane

Il rischio cambia in un modo preciso. Prima del 30 settembre, sfruttare la falla richiedeva di scoprirla da zero: un lavoro per attori ben attrezzati. Con causa radice, input di crash e script pubblici, la parte più difficile della scoperta è fatta. Lo storico di molte vulnerabilità mostra che dopo la pubblicazione di dettagli tecnici cresce il numero di soggetti in grado di sviluppare un exploit, anche se il passaggio dal crash al codice eseguibile su un sistema moderno, con le sue mitigazioni, resta un ostacolo reale. Dire che sia «imminente» sarebbe una previsione nostra non supportata dalle fonti; dire che la finestra utile per aggiornare si sta restringendo è invece ragionevole.

Per un'organizzazione italiana questo ha tre implicazioni:

  1. Il rischio non è più solo per i profili da attacco mirato. Il rischio resta basso per la maggior parte degli utenti, ma non è più confinato a giornalisti, dirigenti e avvocati: un PoC pubblico abbassa la soglia per attacchi opportunistici basati su PDF, che sono il formato di allegato più comune in azienda.
  2. Non esiste una mitigazione lato utente. La falla sta nello stack di rendering del sistema operativo: l'unica correzione è l'aggiornamento. Questo rende cruciale sapere quanti dispositivi aziendali, e quanti BYOD, siano ancora sulle versioni vulnerabili.
  3. I controlli perimetrali possono aiutare solo in parte. Bloccare o analizzare PDF con font incorporati sul gateway di posta è una difesa a strati sensata, ma non copre i canali di messaggistica e i file condivisi in cloud.

Per i soggetti NIS2 la gestione tempestiva delle vulnerabilità rientra fra le misure di gestione del rischio dell'art. 21; avere un parco mobile non gestito e non verificabile è una lacuna difficile da difendere in sede di audit. Se un dispositivo compromesso dà accesso a dati personali, vale l'art. 33 GDPR (notifica al Garante entro 72 ore, quando sia probabile un rischio per gli interessati).

Cosa fare subito

  • Verificare la versione dei dispositivi: iOS/iPadOS 26.7.1, macOS Tahoe 26.7.1 o macOS Sequoia 15.8.1 sono le versioni corrette indicate dalle fonti. Per chi è su iOS 27, consultare la pagina di sicurezza Apple per la propria versione, come spiegato nell'articolo precedente.
  • Imporre l'aggiornamento tramite MDM con una scadenza e produrre l'elenco dei dispositivi non conformi; per i BYOD richiedere conferma scritta o limitare l'accesso ai dati aziendali.
  • Per i profili ad alto rischio, valutare la Modalità di isolamento (Lockdown Mode) come misura generale, tenendo conto delle limitazioni d'uso.
  • Trattare con sospetto i PDF inattesi ricevuti via posta o messaggistica, anche se arrivano da contatti noti: un account compromesso è un canale di consegna tipico.
  • Se un dispositivo mostra segni anomali (crash ripetuti dell'anteprima di PDF, surriscaldamento, consumo di batteria insolito) e appartiene a un profilo sensibile, isolarlo e coinvolgere il team di sicurezza e, se necessario, il CSIRT Italia.