TP-Link Omada e Gitea espongono reti e segreti dei server

🛡️ Executive Summary

• Quindici falle nel sistema Omada ZTP permettono di dirottare dispositivi, sottrarre configurazioni e penetrare nelle reti gestite.
• Gitea CVE-2026-59774 consente a utenti non autenticati di leggere file accessibili all’account del servizio attraverso Org-mode.
• TP-Link richiede firmware aggiornati e rotazione dei segreti, mentre Gitea deve essere portato immediatamente alla versione 1.27.1.

TP-Link ha corretto una serie di 15 vulnerabilità che compromettono la catena di fiducia delle tecnologie Omada Zero-Touch Provisioning, utilizzate per configurare da remoto gateway, switch e access point senza interventi sul posto. Le falle possono essere concatenate per impersonare dispositivi, sottrarre configurazioni, rubare credenziali amministrative e creare collegamenti verso le reti interne. Parallelamente, Gitea ha distribuito la versione 1.27.1 per chiudere CVE-2026-59774, vulnerabilità critica che consente a un attaccante non autenticato di leggere file locali attraverso il renderer Org-mode. Entrambi i casi colpiscono infrastrutture centrali: il primo compromette il processo con cui i dispositivi entrano nella rete, il secondo espone segreti conservati sui server DevOps.

Le falle colpiscono la catena di fiducia di Omada

Il sistema Zero-Touch Provisioning, o ZTP, permette a un’azienda o a un managed service provider di spedire un dispositivo direttamente nella sede da collegare e configurarlo successivamente dal cloud. Gateway, switch e access point comunicano con il controller, dimostrano la propria identità e ricevono automaticamente configurazioni, credenziali, certificati, impostazioni Wi-Fi e parametri VPN. La sicurezza dell’intero processo dipende quindi dalla capacità di distinguere un dispositivo autentico da uno contraffatto e di proteggere le comunicazioni tra hardware, applicazioni mobili, controller locali e servizi cloud. Nel bollettino complessivo pubblicato da TP-Link sulle vulnerabilità ZTP, il produttore conferma problemi nei flussi di adozione, nella gestione delle credenziali, nelle relazioni crittografiche di fiducia, nella validazione dei certificati e nelle interfacce di amministrazione. Undici vulnerabilità hanno ricevuto identificativi CVE, mentre quattro ulteriori debolezze riguardano l’uso del numero seriale durante l’adozione, credenziali predefinite, sequenze prevedibili dei seriali e file recuperabili tramite collegamenti temporanei. La superficie interessa controller, gateway, switch, access point, piattaforme OLT, servizi cloud e applicazioni mobili. Il rischio conferma quanto emerso con le precedenti vulnerabilità critiche corrette da Cisco e TP-Link su router, switch e servizi cloud: la gestione centralizzata riduce i costi operativi, ma crea un punto nel quale un errore di autenticazione può propagarsi verso numerosi dispositivi.

Un dispositivo contraffatto può ricevere la configurazione reale

Una delle catene ricostruite parte dalla possibilità di enumerare numeri seriali prevedibili e ricavare informazioni associate a dispositivi in attesa di adozione. L’attaccante può quindi impersonare un apparato Omada, partecipare alla procedura cloud e sfruttare una condizione di gara per essere registrato prima dell’hardware legittimo. Alcuni flussi iniziali si basavano inoltre su credenziali predefinite o su dati conoscibili attraverso il seriale, riducendo l’efficacia dell’autenticazione del dispositivo. Una volta completata l’adozione fraudolenta, il controller può consegnare al sistema contraffatto parti della configurazione destinate al vero gateway o access point, compresi nome utente, hash della password e potenziali segreti VPN. Il rischio non deriva quindi soltanto dalla compromissione di un dispositivo già operativo: l’attaccante può intervenire nel momento in cui l’apparato non ha ancora stabilito definitivamente la propria identità e la relazione di fiducia con il controller. La procedura ZTP, progettata per evitare la configurazione manuale, diventa in questo scenario un canale per ottenere informazioni sull’architettura della rete e preparare accessi successivi. TP-Link precisa che molte delle catene richiedono la combinazione di più debolezze e condizioni specifiche, tra cui la fase di onboarding, la posizione dell’attaccante e il tipo di controller utilizzato. Questo limite riduce la probabilità di un attacco opportunistico universale, ma non l’impatto negli ambienti nei quali numerosi dispositivi vengono preparati e distribuiti attraverso lo stesso account cloud.

XSS e credenziali rubate permettono di riconfigurare la rete

Le vulnerabilità comprendono anche problemi nelle interfacce dei controller Omada, tra cui cross-site scripting, debolezze di autenticazione e policy web troppo permissive. Un dispositivo o un contenuto controllato dall’attaccante può introdurre JavaScript nell’interfaccia amministrativa e colpire l’operatore quando accede al pannello di gestione. Il codice può tentare di sottrarre cookie, token o credenziali cloud, sfruttando la fiducia riposta nel controller. Con un account amministrativo compromesso, l’operatore ostile può modificare configurazioni, alterare reti wireless, cambiare DNS, creare tunnel VPN e raggiungere segmenti normalmente non accessibili da Internet. Le nuove falle possono inoltre essere concatenate con CVE-2025-7850 e CVE-2025-7851, due precedenti problemi nei gateway Omada che consentono l’iniezione di comandi e, in determinate condizioni, l’accesso root al sistema sottostante. Le indicazioni ufficiali di TP-Link sulle due vulnerabilità dei gateway Omada mostrano che la compromissione del piano di gestione può trasformarsi nell’esecuzione di comandi sul dispositivo. La combinazione tra furto dell’account cloud e vulnerabilità locali produce quindi un percorso completo: acquisizione delle credenziali, riconfigurazione dell’infrastruttura, apertura di collegamenti verso la rete interna e controllo del gateway. Il tema si inserisce nel quadro delle patch urgenti già distribuite da TP-Link per router e apparati esposti, dove la protezione del pannello amministrativo rappresenta un requisito decisivo quanto quella del firmware.

La validazione dei certificati espone applicazioni e traffico cloud

Alcune vulnerabilità riguardano le relazioni crittografiche utilizzate dalle applicazioni mobili e dai servizi cloud. Una verifica insufficiente dei certificati può consentire a un attaccante posizionato sulla rete di intercettare le comunicazioni attraverso una tecnica man-in-the-middle, presentando un certificato non autorizzato che l’applicazione accetta come valido. Altri problemi nelle policy cross-origin dei controller cloud permettono a contenuti caricati da origini esterne di interagire con risorse che dovrebbero essere isolate. In un ecosistema di gestione centralizzata, questi errori possono esporre token di sessione, informazioni sui dispositivi, parametri amministrativi e richieste indirizzate al controller. L’impatto dipende dalla specifica applicazione, dal prodotto e dalla versione installata, motivo per cui TP-Link ha pubblicato più bollettini separati con i modelli e i firmware corretti. Gli amministratori devono aggiornare controller, gateway, switch, access point e applicazioni mobili, senza limitarsi al solo dispositivo che svolge la funzione di router. Il produttore raccomanda inoltre di attivare l’autenticazione multifattore sugli account cloud, usare password amministrative uniche e ruotare credenziali, certificati e segreti VPN potenzialmente esposti. La segmentazione deve impedire al controller di raggiungere indiscriminatamente tutti i sistemi aziendali, mentre le interfacce Omada non dovrebbero essere pubblicate direttamente su Internet. La ricerca ha individuato oltre 1.800 controller accessibili pubblicamente, nonostante questi ambienti non siano normalmente progettati per un’esposizione diretta.

Gitea permette di leggere file locali attraverso Org-mode

La seconda vulnerabilità interessa Gitea dalla versione 1.22.1 alla 1.27.0 ed è identificata come CVE-2026-59774, con punteggio CVSS 9,8. Un attaccante remoto non autenticato può inviare markup Org-mode all’endpoint POST /{owner}/{repo}/markup associato a un repository pubblico e utilizzare la direttiva #+INCLUDE per richiedere un percorso assoluto sul server. Il problema nasce dal renderer go-org, inizializzato senza sostituire la funzione predefinita ReadFile. La libreria passa quindi il percorso fornito alla funzione ioutil.ReadFile, permettendo di restituire nel contenuto renderizzato qualsiasi file accessibile all’utente di sistema che esegue Gitea. L’attacco non richiede la creazione di un account, la possibilità di scrivere nel repository o il caricamento permanente di un file malevolo. È sufficiente che l’istanza ospiti almeno un repository pubblico con la sezione codice leggibile e che l’endpoint di rendering possa essere raggiunto. Nell’advisory ufficiale di Gitea dedicato alla lettura arbitraria dei file, il progetto indica come esposti configurazioni, token interni, materiale OAuth e JWT, metadati del deployment e altri segreti leggibili dall’account del servizio. La vulnerabilità amplia una sequenza di problemi già osservata nell’ecosistema, compreso il bypass di autenticazione nei container Gitea corretto a luglio.

Il furto di app.ini può trasformarsi in esecuzione di codice

La lettura arbitraria non equivale automaticamente a un comando remoto eseguito con una sola richiesta, ma può diventare il primo passaggio di una catena più grave. Il file app.ini può contenere INTERNAL_TOKEN, segreti applicativi, configurazioni del database e credenziali utilizzate dalle integrazioni. Secondo l’advisory, l’attaccante può estrarre il token interno, utilizzarlo per iniettare un Git hook attraverso il sistema di logging interno e attivarlo durante un clone anonimo. Il comando viene eseguito con i privilegi dell’utente di sistema che gestisce Gitea, offrendo accesso ai repository montati, alle variabili d’ambiente, al database e agli altri servizi raggiungibili dal server. La versione 1.27.1 sostituisce il callback per la lettura dei file, trattando il percorso indicato nella direttiva Org-mode come semplice contenuto invece di risolverlo sul filesystem. Gitea 1.27.1 corregge anche CVE-2026-60004, separata vulnerabilità che permette di installare un Git hook attraverso l’endpoint diffpatch. Le organizzazioni che utilizzano Gitea self-hosted devono aggiornare immediatamente e controllare richieste anonime verso gli endpoint /markup, in particolare quelle associate alla modalità file, a nomi .org e a percorsi assoluti. Le istanze già esposte devono considerare compromessi i segreti leggibili dall’account del servizio e ruotare token interni, credenziali del database, chiavi OAuth e materiale JWT. L’urgenza è coerente con le precedenti vulnerabilità che hanno colpito Gitea insieme ad altri nodi critici della supply chain.

Provisioning e DevOps condividono lo stesso rischio sistemico

Le vulnerabilità Omada e Gitea coinvolgono tecnologie differenti, ma colpiscono entrambi sistemi ai quali viene delegata una fiducia estesa. Omada configura apparati che controllano il traffico della rete; Gitea conserva codice, segreti, pipeline e integrazioni utilizzate dagli sviluppatori. Compromettere il provisioning permette di introdurre o riconfigurare dispositivi nel perimetro aziendale, mentre leggere i file del server DevOps può esporre credenziali sufficienti per raggiungere repository, database e infrastrutture CI/CD. La correzione richiede quindi più di un aggiornamento puntuale. Negli ambienti Omada occorre verificare dispositivi adottati recentemente, ruotare le credenziali e controllare tunnel, account e modifiche alle configurazioni. Sui server Gitea è necessario analizzare i log web, gli hook Git e le operazioni eseguite dall’utente del servizio. In entrambi i casi, patchare chiude la vulnerabilità ma non annulla automaticamente gli effetti di un accesso già ottenuto.