Il 21 ottobre 2026 PHP ha pubblicato quattro release di sicurezza per correggere due vulnerabilità critiche capaci di portare a esecuzione di codice da remoto senza autenticazione. La domanda per chi gestisce un sito WordPress non è soltanto «quale versione uso?», ma soprattutto «chi interviene quando la patch deve uscire subito?».
Il confronto utile è quindi tra hosting gestito e VPS autogestita. Il criterio non è la potenza teorica del server: è la capacità di ridurre il tempo tra l’avviso di sicurezza, l’aggiornamento effettivo e la verifica che il sito continui a funzionare.
Il caso PHP2Shell cambia il criterio di scelta
Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 interessavano il runtime PHP, non un singolo plugin WordPress. L’advisory ufficiale indicava come esposte le installazioni che servono richieste web tramite PHP-FPM, mod_php, php-cgi, FrankenPHP e LiteSpeed. Le versioni corrette erano PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Questo dettaglio separa subito i due modelli. Su un hosting gestito l’aggiornamento del runtime dipende dal provider. Su una VPS autogestita dipende da chi amministra sistema operativo, repository, PHP-FPM e web server. In entrambi i casi WordPress può risultare aggiornato mentre il livello sottostante resta vulnerabile.
Hosting gestito: meno controllo, meno passaggi manuali
Il vantaggio concreto del gestito è la riduzione della superficie operativa affidata al proprietario del sito. Il provider prepara o riceve i pacchetti, pianifica il rollout e mantiene il runtime. WordPress ricorda inoltre che la versione PHP è configurata a livello server dal servizio di hosting: se il pannello non consente il cambio, bisogna coinvolgere l’assistenza.
Per una PMI senza sistemista reperibile questo trasferimento di responsabilità ha valore. Non elimina il rischio e non garantisce che ogni provider aggiorni nello stesso momento, ma evita che la patch dipenda da una procedura improvvisata. Il controllo da fare resta molto semplice: chiedere quale build corretta è attiva, in quali tempi è stata distribuita e come viene gestito un eventuale rollback.
Il limite è la trasparenza. Il cliente vede spesso una voce «PHP 8.4» nel pannello, non la patch completa. Inoltre non decide l’ordine del rollout né le estensioni compilate. Se un’applicazione legacy richiede una configurazione particolare, il provider può diventare un vincolo invece che un vantaggio.
VPS autogestita: controllo pieno, responsabilità piena
La VPS consente di scegliere repository, finestra di manutenzione, configurazione PHP e strategia di rollback. È la soluzione più adatta quando il sito integra servizi custom, code, worker o automazioni che devono essere testati come un unico sistema. La stessa libertà, però, crea un requisito non negoziabile: qualcuno deve sapere che la patch esiste e deve poter intervenire.
Nel caso PHP2Shell, il progetto PHP ha specificato che le distribuzioni Linux e i vendor LTS avevano ricevuto le correzioni in anticipo. Su una VPS non basta quindi leggere il numero mostrato da php -v: serve verificare il pacchetto del vendor, applicare gli aggiornamenti, riavviare i servizi coinvolti e controllare che la build in esecuzione sia davvero quella corretta.
Il pro è la verificabilità. Log, pacchetti e configurazione sono sotto controllo diretto. Il contro è il costo organizzativo: inventario, monitoraggio degli advisory, backup, staging e reperibilità non sono optional. Se queste attività esistono solo nella testa di una persona, la VPS è tecnicamente flessibile ma operativamente fragile.
Il WAF aiuta, ma non sostituisce la patch
Cloudflare ha distribuito protezioni WAF contro PHP2Shell. È un livello utile, soprattutto mentre i pacchetti vengono distribuiti, ma l’indicazione ufficiale di PHP era netta: non esistevano mitigazioni complete e l’aggiornamento restava la scelta sicura.
Per WordPress questo significa usare la difesa a strati nel giusto ordine: runtime aggiornato, core e plugin mantenuti, accessi amministrativi controllati, backup verificati e WAF. Ho già spiegato come impostare la cache Cloudflare su WordPress senza coinvolgere le aree riservate; la stessa precisione serve quando si aggiungono regole di sicurezza davanti al sito.
Costi e tempi: il confronto reale
L’hosting gestito costa di più per unità di risorsa, ma include parte del lavoro operativo. La VPS appare economica se si confrontano solo CPU, RAM e spazio; smette di esserlo quando si contabilizzano monitoraggio, test, aggiornamenti e interventi fuori orario.
Per un sito vetrina, un e-commerce standard o un portale aziendale senza team infrastrutturale, il tempo di risposta vale più dell’accesso root. Per un progetto con integrazioni proprietarie, requisiti di rete o carichi non standard, la VPS può essere la scelta corretta, a condizione che esistano una persona responsabile, una procedura di patching e una prova periodica di ripristino.
Lo stesso principio vale per fornitori e agenzie: la sicurezza non si delega con una password condivisa. Serve definire chi può intervenire e quando revocare gli accessi. Una checklist pratica è nel mio approfondimento su come revocare gli accessi remoti a WordPress.
La scelta netta per PMI e professionisti
Se non hai già un processo documentato di patching server, scegli un hosting gestito che dichiari versioni, tempi di aggiornamento e supporto. Non comprare una VPS per risparmiare sul canone: senza ownership operativa stai solo spostando il costo verso il primo incidente.
Scegli invece la VPS quando il controllo serve davvero al prodotto e puoi sostenerlo con staging, monitoraggio e reperibilità. PHP2Shell mostra il punto decisivo: il modello migliore non è quello con più opzioni nel pannello, ma quello che porta una patch critica in produzione in modo rapido, verificabile e reversibile.