Ubuntu e Debian, falla in APT permette attacchi root: quanto è grave?

Una vulnerabilità nel gestore dei pacchetti APT (Advanced Package Tool) permette, in determinate condizioni, di aggirare la verifica dei pacchetti software e installare codice dannoso con privilegi di root su Ubuntu, Debian e altre distribuzioni Linux derivate. La falla, identificata come CVE-2026-109518, interessa un componente fondamentale del sistema operativo, utilizzato quotidianamente per scaricare, installare e aggiornare applicazioni e librerie.

APT accompagna Debian dalla fine degli anni ’90 e Ubuntu fin dalla sua prima versione del 2004. La sicurezza del meccanismo di distribuzione dei pacchetti si basa su firme crittografiche, metadati autenticati e controlli di integrità: è un modello progettato per impedire che un mirror server compromesso o un intermediario di rete possano sostituire i programmi originali con versioni manipolate.

La vulnerabilità scoperta dal ricercatore Max Justicz, resa pubblica il 4 novembre 2026, dimostra che anche una catena di verifica crittografica robusta può perdere efficacia quando il software commette errori nella gestione dei file già verificati. Canonical ha assegnato alla falla una gravità High, con punteggio CVSS 4.0 di 7,7, e ha distribuito aggiornamenti correttivi per tutte le versioni Ubuntu interessate.

Come funziona la vulnerabilità CVE-2026-109518

Il problema risiede nel componente HTTP di APT, responsabile del trasferimento dei pacchetti dai repository. Quando un download incontra un reindirizzamento HTTP o un errore temporaneo, APT può tentare nuovamente di recuperare il file: è proprio nella gestione di questi tentativi che si annida il difetto.

Secondo il bollettino di sicurezza Debian DSA-6607-1, APT può associare due download differenti quando un reindirizzamento li conduce allo stesso URI. La gestione scorretta dei file durante la ripresa del trasferimento permette quindi a un aggressore di sostituire un pacchetto dopo che il sistema ne ha verificato l’integrità.

Un ruolo importante è ricoperto dai cosiddetti hard link, collegamenti che consentono a più nomi di file di riferirsi allo stesso inode su Linux e, quindi, agli stessi dati memorizzati a livello di filesystem. Un’operazione che modifica il contenuto attraverso uno di questi collegamenti può alterare anche ciò che risulta accessibile attraverso gli altri.

La vulnerabilità nasce proprio dall’interazione tra reindirizzamenti HTTP, tentativi di download e riutilizzo degli hard link. Manipolando opportunamente le risposte del server, un aggressore può indurre APT a sovrascrivere dati associati a un pacchetto precedentemente verificato, facendo arrivare alla fase di installazione contenuti diversi da quelli attesi.

È davvero una vulnerabilità così grave? Cosa serve per sfruttarla

Al netto degli scenari apocalittici descritti da alcune fonti, CVE-2026-109518 non consente a un qualsiasi aggressore su Internet di prendere direttamente il controllo di un server Ubuntu. Non basta conoscere l’indirizzo IP della macchina, né è sufficiente che APT sia installato.

L’aggressore deve poter manipolare il traffico HTTP tra il computer e il repository utilizzato per scaricare i pacchetti. Può trovarsi lungo il percorso di comunicazione, controllare un proxy oppure gestire un mirror malevolo o compromesso. Serve inoltre che il sistema avvii un’installazione o un aggiornamento che comporti il download di un pacchetto .deb, con una particolare sequenza di reindirizzamenti e tentativi di recupero.

Un altro requisito riguarda l’opzione Acquire::Retries, che stabilisce quante volte APT ritenta un download fallito. Il suo valore deve essere maggiore di zero: a partire da APT 2.3.2, la configurazione predefinita prevede 3 tentativi. Per tale ragione Ubuntu 22.04 LTS e le versioni successive risultano vulnerabili nelle impostazioni standard; le release precedenti lo sono soltanto quando l’amministratore o uno script ha abilitato esplicitamente i tentativi automatici.

La necessità di un’operazione svolta lato APT non rende tuttavia improbabile l’attacco. I server Linux ricevono spesso aggiornamenti mediante procedure pianificate e Ubuntu utilizza unattended-upgrades per applicare automaticamente gli aggiornamenti di sicurezza, generalmente con una verifica quotidiana. Su reti aziendali, infrastrutture con proxy HTTP o sistemi che utilizzano mirror interni, la superficie di esposizione va esaminata con cura.

Perché HTTPS protegge dall’attacco e le firme APT non sono bastate

Canonical precisa che l’utilizzo di HTTPS con TLS impedisce lo sfruttamento della vulnerabilità da parte di un intermediario che non possa alterare la comunicazione cifrata. La falla richiede infatti la manipolazione del traffico HTTP; FTP e gli altri metodi di trasporto non risultano interessati dal difetto descritto.

Può sorprendere che APT utilizzi ancora repository accessibili tramite HTTP, quindi senza cifratura. La spiegazione è che il sistema di sicurezza apt-secure verifica i metadati firmati dei repository, inclusi i riferimenti crittografici ai pacchetti. In condizioni normali, questa protezione mantiene l’integrità del software indipendentemente dal canale utilizzato per scaricarlo.

HTTPS aggiunge cifratura e autenticazione del collegamento verso il server, ma non sostituisce la verifica end-to-end dei repository.

Quali versioni Ubuntu e Debian sono vulnerabili

Canonical ha pubblicato le correzioni nel bollettino USN-8996-1. Per Ubuntu 22.04 LTS la versione corretta di APT è 2.4.15ubuntu0.1; per Ubuntu 24.04 LTS è 2.8.4ubuntu0.1, mentre Ubuntu 26.04 LTS richiede 3.2.1ubuntu0.1 e Ubuntu 26.10 utilizza 3.3.3ubuntu0.1.

Le release precedenti ricevono correzioni attraverso i rispettivi canali di manutenzione estesa: Ubuntu 20.04 LTS con APT 2.0.12+esm1, Ubuntu 18.04 LTS con 1.6.19+esm1, Ubuntu 16.04 LTS con 1.2.36+esm1 e Ubuntu 14.04 LTS con 1.0.1ubuntu2.24+esm4. L’accesso a tali aggiornamenti dipende dal servizio Ubuntu Pro e, per le versioni più vecchie, dall’estensione Legacy.

Anche Debian ha rilasciato un aggiornamento: per Debian 13 Trixie, la versione corretta è APT 3.0.4.

Gli utenti delle altre release Debian e delle distribuzioni derivate devono verificare i rispettivi avvisi di sicurezza, senza presumere che il numero di versione Ubuntu sia applicabile direttamente al proprio sistema.

Come verificare la configurazione e installare la patch senza esporsi

Su Ubuntu è possibile controllare i pacchetti installati provenienti dal sorgente APT mediante il comando apt list --installed '?source-package(^apt$)'. La versione riportata va confrontata con quella corretta indicata nel bollettino Canonical.

Per verificare il numero di tentativi configurati, si può utilizzare apt-config dump | grep -i 'Acquire::Retries'. Se la direttiva non compare, vanno considerati anche i valori predefiniti della versione installata: l’assenza della riga non dimostra che i tentativi siano disabilitati.

Canonical suggerisce di applicare gli aggiornamenti utilizzando temporaneamente Acquire::Retries=0, così da impedire la sequenza di tentativi necessaria allo sfruttamento della vulnerabilità. Il comando consigliato è sudo apt update && sudo apt upgrade -o Acquire::Retries=0.

Se non è possibile aggiornare tutti i pacchetti, si può intervenire soltanto sui componenti provenienti dal sorgente APT con sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'.

Per ridurre ulteriormente l’esposizione durante l’operazione, soprattutto su reti non completamente affidabili, conviene verificare che i repository utilizzino URL HTTPS, modificando le configurazioni presenti in /etc/apt/sources.list e nella directory /etc/apt/sources.list.d/. Bisogna controllare che i mirror supportino effettivamente TLS; non tutti i server comunitari lo garantiscono.

Un’ultima precisazione: il problema interessa il componente HTTP della libreria APT e quindi anche frontend come apt-get, aptitude e applicazioni grafiche che utilizzano tale libreria. Non riguarda invece l’installazione tramite Snap, che impiega un meccanismo differente.

Una falla seria, ma non un accesso root automatico a tutti i sistemi Linux

CVE-2026-109518 è certamente un problema rilevante perché colpisce il meccanismo con cui Linux distribuisce software considerato attendibile. Il suo impatto potenziale è massimo: un pacchetto malevolo può eseguire codice con privilegi amministrativi, senza che l’utente debba approvare manualmente il contenuto alterato.

La possibilità concreta di attaccare una macchina, però, richiede condizioni specifiche: una comunicazione HTTPS correttamente autenticata ostacola l’intercettazione del traffico; la disabilitazione dei tentativi automatici elimina un requisito dello sfruttamento. La patch, disponibile dal 4 novembre 2026, corregge invece il problema alla radice.