Falle critiche in PHP: perché i siti vetrina non hanno bisogno di eseguirlo

Il 21 ottobre il progetto PHP ha rilasciato correzioni d'emergenza per due vulnerabilità critiche, identificate come CVE-2026-109618 e CVE-2026-109619, entrambe valutate 9.2 su CVSS v4.0 e capaci, in certe condizioni, di portare all'esecuzione di codice da remoto senza autenticazione. Le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per i rami non più supportati non ci sono correzioni ufficiali. Le condizioni di sfruttamento le leggo dall'annuncio su php.net, che consiglio di verificare: le fonti secondarie non sono sempre allineate.

Non voglio fare l'ennesimo articolo di allarme. Voglio dire cosa mi hanno ricordato queste ore passate ad aggiornare server: la maggior parte dei siti che gestisco non aveva alcun motivo di eseguire PHP.

Il costo di eseguire codice a ogni richiesta

Un sito WordPress, a ogni richiesta non servita dalla cache, avvia PHP, carica il core, il tema e i plugin, interroga il database e assembla una pagina che sarà identica a quella di ieri. Per un sito vetrina, dove i contenuti cambiano una volta l'anno, il lavoro è sprecato e, peggio, è un punto d'ingresso: finché esiste un interprete raggiungibile da internet, ogni falla del linguaggio, del core, di un plugin o del tema è un'emergenza.

Una falla come queste ha una proprietà scomoda: non dipende da quanto sei stato prudente con i plugin. Colpisce il runtime sotto, quello che non scegli sito per sito. L'unica difesa è l'aggiornamento tempestivo, e l'aggiornamento tempestivo di decine di siti, ciascuno con la sua versione di PHP, il suo hosting e la sua compatibilità con i plugin, è esattamente il tipo di lavoro che preferirei non dover rifare a ogni vulnerabilità. Ne ho parlato in Sito WordPress hackerato: la finestra tra la pubblicazione di una falla e l'aggiornamento è il momento in cui gli scanner automatici lavorano meglio.

Perché sto migrando i siti vetrina

Per questo sto portando i siti vetrina su un'architettura statica. Non perché WordPress sia un cattivo strumento, ma perché a un sito che cambia di rado non serve né un database né un linguaggio eseguito a ogni visita. Il sito viene costruito una volta, in fase di build, e pubblicato come file su una CDN. Chi lo visita riceve HTML già pronto.

Le conseguenze pratiche sono tre.

• Meno superficie d'attacco: sul server pubblico non gira PHP, non c'è wp-login.php e non c'è un database da raggiungere. Una falla nell'interprete non ha nulla da colpire, perché non c'è un interprete.
• Velocità: l'HTML è già costruito, quindi il tempo di risposta dipende dalla CDN e non dal server che assembla la pagina. Per LCP e Core Web Vitals è un vantaggio strutturale, non un ritocco, e quindi aiuta anche la SEO. Ho scritto di cosa fa davvero lento un sito in Sito WordPress lento.
• Meno manutenzione urgente: nessuna corsa agli aggiornamenti di PHP, di tema e plugin per un sito che nessuno tocca da mesi.

Dire che un sito statico sia «inattaccabile» è comodo ma non è vero. Restano da proteggere gli account di GitHub, del provider e del dominio con l'autenticazione a due fattori, le dipendenze usate nella build e le eventuali funzioni server per moduli o chat. È una superficie piccola e conosciuta, non nulla.

Ma i contenuti, come si aggiornano?

È l'obiezione giusta, e per alcuni clienti il pannello è indispensabile: lo so bene, per anni ho lavorato così. Il punto è che il pannello non deve per forza stare sullo stesso server che serve il sito. Le strade che uso o valuto sono queste.

• Nuxt Studio: un editor che lavora sui file Markdown del progetto. Chi scrive modifica i testi da browser, anche con un'anteprima, e il salvataggio diventa un commit su GitHub; Netlify ricostruisce il sito. Non c'è un database di mezzo e ogni modifica ha un autore e si può annullare. È la soluzione che uso più spesso quando il sito è in Nuxt Content.
• Strapi: un CMS headless da installare e gestire per conto proprio, con tipi di contenuto, ruoli e API. Lo uso in Fix and Sail, dove serve anche una parte applicativa. Ha un suo database e un suo server, ma sono separati dal sito pubblico, dietro un accesso riservato.
• Storyblok o altri CMS headless in servizio: l'editor visuale è ospitato dal fornitore, il sito legge i contenuti via API e si ricostruisce a ogni pubblicazione. Si evita di gestire un server, in cambio di un canone e di una dipendenza da un servizio esterno.

La scelta dipende da chi scrive. Con tre pagine da correggere una volta l'anno basta il Markdown; con una persona di redazione serve un pannello; con più ruoli e flussi di approvazione si valuta un CMS vero. Il criterio comune è che il pannello stia fuori dal percorso di chi visita il sito, così la sua eventuale falla non diventa una falla del sito pubblico.

Quando WordPress resta la scelta giusta

Non migro tutto. Un negozio con WooCommerce, una redazione che pubblica ogni giorno, un sito che dipende da plugin senza equivalente semplice: lì WordPress ha ancora senso, e il lavoro diventa tenerlo asciutto, con pochi plugin, PHP aggiornato e una manutenzione seria. Il confronto completo, con la procedura di migrazione, sta in Da WordPress a Nuxt.js, GitHub e Netlify.

Come la vedo io

Amo WordPress, ci ho costruito siti di cui vado fiero. Ma l'ultima emergenza mi ha chiarito una cosa: per un sito vetrina che si aggiorna una volta l'anno, tenere acceso un motore dinamico solo per mostrare pagine ferme è un rischio che non serve a nessuno. Preferisco costruire una volta, pubblicare su una CDN e lasciare che la sicurezza non dipenda da quanto in fretta riesco ad aggiornare un server.

Il sito che stai leggendo è fatto così: Nuxt, contenuti in Markdown, GitHub e Netlify, con un'anteprima per ogni modifica e il ramo principale mai toccato direttamente. Per chi ha bisogno di aggiornare i testi da solo, il pannello c'è, ma sta in un posto separato. E se un sito ha bisogno di un pannello ricco, lo dico chiaramente e non lo forzo su una soluzione statica.

Perché affidarlo a me

Ho consegnato più di 300 progetti e collaboro con più di 30 agenzie come sviluppatore esterno, da Roma e da remoto. Conosco WordPress dall'interno e per questo so dire quali siti conviene tenere dov'erano e quali conviene spostare.

Se hai un sito vetrina su WordPress e vuoi capire se ha senso passare a una versione statica, scrivimi: in una chiacchierata di circa 20 minuti guardiamo il sito, chi lo aggiorna e con quale frequenza, e ti dico cosa farei. Il servizio è in Creazione siti web.