Falla grave del kernel Linux: riguarda il tuo negozio PrestaShop?

Se hai letto che c'è una falla grave del kernel Linux e hai un negozio PrestaShop, è probabile che ti riguardi: quasi tutti i negozi funzionano su Linux. Con questa falla nessuno entra direttamente nel tuo negozio da internet, ma chi è già riuscito a eseguire qualcosa sul tuo server può impadronirsi dell'intera macchina. Quello che devi fare oggi dipende da dove si trova il tuo negozio: su un hosting condiviso, chiedi al tuo fornitore; su un server tuo, aggiorni e riavvii.

L'avviso che ha riacceso il tema è arrivato il 28 ottobre, quando l'agenzia statunitense per la cybersicurezza, la CISA, ha aggiunto la falla Fragnesia al suo elenco delle vulnerabilità già usate in attacchi reali.

Cosa è successo con il kernel Linux?

Il kernel è il pezzo centrale di Linux: quello che comanda tutto il resto che gira sul server. Quest'anno sono uscite diverse falle gravi una dopo l'altra, ed è per questo che vedi tanti titoli: Copy Fail, Dirty Frag, Fragnesia, GhostLock, Vghost. Da maggio, la CISA ha aggiunto a quell'elenco otto falle del kernel.

Non serve che impari i nomi. Queste cinque hanno in comune ciò che ti interessa davvero: sono falle locali.

Possono entrare nel mio negozio PrestaShop da questa falla?

Da sola, no. Microsoft lo spiega parlando di Copy Fail: l'attaccante deve aver già messo piede sulla macchina. E Red Hat dice lo stesso di Fragnesia: serve l'accesso locale al sistema.

Pensa al tuo server come a un palazzo di uffici. Queste falle non aprono il portone sulla strada. Ma a chi è già dentro, anche solo in uno sgabuzzino, danno le chiavi di tutto il palazzo.

E come si arriva in quello sgabuzzino? Per strade piuttosto comuni:

• Un modulo con una falla di sicurezza che permette di eseguire codice sul tuo server.
• Un altro sito del tuo stesso account, come quel vecchio WordPress che nessuno aggiorna.
• Il sito di un altro cliente, se sei su un hosting condiviso. CloudLinux, il cui sistema è usato da molti hosting, avverte che un cliente malintenzionato potrebbe arrivare ad altri account della stessa macchina.
• Una falla in PHP, come PHP2Shell.

L'ultimo caso non è teoria. Nella sua scheda su Fragnesia, la CISA avverte che questa falla si può concatenare con PHP2Shell per installare una porta di servizio ed eseguire comandi con il controllo totale del server. La CISA non ha dato dettagli su quegli attacchi e ciò che abbiamo letto non parla di negozi online: nessun motivo di panico, ma ogni motivo per chiudere entrambe.

Perché non basta aggiornare il server?

Perché un kernel nuovo non fa nulla finché il server non si avvia con esso. Lo ricordano Ubuntu, AlmaLinux e il centro canadese per la cybersicurezza: aggiornare e riavviare. Un server può avere la correzione installata da settimane e funzionare ancora con il kernel vecchio.

L'altro modo è la correzione a caldo: strumenti come KernelCare, che applicano la correzione sul kernel in funzione, senza riavviare. Su un hosting condiviso ogni riavvio lascia senza servizio tutti i clienti, quindi «non abbiamo riavviato» non è un brutto segno se ti dicono che la correzione a caldo c'è.

Cosa devo fare in base a dove si trova il mio negozio?

Se sei su un hosting condiviso

Entri in un pannello, come cPanel o Plesk, e non amministri il server. Il kernel è compito del tuo fornitore; il tuo è chiedere. Copia e invia questo:

Una buona risposta contiene dati: una versione, una data, il nome dello strumento. Se ti rispondono solo «siamo aggiornati», chiedi di nuovo la versione. Se in un paio di giorni non chiariscono, è un buon momento per pensare di cambiare.

Se hai un VPS o un server dedicato

Qui tocca a te o a chi te lo gestisce: installare gli aggiornamenti di sicurezza e riavviare. Scegli un'ora con poche vendite, perché il negozio resta giù per qualche minuto, e al ritorno controlla che si possa comprare.

Poi confronta la versione in funzione con quella dell'avviso del tuo sistema: Ubuntu, Debian, AlmaLinux o Red Hat. Ogni sistema numera a modo suo: guarda sempre il tuo.

Se il tuo negozio gira in un container

Docker e simili, e anche alcuni VPS economici che in realtà sono container. Condividono il kernel della macchina che li ospita, quindi aggiornare dall'interno non cambia nulla. La correzione la mette chi amministra quella macchina: se è il tuo fornitore, inviagli il messaggio qui sopra.

Cosa fare oggi, in ordine

1. Scopri in quale caso sei: condiviso, server tuo o container. Se non lo sai, chiedilo al tuo hosting.
2. Fai un backup completo, file e database, e conservalo fuori dal server.
3. Invia il messaggio al tuo hosting, oppure aggiorna e riavvia se il server è tuo.
4. Chiudi le porte d'ingresso: PHP con la correzione di PHP2Shell, moduli aggiornati e via ciò che non usi più, moduli o vecchi siti del tuo account. Quale PHP accetta ogni versione lo trovi in quale versione di PHP serve a PrestaShop.
5. Cerca segnali che qualcuno sia già entrato, come una finestra strana visitando il tuo negozio o file che non riconosci.

Aggiornare chiude la porta, ma non caccia chi è già dentro. Microsoft avverte che le misure di protezione possono non annullare ciò che un attaccante ha già fatto.

Se qualcosa non ti torna, comincia da come appare un negozio hackerato con ClickFix, e non cancellare nulla finché qualcuno non ha controllato: quei file dicono da dove sono entrati.

Per il tuo team tecnico

Kernel in funzione: uname -r rispetto a quello installato (rpm -q kernel, dpkg -l 'linux-image*'). Le correzioni arrivano per backport senza cambio visibile di versione: conta la revisione del pacchetto, non il numero di kernel.org.

Revisioni con la correzione di Fragnesia (CVE-2026-46300): Ubuntu 26.04 7.0.0-22.22, 24.04 6.8.0-124.124, 22.04 5.15.0-181.191; AlmaLinux 8 4.18.0-553.124.3.el8_10, 9 5.14.0-611.54.5.el9_7, 10 6.12.0-124.56.3.el10_1. Ogni CVE ha la sua: installa l'ultima del tuo ramo.

Non ancora chiusa su tutti i rami: Vghost (CVE-2026-74580). Al 4 novembre, Ubuntu la dà corretta su 26.04 e 22.04 e in corso su 24.04. Red Hat la colloca soprattutto sulle macchine di virtualizzazione e richiede l'accesso a /dev/vhost-*: finché non è corretta, non esporlo a container né a utenti non fidati.