News Linux: exploit root, Kali Linux 2026.3, Rust in systemd e Python

Questa settimana il mondo Linux e open source ci offre quattro notizie che meritano attenzione, soprattutto per chi usa Linux per lavoro, per sviluppare software o per gestire server.

Una vulnerabilità del kernel Linux può permettere a un utente locale di ottenere privilegi root; arriva Kali Linux 2026.3, con sei nuovi strumenti e un processo di build rinnovato; Rust entra ufficialmente nel progetto systemd; infine, Python pubblica cinque release di sicurezza che affrontano anche il problema di alcuni certificati compromessi.

Non si tratta soltanto di aggiornamenti software: queste quattro notizie raccontano perché la sicurezza dipende dai privilegi, dagli strumenti di sviluppo, dal codice di sistema e dalla fiducia nelle connessioni utilizzate per distribuire i pacchetti.

Vulnerabilità Linux ZDI-CAN-33367: come può un utente normale diventare root?

La prima notizia riguarda ZDI-CAN-33367, una vulnerabilità del sottosistema di networking del kernel Linux per la quale sono stati resi pubblici dettagli tecnici e un proof-of-concept. CloudLinux ha riportato di aver verificato l’escalation a root in specifiche configurazioni di AlmaLinux 8, 9 e 10, Debian 12 e 13, Ubuntu 24.04 e 26.04.

Che cos’è una privilege escalation locale?

Una privilege escalation, o escalation dei privilegi, avviene quando un processo ottiene autorizzazioni superiori a quelle che dovrebbe possedere. Su Linux, il passaggio più critico è quello da un utente non privilegiato a root, l’account amministrativo. Per capire come vengono creati e gestiti gli account, puoi leggere la guida a creare utenti Linux con useradd .

Immaginiamo un server che ospiti un’applicazione web. Un aggressore potrebbe ottenere un primo accesso tramite una vulnerabilità dell’applicazione oppure credenziali compromesse. Quel primo accesso potrebbe però essere limitato a un utente di servizio, come www-data.

Il percorso concettuale è questo:

Applicazione o credenziali compromesse → shell limitata → utente non privilegiato → vulnerabilità del kernel → privilegi root.

La vulnerabilità del kernel non rappresenta necessariamente il punto di ingresso: può costituire il secondo passaggio di un attacco, quello che trasforma un accesso limitato in un controllo molto più esteso.

Non è un attacco remoto automatico contro tutti i server Linux

È fondamentale chiarire cosa non significa questa notizia. ZDI-CAN-33367 non va descritta come una vulnerabilità che permette a chiunque su Internet di prendere direttamente il controllo di qualsiasi server Linux.

Per il percorso di exploit descritto è necessario poter eseguire codice localmente. Lo sfruttamento dipende inoltre da caratteristiche e configurazioni del sistema, compresa la disponibilità degli unprivileged user namespaces, una funzionalità del kernel utilizzata anche per creare ambienti isolati.

Questo non riduce automaticamente la gravità del problema: nei server multiutente, negli hosting condivisi o nei sistemi nei quali applicazioni esposte possono essere compromesse, una vulnerabilità locale può amplificare notevolmente le conseguenze di un’intrusione iniziale. Se vuoi approfondire la terminologia, abbiamo spiegato cosa sono le vulnerabilità zero-day e quali rischi comportano .

Patch e mitigazioni: cosa verificare

AlmaLinux ha comunicato la disponibilità di kernel corretti nei repository di testing per alcune versioni, mentre CloudLinux ha pubblicato aggiornamenti sul rilascio di kernel corretti e su soluzioni di live patching per determinati sistemi. La disponibilità delle correzioni non è necessariamente uniforme fra le distribuzioni.

Per chi amministra macchine Linux, la priorità è verificare gli advisory ufficiali del proprio vendor, il kernel effettivamente in esecuzione e le mitigazioni applicabili alla configurazione. È importante anche limitare gli accessi locali non necessari e applicare il principio del minimo privilegio.

Alla data della puntata, non risultavano prove pubbliche documentate di sfruttamento reale in the wild nelle fonti consultate. Questo non costituisce una garanzia che non possano esistere tentativi non osservati.

Fonte: CloudLinux — ZDI-CAN-33367 .

Kali Linux 2026.3: non soltanto sei nuovi strumenti

Il 26 ottobre 2026 è uscita Kali Linux 2026.3, la terza release dell’anno della distribuzione basata su Debian e specializzata nelle attività di cybersecurity, analisi e penetration testing autorizzato.

Kali non è una distribuzione che “hackerà” automaticamente altri sistemi: è un ambiente che raccoglie strumenti utili a professionisti, ricercatori e studenti impegnati in test legittimi e controllati. Se vuoi comprendere le differenze tra le distribuzioni prima di provarne una, trovi una guida su come scegliere una distribuzione Linux .

Le novità principali di Kali Linux 2026.3

La nuova release include:

• kernel Kali 7.1.5;
• KDE Plasma 6.7;
• 126 pacchetti aggiornati;
• aggiornamenti a Kali NetHunter;
• sei nuovi strumenti: Dalfox, Katana, QSReplace, RustScan, SDRangel e Snaffler-ng.

I nuovi tool riguardano aree diverse: analisi della sicurezza web, esplorazione di applicazioni, gestione dei parametri URL, scansione delle porte, radio definita via software e ricerca di informazioni sensibili nelle condivisioni di rete. Per approfondire il tema della scansione, leggi cos’è Nmap e come viene utilizzato nella sicurezza di rete .

La novità più interessante: build delle immagini con Docker e Podman

Uno degli aspetti più significativi della release riguarda gli script utilizzati per costruire le immagini Kali.

Quando scarichiamo una ISO, utilizziamo un sistema già assemblato dal progetto. Ma un team di sicurezza può avere bisogno di un’immagine personalizzata con strumenti, configurazioni e pacchetti specifici. Per questo servono script di build affidabili e facili da ripetere.

Con Kali Linux 2026.3, gli script vengono resi più coerenti tra le diverse piattaforme e le build aggiornate possono essere eseguite anche in container Docker o Podman, attraverso l’apposito build-in-container.sh.

Un ambiente containerizzato può rendere più semplice ripetere le procedure e ridurre la dipendenza dalla configurazione del computer utilizzato. Per un approfondimento pratico sui container e la loro configurazione, vedi anche la gestione delle variabili d’ambiente con Docker Compose . Non garantisce da solo build perfettamente riproducibili byte per byte, ma costituisce un passo utile verso processi più controllati.

Gli sviluppatori precisano inoltre che il rinnovamento degli script è ancora in corso.

Fonte: Kali Linux 2026.3 — annuncio ufficiale .

Rust entra in systemd: Linux abbandonerà il linguaggio C?

Il 24 ottobre 2026 è stata integrata nel repository principale di systemd la pull request #44324, proposta da Christian Brauner, che introduce il supporto necessario a realizzare nuovi programmi systemd scritti in Rust.

È una novità tecnica importante, ma va letta nel modo giusto: systemd non viene riscritto in Rust. Il codice C esistente resta in C; il nuovo linguaggio potrà essere utilizzato per componenti autonomi.

Che cosa fa systemd in Linux?

In molte distribuzioni Linux, systemd svolge un ruolo centrale nell’avvio e nella gestione dei servizi. Se stai iniziando a conoscere le distribuzioni, può essere utile anche l’approfondimento su cosa sono le distribuzioni Linux e perché ne esistono così tante . Dopo le prime fasi di boot e l’avvio del kernel, contribuisce a inizializzare processi e unità di sistema: servizi, mount, timer e altre risorse.

Si tratta quindi di un progetto delicato, nel quale ogni cambiamento tecnologico deve essere valutato con attenzione.

Il 27 ottobre è stato integrato il primo programma Rust

C’è anche un aggiornamento concreto successivo all’introduzione dell’infrastruttura: il 27 ottobre 2026 è stata integrata la pull request #44114, che aggiunge systemd-keyring-setup, il primo programma Rust nel ramo principale del progetto.

Il suo compito riguarda l’impostazione di portachiavi crittografici del kernel a partire da certificati digitali X.509. Tuttavia, essere integrato nel ramo di sviluppo non significa essere già presente nelle release stabili installate su tutte le distribuzioni.

Perché Rust è interessante per la sicurezza?

Rust è apprezzato soprattutto per il suo approccio alla memory safety, cioè la prevenzione di numerosi errori di gestione della memoria. In determinate condizioni, bug come gli use-after-free o gli accessi fuori dai limiti di un buffer possono provocare crash e vulnerabilità sfruttabili.

Il compilatore Rust aiuta a evitare molte di queste classi di errori, pur senza eliminare bug logici, problemi di concorrenza, errori architetturali o rischi introdotti da codice unsafe.

L’approccio scelto da systemd è graduale: nuovi componenti autonomi, integrazione con le librerie esistenti e mantenimento di Meson come sistema di build, senza introdurre Cargo nel normale processo di compilazione.

In sintesi, non stiamo assistendo alla sostituzione improvvisa del C, ma a un’adozione selettiva di Rust nei punti in cui può offrire benefici concreti.

Fonti: systemd PR #44324 — supporto Rust · systemd PR #44114 — systemd-keyring-setup .

Python: cinque aggiornamenti di sicurezza e il problema dei certificati eMudhra

Il 26 ottobre 2026 il Python Release Team ha pubblicato cinque aggiornamenti di sicurezza accelerati:

• Python 3.15.2
• Python 3.14.10
• Python 3.13.18
• Python 3.12.16
• Python 3.11.18

Il motivo principale riguarda anche la gestione delle connessioni TLS e il caso delle chiavi compromesse di certificati intermedi della Certificate Authority eMudhra.

Che cosa c’entra pip con i certificati TLS?

Quando eseguiamo un comando come:

python -m pip install nome-pacchetto

pip recupera normalmente i pacchetti da PyPI attraverso una connessione HTTPS. Per capire come organizzare gli interpreti e gli ambienti di sviluppo, puoi approfondire la gestione degli ambienti virtuali Python con pyenv su Linux . Il protocollo TLS permette di proteggere la comunicazione e verificare l’identità del server mediante certificati digitali e una catena di fiducia collegata alle Certificate Authority.

La catena concettuale è:

pip → HTTPS/TLS → PyPI, con verifica dei certificati effettuata tramite la catena delle autorità di certificazione attendibili.

Python ha aggiornato il modulo ssl per rifiutare le catene di certificati che utilizzano gli intermedi eMudhra compromessi. È una protezione importante perché interviene a un livello sottostante al singolo programma: anche le normali operazioni di pip possono beneficiarne quando utilizzano un interprete Python aggiornato, pur senza una modifica specifica di pip per quel problema.

Questo non significa che PyPI sia stato compromesso, né che tutti i pacchetti Python siano diventati inaffidabili.

Altre correzioni e distribuzione degli aggiornamenti

Le cinque release includono anche correzioni relative a tarfile e http.cookiejar, oltre ad altri interventi dipendenti dalla versione.

Python 3.15.2 e 3.14.10 dispongono di installer binari ufficiali. Python 3.13.18, 3.12.16 e 3.11.18 sono invece pubblicate dal progetto come release di sicurezza source-only.

Su Linux, chi utilizza l’interprete fornito dalla distribuzione deve verificare gli aggiornamenti del manutentore: le patch di sicurezza possono essere integrate nei pacchetti distribuiti senza che il numero di versione coincida necessariamente con l’ultima release upstream.

Fonte: Python Insider — cinque release di sicurezza del 26 ottobre 2026 .

Cosa ci insegnano queste news Linux sulla sicurezza open source?

Quattro notizie, quattro livelli diversi della stessa questione.

La vulnerabilità del kernel ricorda l’importanza della separazione dei privilegi. Kali Linux mostra quanto contino strumenti affidabili e processi di build controllati. L’integrazione di Rust in systemd riguarda la qualità e la sicurezza del codice di sistema. Gli aggiornamenti Python dimostrano che la software supply chain comprende anche i certificati e i protocolli con cui riceviamo il software.

Per chi usa Linux tutti i giorni, il messaggio pratico è semplice: seguire gli advisory, verificare aggiornamenti e configurazioni, comprendere quali componenti siano esposti e distinguere sempre tra vulnerabilità teorica, exploit dimostrato e attacco realmente osservato. Per altri esempi di strumenti e verifiche, consulta l’approfondimento dedicato al network security testing su Linux .

Se vuoi approfondire queste notizie con spiegazioni e schemi, guarda il video completo su YouTube e iscriviti a ScrivoCodice per le prossime puntate settimanali dedicate a Linux, open source, programmazione e cybersecurity.

Nota editoriale: l’articolo riassume le notizie trattate nella puntata del 29 ottobre 2026. Le disponibilità delle correzioni possono cambiare: prima di effettuare interventi su sistemi in produzione consulta sempre gli advisory aggiornati dei produttori.