Che cosa ha pubblicato Apple il 27 luglio

Le pagine di sicurezza di Apple si sono riempite in un blocco unico il 27 luglio. macOS Tahoe 26.6 è arrivato come build 25G72 con 155 identificativi CVE unici, insieme a Safari 26.6. iOS 26.6 e iPadOS 26.6 hanno elencato 78 voci distinte di vulnerabilità legate a 87 CVE unici. Gli aggiornamenti per watchOS, tvOS e visionOS 26.6 hanno aggiunto altri 194 una volta rimossa la sovrapposizione tra piattaforme.

I componenti citati si leggono come un inventario dell'intero sistema e non come un singolo angolo debole. Sul telefono le correzioni toccano il kernel, WebKit, la rete senza fili, Siri, l'App Store, MediaRemote, ImageIO, SceneKit, libc, CloudAttestation, Game Center, Accessibilità e Contatti. Sul Mac le descrizioni sono più nette: falle che potevano permettere a un'applicazione di ottenere privilegi di amministratore, uscire dal proprio ambiente isolato, aggirare Gatekeeper, scavalcare le preferenze di privacy o raggiungere dati protetti.

Apple non afferma che una di esse fosse sfruttata prima della pubblicazione degli aggiornamenti, e nessuna testata ha portato prove del contrario. Contarle è stranamente difficile: pubblicazioni specializzate che lavorano sullo stesso documento Apple arrivano a cifre comprese tra circa 130 e 155, a seconda che contino voci o identificativi. Questo scarto è un dettaglio, ma dice che l'inventario è scritto perché lo legga una persona e non perché lo analizzi uno strumento.

I sette tentativi sono la parte da leggere

Il dato che conta non sta nel numero di CVE. macOS Sequoia 15.7.8 e macOS Sonoma 14.8.8 sono usciti lo stesso giorno, e hanno raggiunto la pubblicazione solo dopo che Apple aveva emesso sette candidate alla versione finale. Una quinta candidata il 13 luglio era già abbastanza insolita da essere segnalata come rara di per sé. Poi ne sono seguite altre due.

Va letto come un segnale ingegneristico, non come una curiosità. Una candidata alla versione finale è la build che il produttore ritiene conclusa. Emetterne sette significa che Apple ha creduto ripetutamente che il riporto fosse finito e ha ripetutamente scoperto che non lo era. Il ramo attuale, Tahoe, non ha avuto bisogno di questo andirivieni: è stato scritto una volta sola sul codice per cui le correzioni erano pensate.

Insieme, Sequoia 15.7.8 e Sonoma 14.8.8 risolvono più di 138 vulnerabilità distinte. Il volume è paragonabile a quello di Tahoe. Ciò che cambia è la difficoltà di portarlo fin lì, e le note di rilascio di Apple per i due rami più vecchi non dicono quasi nulla in proposito: offrono soltanto che si tratta di importanti correzioni di sicurezza, consigliate a tutti gli utenti che vi lavorano ancora.

L'argomento della stabilità funziona al contrario

La maggior parte delle flotte che restano una versione indietro lo fa deliberatamente. Il ragionamento è familiare e di solito valido: lasciare che siano altri a trovare le regressioni, tenere il parco su una build che sta nel mondo da abbastanza tempo da risultare noiosa e aggiornare quando l'azienda ha una settimana tranquilla. Applicata alle funzioni, questa logica regge.

Applicata alle correzioni di sicurezza, il 27 luglio la rovescia. Il ramo più vecchio non è quello assestato. È quello che ha richiesto sette tentativi, perché un riporto all'indietro non è lo stesso lavoro di una correzione: la falla viene trovata e riparata nel codice attuale e poi trasportata indietro in una base di codice che nel frattempo è andata avanti. Ogni versione di distanza tra il vostro parco e la prima linea di Apple è distanza tecnica che qualcuno deve colmare sotto pressione, e questo mese ci sono voluti sette passaggi.

La conseguenza di secondo ordine riguarda le prove, non la propensione al rischio. La NIS2 chiede alle organizzazioni interessate di trattare le vulnerabilità come un processo documentato e non come un istinto, e la domanda di un audit raramente è se avete applicato la patch. È quando lo avete saputo, che cosa avete deciso e perché. "Restiamo una versione indietro per stabilità" è una risposta difendibile solo finché il registro non mostra che il ramo più vecchio riceve le correzioni più tardi e in modo più fragile. In Italia quel registro passa sotto gli occhi dell'ACN.

L'ordine di lavoro di questa settimana

Partite dalle macchine già esposte, non da quelle più facili da raggiungere. Tutto ciò che usa Safari o WebKit su pagine non affidabili, ogni Mac su cui un utente normale potrebbe plausibilmente essere indotto ad aprire un file costruito ad arte e ogni dispositivo fuori dalla rete dell'ufficio appartiene alla prima ondata. Gli aggiramenti di Gatekeeper e delle preferenze di privacy pesano soprattutto sui portatili che escono dall'edificio.

Poi affrontate il parco più vecchio con onestà. Se un gruppo di Mac è su Sonoma o Sequoia perché l'hardware non regge Tahoe, questo è un fatto da pianificare e prima o poi da mettere a bilancio, non una posizione da difendere. Se sono su una versione più vecchia per scelta, questo è il mese in cui chiedersi se quella scelta compri ancora ciò che doveva comprare.

Una cosa da annotare. Registrate la data di pubblicazione delle note e la data in cui ogni gruppo di dispositivi è stato aggiornato, perché la distanza tra questi due numeri è l'unica parte della vicenda che un audit potrà verificare in seguito, ed è l'unica che controllate voi.

Da leggere ora: La patch nginx è uscita, l'exploit arriva ad agosto  |  Due falle di Cursor con punteggio 9.8 consegnano la macchina dello sviluppatore agli aggressori