CVE-2026-109518: quando APT verifica un pacchetto ma ne installa un altro

La firma di un repository dovrebbe rispondere a una domanda semplice: il software che sto installando è davvero quello autorizzato? Ma la risposta diventa meno rassicurante se, dopo il controllo, il programma finisce per usare un file diverso. È il confine che rende interessante la CVE-2026-109518, una vulnerabilità di APT corretta da Canonical il 4 novembre 2026. Non è un generico problema di pacchetti non firmati: è un errore nel percorso tra download, retry e installazione.

La conseguenza potenziale è seria: un aggressore in grado di manipolare il traffico HTTP verso il repository, oppure un mirror malevolo, può far installare un pacchetto .deb non verificato. Gli script di installazione dei pacchetti vengono eseguiti con privilegi root. Il punto, però, è distinguere questa possibilità tecnica da un attacco remoto indiscriminato: servono condizioni precise, e conoscere quelle condizioni permette di intervenire senza trasformare ogni aggiornamento Ubuntu in un’emergenza indistinta.

La vulnerabilità è nel passaggio tra verifica e utilizzo

APT si affida a una catena di controlli sulle informazioni firmate dell’archivio e sui pacchetti recuperati. Questa architettura è più forte della semplice protezione del trasporto: una firma valida può continuare a dare garanzie anche quando la rete non è affidabile. Il problema emerge quando un’implementazione non mantiene coerente l’identità dell’oggetto che viene verificato con quella dell’oggetto che viene poi installato.

Secondo l’avviso di sicurezza USN-8996-1, APT gestiva in modo scorretto gli hard link quando incontrava redirect e tentava nuovamente il download dei pacchetti. L’attaccante poteva sfruttare quel percorso per sostituire il file utilizzato, aggirando di fatto il controllo che normalmente impedisce l’installazione di un .deb non verificato. È una classe di errore che merita attenzione anche fuori da APT: validare qualcosa e consumare qualcos’altro significa perdere l’invariante fondamentale del processo.

Non è corretto concludere che le firme dei repository siano inutili. Il modello di firma resta essenziale; questa vulnerabilità dimostra che anche la gestione dei file temporanei, dei redirect e dei retry deve preservare l’identità del contenuto. Un controllo crittografico perfetto non ripara automaticamente un errore di stato nella logica che lo circonda.

Quali condizioni rendono possibile l’attacco

Canonical classifica il problema come High, con CVSS 4.0 pari a 7,7. Non significa che basti conoscere l’indirizzo IP di un server per ottenere root. L’aggressore deve poter intervenire sul percorso HTTP usato dal client APT, o controllare un mirror/proxy malevolo; il client deve essere impegnato nell’installazione di un pacchetto e attraversare la sequenza vulnerabile di redirect e nuovo tentativo di download. La configurazione Acquire::Retries deve inoltre essere diversa da zero.

Su Ubuntu 22.04 LTS e versioni successive i retry sono abilitati per impostazione predefinita. Le release più vecchie, secondo Canonical, non sono esposte nella configurazione predefinita, ma possono esserlo quando il parametro è stato modificato. Anche Debian 12 usa un valore predefinito di tre retry; questo dato descrive il requisito della vulnerabilità, non autorizza a usare le versioni dei pacchetti Ubuntu come se fossero patch Debian.

Il vettore riguarda il backend HTTP di APT e i frontend che lo utilizzano, inclusi apt, apt-get e aptitude. Non riguarda l’installazione tramite snap, che segue un sistema distinto. È importante soprattutto per chi amministra server: un aggiornamento automatizzato o una procedura di provisioning possono attraversare il percorso vulnerabile senza che qualcuno stia interagendo con la console in quel momento.

Prima del fix: HTTPS e retry zero non sono la stessa difesa

Ci sono due mitigazioni temporanee, con proprietà differenti. Passare da HTTP a HTTPS per i repository protegge il trasporto contro un aggressore che manipola il traffico lungo il percorso, purché la connessione TLS sia verificata correttamente. Non elimina però da solo il rischio di un mirror intenzionalmente malevolo: Canonical stessa distingue la protezione TLS dal controllo end-to-end fornito dalle firme dell’archivio.

Impostare temporaneamente Acquire::Retries=0 elimina invece il prerequisito del nuovo tentativo di download. È la mitigazione che Canonical suggerisce anche durante l’installazione del fix, perché copre il percorso di exploit che può coinvolgere un mirror malevolo. Il costo è operativo: un download fallito non viene ritentato automaticamente. Non è una buona ragione per lasciare quel parametro disabilitato per sempre; è una precauzione per aggiornare in sicurezza.

La procedura documentata dal produttore è sudo apt update && sudo apt upgrade -o Acquire::Retries=0. In alternativa si può aggiornare soltanto il componente APT, con sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'. Questi comandi vanno eseguiti dopo aver verificato repository e policy di manutenzione del sistema: non sono una scorciatoia per ignorare errori di firma, sorgenti inattese o modifiche ai mirror.

Come verificare che il server sia corretto

La prima domanda è quale release stia realmente eseguendo la macchina. La seconda è quale versione del pacchetto APT sia installata, non soltanto quale versione sia disponibile nei repository. Canonical propone apt list --installed '?source-package(^apt$)' per identificare i pacchetti installati provenienti dalla sorgente APT. Per la verifica completa occorre confrontare l’output con l’advisory aggiornato.

• Ubuntu 22.04 LTS: 2.4.15ubuntu0.1
• Ubuntu 24.04 LTS: 2.8.4ubuntu0.1
• Ubuntu 26.04 LTS: 3.2.1ubuntu0.1
• Ubuntu 26.10: 3.3.3ubuntu0.1

Per Ubuntu 20.04 LTS e release precedenti le correzioni elencate nell’advisory sono disponibili attraverso i canali ESM/Ubuntu Pro pertinenti. Non basta confrontare un numero di versione senza considerare la release e il relativo canale di supporto. Su una flotta, l’inventario dovrebbe registrare almeno release, versione APT installata, configurazione dei retry, protocollo dei repository e stato dell’ultimo aggiornamento. Una dashboard che mostra soltanto “update completato” non dà la stessa evidenza.

Chi usa unattended-upgrades non dovrebbe interpretare la presenza del servizio come prova immediata di correzione: il processo può applicare gli aggiornamenti automaticamente, ma la verifica del pacchetto installato resta necessaria. Analogamente, spostare le sorgenti su HTTPS richiede controllare anche repository di terze parti e mirror personalizzati; una sostituzione automatica di alcuni URL Ubuntu non garantisce che ogni sorgente del sistema usi TLS.

Il problema generale: la sicurezza deve sopravvivere agli errori di rete

Redirect, retry e file temporanei sembrano dettagli implementativi. Nei sistemi reali, però, sono proprio i percorsi di recupero dagli errori a cambiare lo stato degli oggetti e a rendere più difficile dimostrare che il dato usato alla fine sia quello verificato all’inizio. Un pacchetto software è un caso evidente perché esegue script privilegiati, ma il principio riguarda anche pipeline di build, download di artefatti, cache e distribuzione degli aggiornamenti.

La domanda da porre in una revisione tecnica non è soltanto “abbiamo verificato la firma?”, ma “possiamo dimostrare che i byte eseguiti sono ancora quelli verificati, anche dopo un redirect o un retry?”. La riflessione sulla filiera di Ubuntu 26.10 affronta un problema affine: adottare componenti più sicuri non sostituisce la verifica dell’intera catena. E, come nel caso delle patch Ubuntu ancora in proposed, un annuncio di correzione non coincide automaticamente con la prova che il server sia protetto.

Qui la correzione è disponibile. L’azione utile è aggiornare APT con una mitigazione prudente durante il passaggio, controllare la versione effettivamente installata e rimuovere l’eventuale esposizione residua dei repository. La lezione architetturale resta più ampia: un sistema è sicuro soltanto se il controllo di integrità continua a valere fino al momento in cui il contenuto viene utilizzato.