Cloudflare e il leak BGP: cosa è successo davvero tra Grist-Core, CVE-2026-24002 e 1Password

0

Cloudflare ammette un leak BGP IPv6 durato 25 minuti il 22 gennaio 2026, causato da una misconfigurazione di policy di routing su un edge router a Miami, mentre Grist-Core, 1Password e l’intero ecosistema sicurezza mostrano come errori di configurazione, sandbox fragili e phishing AI-driven stiano convergendo in una superficie di rischio sistemica.

Cloudflare BGP leak è l’evento che ha messo in evidenza una fragilità strutturale nel routing automatizzato IPv6: Cloudflare, Grist-Core, CVE-2026-24002 e 1Password emergono nelle stesse ore come tasselli di un’unica dinamica, dove automazione, fiducia implicita e execution environment diventano vettori di incidente. Il lettore ottiene qui una ricostruzione tecnica completa dell’incidente, dei meccanismi BGP coinvolti, delle correzioni adottate e delle implicazioni concrete per operatori di rete, sviluppatori e responsabili sicurezza.

Cloudflare e il leak BGP IPv6 del 22 gennaio 2026

L’incidente Cloudflare del 22 gennaio 2026 non è stato un semplice glitch di routing, ma un leak BGP di tipo 3 e 4 secondo RFC 7908, confinato a IPv6 ma con effetti rilevanti sull’intero ecosistema di interconnessione. Una modifica di policy pensata per rimuovere specifici annunci IPv6 legati a Bogotá ha reso eccessivamente permissiva una regola di export su un router edge a Miami. In particolare, la rimozione di prefix-list dedicate da statement come 6-TELIA-ACCEPT-EXPORT ha permesso al router di accettare tutte le route interne iBGP e di esportarle verso peer e transit provider esterni.

Il risultato è stato un routing non valley-free, in cui AS13335 è apparso come transito tra peer e provider, violando un principio cardine dell’Internet routing. Traffico originato da grandi peer, inclusi network come Meta, ha iniziato a fluire attraverso Cloudflare verso provider come Lumen, generando percorsi sub-ottimali, congestione sul backbone Miami–Atlanta e perdita di pacchetti. I firewall di Cloudflare hanno correttamente scartato il traffico non destinato ai servizi dell’azienda, ma il volume ha raggiunto circa 12 Gbps di traffico droppato, con aumento significativo della latenza per clienti IPv6.

Cloudflare ha rilevato le anomalie intorno alle 20:40 UTC, avviando l’investigazione entro pochi minuti. L’intervento manuale ha revertito la configurazione entro 25 minuti, limitando l’impatto temporale ma non la portata tecnica dell’evento. L’incidente ha colpito prevalentemente traffico IPv6, lasciando IPv4 indenne, ma ha coinvolto anche reti esterne a Cloudflare, che hanno osservato instabilità e flapping dei percorsi.

Timeline tecnica del leak BGP Cloudflare

La sequenza temporale dell’evento mostra come automazione e CI/CD applicati al routing possano amplificare errori minimi. Il cambio di codice viene mergiato alle 19:52 UTC del 22 gennaio 2026. Alle 20:25 UTC l’automazione applica la policy errata su un edge router a Miami, che inizia immediatamente ad annunciare prefissi IPv6 interni verso peer e transit provider.

Alle 20:44 UTC il team network di Cloudflare eleva formalmente l’incidente, dopo aver osservato pattern anomali tramite strumenti di osservabilità come Monocle e RIPE BGPlay. Alcuni percorsi IPv6 mostrano AS-path chiaramente sospetti, come 64112 22850 174 3356 13335 32934, evidenziando la violazione del modello valley-free. Un operatore esegue il revert manuale alle 20:50 UTC, fermando la propagazione del leak. Il trigger di automazione viene completamente revertito alle 21:47 UTC, mentre i controlli di sanità della pipeline CI/CD tornano verdi alle 22:07 UTC, consentendo il riavvio dell’automazione alle 22:40 UTC.

Cloudflare ha sottolineato come questo evento richiami direttamente l’outage del 2020, confermando che il routing automatizzato, se non rigidamente vincolato, resta una delle superfici di rischio più delicate dell’infrastruttura Internet.

Le contromisure Cloudflare dopo l’incidente

Dopo il leak BGP, Cloudflare ha implementato una serie di safeguard strutturali mirati a ridurre drasticamente il rischio di recidiva. Sono state introdotte community BGP vincolanti per impedire l’export di route apprese da peer o provider verso altri peer o provider, anche in presenza di policy errate. La pipeline CI/CD per le configurazioni di rete ora include controlli automatici in grado di rilevare termini vuoti, prefix-list mancanti o policy eccessivamente permissive prima del deploy.

Un ulteriore livello di protezione deriva dalla validazione delle implementazioni vendor di RFC 9234, con ruoli BGP e attributo Only-to-Customer, progettati per prevenire leak locali anche in caso di errori umani. Cloudflare ha inoltre ribadito il proprio supporto all’adozione di RPKI ASPA, che consentirebbe di rigettare automaticamente percorsi AS logicamente impossibili. Il messaggio è chiaro: senza defense-in-depth nel routing, l’automazione resta un moltiplicatore di rischio.

Grist-Core e la vulnerabilità RCE CVE-2026-24002

In parallelo all’incidente Cloudflare, Grist-Core ha corretto una delle vulnerabilità più critiche del periodo, identificata come CVE-2026-24002 con CVSS 9.1. La falla, scoperta da Cyera Research Labs e soprannominata Cellbreak, consente una Remote Code Execution partendo da formule spreadsheet apparentemente innocue. Grist-Core, nella sua versione open-source self-hosted, esegue formule Python non fidate all’interno di Pyodide, un runtime WebAssembly sandboxato. Tuttavia, l’approccio basato su blocklist si è rivelato insufficiente.

Gli attaccanti possono sfruttare la traversal della gerarchia delle classi Python per raggiungere moduli come ctypes e, da lì, funzioni runtime di Emscripten, ottenendo accesso a esecuzione di comandi OS o JavaScript sull’host. In pratica, uno spreadsheet diventa un beachhead RCE, capace di esporre API key, credenziali database e file sensibili. Il pattern richiama da vicino vulnerabilità come N8scape in n8n, dimostrando quanto siano fragili i sandbox applicativi basati su filtri incompleti.

La versione Grist-Core 1.7.9, rilasciata il 9 gennaio 2026, sposta l’esecuzione Pyodide sotto Deno per default, introducendo un isolamento più robusto. Grist consiglia inoltre l’uso di gVisor come sandbox alternativo e raccomanda di evitare configurazioni come GRIST_PYODIDE_SKIP_DENO=1 se non strettamente necessario. Il caso Grist evidenzia un punto critico: quando la sandbox fallisce, il confine di fiducia tra dati ed esecuzione collassa.

1Password e la risposta al phishing AI-driven

Il terzo tassello di questo quadro è l’introduzione, da parte di 1Password, di avvisi pop-up attivi contro siti phishing sospetti. La nuova funzione della browser extension genera un alert quando il dominio visitato non corrisponde a quello salvato nel vault o presenta segnali di typosquatting, come varianti del tipo faceb00k.com. A differenza del semplice blocco dell’auto-fill, il pop-up introduce un attrito cognitivo intenzionale, spingendo l’utente a verificare l’URL prima di inserire manualmente le credenziali.

La misura nasce in risposta a un contesto in cui il phishing AI-powered produce campagne altamente convincenti e su larga scala. Dati interni indicano che il 61% degli utenti ha subito almeno un tentativo di phishing, mentre il 75% ammette di non controllare l’URL prima di cliccare. In ambienti aziendali, la combinazione di riutilizzo password e phishing resta uno dei principali vettori di compromissione iniziale.

La funzione è attiva automaticamente per piani individuali e familiari, mentre nelle aziende può essere gestita dagli amministratori tramite Authentication Policies nella console. L’obiettivo non è solo bloccare l’attacco, ma educare l’utente in tempo reale, riducendo la probabilità di inserimenti manuali su pagine fraudolente.

Domande frequenti su Cloudflare BGP leak