Apple ha rilasciato il primo aggiornamento attraverso un meccanismo automatico che molti utenti non conoscono ancora: i Background Security Improvements.
Prima di entrare nel merito della vulnerabilità corretta, è utile capire cosa sia questo nuovo strumento e perché rappresenta un cambiamento significativo nel modo in cui Apple gestisce la sicurezza dei propri dispositivi.
Indice degli argomenti
Cosa sono i Background Security Improvements
I Background Security Improvements sono aggiornamenti di sicurezza leggeri, mirati e silenziosi, distribuiti automaticamente in background senza richiedere un aggiornamento completo del sistema operativo e, soprattutto, senza richiedere il riavvio del dispositivo.
Sono disponibili a partire da iOS 26.1, iPadOS 26.1 e macOS 26 e si applicano a componenti specifici come il motore browser WebKit, le librerie di sistema e altri framework critici.
In parole semplici, possiamo immaginare di tappare una perdita d’acqua senza smontare l’intero impianto idraulico di casa. I Background Security Improvements fanno esattamente questo: correggono un componente specifico (come, ad esempio, il motore che gestisce le pagine web) senza toccare il resto del sistema operativo e senza interrompere il lavoro in corso.
Apple non è la prima azienda a percorrere questa strada: Microsoft ha introdotto una tecnologia analoga con gli hotpatch su Windows 11 Enterprise e Linux offre da anni meccanismi di live patching del kernel. Ma per l’ecosistema Apple si tratta di una vera novità, destinata a diventare uno strumento centrale nella gestione del rischio su miliardi di dispositivi.
Come differisce dal Rapid Security Response
Chi segue la sicurezza Apple ricorderà i Rapid Security Response, introdotti con iOS 16 nel 2022 con uno scopo analogo: correzioni puntuali e rapide tra un aggiornamento e l’altro. I Background Security Improvements ne rappresentano l’evoluzione diretta, con alcune differenze rilevanti.
I Rapid Security Response erano identificabili da un suffisso nella versione di iOS (ad esempio iOS 16.4.1 (a)), richiedevano a volte il riavvio del dispositivo e potevano essere disinstallati manualmente dall’utente ripristinando la versione base.
I Background Security Improvements seguono la stessa logica di denominazione, aggiungendo il suffisso “(a)” alla versione corrente del sistema operativo, ma Apple sottolinea che la loro applicazione è ancora più trasparente e a basso impatto.
Da sottolineare che se un Background Security Improvement viene rimosso manualmente, il dispositivo torna alla versione base senza alcun aggiornamento di sicurezza applicato.
Un comportamento identico a quello dei Rapid Security Response che, però, impone una riflessione: la possibilità di disinstallare patch di sicurezza è una funzione di usabilità che può diventare un vettore di rischio se non gestita correttamente nelle policy aziendali.
La vulnerabilità in WebKit corretta da Apple
WebKit, lo ricordiamo, è il motore di rendering web alla base del browser Safari e di tutti i browser disponibili su iOS e iPadOS, inclusi Chrome e Firefox. In altre parole, anche se sul nostro iPhone usiamo Chrome, il codice che effettivamente interpreta e visualizza le pagine web è WebKit.
Questo rende ogni vulnerabilità in WebKit potenzialmente applicabile a qualsiasi browser su qualsiasi dispositivo Apple.
Cos’è la Same Origin Policy e perché il suo aggiramento è pericoloso
La Same Origin Policy (SOP) è uno dei principi fondamentali della sicurezza del web. Stabilisce che una pagina web può accedere solo alle risorse che provengono dalla stessa origine, ossia dallo stesso dominio, protocollo e porta.
In pratica, impedisce a un sito malevolo aperto in una scheda del browser di leggere i dati presenti in un’altra scheda aperta, ad esempio, sulla pagina personale della nostra banca online, sulla nostra webmail o su qualsiasi altro servizio.
In pratica, in un possibile scenario di attacco, un utente visita un sito web apparentemente innocuo come può essere un articolo condiviso sui social, una pagina di e-commerce o una landing page di phishing ben costruita.
La pagina contiene codice JavaScript malevolo che, sfruttando la vulnerabilità CVE-2026-20643, viola la Same Origin Policy e legge dati da un’altra scheda aperta nel browser: cookie di sessione, token di autenticazione, contenuto di pagine web aperte. Il tutto in modo silenzioso, senza che l’utente si accorga di nulla.
Il dettaglio tecnico: Navigation API e validazione dell’input
La vulnerabilità risiede specificamente nella Navigation API di WebKit, un’interfaccia JavaScript che consente alle applicazioni web di controllare e monitorare la navigazione nel browser.
Il problema è una cross-origin issue: attraverso questa API era possibile, in condizioni specifiche, accedere a informazioni provenienti da origini diverse da quella corrente, violando esattamente il confine che la Same Origin Policy dovrebbe proteggere.
La causa alla base di questo malfunzionamento è una validazione insufficiente dell’input all’interno della Navigation API. Apple ha quindi corretto il problema rafforzando i controlli di validazione, rendendo impossibile per il codice malevolo sfruttare il percorso vulnerabile.
La nota positiva è che, al momento del rilascio della patch, non sono stati ancora segnalati casi di sfruttamento attivo della vulnerabilità che, è bene sottolineare, è stata scoperta e comunicata in modo responsabile (responsible disclosure) prima che chiunque ne facesse uso malevolo documentato.
Un elemento sicuramente positivo, ma che non riduce l’urgenza di applicare il fix.
Il contesto: WebKit, un bersaglio ricorrente
La vulnerabilità CVE-2026-20643 appena corretta da Apple non è un episodio isolato: WebKit è, storicamente, uno dei componenti maggiormente presi di mira nell’ecosistema della Mela dai ricercatori di sicurezza e dagli attori malevoli.
E ciò avviene per una ragione molto semplice: correggere WebKit significa correggere tutti i browser su tutti i dispositivi Apple contemporaneamente, con un impatto potenziale enorme.
Solo nelle settimane precedenti a questo aggiornamento, Apple aveva già emesso un fix per un’altra vulnerabilità zero-day, tracciata come CVE-2026-20700, già attivamente sfruttato che consentiva l’esecuzione arbitraria di codice su iOS, iPadOS, macOS, tvOS, watchOS e visionOS.
Senza dimenticare, a inizio marzo, il rilascio delle patch per altre quattro vulnerabilità sfruttate nel contesto del Coruna exploit kit, una suite di exploit che ha preso di mira dispositivi Apple con iOS 13 in versione 17.2.1.
Questo contesto rafforza la rilevanza strategica dei Background Security Improvements in un ecosistema in cui le vulnerabilità browser vengono scoperte e talvolta sfruttate attivamente in tempi molto brevi.
E questo significa che la capacità di distribuire fix mirati in ore anziché in settimane è una difesa concreta, non solo una comodità operativa.
Indicazioni pratiche: cosa fare
Alla luce dell’analisi tecnica della vulnerabilità corretta da Apple nel suo motore di rendering WebKit, gli utenti e i responsabili della sicurezza aziendale possono adottare alcune buone regole di igiene cyber.
Per gli utenti individuali
- Verificare che i Background Security Improvements siano abilitati: per farlo, dal menu Impostazioni/Privacy e sicurezza/Background Security Improvements assicurarsi che la voce Installa automaticamente sia attiva. Se è disattivata, il fix per CVE-2026-20643 non verrà applicato automaticamente.
- Verificare la versione installata: dopo l’aggiornamento automatico, la versione del sistema operativo dovrebbe mostrare il suffisso “(a)”, ad esempio iOS 26.3.1 (a). La verifica si effettua accedendo al menu Impostazioni/Generali/Info.
- Non rimuovere manualmente l’aggiornamento: Apple consente la disinstallazione delle patch installate nel proprio sistema operativo, ma riportare il dispositivo alla versione base senza Background Security Improvements significa riesporsi alla vulnerabilità.
Per gli amministratori IT e i responsabili della sicurezza
- Aggiornare le policy MDM per includere i Background Security Improvements: verificare che le soluzioni di Mobile Device Management (Apple Business Manager, Jamf, Microsoft Intune con supporto Apple ecc.) gestiscano correttamente questa nuova tipologia di aggiornamento e non la blocchino per policy di approvazione manuale.
- Monitorare l’inventario delle versioni con precisione: il suffisso “(a)” è semanticamente rilevante per la sicurezza. I tool di asset management e vulnerability management devono essere in grado di distinguere tra iOS 26.3.1 e iOS 26.3.1 (a) in quanto indicano due stati di sicurezza diversi.
- Aggiornare i playbook di incident response: con l’introduzione dei Background Security Improvements, il ciclo di vita di una vulnerabilità Apple si accorcia significativamente. I processi di valutazione e risposta alle CVE Apple devono tenerne conto.
- Comunicare la novità agli utenti finali: molti utenti non sanno cosa siano i Background Security Improvements e potrebbero disabilitarli per curiosità o per ridurre i consumi in background. Una comunicazione interna chiara riduce questo rischio.
Un passo avanti nel modello di sicurezza Apple
I Background Security Improvements rappresentano un cambiamento di paradigma nel modo in cui Apple gestisce la sicurezza dei propri dispositivi.
La logica è quella già applicata con successo da Microsoft con gli hotpatch su Windows: separare il fix di sicurezza dall’aggiornamento di funzionalità, riducendo il tempo di esposizione senza imporre il costo operativo di un aggiornamento completo.
Questa è, nella sostanza, la risposta di Apple a una realtà che il settore ha dovuto affrontare: il tasso di scoperta di vulnerabilità nei motori browser è troppo elevato per attendere i cicli mensili o bimestrali di aggiornamento del sistema operativo. Quando una vulnerabilità WebKit viene scoperta, ogni giorno di attesa è un giorno in cui miliardi di dispositivi rimangono esposti.
Il vero banco di prova di questa tecnologia sarà nella coerenza della sua applicazione: Apple dovrà dimostrare di essere disposta a usarla non solo per vulnerabilità scoperte in modo responsabile da ricercatori collaborativi, ma anche e soprattutto per le falle zero-day sfruttate attivamente, dove la velocità di distribuzione del fix è la differenza tra contenimento e danno su scala globale.
