PHP2Shell, ovvero come abbiamo affidato Internet a un linguaggio nato per fare un contatore di visite

Due vulnerabilità di memory safety nel core di PHP, CVE-2026-109618 e CVE-2026-109619, collettivamente note come PHP2Shell. Permettono l'esecuzione di codice da remoto. Punteggio CVSS: 9.2 su 10. Il punto e otto mancanti è puramente cerimoniale, perché nessuno ha il coraggio di dare 10 a qualcosa.

Conclusione anticipata, perché tanto fin qui arriva solo chi ha fretta: aggiornate PHP. Gli altri restino, che c'è da ridere. Poco, ma c'è.

La sedia dell'IKEA

PHP nasce a metà degli anni Novanta come un pugno di script per gestire una home page personale. Una cosa piccola, innocente, artigianale.

Trent'anni dopo, quella cosa piccola e innocente regge una porzione imbarazzante di Internet: blog, e-commerce, gestionali pubblici, il sito della pizzeria sotto casa e, con ogni probabilità, il portale da cui vostra madre prenota le analisi del sangue.

È come se il ponte sullo Stretto lo reggesse una sedia dell'IKEA montata nel 1995 senza istruzioni. Regge, eh. Regge. Finché qualcuno non ci si siede sopra nel modo sbagliato.

E qualcuno, puntualmente, ci si è seduto.

La memory safety spiegata a mio zio

PHP è scritto in C. Il C è un linguaggio meraviglioso, potente ed elegante, che ti dà accesso diretto alla memoria del computer, e poi si gira dall'altra parte.

Il C non controlla niente. Il C si fida di te. Il C è quell'amico che ti presta la macchina senza chiederti se hai la patente, se hai bevuto, o se sai cos'è un freno.

Se scrivi un dato nel posto sbagliato della memoria, il C non dice niente. Non un warning, non un "sei sicuro?". Silenzio. E quel silenzio, in informatica, si chiama comportamento indefinito. Tradotto dal tecnichese: può succedere qualunque cosa, compreso che uno sconosciuto in un altro continente prenda il controllo del tuo server e ci installi un miner di criptovalute che si chiama tipo SuperMegaCoin.

Cosa succede, in pratica

Un attaccante manda dati costruiti ad arte, PHP li gestisce male a livello di memoria, e alla fine l'attaccante riesce a far girare codice suo sul vostro server. Come si fa nel dettaglio non ve lo spiego: questo è un blog di divulgazione, non un corso serale per ragazzini con la felpa e troppo tempo libero.

Attaccante:  *manda una richiesta strana*
PHP:         "mh, strano, vabbè"
PHP:         *gestisce la memoria come un ubriaco gestisce le chiavi di casa*
Attaccante:  *è dentro*
Voi:         *dormite*
Il server:   *mina SuperMegaCoin*

Quanto è grave

Il KEV (Known Exploited Vulnerabilities) è la lista delle falle che vengono usate davvero, adesso, da gente vera. Non sono vulnerabilità da conferenza, di quelle che servono a pubblicare un paper e appuntarsi la medaglia. Quando una CVE finisce lì dentro non è più "potrebbe succedere": è "sta succedendo, e forse proprio a te".

Quando poi pure l'FBI scrive pubblicamente "aggiornate e controllate se vi hanno già bucato", siamo al medico che guarda la lastra, si toglie gli occhiali e dice: "si sieda".

Il colpo di scena

La correzione è uscita il 21 ottobre senza cambiare il numero di versione di PHP. Avete capito bene: hanno sistemato il codice vulnerabile e lasciato il numerino identico.

Quindi se lanciate php -v e vedete la versione giusta, non vuol dire niente. Potreste avere quella corretta, oppure quella bucata con lo stesso identico numero. Sono due bottiglie con la stessa etichetta e la stessa data, e in una c'è la candeggina.

Per sapere se siete al sicuro dovete controllare con chi vi fornisce PHP (la distribuzione Linux, Plesk, l'hosting) che il pacchetto installato contenga la correzione.

Le cinque fasi del sistemista

1. Negazione: "Noi non usiamo PHP." Usano WordPress.
2. Rabbia: "Ma chi c***o scrive ancora in C nel 2026?!"
3. Contrattazione: "Se mettiamo il WAF davanti forse possiamo aspettare la finestra di manutenzione di dicembre..."
4. Depressione: apre i log.
5. Accettazione: aggiorna alle 23:47 di venerdì.

Cosa fare, in ordine

1. Aggiornate. Adesso. Non dopo il caffè, non dopo la call, non "appena ho un attimo". Adesso.
2. Verificate che il pacchetto installato includa davvero la correzione. Vedi la candeggina.
3. Andate a caccia. Log, processi in esecuzione, file modificati di recente nella cartella del sito. Se trovate un x.php, uno shell.php o un wp-config-backup-old-new-FINAL2.php che non avete creato voi, non è un vostro vecchio backup. Non vi illudete.
4. Mettete un WAF davanti. Non vi rende invulnerabili, ma è il cancello del giardino: il ladro deciso entra lo stesso, quello di passaggio no.
5. Non esponete roba inutile. Il pannello di amministrazione aperto a tutto Internet con utente admin e password admin123 non è un "piccolo rischio accettabile". È un invito a cena scritto a mano.

In conclusione

PHP non morirà mai. Sopravviverà a noi, ai nostri figli e probabilmente alla morte termica dell'universo. Fra dieci miliardi di anni, nel freddo vuoto cosmico, ci sarà ancora un server con dentro un WordPress 4.2 non aggiornato.

Ma non è un buon motivo per lasciarlo bucato.

Aggiornate. Fatelo per gli utenti, e per il vostro fegato, che non merita un altro venerdì sera in ufficio.