Contattaci
Tecnologia

PHP2Shell: le due falle critiche di PHP e cosa fare subito sul tuo sito

9 min di lettura

Il 21 ottobre 2026 il PHP Security Team ha pubblicato aggiornamenti d’emergenza per due falle critiche nel motore di PHP, battezzate PHP2Shell. Riguardano praticamente ogni sito che gira su PHP, quindi anche la grande maggioranza dei siti WordPress, degli e-commerce e dei gestionali web delle PMI. In questo articolo vediamo cosa sono, perché sono così gravi e cosa fare subito, anche se il sito non lo gestisci tu in prima persona.

Cosa sono le vulnerabilità PHP2Shell

PHP2Shell è il nome con cui sono note due vulnerabilità di php-src, il codice sorgente del linguaggio PHP. Entrambe hanno un punteggio di gravità CVSS v4.0 pari a 9.2, cioè critico, e in entrambi i casi l’effetto finale è lo stesso: l’esecuzione di codice da remoto (in gergo RCE, Remote Code Execution).

  • CVE-2026-109618, corruzione della memoria per esaurimento (OOM). Quando la memoria a disposizione finisce, PHP interrompe la richiesta. Se succede nel momento sbagliato, mentre i dati interni della richiesta sono inizializzati solo in parte, la fase di chiusura può trattare dati non validi come validi. Secondo l’advisory ufficiale l’innesco passa soprattutto dall’analisi dei moduli multipart, cioè le richieste usate per inviare form e file.
  • CVE-2026-109619, stato globale residuo. Alcune informazioni legate a una richiesta possono sopravvivere alla memoria che le contiene. Una richiesta successiva, gestita dallo stesso processo del server, può riutilizzarle prima che vengano azzerate: è il classico errore di tipo “use after free”.

Le falle sono state scoperte dai ricercatori di Calif, OpenAI e Wiz. Il team di PHP aveva preannunciato la release il 20 ottobre e l’ha pubblicata il giorno dopo alle 14:00 UTC.

Perché sono così pericolose

Tre caratteristiche rendono PHP2Shell più grave di una normale vulnerabilità:

  • Nessuna autenticazione. L’attaccante non ha bisogno di password né di un account sul sito: basta inviare richieste HTTP preparate ad arte.
  • Agisce prima del sito. Per la configurazione Apache con mod_php, quella giudicata più a rischio, esiste un exploit dimostrato che scatta prima che venga eseguita una sola riga del codice dell’applicazione. Firewall applicativi, plugin di sicurezza di WordPress e password robuste non bastano, perché il problema è “sotto” il CMS.
  • Riguarda tutti i modi di far girare PHP. Il PHP Security Team indica come esposte tutte le installazioni che servono pagine web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed.

Chi riesce a sfruttarle ottiene i privilegi dell’utente con cui gira il server web: in pratica può leggere e modificare i file del sito, i dati di accesso al database e, da lì, i dati dei clienti. Non è un rischio teorico: Cloudflare ha confermato di vedere già tentativi di attacco, Amazon ne ha registrato uno nei propri sistemi esca il 17 ottobre, quattro giorni prima della pubblicazione, e il National Cyber Security Centre britannico ha invitato ad aggiornare subito o a mettere offline i sistemi che non si possono correggere.

La falla spiegata in video

Se preferisci una spiegazione a voce, Simone Rizzo racconta in modo chiaro che tipo di falla è stata scoperta e perché riguarda anche i siti delle piccole aziende:

Il video si carica da Instagram (Meta) solo se premi il pulsante: da quel momento Meta può impostare i propri cookie. Cookie Policy · Apri su Instagram

Le versioni di PHP corrette

La correzione è contenuta in queste versioni, una per ogni ramo ancora supportato:

Ramo PHPVersione correttaSupporto di sicurezza
8.58.5.12Attivo
8.48.4.27Attivo
8.38.3.36Attivo
8.28.2.35Fino al 31 dicembre 2026
8.1 e precedentiNessuna release ufficialeTerminato

Per PHP 7.4, 8.0 e 8.1 il team ha pubblicato solo delle correzioni minime del codice sorgente, pensate per chi compila PHP da sé. Alcune distribuzioni Linux e alcuni fornitori di supporto esteso le integrano nei propri pacchetti, ma per un sito aziendale su hosting condiviso la strada giusta è una sola: passare a un ramo supportato. E chi oggi è su PHP 8.2 farebbe bene a pianificare il passaggio a 8.3 o superiore, visto che il supporto finisce tra poco più di due mesi.

Cosa fare subito: la checklist per il tuo sito

  1. Scopri che versione di PHP usa il sito. Su WordPress la trovi in Bacheca, alla voce Strumenti, Salute del sito, scheda Info, sezione Server. Sui pannelli di hosting come cPanel o Plesk è indicata nella sezione dedicata a PHP.
  2. Chiedi conferma al fornitore di hosting. Su hosting condiviso e server gestiti PHP lo aggiorna il provider, non tu. Scrivi all’assistenza e chiedi esplicitamente se le patch per CVE-2026-109618 e CVE-2026-109619 sono già installate. Attenzione: alcuni provider e distribuzioni applicano la correzione senza cambiare il numero di versione, quindi la loro conferma scritta vale più del numero che leggi nel pannello.
  3. Se sei su un ramo obsoleto, pianifica il passaggio adesso. Con PHP 8.1, 8.0 o 7.x il sito resta vulnerabile in modo permanente. Prima di cambiare versione fai un backup completo e verifica che tema e plugin siano compatibili, meglio se su una copia di prova del sito.
  4. Aggiorna WordPress, tema e plugin. L’aggiornamento del CMS non corregge PHP2Shell, perché la falla è nel motore e non nel sito. Però un sito fermo a versioni vecchie spesso non funziona con PHP recenti, ed è proprio questo che costringe molti a restare su rami vulnerabili.
  5. Se gestisci un server tuo (VPS o dedicato), aggiorna i pacchetti e riavvia i processi. Dopo l’aggiornamento vanno riavviati PHP-FPM o il server web, altrimenti continua a girare il codice vecchio già caricato in memoria.
  6. Controlla che non sia già successo qualcosa. Dato che i primi tentativi sono iniziati prima della pubblicazione, vale la pena verificare se ci sono file PHP nuovi o modificati di recente nelle cartelle del sito, utenti amministratori che non conosci e picchi anomali di richieste nei log del server.

Se non puoi aggiornare subito: le mitigazioni temporanee

Il PHP Security Team ha indicato alcune impostazioni che riducono l’esposizione, ma è chiaro su un punto: non rendono sicura l’installazione, servono solo a guadagnare tempo fino all’aggiornamento. Sono interventi per chi amministra il server, non per chi ha un hosting condiviso:

  • Per CVE-2026-109618: impostare memory_limit=-1 a livello amministrativo (per esempio con php_admin_value nel pool FPM o nella configurazione di Apache), ridurre post_max_size a 8M se il sito non riceve file o a 32M se li riceve, e limitare a livello di server web la dimensione e la complessità delle richieste.
  • Per CVE-2026-109619: impostare session.upload_progress.enabled=0 nel php.ini o nel pool FPM e riavviare tutti i processi (non basta modificarlo da codice né con il file .user.ini); su PHP 8.5 anche fatal_error_backtraces=0. Nascondere gli errori con display_errors o error_reporting non serve.
  • Un firewall davanti al sito aiuta. Cloudflare ha distribuito regole WAF contro i vettori di attacco noti, ma lo stesso Cloudflare le definisce una protezione temporanea.

Il 23 ottobre il team di PHP ha segnalato anche un problema collegato alla funzione session.upload_progress (CVE-2026-115560): chi ha già applicato la mitigazione del 21 ottobre è coperto anche per questo.

La lezione per le aziende: la versione di PHP è parte della sicurezza

Secondo le scansioni di Bitsight, solo circa un terzo delle installazioni PHP di cui è stato possibile leggere la versione usa un ramo coperto da questo aggiornamento, e il ramo più diffuso in assoluto è ancora PHP 7.4, con oltre 2 milioni di installazioni rilevate. Vuol dire che molti siti girano ancora su versioni che nessuno corregge più, spesso perché “funziona tutto” e nessuno ci guarda da anni. PHP2Shell mostra cosa costa quella scelta: quando arriva una falla critica, chi è aggiornato installa una patch, chi non lo è deve prima rifare mezzo sito.

Abbiamo già visto un caso simile, dalla parte delle email, nell’articolo sull’attacco al record SPF delle email aziendali: la sicurezza di un’azienda online dipende da pezzi che il titolare non vede, ed è lì che serve qualcuno che li tenga d’occhio.

Domande frequenti

Il mio sito WordPress è a rischio?

Se gira su una versione di PHP precedente a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 e il provider non ha applicato la correzione, sì. WordPress in sé non è vulnerabile, ma il motore PHP su cui gira sì, e l’attacco può partire prima che WordPress venga caricato.

Basta un plugin di sicurezza per proteggersi?

No. I plugin di sicurezza lavorano dentro WordPress, mentre PHP2Shell colpisce il livello inferiore. L’unica difesa definitiva è aggiornare PHP; un firewall esterno come quello di Cloudflare può ridurre il rischio nel frattempo.

Ho un hosting condiviso: devo fare qualcosa io?

L’aggiornamento di PHP lo fa il provider, ma tocca a te verificare che l’abbia fatto e, se il sito usa un ramo obsoleto, scegliere dal pannello una versione supportata. Chiedi una conferma scritta all’assistenza dell’hosting.

Uso ancora PHP 7.4: cosa rischio?

PHP 7.4 non è supportato dal 2022 e non riceverà una release corretta. Esistono solo correzioni minime da compilare a mano, che su un hosting non puoi installare. Il sito resta esposto finché non passi a un ramo supportato.

Come capisco se il sito è già stato attaccato?

I segnali più comuni sono file PHP sconosciuti o modificati di recente, nuovi utenti amministratori, reindirizzamenti verso siti esterni e avvisi di Google Search Console o dell’antivirus del browser. Se noti uno di questi segnali, non limitarti ad aggiornare PHP: il sito va controllato e ripulito.

Ti aiutiamo a verificare il tuo sito

Controllare la versione di PHP, gli aggiornamenti e la compatibilità di tema e plugin fa parte del nostro servizio di assistenza e manutenzione dei siti web. Se non sai su che versione gira il tuo sito o hai un dubbio, prenota una consulenza gratuita e lo verifichiamo insieme.

Fonti