Apple, MCP e Bitget: tre falle mostrano il rischio della fiducia delegata

🛡️ Cosa cambia

• Apple corregge CVE-2026-86950, falla CoreGraphics potenzialmente già sfruttata in attacchi estremamente sofisticati e mirati.
• Il Python SDK ufficiale MCP permetteva a un server di indurre il client a recuperare URL $ref durante la validazione degli output.
• Bitget attribuisce il furto da 387,5 milioni di dollari a una vulnerabilità in un prodotto di sicurezza terzo, non alla compromissione delle private key.

Tre incidenti apparentemente lontani mostrano lo stesso problema: la sicurezza cede spesso nel componente al quale il sistema ha già deciso di concedere fiducia. Apple ha corretto una vulnerabilità di CoreGraphics capace di portare all’esecuzione di codice durante l’elaborazione di un file malevolo; il Python SDK ufficiale del Model Context Protocol ha dovuto correggere un comportamento che consentiva a un server di scegliere riferimenti remoti recuperati dal client durante la validazione degli output; Bitget ha ricostruito il furto da 387,5 milioni di dollari individuando il punto iniziale in un prodotto di sicurezza esterno utilizzato per proteggere la propria infrastruttura. In tutti e tre i casi il nodo non è semplicemente l’exploit: è la trasformazione di una relazione di fiducia preesistente in un percorso operativo per l’attaccante.

Apple corregge CoreGraphics dopo attacchi mirati contro utenti specifici

L’advisory Apple per macOS Tahoe 26.7.1 descrive CVE-2026-86950 come una out-of-bounds write in CoreGraphics, corretta attraverso un controllo più rigoroso dei limiti di memoria. L’elaborazione di un file appositamente costruito può portare ad arbitrary code execution e Apple afferma di essere a conoscenza di un report secondo cui la vulnerabilità potrebbe essere stata utilizzata in un attacco “estremamente sofisticato” contro individui specifici su versioni di iOS precedenti a iOS 27. La falla, segnalata da Meta Product Security, è stata corretta anche attraverso iOS 26.7.1, iPadOS 26.7.1 e macOS Sequoia 15.8.1. Apple non pubblica numero delle vittime, catena completa né identità dell’operatore, scelta coerente con la gestione abituale dei casi nei quali una vulnerabilità memory-safety entra in operazioni mirate. Il punto importante è che CoreGraphics si trova in una posizione particolarmente sensibile: deve interpretare contenuti grafici e file provenienti dall’esterno, trasformando dati apparentemente passivi in strutture elaborate localmente dal sistema. È lo stesso schema che rende così preziose le vulnerabilità nelle librerie multimediali, nei parser e nei motori di rendering: la superficie di attacco è raggiungibile attraverso un contenuto che l’utente può considerare innocuo. Il precedente delle zero-day Apple corrette dopo sfruttamento attivo mostra quanto queste catene siano utilizzate soprattutto contro obiettivi selezionati, mentre il caso CVE-2025-24085 in Core Media aveva già evidenziato il valore operativo delle componenti che processano dati multimediali.

Leggi anche: APT31 e UTA0560 sfruttano il patch gap di Chrome con tre zero-day

MCP Python SDK mostra che anche uno schema può diventare una richiesta di rete

Molto diverso tecnicamente, ma simile nel modello di fiducia, è il problema pubblicato nel security advisory ufficiale del Python SDK MCP. L’advisory GHSA-rwrf-2pqf-9j8j, classificato Moderate e pubblicato il 28 settembre, riguarda il comportamento del client durante la validazione dei risultati restituiti dagli strumenti: un server MCP poteva includere riferimenti $ref all’interno degli output schema e il client poteva recuperare quegli URL durante la fase di validazione. In altre parole, un server remoto non controllava soltanto i dati restituiti ma poteva influenzare quali destinazioni di rete il client avrebbe tentato di raggiungere mentre cercava di verificare formalmente la struttura della risposta. La vulnerabilità è importante perché MCP nasce precisamente per mettere in relazione modelli, strumenti e servizi esterni. Quando una componente viene considerata autorevole abbastanza da descrivere il proprio schema, quel metadato può finire per assumere capacità operative che il progettista non aveva previsto. Non serve quindi immaginare un agente che “decide” autonomamente di attaccare una rete: basta che il livello di protocollo trasformi un riferimento controllato dal server in una richiesta effettuata dal client. È lo stesso problema architetturale che emerge quando MCP viene utilizzato come standard per collegare modelli a strumenti e dati: ogni nuova primitive di interoperabilità deve essere trattata anche come superficie di sicurezza. Il rischio cresce ulteriormente negli stack agentici, dove il client può avere accesso contemporaneamente a repository, filesystem, API interne e credenziali. La lezione non riguarda quindi soltanto il singolo SDK. Gli schema, i metadata e i riferimenti non possono essere trattati come contenuto passivo quando il runtime è autorizzato a risolverli o interpretarli automaticamente. È un problema destinato a diventare sempre più importante con la diffusione di server MCP interni ed esterni collegati agli stessi agenti.

Bitget perde 387,5 milioni perché il prodotto di sicurezza diventa il punto d’ingresso

Bitget ha aggiornato il proprio incident report ufficiale chiarendo il vettore dell’attacco del 24 settembre. L’exchange stima ora in 387,5 milioni di dollari i fondi sottratti e afferma che gli aggressori hanno sfruttato una vulnerabilità in un prodotto di sicurezza di terze parti per ottenere credenziali di accesso alla rete interna. Con quelle credenziali sono stati inviati comandi di prelievo falsificati al sistema wallet, presentandoli come operazioni amministrative legittime e riuscendo a superare i controlli di rischio. Bitget precisa che le private key non risultano compromesse e che i cold wallet sono rimasti fuori dall’incidente; la perdita ha interessato invece una porzione dei livelli hot e warm. Questo dettaglio modifica sostanzialmente l’interpretazione iniziale dell’attacco. Il primo report sul caso Bitget poteva stabilire con certezza soltanto che l’infrastruttura wallet era stata manipolata, non il vettore iniziale. L’aggiornamento successivo mostra che la componente progettata per aumentare la sicurezza dell’exchange è diventata il canale utilizzato per ottenere identità interne sufficientemente privilegiate. Una volta dentro, l’attaccante non ha dovuto estrarre le chiavi crittografiche: ha convinto l’infrastruttura autorizzativa a eseguire transazioni apparentemente valide.

Continua con:
Bitget, THORChain e Zano mostrano il paradosso delle criptovalute
BGP hijacking e Packagist: quando la supply chain trasforma la fiducia in attacco

Apple, MCP e Bitget descrivono quindi tre livelli diversi dello stesso problema. Apple deve fidarsi di una libreria che interpreta contenuti; un client MCP deve fidarsi delle strutture dichiarate dal server; un exchange deve affidarsi a prodotti di sicurezza che operano dentro la propria infrastruttura privilegiata. Più una componente è integrata e autorizzata, maggiore diventa l’impatto quando quella fiducia viene sfruttata contro il sistema stesso. La sicurezza moderna non consiste quindi soltanto nel ridurre il numero delle vulnerabilità, ma nel limitare ciò che ogni componente può fare quando inevitabilmente una di quelle vulnerabilità viene trovata.