Server Linux: un utente limitato non basta più. Kernel aggiornato e riavvii
Il 4 novembre OpenAI ha pubblicato i risultati di una pipeline di agenti AI che ha trovato e sfruttato centinaia di vulnerabilità nel kernel Linux. Il messaggio per chi gestisce server è semplice: su un sistema non aggiornato, un account limitato vale quasi quanto un accesso da amministratore.
Cosa è successo
Il 4 novembre 2026 OpenAI ha descritto una pipeline di agenti AI che cerca vulnerabilità nel kernel Linux, le riproduce, prova a sfruttarle e propone una correzione. In una sola esecuzione a metà ottobre ha esaminato 2.308 possibili difetti, ne ha riprodotti 1.724 e ha prodotto 948 exploit distinti di escalation locale dei privilegi su una distribuzione Linux di uso comune, non indebolita (OpenAI).
Il costo dichiarato è di circa 1,2 milioni di dollari di utilizzo dei modelli, circa 1.279 dollari per exploit. Secondo OpenAI gli agenti hanno usato almeno 10 tecniche di sfruttamento che nemmeno gli esperti consultati conoscevano.
Le correzioni stanno arrivando in fretta: nei 10 giorni della ricerca 61 di queste vulnerabilità erano già corrette nel kernel ufficiale, 43 avevano una patch in preparazione e 299 erano in discussione pubblica (OpenAI). Arrivano, però, a chi aggiorna.
Cos'è un'escalation locale dei privilegi
Su un server Linux ogni programma gira con i permessi di un utente. Un sito WordPress, per esempio, gira di solito con un utente che può leggere e scrivere solo i propri file. Se il sito viene violato, l'attaccante ottiene quei permessi e niente di più: è il principio su cui si basa l'isolamento tra siti.
Un'escalation locale dei privilegi (in inglese local privilege escalation, LPE) è un difetto che permette a quell'utente limitato di diventare root, cioè amministratore del server. Da root si leggono i file di tutti i siti, le password dei database, le chiavi, e si può installare qualsiasi cosa.
La conclusione di OpenAI è netta: nel breve e medio periodo, un account a bassi privilegi su un sistema senza le ultime patch va considerato equivalente a un accesso root per un attaccante con risorse (OpenAI).
Perché riguarda anche una PMI
Un attacco di questo tipo ha bisogno di un primo punto d'appoggio sul server. Nei casi reali è quasi sempre uno di questi:
- un sito violato tramite un plugin vulnerabile o una falla come PHP2Shell;
- un account SSH di un fornitore o di un ex collaboratore rimasto attivo;
- un'applicazione che esegue codice caricato dagli utenti, come importazioni di file o anteprime di documenti.
Su un server con un solo sito il danno resta in quel sito. Su un server che ospita dieci siti di clienti diversi, un'escalation trasforma il problema di un sito nel problema di tutti. Per questo l'isolamento per utente è utile, ma tiene solo se il kernel sotto è aggiornato.
Aggiornare il kernel non basta: bisogna riavviare
Un dettaglio che si dimentica spesso: installare il pacchetto del nuovo kernel non protegge il server. Il kernel corretto entra in funzione solo al riavvio successivo. Un server acceso da mesi può avere l'ultimo kernel scaricato sul disco e continuare a girare con quello vecchio.
| Situazione | Il server è protetto? |
|---|---|
| Aggiornamenti automatici attivi, nessun riavvio da mesi | No: il kernel in uso è quello dell'ultimo avvio |
| Kernel aggiornato e server riavviato | Sì, fino alla prossima correzione |
| Livepatch attivo, riavvii programmati | Sì per le vulnerabilità gravi e critiche corrette a caldo; il resto al riavvio |
| Sistema operativo fuori supporto | No: le correzioni non arrivano più |
Su Ubuntu esiste Livepatch, che applica in memoria le correzioni del kernel per le vulnerabilità gravi e critiche senza riavviare. È incluso in Ubuntu Pro, gratuito per uso personale fino a 5 macchine. Canonical stessa precisa che non elimina i riavvii programmati, li riduce (Ubuntu).
Cosa fare sui vostri server
- 01
Controllate il kernel in uso
Per ogni server confrontate il kernel in funzione con l'ultimo installato e guardate da quanto tempo il server è acceso. Su Ubuntu e Debian il file /var/run/reboot-required segnala che serve un riavvio.
- 02
Fissate una finestra di riavvio
Un riavvio programmato ogni settimana o due, in un orario di basso traffico, costa pochi minuti di interruzione e chiude il problema alla radice. Per i siti che non possono fermarsi si progetta la ridondanza, non si rimanda il riavvio.
- 03
Attivate Livepatch dove serve
Sui server più esposti copre le vulnerabilità gravi tra una finestra di riavvio e l'altra.
- 04
Uscite dai sistemi fuori supporto
Un sistema operativo a fine vita non riceve più correzioni del kernel: va migrato, oppure coperto con un supporto esteso come Ubuntu Pro.
- 05
Togliete gli accessi che non servono
Account SSH di fornitori ed ex collaboratori, chiavi vecchie, utenti di prova: ogni account locale è un possibile punto di partenza.
- 06
Separate quello che vale di più
I siti e le applicazioni con dati sanitari, pagamenti o dati di clienti stanno meglio su server o account cloud propri. Se uno viene compromesso, gli altri restano fuori.
- 07
Controllate cosa succede
Nuovi utenti, nuove chiavi SSH, processi di root sconosciuti e file di sistema modificati sono i segnali che contano. Meglio scoprirli da un controllo automatico che da un cliente.
Come lavoriamo
In Cloudfactory gestiamo oltre 110 server Linux e Windows per aziende, studi professionali e strutture sanitarie. Dopo PHP2Shell abbiamo rafforzato l'isolamento tra i siti; questa ricerca ricorda che l'isolamento vale quanto il kernel su cui poggia. Per questo nei nostri piani di manutenzione aggiornamenti del kernel e riavvii hanno una data, e i progetti con dati delicati girano su infrastruttura separata.
Se volete sapere da quanto i vostri server non vengono riavviati e con quale kernel stanno girando, scriveteci: è un controllo rapido.
Come abbiamo scritto questo articolo
In Cloudfactory usiamo l'intelligenza artificiale anche nel lavoro editoriale: ci aiuta a cercare e incrociare le fonti, a confrontare i dati, a impostare la struttura e a rifinire la lingua. Il sistema che usiamo è configurato da noi, con istruzioni, esempi e procedure costruiti sul nostro modo di scrivere. Il nostro team ha controllato ogni fonte, corretto il testo e approvato la versione pubblicata. Le valutazioni e le scelte sono di Cloudfactory, e ne rispondiamo noi.
Domande frequenti
Se il mio server ha gli aggiornamenti automatici sono tranquillo?
Non del tutto. Gli aggiornamenti automatici installano il nuovo kernel, ma finché il server non viene riavviato continua a usare quello vecchio. Controllate da quanto tempo è acceso.
Queste vulnerabilità si sfruttano da Internet?
No, servono un accesso iniziale al server, per esempio un sito violato o un account SSH. Sono la seconda metà di un attacco: trasformano un problema limitato in un controllo completo del server.
Livepatch sostituisce i riavvii?
No. Copre le vulnerabilità gravi e critiche del kernel tra una finestra di manutenzione e l'altra, ma Canonical consiglia comunque riavvii programmati.
Uso un hosting condiviso: cosa posso fare?
Chiedete al fornitore con che frequenza aggiorna e riavvia i server e se i siti dei clienti sono isolati. Se il sito tratta dati delicati, valutate un server dedicato.