PHP ha rilasciato aggiornamenti di sicurezza d'emergenza per due vulnerabilità critiche che potrebbero consentire ad attaccanti di eseguire codice dannoso su un server web senza effettuare l'accesso.

Le vulnerabilità, registrate come CVE-2026-109618 e CVE-2026-109619 e congiuntamente soprannominate PHP2Shell, risiedono in PHP stesso — il linguaggio di programmazione alla base di siti web e applicazioni come WordPress, Drupal e Joomla. Ciascuna ottiene un punteggio di 9,2 su 10 nel Common Vulnerability Scoring System (CVSS), collocandole entrambe nella fascia critica.

Cos'è PHP2Shell?

PHP viene eseguito su un server web, dove gestisce le richieste dei visitatori, recupera informazioni dai database, elabora i moduli e genera le pagine. Secondo l'azienda di sicurezza Qualys, PHP2Shell comprende due bug nel modo in cui il linguaggio gestisce la memoria e lo stato di una richiesta web. Le vulnerabilità sono in PHP stesso, non in WordPress, Drupal o Joomla.

WordPress ha dichiarato in un post su X che le vulnerabilità interessano qualsiasi server che ospiti un'applicazione PHP e che non è richiesto né pianificato alcun aggiornamento di WordPress. Poiché ogni applicazione su un server si affida allo stesso runtime, un PHP aggiornato chiude la falla per tutte — mentre un singolo runtime non aggiornato le lascia tutte esposte, per quanto aggiornate siano le loro applicazioni e plugin.

La prima vulnerabilità, CVE-2026-109618, si manifesta quando PHP esaurisce la memoria nel corso di una richiesta e lascia dati parzialmente inizialati. La seconda, CVE-2026-109619, si verifica quando PHP continua a puntare a dati della richiesta dopo che la memoria sottostante è stata liberata.

Wiz, una delle aziende che ha segnalato i bug, ha dichiarato di aver dimostrato attacchi che eseguono codice su siti WordPress e Drupal prima dell'accesso. L'azienda ha aggiunto che una delle vulnerabilità può anche esporre la memoria di un processo PHP in esecuzione. L'attaccante non ha bisogno di alcun account, e ciò che accade dopo dipende dalla configurazione del server e dai permessi detenuti dal processo PHP compromesso.

Chi è esposto?

PHP ha dichiarato nel suo annuncio che qualsiasi installazione che serva richieste web è a rischio, comprese PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il progetto ha indicato che il rischio è più alto per il mod_php di Apache, sottolineando che un exploit dimostrato consente a una richiesta non autenticata di innescare l'attacco prima che venga eseguito qualsiasi codice applicativo — il che significa che l'innescamento non dipende da alcuna debolezza nel codice del sito ospitato.\nWiz ha dichiarato che le versioni interessate risalgono fino a PHP 5.4 — un arco che comprende server legacy di lunga durata. Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. PHP 8.1 e versioni precedenti non ricevono più aggiornamenti dal progetto, sebbene PHP fornisca minimali backport dal codice sorgente per 7.4, 8.0 e 8.1 a chi compila dal sorgente o non dispone del supporto di un fornitore.

PHP ha inoltre dichiarato che 8.2 cesserà di ricevere correzioni di sicurezza alla fine dell'anno, quindi gli utenti di tale ramo dovrebbero pianificare un aggiornamento. Alcune distribuzioni Linux e fornitori potrebbero eseguire il backport delle correzioni su versioni precedenti; gli amministratori dovrebbero consultare i relativi advisory e, in assenza di questi, pianificare il passaggio a una versione supportata. I prodotti, i container e i pannelli di hosting che integrano il proprio PHP necessitano di aggiornamenti separati.

Secondo l'azienda di sicurezza Huntress, i dettagli delle vulnerabilità sono trapelati online un giorno prima della divulgazione prevista. PHP ha anticipato il rilascio e ha pubblicato le correzioni il 21 ottobre.

Sansec, un'altra azienda di sicurezza, dichiarato di attendersi uno sfruttamento di massa ora che le patch e le analisi tecniche sono pubbliche. Ha rilevato che Cloudflare ha già segnalato attacchi iniziali. Con i dettagli tecnici in circolazione e attacchi già registrati, i tentativi di sfruttamento contro server non ancora aggiornati rappresentano la priorità immediata da monitorare per i difensori.

Come intervenire

Aggiornare WordPress, Drupal, Joomla o un plugin non risolverà una vulnerabilità in PHP stesso. Gli amministratori possono adottare i seguenti passaggi:

Aggiornare PHP. Installare una versione corretta tramite il gestore di pacchetti, quindi verificare che il server web la stia utilizzando. Gli utenti WordPress possono visualizzare la propria versione in Strumenti > Salute del sito > Info > Server, e molti host la mostrano nel proprio pannello di controllo.

Controllare ogni installazione. Esaminare i container, i pannelli di controllo e qualsiasi applicazione che integri il proprio PHP.

Rivolgersi all'host. In un hosting condiviso, PHP potrebbe non essere sotto il controllo dell'operatore. Chiedere al fornitore se ha applicato le patch, senza dare per scontato che lo abbia fatto. WordPress ha dichiarato che gli host potrebbero essere già al lavoro su patch e regole firewall, ma consiglia comunque di verificare con il proprio host.

Monitorare il proprio repository. Sansec ha avvertito che il repository di Remi, comune sui server PHP, non disponeva della correzione il giorno del rilascio, e ha consigliato di utilizzare i pacchetti della propria distribuzione o di compilare dal sorgente.

Usare le mitigazioni solo come soluzione provvisoria. PHP ha dichiarato che non esistono mitigazioni complete e che l'aggiornamento è l'unica scelta sicura. Misure come la limitazione delle dimensioni delle richieste e la disattivazione del tracciamento degli upload non rendono sicura un'installazione.

Verificare eventuali compromissioni. Cercare processi inattesi avviati da PHP, file sconosciuti e connessioni in uscita insolite. Una patch non rimuoverà il malware già installato.

I visitatori ordinari non possono risolvere il problema, perché le vulnerabilità risiedono sui server e non su telefoni o laptop. Questo non significa che ogni sito web PHP sia stato compromesso, ma l'aggiornamento a una versione corretta è l'unica soluzione completa.