Quando il mare è calmo, ogni stronzo è marinaio. Il caso delle vulnerabilità PHP che noi abbiamo risolto, dove gli altri hosting hanno fallito miseramente.

Non capita tutti i giorni di leggere un titolo così sul blog di un’azienda. Siamo abituati a comunicati misurati, frasi levigate dall’ufficio marketing, aggettivi scelti per non offendere nessuno. Questa volta no. Questa volta abbiamo deciso di usare le parole che usiamo tra noi, in ufficio, davanti a un terminale, quando le cose si fanno serie. E il proverbio marinaro che dà il titolo a questo articolo è esattamente la frase che ci è venuta in mente nei giorni scorsi, guardando come il mondo dell’hosting ha reagito a una delle crisi di sicurezza più pesanti degli ultimi anni.

Da anni, nel mercato italiano, chi fa hosting viene messo tutto nello stesso calderone. Da una parte ci sono aziende che progettano infrastrutture, scrivono codice, studiano i problemi fino in fondo e li risolvono. Dall’altra c’è un esercito di rivenditori improvvisati che si limitano a comprare un server, installarci sopra un pannello come Plesk, cPanel o DirectAdmin, mettere un listino su un sito vetrina e chiamarsi “provider”. Per il cliente finale, che non ha gli strumenti per distinguere gli uni dagli altri, sono tutti uguali: un nome, un prezzo, un’offerta con scritto “SSD” e “supporto 24/7”.

Finché il mare è calmo, in effetti, la differenza non si vede. Un WordPress gira più o meno ovunque, un certificato SSL lo installa chiunque con un clic, e un backup notturno lo fa anche il pannello da solo. Tutti sembrano marinai.

Poi arriva la tempesta. E la tempesta, a fine ottobre 2026, ha un nome preciso.

La tempesta perfetta: due CVE da 9.2

Il 21 ottobre 2026 il progetto PHP ha corretto due vulnerabilità, CVE-2026-109618 e CVE-2026-109619, ribattezzate in rete PHP2Shell. Ne abbiamo parlato il giorno stesso: due falle con un punteggio di gravità CVSS di 9.2, sfruttabili da remoto e senza autenticazione, che riguardano qualunque installazione di PHP che serva richieste web. In parole semplici: un attaccante, senza avere alcun account, può arrivare a eseguire codice sul server. E i codici di attacco circolavano già prima che le patch fossero pubbliche.

Quando escono vulnerabilità di questo tipo non c’è molto da discutere. Non si fanno riunioni, non si aspetta il lunedì, non si manda una newsletter. Si aggiorna. Tutti gli hosting provider con un minimo di amor proprio, e con un minimo di rispetto per i propri clienti, hanno aggiornato PHP alle versioni corrette (8.5.12, 8.4.27, 8.3.36 e 8.2.35) nella mezz’ora successiva al rilascio. Noi lo abbiamo fatto su tutta la nostra infrastruttura. Fin qui, niente di speciale: è il minimo sindacale.

Il problema vero è un altro, ed è quello che separa chi sa navigare da chi ha solo comprato il cappello da capitano.

“Patchiamo solo dalla 8.2 in su”

Il progetto PHP è stato molto chiaro, come è giusto che sia: le versioni supportate sono quelle dalla 8.2 in poi, e solo quelle ricevono correzioni ufficiali. Per le versioni precedenti, fuori dal ciclo di vita, il team di sicurezza ha messo a disposizione una correzione minima dei sorgenti, pensata proprio per chi non può aggiornare subito.

A quel punto è intervenuto chi, nel mondo Linux, fa questo mestiere da vent’anni. Remi Collet, il manutentore del repository Remi che chiunque lavori con Red Hat, AlmaLinux o Rocky Linux conosce bene, ha portato la correzione sulle versioni ancora molto diffuse: PHP 8.1, 8.0 e 7.4, con pacchetti pronti all’uso. Ne abbiamo parlato in un articolo dedicato. Un lavoro enorme, fatto in pochi giorni, per cui la comunità dovrebbe essergli grata.

E sotto la 7.4? Lì la situazione si fa buia. Per la 7.3 e la 7.2 la correzione esiste nei sorgenti, ma non ci sono pacchetti pronti per le distribuzioni enterprise attuali come AlmaLinux 9. Per PHP 7.1, 7.0 e 5.6, invece, non c’è proprio niente: nessuna patch ufficiale, nessun pacchetto, nessun repository. Il vuoto.

Ed è qui che il mondo dell’hosting si è diviso in due.

La resa annunciata

Nei giorni successivi abbiamo letto comunicati di aziende di hosting, anche molto conosciute, che hanno detto pubblicamente quello che in fondo pensavano in tanti: per le versioni precedenti non esiste soluzione, abbiamo già contattato i clienti per invitarli ad aggiornare a una versione sicura di PHP, come potete vedere ad esempio dallo screen di seguito, non che sia l’unico, anzi, la totalità si sono posti in questo modo.

Detta così, sembra una frase responsabile. Prudente, persino. In realtà è una resa. È il capitano che, alla prima onda alta, annuncia ai passeggeri che la nave non è attrezzata per il mare grosso e che conviene cercarsi un’altra barca. Possibilmente in fretta, possibilmente da soli.

Sia chiaro: aggiornare PHP è sempre la strada giusta nel lungo periodo. Lo diciamo da anni e continueremo a dirlo. Ma c’è una differenza enorme tra consigliare a un cliente di pianificare una migrazione e dirgli, nel pieno di un’emergenza, che il problema è suo.

Il mondo reale non è fatto solo di WordPress

Chi si limita a gestire qualche centinaio di WordPress con un tema comprato su un marketplace può anche permettersi di pensare che aggiornare PHP sia una formalità. Si cambia versione dal pannello, si incrociano le dita, al massimo si disattiva un plugin che dà errore. Fine.

Ma l’hosting serio non è fatto solo di WordPress. È fatto di aziende che hanno in produzione:

• gestionali sviluppati dieci o quindici anni fa, di cui nessuno ha più lo sviluppatore originale;
• e-commerce su versioni datate di Magento, PrestaShop o soluzioni proprietarie, con personalizzazioni profonde che non funzionano sulle versioni nuove;
• portali, intranet e aree riservate integrati con sistemi esterni (ERP, CRM, gestionali di magazzino, sistemi di pagamento) che “funzionano e nessuno vuole toccare”;
• framework e librerie che non esistono più, scritti per PHP 5.6 o 7.1 e mai portati avanti.

Per questi progetti dire “aggiornate almeno alla 7.4” non è un consiglio: è una sentenza. Perché chi conosce davvero PHP sa benissimo cosa succede quando si sposta un’applicazione legacy da PHP 5.6 a PHP 7.4 o 8: funzioni rimosse, estensioni scomparse (mysql, mcrypt, ereg), comportamenti cambiati, errori che prima erano avvisi silenziosi e ora fermano tutto. Il software smette di funzionare. Non forse: sicuramente.

E il porting di un’applicazione del genere verso una versione recente di PHP non si fa in un pomeriggio. Richiede settimane, a volte mesi di lavoro: analisi del codice, correzioni, test, collaudo. Nel frattempo il sito deve restare online, gli ordini devono continuare ad arrivare, il gestionale deve continuare a fatturare. Non esiste un’azienda che possa permettersi di spegnere tutto per un mese perché il suo fornitore di hosting non sa come proteggerla.

Dire a un cliente in quella situazione “per la vostra versione non c’è soluzione, aggiornate” significa scaricargli addosso un problema che non è in grado di risolvere nei tempi che l’emergenza impone. È comodo per chi lo dice. È un disastro per chi lo riceve.

Cosa abbiamo fatto noi

Noi abbiamo scelto la strada opposta. Invece di dire che era impossibile, ci siamo rimboccati le maniche e lo abbiamo fatto.

Abbiamo preso la correzione pubblicata per PHP 7.4 e l’abbiamo riportata a mano sulle versioni precedenti: PHP 7.1, PHP 7.0 e PHP 5.6. Non si tratta di copiare e incollare una patch e sperare che si applichi. Il motore di PHP cambia moltissimo tra una versione e l’altra: strutture dati diverse, gestione della memoria diversa, interi pezzi del motore che in una versione esistono e nell’altra no. Per ogni versione abbiamo dovuto capire esattamente cosa corregge la patch originale, ritrovare nel codice vecchio i punti equivalenti e riscrivere le modifiche rispettando l’architettura di quella specifica release.

Per PHP 7.1 e 7.0 si è trattato di un porting accurato, riga per riga. Per PHP 5.6, che ha un motore completamente diverso da quello delle versioni 7, la correzione è stata riscritta da zero, seguendone la logica: stesso principio di protezione, implementato sulle strutture interne della 5.6. Per PHP 7.3 e 7.2 abbiamo usato la correzione già disponibile nei sorgenti, ricostruendo i pacchetti per i sistemi su cui lavoriamo, dato che pacchetti pronti non esistevano.

Poi abbiamo ricostruito tutto. Non un singolo binario di PHP buttato lì, ma l’intero ecosistema di ogni versione, così come lo usano davvero i nostri clienti: PHP-FPM, tutte le estensioni standard, i driver per MySQL, PostgreSQL e gli altri database, e le estensioni che fanno la differenza nei progetti reali, come Imagick per l’elaborazione delle immagini, Redis, APCu, igbinary, msgpack, zip, mcrypt e la vecchia estensione mysql per i software più datati. Il tutto per le distribuzioni enterprise moderne, dove queste versioni di PHP non esistono più in forma ufficiale.

Abbiamo testato ogni versione con le migliaia di test automatici del progetto PHP, verificato che ogni estensione si carichi e funzioni, provato l’elaborazione delle immagini con GD e ImageMagick, le connessioni cifrate, le sessioni, i database. E naturalmente abbiamo verificato che la correzione faccia esattamente quello che deve fare, nelle stesse condizioni in cui un attaccante proverebbe a sfruttare la vulnerabilità.

Infine abbiamo reso tutto disponibile in un repository interno, firmato digitalmente, a uso dei nostri sistemi e dei nostri clienti. Oggi siamo in grado di offrire in modo sicuro PHP 7.3, 7.2, 7.1, 7.0 e 5.6 corretti contro CVE-2026-109618 e CVE-2026-109619, e lo stesso lavoro può essere esteso anche a PHP 5.4 e 5.5 per chi ne avesse bisogno.

Non entriamo volutamente nei dettagli tecnici di come lo abbiamo fatto. Non per vanità, ma perché il know-how è esattamente ciò che fa la differenza tra noi e gli altri, e non abbiamo intenzione di regalare a nessuno il lavoro di giorni e notti passati sul codice del motore di PHP.

Una cosa però vogliamo dirla con onestà, perché la serietà passa anche da qui: la correzione che abbiamo applicato segue la stessa logica di quella ufficiale, che per scelta dei manutentori di PHP è una mitigazione minima pensata per le versioni fuori supporto. Mette al sicuro dalla vulnerabilità, non trasforma PHP 5.6 in PHP 8.4. Resta un ponte, un ponte solido, che permette di attraversare l’emergenza e di pianificare con calma, e con i tempi giusti, la migrazione verso una versione supportata. Senza panico, senza siti spenti, senza porting fatti di corsa che creano più problemi di quanti ne risolvono.

Perché non è una cosa da tutti

Qualcuno potrebbe pensare: se lo avete fatto voi, lo può fare chiunque. In teoria sì. In pratica però lo abbiamo fatto solo noi, e questo è quello che conta. Per arrivare in fondo servono contemporaneamente competenze che raramente si trovano sotto lo stesso tetto, e tanto meno sotto il tetto di chi vende hosting a cinque euro al mese.

Serve saper leggere e scrivere C a livello di sistema, perché PHP è scritto in C e la vulnerabilità sta nelle viscere del suo motore, non in uno script. Serve conoscere l’architettura interna di PHP e come è cambiata nel corso di dieci anni di versioni, perché una modifica sbagliata di una riga, in quel punto del codice, non produce un errore evidente: produce un PHP che sembra funzionare e che poi, sotto carico, in produzione, si comporta in modo imprevedibile.

Serve conoscere a fondo il packaging delle distribuzioni enterprise, perché una versione di PHP del 2016 non si compila e non si installa così com’è su un sistema operativo del 2026: le librerie di sistema sono cambiate, alcune non esistono più, altre hanno cambiato interfaccia. Serve saper gestire le dipendenze, le estensioni, la convivenza di più versioni sullo stesso server, la firma dei pacchetti e la loro distribuzione sicura.

E serve, soprattutto, il metodo: verificare tutto, non dare niente per scontato, confrontare il risultato con l’originale, provare ogni pacchetto come lo userebbe un cliente vero prima che arrivi su un server di produzione. Il metodo non si improvvisa la notte dell’emergenza. Si costruisce in anni di lavoro su sistemi veri, con clienti veri e problemi veri.

Non è un caso che, in queste settimane, il silenzio su PHP 7.1, 7.0 e 5.6 sia stato quasi totale. Non perché il problema non esistesse: perché quasi nessuno era in grado di affrontarlo.

La competenza si vede quando gli altri aspettano

Il punto non è la singola patch. Il punto è l’atteggiamento.

Quando esce un problema serio, la maggior parte dei fornitori di hosting fa una cosa sola: aspetta. Aspetta che il produttore del pannello rilasci un aggiornamento, che il vendor pubblichi una patch, che qualcun altro, da qualche parte nel mondo, risolva il problema al posto suo. Se la soluzione arriva, la installa e manda una mail ai clienti dicendo che “il nostro team ha prontamente risolto”. Se la soluzione non arriva, manda una mail ai clienti dicendo che non si può fare niente.

Noi non aspettiamo. Non è la prima volta che lo dimostriamo e non sarà l’ultima.

Lo abbiamo fatto con il bug di NGINX in HTTP/3 che impediva la valorizzazione della variabile $http_host sulle connessioni QUIC: un problema che faceva impazzire configurazioni, redirect e applicazioni, e che nel mondo tutti si limitavano a segnalare o a scavalcare con qualche workaround. Noi lo abbiamo analizzato, abbiamo trovato la causa nel codice di NGINX e lo abbiamo corretto, in autonomia, proponendo la patch alla comunità.

Lo abbiamo fatto con WAF4NGINX, il web application firewall che abbiamo sviluppato internamente per difendere i siti dei nostri clienti dalle ondate di bot che si mascherano da browser legittimi: richieste che imitano alla perfezione Chrome, Firefox o Safari e che i sistemi tradizionali non riescono a distinguere dal traffico umano. Con WAF4NGINX li filtriamo con precisione chirurgica, senza alcuna intrusione visiva per gli utenti reali: niente pagine di attesa, niente caselle da spuntare, niente banner di verifica del browser come quelli a cui ci hanno abituato soluzioni come Cloudflare, che a ogni controllo fanno perdere un visitatore o una conversione. Chi vuole capire come ragioniamo su questi temi può leggere come si costruiscono sistemi anti-bot efficaci.

Sono storie diverse con un filo comune: quando il problema è difficile e nessuno ha la soluzione pronta, noi la costruiamo.

La resa dei conti

Oggi molti utenti con siti su versioni di PHP non più corrette si troveranno a fare i conti con la realtà. Scopriranno che il loro fornitore, quello con l’offerta così conveniente e il pannello così comodo, di fronte al primo vero problema ha saputo solo inoltrare un consiglio: aggiornate. Scopriranno che dietro il marchio, il sito patinato e il supporto “24/7” non c’era nessuno in grado di mettere le mani nel motore. Scopriranno, nel modo peggiore, la differenza tra un rivenditore di spazio web e un’azienda di ingegneria dei sistemi.

Per i nostri clienti, invece, questa può essere una settimana come le altre. Il sito su PHP 7.1 continua a servire pagine, il gestionale su PHP 5.6 continua a fatturare, l’e-commerce continua a ricevere ordini. Nessuno deve riscrivere il proprio software in una notte, nessuno deve trovare in fretta uno sviluppatore disponibile, nessuno deve scegliere tra restare vulnerabile e restare spento. La correzione si installa sul server come un normale aggiornamento di sistema, nella stessa versione di PHP già in uso, senza toccare una riga del codice dell’applicazione. E la migrazione verso una versione moderna di PHP, che resta l’obiettivo, si pianifica insieme con i tempi giusti, non con i tempi del panico.

E sia chiaro: non è una colpa non saper fare tutto. Nessuno può avere competenze universali. La colpa, semmai, è non voler uscire dalla propria zona di comfort e rinunciare a pratiche consolidate da decenni nell’ambito della sistemistica, come il backporting delle patch di sicurezza.

È esattamente ciò che fa abitualmente Red Hat quando, ad esempio, adatta una correzione sviluppata per una vulnerabilità individuata in un kernel Linux recente, appartenente al ramo 6.x, a un kernel molto più vecchio, come quello del ramo 4.x, senza necessariamente aggiornare l’intero sistema a una nuova versione.

Il fatto che oggi molti hosting provider e sistemisti non lo facciano non significa affatto che sia tecnicamente impossibile. Significa, piuttosto, che si è progressivamente consolidata una prassi per cui ciò che non viene più fatto dalla maggioranza finisce per essere considerato inutile, impraticabile o addirittura impossibile.

Una sorta di «mal comune, mezzo gaudio» applicato alla sistemistica, dove i limiti delle proprie competenze vengono scambiati per limiti della tecnologia e dove l’abitudine a non fare qualcosa diventa, paradossalmente, la giustificazione per continuare a non farla.

Ma la realtà tecnica, come abbiamo dimostrato, è ben diversa. Il backporting delle patch di sicurezza è possibile, è una pratica consolidata nell’industria del software e, quando eseguito correttamente e sottoposto alle necessarie verifiche, consente di mantenere sicuri anche componenti legacy.

La differenza è che noi sappiamo farlo. E lo facciamo.

Noi, da parte nostra, abbiamo già dimostrato più volte di avere molto altro da offrire oltre un banale hosting. Un hosting con prestazioni discrete oggi riescono a offrirlo più o meno tutti: i server costano poco, i pannelli fanno quasi tutto da soli e l’intelligenza artificiale scrive le configurazioni al posto di chi non le sa scrivere. Quello che non si compra, non si installa e non si improvvisa è la competenza: la capacità di capire un problema nel profondo e di risolverlo quando nessun altro lo ha ancora fatto.

Una linea netta

Questa vicenda ha riguardato tutti gli hosting provider del mondo, senza eccezioni. Lo stesso problema, nello stesso momento, per tutti. Ed è proprio per questo che è stata così rivelatrice: non c’erano scuse, non c’erano vantaggi di partenza, non c’erano clienti più facili o più difficili. C’era solo una domanda, uguale per tutti: e adesso, per chi è rimasto indietro, che si fa?

La risposta ha tracciato una linea netta.

Da una parte c’è chi ha continuato a offrire ai propri clienti il servizio di cui avevano bisogno, mettendo in sicurezza le versioni vulnerabili con il proprio lavoro e la propria competenza, e dando loro il tempo di pianificare con serenità il futuro.

Dall’altra c’è chi, non sapendolo fare, si è limitato a parlare con il cliente spronandolo a fare un porting verso una versione sicura, come se quella fosse sempre una strada percorribile, facile e veloce. Come se bastasse un clic.

Se avete un sito o un’applicazione su PHP 7.3, 7.2, 7.1, 7.0 o 5.6, e il vostro fornitore vi ha detto che “non c’è soluzione”, sappiate che non è vero. La soluzione c’è, la abbiamo già costruita e la usiamo ogni giorno. Trovate i dettagli del nostro servizio di backporting delle patch di sicurezza PHP e, se volete parlarne, contattateci: analizziamo la vostra situazione e vi diciamo con chiarezza cosa si può fare, in quanto tempo e con quali limiti.

Perché quando il mare è calmo, ogni stronzo è marinaio. Ma è nella tempesta che si vede chi sa davvero tenere il timone.