La sicurezza del cuore delle reti mobili si è retta per vent’anni su una regola non scritta: ciò che parla dall’interno del core è affidabile, perché per arrivarci bisognava entrare in una sala macchine dell’operatore. Un gruppo di ricercatori della Nanyang Technological University di Singapore ha messo quella regola davanti a una squadra di agenti basati su modelli linguistici, e il risultato è un elenco di 84 vulnerabilità mai segnalate prima in sette implementazioni open source di core 4G e 5G. Ottantatré sono state confermate dagli sviluppatori, 81 hanno già un identificativo CVE, e una di queste, un dirottamento di sessione, è stata riprodotta anche su due core 5G commerciali. La ricerca è stata depositata su arXiv a luglio e sarà presentata a USENIX Security 2026; la stampa di settore, da Fierce Network a Corriere Comunicazioni, ci è tornata sopra in queste ore.
Il peccato originale si chiama fiducia implicita
I ricercatori, guidati da Ziyu Lin, hanno dato un nome al difetto ricorrente: “implicit trust error”, errore di fiducia implicita. Le interfacce tra i componenti del core, dal Serving Gateway del 4G alla User Plane Function del 5G, sono nate quando tutto stava dentro un perimetro fisico chiuso. I due protocolli analizzati, GTP-C per la segnalazione e PFCP per dire alla UPF come inoltrare il traffico degli utenti, non prevedono di serie i livelli di autenticazione che si pretendono da qualunque servizio esposto su internet. Con il core che diventa software distribuito in container e cluster Kubernetes, talvolta su cloud pubblico o condiviso, una segmentazione insufficiente o un permesso di rete troppo largo bastano a rendere raggiungibile un’interfaccia progettata per non esserlo mai. E il componente dall’altra parte accetta il messaggio senza discutere, perché è così che è stato scritto.
Le falle riflettono quell’atteggiamento. La categoria più numerosa, 31 casi, riguarda un campo obbligatorio usato senza controllare che nel messaggio ci sia davvero. Secondo il conteggio riportato da Corriere Comunicazioni, 47 vulnerabilità su 84 stanno nel PFCP, soprattutto nel codice delle UPF, e le altre 37 nel GTP-C, in prevalenza nei Serving Gateway. Open5GS in configurazione LTE è l’implementazione con più segnalazioni, 30 confermate con CVE, seguita da free5GC con 14 e da OpenAirInterface 5G con 11.
Come un dirottamento diventa concreto
L’esempio che ha fatto il giro delle testate di sicurezza è il dirottamento di sessione via PFCP. Chi raggiunge l’interfaccia interna della UPF invia una richiesta di modifica di sessione che riutilizza l’identificativo di una regola di rilevamento pacchetti già assegnata a un utente reale, con precedenza più alta dell’originale e legata a una regola di inoltro maligna. Nessuno verifica che l’identificativo sia unico, la UPF ordina le regole per precedenza e da quel momento il traffico in uscita dell’utente finisce a un endpoint controllato dall’attaccante, che può osservarlo, modificarlo, rilanciarlo o buttarlo via, spegnendo la connettività di quel singolo abbonato senza toccare gli altri. Anche con il payload cifrato, ha spiegato Lin a The Hacker News, restano esposti i metadati.
La parte che sposta il caso dal laboratorio alla rete vera è la verifica sui prodotti commerciali. Il gruppo non ha potuto analizzare il codice dei core proprietari, quindi ha rigiocato contro di essi gli exploit costruiti sulle versioni open source. Tre hanno funzionato: il dirottamento su entrambi i core, più due denial of service su uno dei due. Un fornitore, Dotouch, ha corretto la sua XproUPF e la falla ha ricevuto il codice CVE-2026-8233; l’altro, descritto come un grande operatore 5G, risultava ancora al lavoro sulla correzione. Lo stesso Lin, interpellato da Help Net Security, invita alla prudenza: tre casi sono un campione piccolo, e l’idea che i core commerciali ereditino i difetti dagli stack open source che incorporano resta un indizio, non una conclusione. C’è poi una seconda porta d’ingresso, meno esotica della configurazione cloud sbagliata: un telefono qualsiasi con una SIM valida che nasconde messaggi PFCP o GTP-C dentro il tunnel dati del proprio uplink. Senza un controllo rigoroso del confine tra piano utente e piano di controllo, arrivano al core e vengono interpretati: nei test è successo su cinque implementazioni su sette.
L’agente che non si fida di sé stesso
Il metodo vale quanto i risultati. iFinder, così si chiama il sistema, è una catena di tre agenti. Il primo legge il codice cercando i punti in cui un dato ricevuto viene usato senza controllo; il secondo confronta ogni sospetto con le procedure delle specifiche 3GPP, per capire se la verifica mancante avviene in un passaggio precedente della procedura; il terzo scrive un exploit dimostrativo, lo esegue contro una rete di prova, legge i log e lo riscrive finché funziona o si arrende. Il passaggio intermedio è quello decisivo: senza il confronto con le specifiche i falsi positivi salgono da 19 a 62. Anche così la pipeline non è infallibile, e i ricercatori lo dichiarano: su 22 bug già noti ne ha ritrovati 15, e circa un quarto di ciò che segnala è sbagliato; per questo ogni segnalazione è stata riverificata a mano prima di arrivare ai manutentori.
Il seguito è meno rassicurante. All’11 agosto, secondo Help Net Security, delle 83 falle confermate 58 erano corrette e 23 avevano un CVE ma nessuna riga di codice cambiata, perché tre progetti su sette non avevano pubblicato correzioni. Lin lo attribuisce alla capacità di sviluppo dei manutentori: Open5GS, SD-Core e free5GC hanno chiuso i problemi, eUPF ha preso atto rimandando alle risorse disponibili, OpenAirInterface non ha risposto. Sono gli stessi stack che sorreggono banchi di prova, reti private e, a valle, prodotti commerciali.
Il commento della redazione
Noi la leggiamo così: la notizia non è che il core delle reti mobili abbia dei bug, ma che il ritmo con cui vengono trovati è cambiato di scala, e i cicli di correzione no. Una pipeline di agenti che produce 81 CVE in un giro domani sarà anche nelle mani di chi i report ai manutentori non li manda. Chi ha spostato il core nel cloud ha comprato elasticità, e insieme un perimetro che non esiste più: è la lezione che raccontavamo ieri sulle reti 5G private con il core in fabbrica e che vale ancora di più per chi, come Rakuten con la sua rete tutta software, ha fatto del core virtualizzato una bandiera. Colpisce anche la sproporzione tra il dibattito pubblico e il problema reale: in Europa si discute da anni di quanto costi sfrattare i fornitori cinesi per ragioni di sicurezza, e intanto le interfacce N4 e S11 accettano messaggi da chiunque riesca a bussare. La fiducia implicita non ha nazionalità. Ha solo bisogno di essere sostituita da autenticazione, segmentazione e validazione dei messaggi, e di qualcuno che, nei progetti open source su cui tutti costruiscono, abbia il tempo di scriverle.
