← Tutti gli articoli

Le patch PHP2Shell affrontano un rischio critico per i server WordPress

Le patch PHP2Shell affrontano un rischio critico per i server WordPress

PHP2Shell è il nome collettivo di due vulnerabilità critiche di PHP divulgate pubblicamente il 21 ottobre 2026. PHP è il linguaggio di programmazione lato server su cui viene eseguito WordPress. Le falle, CVE-2026-109618 e CVE-2026-109619, potrebbero consentire a un attaccante di eseguire codice dannoso su un server interessato senza autenticazione, cioè senza dover prima fornire un account valido o effettuare l'accesso. Entrambe hanno ricevuto un punteggio critico di 9,2 secondo CVSS 4.0, il Common Vulnerability Scoring System utilizzato per valutare la gravità delle falle di sicurezza.

Le vulnerabilità riguardano il modo in cui PHP gestisce la memoria durante l'elaborazione delle richieste. Un exploit riuscito potrebbe compromettere i siti web e i dati archiviati sullo stesso server. Qualsiasi installazione di WordPress che utilizzasse una versione di PHP interessata era quindi potenzialmente esposta, ma il problema non risiedeva in WordPress. PHP2Shell ha interessato il PHP runtime, il software server sottostante che interpreta ed esegue il codice PHP, anziché WordPress core, un plugin o un theme. L'aggiornamento di questi componenti di WordPress non avrebbe corretto il software PHP vulnerabile.

Il team di sviluppo di PHP ha pubblicato aggiornamenti di sicurezza di emergenza per PHP 8.2, 8.3, 8.4 e 8.5 il 21 ottobre. Le correzioni di sicurezza per le versioni precedenti di PHP sono state fornite da maintainer di terze parti. Kinsta afferma che i suoi team di engineering e sicurezza avevano iniziato a prepararsi prima che diventassero disponibili le correzioni ufficiali, comunemente chiamate patch. Inizialmente il provider ha introdotto misure pensate per ridurre le possibilità di exploit mentre convalidava e distribuiva le build PHP corrette.

Un livello temporaneo di protezione è stato fornito dal Web Application Firewall (WAF) di Cloudflare, un servizio che esamina le richieste web in entrata e blocca il traffico corrispondente a pattern dannosi. Secondo Kinsta, Cloudflare aveva implementato prima della divulgazione pubblica protezioni progettate per identificare i tentativi di exploit di PHP2Shell. Kinsta ha abilitato le protezioni pertinenti in tutta la propria infrastruttura di hosting, consentendo di filtrare il traffico prima che raggiungesse i siti web ospitati. Questi controlli a livello edge, cioè protezioni applicate al confine esterno della rete di hosting, sono rimasti attivi durante l'installazione degli aggiornamenti PHP.

Kinsta ha inoltre modificato le impostazioni di configurazione di PHP in tutti i propri ambienti di hosting per limitare la potenziale esposizione. Durante la risposta all'incidente, ha scambiato informazioni sulle minacce e sui pattern di attacco osservati con Patchstack, il suo partner per la protezione dalle vulnerabilità. Kinsta ha sottolineato che il firewall e le misure di configurazione erano salvaguardie provvisorie, non sostituti della correzione del PHP runtime stesso.

Dopo che il team PHP ha pubblicato le correzioni, Kinsta ha convalidato e distribuito in tutta la piattaforma pacchetti PHP dotati di patch, ossia build installabili del software server. Il rollout ha incluso da PHP 7.4 a PHP 8.5, comprese le patch per le versioni precedenti fornite da Freexian, il provider dei pacchetti PHP di Kinsta. Poiché PHP era gestito centralmente a livello di hosting, i clienti non hanno dovuto installare una correzione separata né cambiare versione manualmente. Il rollout ha incluso sia i siti live sia gli staging environments, ossia copie di test utilizzate per verificare le modifiche prima di applicarle a un sito web pubblico.

Kinsta ha contrassegnato l'incidente come risolto sulla propria pagina di stato pubblica alle 08:26 UTC del 22 ottobre 2026. Ha dichiarato che tutti i siti avevano ricevuto le protezioni e gli aggiornamenti di sicurezza necessari. Durante l'incidente, i suoi team hanno monitorato le attività sospette, esaminato manualmente i siti che sembravano essere stati presi di mira ed eseguito ulteriori verifiche a campione alla ricerca di prove di compromissione. Kinsta ha riferito di non aver trovato alcuna prova di violazioni PHP2Shell riuscite sulla propria piattaforma. Questa dichiarazione descrive le prove disponibili attraverso il suo monitoraggio, ma non dimostra che non si siano verificati exploit altrove.

Secondo il provider, i clienti Kinsta non devono mettere offline i propri siti web, installare un'altra patch o cambiare versione di PHP a causa di PHP2Shell. Gli ambienti sospesi a titolo precauzionale possono essere riattivati, poiché Kinsta afferma di aver aggiornato anche gli ambienti sospesi. I clienti dovrebbero continuare ad aggiornare WordPress core, plugin e theme nell'ambito della manutenzione ordinaria, ricordando però che questi aggiornamenti riguardano un livello di sicurezza diverso e non sostituiscono le correzioni PHP a livello server.

I clienti possono vedere la versione PHP configurata aprendo Sites in MyKinsta, selezionando il sito web e passando a Tools, quindi a PHP settings. Tuttavia, la versione visualizzata da sola potrebbe non indicare se una correzione è presente. Alcuni maintainer utilizzano backported security fixes, che aggiungono una correzione di sicurezza a una versione precedente del software senza aggiornarla al numero di versione ufficiale più recente. I proprietari dei siti che hanno ancora dubbi possono contattare tramite MyKinsta il team di supporto Kinsta, disponibile 24 ore su 24 e 7 giorni su 7, per confermare lo stato della patch di uno specifico ambiente. Anche le agenzie possono condividere con i clienti il rapporto pubblico sull'incidente di Kinsta, poiché documenta il rollout e la risoluzione.

Per i proprietari che stanno valutando a chi debba spettare la responsabilità della sicurezza del server, AEU Hosting offre un hosting WordPress gestito e protetto end-to-end. PHP2Shell dimostra perché questa distinzione è importante: un aggiornamento dalla dashboard di WordPress non può correggere una falla nel PHP runtime, quindi la conferma deve arrivare da chi gestisce il software PHP del server.

Disponibile anche in: EnglishDeutschShqip