PHP2Shell: cosa significa la vulnerabilità critica di PHP per il tuo sito e cosa fare adesso

• Cosa: due falle critiche nello stesso PHP (CVE-2026-109618 e CVE-2026-109619), entrambe valutate CVSS v4.0 9,2 dal progetto PHP. Possono consentire l'esecuzione di codice da remoto senza autenticazione.
• Chi: secondo il progetto PHP, tutte le installazioni PHP che gestiscono richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il progetto ritiene il rischio più alto per mod_php.
• Correzione: aggiornare a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Le misure temporanee riducono solo alcuni vettori d'attacco: secondo il progetto PHP, solo l'aggiornamento risolve completamente il problema.
• Versioni vecchie: PHP 8.1 e precedenti non ricevono più aggiornamenti dal progetto PHP. Il team di sicurezza di PHP ha fornito backport minimi del codice sorgente per 7.4, 8.0 e 8.1; alcune distribuzioni e fornitori di supporto esteso (LTS) distribuiscono pacchetti propri.
• Cosa significa per te: se il tuo sito gira su WordPress, Joomla, una piattaforma e-commerce o qualsiasi altro software PHP, chiedi oggi stesso al tuo hosting quale versione di PHP è in uso e se la correzione è installata. Più sotto ti spieghiamo come verificarlo da solo.

PHP è il linguaggio di programmazione con cui moltissimi siti generano le pagine sul server: sistemi di gestione dei contenuti come WordPress, Joomla e TYPO3, negozi online come WooCommerce, Shopware o Magento, forum, software per prenotazioni o aree riservate. Quando un visitatore apre una di queste pagine, un processo PHP gestisce la richiesta sul server.

È proprio lì che si trovano le due falle. Il bollettino di sicurezza del progetto PHP del 21 ottobre 2026 le descrive così:

• CVE-2026-109618 – «RCE via OOM corruption»: la gestione dell'esaurimento della memoria (out of memory) può interrompere PHP mentre i dati interni della richiesta sono inizializzati solo in parte. La pulizia della richiesta può quindi trattare quei dati non validi come se fossero validi.
• CVE-2026-109619 – «RCE via stale global state»: uno stato interno che appartiene a una richiesta può sopravvivere anche dopo che la memoria che lo contiene è stata liberata. Una richiesta successiva gestita dallo stesso processo (worker) può usare quello stato obsoleto prima che la normale inizializzazione lo azzeri.

«RCE» sta per remote code execution, esecuzione di codice da remoto: chi sfrutta la falla può lanciare i propri comandi sul server con i permessi del server web. Da qui il nome PHP2Shell: una normale richiesta web si trasforma in accesso alla riga di comando del server. Il progetto PHP riferisce che per mod_php è stato dimostrato un exploit in cui una richiesta non autenticata può avviare l'attacco prima che venga eseguito qualsiasi codice dell'applicazione. Avere WordPress, i plugin o il negozio online perfettamente aggiornati, quindi, non basta: il punto debole sta un livello più in basso, nel PHP stesso.

Nel preannuncio del 20 ottobre 2026 il progetto PHP ha assegnato a entrambe le falle un punteggio CVSS v4.0 di 9,2. La scala arriva a 10; da 9 in su una vulnerabilità è considerata «critica».

Secondo il progetto PHP, sono a rischio tutte le installazioni PHP che gestiscono richieste web. Vengono citate esplicitamente:

• Apache con mod_php, dove il progetto PHP vede il rischio più alto,
• PHP-FPM (la configurazione più diffusa dietro nginx o Apache),
• php-cgi, FrankenPHP e LiteSpeed.

Quali versioni sono sicure?

Importante: le distribuzioni Linux spesso integrano le correzioni di sicurezza nei propri pacchetti senza portare il numero di versione a 8.x.y. Secondo il progetto PHP, distribuzioni e fornitori LTS hanno ricevuto le patch in anticipo. Un numero «vecchio» su un server Debian, Ubuntu, Red Hat o AlmaLinux può quindi essere comunque protetto: solo il tuo hosting o il tuo reparto IT possono confermarlo.

Cosa significa per un'attività tipica

• WordPress, Joomla, TYPO3, Drupal: girano su PHP. Un CMS aggiornato qui non ti protegge: conta la versione di PHP sul server.
• WooCommerce, Shopware, Magento/Adobe Commerce, PrestaShop: anche questi sono PHP. Un negozio online gestisce dati dei clienti e pagamenti, quindi bisogna muoversi particolarmente in fretta.
• Hosting condiviso: di solito è l'hosting ad applicare centralmente gli aggiornamenti di PHP. Molti piani però ti permettono di scegliere da solo la versione di PHP: se è selezionata una versione vecchia come la 7.4 o la 8.1, resti su quella finché non la cambi.
• Server proprio o VPS: la responsabilità è tua (o della tua agenzia): aggiornare i pacchetti e riavviare tutti i processi PHP.
• Strumenti per creare siti senza PHP: i servizi che distribuiscono pagine statiche o usano un'altra tecnologia non sono interessati da questa specifica falla. Nel dubbio, chiedi al fornitore.

Cronologia

• Agosto/settembre 2026: diversi team scoprono le falle in modo indipendente. Secondo la PHP Foundation, i primi indizi sono arrivati da uno sviluppatore del core di PHP, seguiti dalle segnalazioni di Calif e OpenAI (11 agosto) e di Wiz (24 agosto). Wiz indica il 19 agosto come data della scoperta.
• 20 ottobre: il progetto PHP annuncia un aggiornamento di sicurezza critico, previsto per il 21 ottobre alle 14:00 UTC, con un punteggio CVSS v4.0 di 9,2 per entrambe le falle. Lo stesso giorno, secondo la PHP Foundation, i numeri CVE circolano con un orario sbagliato e un punteggio errato di 10,0; la sera viene pubblicato per errore un video con una dimostrazione dell'attacco.
• 21 ottobre, primo mattino: secondo la PHP Foundation, un fornitore di immagini container pubblica già alle 07:41 UTC pacchetti corretti, più di sei ore prima della data concordata.
• 21 ottobre, 14:00 UTC (16:00 in Italia): vengono pubblicati PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 insieme ai dettagli tecnici.

Autorità e reazioni

Le agenzie nazionali per la cybersicurezza di tutta Europa hanno lanciato l'allerta: in Italia lo CSIRT Italia dell'ACN, in Germania il BSI con un avviso di criticità 3/arancione («le misure devono essere adottate senza indugio»), in Austria il CERT.at, in Francia il CERT-FR, nel Regno Unito l'NCSC e in Spagna l'INCIBE-CERT. BSI e NCSC consigliano di scollegare temporaneamente i sistemi se non sono possibili né l'aggiornamento né una misura temporanea.

Ed è proprio quello che hanno fatto in molti. Secondo derStandard, in Austria sono andati offline per precauzione, tra gli altri, l'Università di Vienna, la TU Wien, il giornale NÖN e la Caritas; secondo Deutschlandfunk, in Germania la città di Magonza ha spento diversi servizi online e il proprio portale web. In Francia il Ministero dell'Interno, su richiesta dell'ANSSI, ha messo in manutenzione preventiva tra gli altri i siti delle prefetture (actu17); nei Paesi Bassi sono stati coinvolti tra gli altri MijnOverheid e DigiD, secondo igizmo.it che cita NOS.

La falla viene sfruttata? Le fonti non concordano

• Sì, tentativi di attacco: Amazon Web Services riferisce di tentativi sui propri honeypot già dal 17 ottobre e di altri a partire dalle prime ore del 21 ottobre. L'azienda di sicurezza watchTowr ha segnalato il 21 ottobre tentativi di sfruttamento attivo di entrambe le falle; Datadog parla di scansioni ampie e non mirate. INCIBE-CERT scrive che erano stati segnalati attacchi già prima della pubblicazione degli aggiornamenti.
• Non ancora confermato: la PHP Foundation afferma che, al momento del rilascio, il team di sicurezza di PHP non aveva individuato exploit funzionanti. Il BSI non è riuscito a verificare le prime segnalazioni dai social media. Al 22 ottobre nessuna delle due CVE compare nel catalogo delle vulnerabilità sfruttate della CISA (KEV), l'agenzia statunitense.

La nostra lettura: sono documentati tentativi di attacco; compromissioni riuscite su larga scala finora non sono state confermate pubblicamente. Per te non cambia nulla: i dettagli sono pubblici e, per esperienza, le scansioni di massa arrivano in fretta. Tratta ogni server PHP non aggiornato come se fosse già sotto attacco.

Quanti siti sono coinvolti?

Un numero esatto non esiste. Nella sua analisi Wiz parla del «70 % di Internet» coinvolto. Secondo The Hacker News, il 20 ottobre circa 884.000 server raggiungibili da Internet mostravano nel proprio banner PHP 8.1 o precedente, cioè versioni senza aggiornamento ufficiale. Questi conteggi si basano sui banner dei server e non dicono se un server sia davvero vulnerabile.

Non serve essere tecnici per scoprire se il tuo sito usa PHP e quale versione è in funzione. Queste strade richiedono di solito pochi minuti:

1. Nella bacheca di WordPress: Strumenti → Salute del sito → Info, sezione Server. Lì trovi la versione di PHP.
2. In Joomla: Sistema → Informazioni di sistema. Lì è indicata la versione di PHP.
3. Nel pannello di controllo del tuo hosting: i piani di hosting condiviso hanno di solito una voce come «Impostazioni PHP» o «Versione PHP», dove puoi vederla e cambiarla.
4. Scrivendo una mail al tuo hosting: chiedi testualmente: «Quale versione di PHP usa il mio sito e sono installate le correzioni per CVE-2026-109618 e CVE-2026-109619?». Fatti dare la risposta per iscritto.
5. Per il personale tecnico: php -v sul server mostra la versione da riga di comando, che può essere diversa da quella che gestisce le richieste web. Affidabile è la versione effettivamente usata dal server web (ad esempio tramite una pagina phpinfo creata per pochi istanti e cancellata subito dopo). Alcuni server indicano la versione nell'intestazione HTTP X-Powered-By; se manca, non significa che PHP non ci sia.

Regola pratica: 8.5.12, 8.4.27, 8.3.36, 8.2.35 o superiore significa che l'aggiornamento ufficiale è installato. Un numero inferiore non è automaticamente insicuro (vedi sopra i pacchetti delle distribuzioni): in quel caso deve essere il tuo hosting a confermare che la correzione è inclusa.

1. Contatta il tuo hosting o la tua agenzia e ottieni una conferma scritta: versione di PHP, correzione per entrambe le CVE installata, tutti i processi PHP riavviati.
2. Controlla la versione di PHP nel pannello di controllo e, se la scegli tu, passa a un ramo mantenuto (8.3, 8.4 o 8.5). Verifica rapidamente che tema e plugin funzionino ancora.
3. Fai un backup e scaricalo: file e database, con la data. Un backup salvato sullo stesso server non basta.
4. Aggiorna CMS, temi e plugin. Questo non chiude PHP2Shell, ma chiude altre porte che gli attaccanti stanno tentando proprio adesso.
5. Controlla gli account amministratore: ci sono utenti che non riconosci? Rimuovili e segnalali.
6. Cambia le password dopo l'aggiornamento: accessi amministrativi, FTP/SFTP, database, account dell'hosting. Attiva l'autenticazione a due fattori ovunque sia possibile.
7. Fai analizzare i log (vedi sotto), soprattutto se il server era raggiungibile tra la divulgazione e l'aggiornamento.
8. Prova i moduli di contatto e il negozio online quando tutto è aggiornato, così non perdi nessuna richiesta.

Se hai messo offline il sito per precauzione, comunicalo sui tuoi canali (Profilo dell'attività su Google, social) con una breve nota su come i clienti possono contattarti nel frattempo.

Il progetto PHP elenca misure temporanee per i server che non possono essere aggiornati subito, sottolineando che riducono solo l'esposizione a specifici vettori d'attacco e non rendono sicura un'installazione. Sono un compito per chi gestisce il server, non per il titolare del sito. In sintesi:

• Contro CVE-2026-109618: impostare memory_limit=-1 in modo che le applicazioni non possano sovrascriverlo (ad es. con php_admin_value); tenere basso post_max_size (8M senza caricamento di file, 32M con) e upload_max_filesize al di sotto; imporre sul server web o sul proxy limiti a dimensione delle richieste, numero di campi, parti multipart, numero di intestazioni e profondità di annidamento; usare limiti di container o cgroup come rete di sicurezza. Da non usare in nessun caso: RLIMIT_AS o RLIMIT_DATA.
• Contro CVE-2026-109619: impostare session.upload_progress.enabled=0 in php.ini o nella configurazione del pool e riavviare tutti i processi (non tramite ini_set() o .user.ini); su PHP 8.5 impostare anche fatal_error_backtraces=0. Correggere gli errori fatali e i timeout che un attaccante può provocare: limitarsi a nascondere i messaggi di errore non serve.

Tutti i dettagli tecnici sono nel bollettino di sicurezza su php.net.

Un aggiornamento installato chiude la falla, ma non rimuove ciò che potrebbe essere stato inserito prima. Se il tuo server era raggiungibile tra la divulgazione e l'aggiornamento, fallo controllare alla ricerca di tracce. I segnali d'allarme generali più comuni dopo la compromissione di un server:

• file PHP nuovi o modificati nelle cartelle di upload o di cache, creati da nessuno di voi,
• account amministratore sconosciuti nel CMS o nuovi utenti sul server,
• molte richieste interrotte o errori di memoria nei log di PHP o del server web, in particolare richieste POST molto grandi o dalla struttura strana,
• connessioni in uscita o nuove attività pianificate (cron job) che nessuno ha impostato,
• reindirizzamenti verso siti sconosciuti, pagine di spam sotto il tuo dominio su Google, avvisi del browser.

Tracce specifiche di PHP2Shell pubblicate da aziende di sicurezza (per chi analizza i tuoi log): Amazon Web Services segnala la stringa PHP_SESSION_UPLOAD_PROGRESS negli invii di moduli POST e consiglia di esaminare i log a partire dal 17 ottobre. Datadog cita messaggi come «Allowed memory size … exhausted … Unknown on line 0», processi figli di Apache che si bloccano con «Segmentation fault» e processi del server web che avviano una shell (sh -c). Wiz consiglia di tenere d'occhio richieste multipart insolite seguite da errori di limite di memoria o da risposte HTTP 500 ripetute.

Se trovi uno di questi segnali: metti il sito offline, coinvolgi degli specialisti, cambia le credenziali solo da un sistema pulito e, se possono essere coinvolti dati personali, verifica l'obbligo di notifica previsto dall'art. 33 del GDPR (72 ore da quando ne sei venuto a conoscenza).

In tanti ci chiedono dei siti realizzati con mekyn. La risposta è semplice: i siti creati e consegnati da mekyn vengono serviti come pagine statiche già pronte. Lì non gira PHP. La piattaforma che c'è dietro (dashboard, moduli, prenotazioni) funziona con Node.js. PHP2Shell quindi non riguarda questi siti.

È una scelta progettuale, non fortuna: una pagina servita in modo statico non esegue logica di programma sul server web a ogni visita. Meno parti in movimento significano una superficie d'attacco più piccola e, in più, tempi di caricamento rapidi. Gli aggiornamenti della piattaforma vengono applicati centralmente: tu non devi fare nulla.

Se il tuo sito attuale gira su PHP e dopo questa settimana ne hai abbastanza di aggiornamenti del server, manutenzione dei plugin e mail d'emergenza: mekyn prende i contenuti del tuo sito attuale e li trasforma in una presenza moderna, con visibilità su Google, canali di contatto e prenotazioni. Fino al trasloco, però, segui la checklist qui sopra: il tuo sito attuale deve essere sicuro già oggi.