Vulnerabilità PHP: gravità di PHP2Shell e cosa fare

Dal 20 ottobre 2026, l’allerta PHP2Shell impone una verifica immediata sui siti PrestaShop, WordPress e WooCommerce. Non riguarda un modulo o un tema specifico: colpisce il cuore di PHP, cioè lo strato che esegue quotidianamente il tuo negozio.

Il punto che cambia le priorità è semplice: le due vulnerabilità sono classificate critiche, con rischio di esecuzione di codice a distanza senza autenticazione e perdita di memoria che può esporre segreti applicativi. Se il tuo sito gira su una branch PHP vulnerabile, aspettare il prossimo intervento di manutenzione ti lascia inutilmente a rischio.

In questo articolo vedrai chi è interessato, come verificare la versione PHP effettiva del sito, cosa fare in base al tuo hosting e cosa prevedere se il negozio è ancora bloccato su una branch vecchia.

PHP2Shell: cosa è stato pubblicato e perché l’allerta è immediata

Al 23 ottobre 2026 le informazioni utili sono sufficienti per agire. I fix sono stati pubblicati e, già il 22 ottobre 2026, il CERT-FR segnalava proof-of-concept note. Per chi gestisce un e-commerce il buon riflesso è quindi semplice: verificare l’esposizione, correggere e poi controllare lo stato del negozio.

La cronologia da ricordare dal 20 ottobre 2026

Il 20 ottobre 2026 PHP ha annunciato una pubblicazione di sicurezza imminente per due vulnerabilità critiche. I dettagli sono trapelati prima della fine dell’embargo. I fix ufficiali sono stati poi pubblicati il 21 ottobre 2026 alle 16:00, ora di Parigi, con le versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12.

Il punto utile per te: se il tuo sito non usa almeno una di queste versioni corrette, o un pacchetto fornitore esplicitamente backportato, va considerato esposto. PHP ricorda inoltre che l’aggiornamento rimane l’unica opzione sicura: avviso di sicurezza PHP e versioni corrette.

Le due vulnerabilità in una frase chiara

PHP2Shell indica qui due falle del core di PHP: CVE-2026-109618, legata a una corruzione dovuta a un overflow di memoria alla fine della richiesta, e CVE-2026-109619, legata a uno stato globale di richiesta riutilizzato dalla richiesta successiva nello stesso processo, con use-after-free e perdita di memoria.

Entrambe sono valutate 9,2 in CVSS v4.0. In altre parole: non è un avviso teorico. Al 22 ottobre 2026 il CERT-FR segnalava già proof-of-concept note.

La gravità è davvero critica per un negozio online

Per un negozio la questione non è solo se il server può crashare. La vera domanda è cosa può raggiungere un attaccante prima che tu lo veda. Su questo punto il livello di rischio è elevato.

Esecuzione di codice a distanza senza autenticazione: cosa cambia

PHP indica che le due vulnerabilità possono consentire esecuzione di codice a distanza senza autenticazione. Vuol dire che un attaccante non ha bisogno di un account cliente, dell’accesso al back-office o di un modulo già compromesso per tentare un exploit. Se il motore PHP in uso è vulnerabile, la superficie di esposizione esiste a livello di gestione delle richieste HTTP.

Cloudflare ha indicato di vedere traffico d’attacco già alla divulgazione pubblica, confermando che la questione è passata rapidamente da allerta a tentativi reali da monitorare: analisi Cloudflare sulle protezioni deployate contro PHP2Shell. Questo non dimostra campagne mirate esclusivamente su PrestaShop, WordPress o WooCommerce, e bisogna restare precisi su questo punto.

Perdita di memoria: perché password, token e chiavi API sono a rischio

L’avviso GHSA-6wmf-4rv5-p3rp descrive uno stato globale di richiesta che può sopravvivere in un worker e poi essere riutilizzato dalla richiesta successiva nello stesso processo. Il possibile risultato: use-after-free, perdita di memoria e, potenzialmente, RCE. L’altro avviso, GHSA-w8hw-w9fx-j79w, riguarda una corruzione legata a un overflow di memoria in chiusura di richiesta.

Per un commerciante la conseguenza concreta è semplice: segreti applicativi presenti in memoria possono essere esposti. Possono riguardare password, token e chiavi API. Un negozio può quindi sembrare ancora funzionante pur mantenendo un rischio serio sul pagamento, i connettori, l’area clienti o l’amministrazione. Il meccanismo di CVE-2026-109619 è descritto nell’avviso ufficiale: advisory GitHub sulla RCE tramite stale global state.

Chi è interessato in base alla versione PHP e all’hosting

La metodologia corretta è posizionarsi su due assi: la branch PHP e il modo di esecuzione. Questo duo determina l’urgenza e il tipo di intervento.

Le branch PHP da considerare esposte

Le branch ufficialmente corrette sono 8.2, 8.3, 8.4 e 8.5 a partire dalle versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Tutte le versioni precedenti di queste branch sono interessate.

Le branch 5.x, 7.x, 8.0 e 8.1 devono essere considerate a rischio. Per 8.1 e versioni precedenti non c’è più supporto upstream. Possono esistere backport forniti da alcuni provider per 7.4, 8.0 e 8.1, ma sono limitati. Sotto 7.4 non è annunciato nulla. L’errore comune è credere che una branch ancora disponibile nel pannello hosting sia automaticamente sicura. Non è un criterio sufficiente.

Perché Apache mod_php e PHP-FPM vanno trattati in priorità

Qualys raccomanda di considerare Apache mod_php come il caso più urgente. Anche PHP-FPM è interessato, così come php-cgi, FrankenPHP e LiteSpeed. Se non sai come il tuo sito esegue PHP, parti dal presupposto che vada verificato subito, poi conferma con l’host o l’infogérance.

Il punto pratico: un negozio che risponde non è automaticamente un negozio protetto. Il rischio è diretto sul motore PHP. Qualys dettaglia questo aspetto e ricorda anche che un pacchetto di distribuzione o del provider può integrare un fix senza mostrare esattamente il numero upstream atteso: valutazione del rischio PHP2Shell da Qualys.

Il caso particolare dell’hosting condiviso

In shared hosting l’host può aver patchato i suoi cluster rapidamente, ma ciò non esime dal controllare la branch PHP selezionata nel pannello cliente. Puoi avere un host reattivo e al tempo stesso un sito esposto se rimani su una branch vecchia come 8.1 o precedente.

Come verificare la vera versione di PHP usata dal tuo sito

È il passo più semplice eppure quello in cui molti sbagliano. Il trucco classico è guardare la versione in CLI o nel contratto hosting e credere che il sito web giri necessariamente su quella stessa versione.

PrestaShop: dove verificare nel back-office

Su PrestaShop controlla prima in Parametri avanzati > Informazioni. Vedrai la versione PHP effettivamente riportata dal negozio. Fai questa verifica prima di qualsiasi modifica, poi rifalla dopo l’intervento.

Se il sito mostra una versione precedente a 8.2.35, 8.3.36, 8.4.27 o 8.5.12 su una branch ancora supportata, l’azione è chiara: aggiornamento immediato. Se sei su 8.1, 8.0 o 7.x, verifica anche se il fornitore dichiara un backport. Senza questa conferma considera il negozio a rischio.

WordPress e WooCommerce: il percorso più sicuro

Su WordPress e WooCommerce vai in Strumenti > Stato di salute del sito. È il modo più semplice per vedere la versione PHP usata dal sito web. Anche qui, non fidarti di ciò che il server «dovrebbe» usare: verifica ciò che WordPress vede realmente.

In ambienti con più siti o più pool, due applicazioni sullo stesso server possono non usare la stessa configurazione PHP. È un errore frequente su VPS e dedicati dopo cambi parziali.

Perché la versione CLI può ingannare

Il comando php -v in SSH può differire dalla versione effettivamente usata dal sito web. Puoi leggere una versione rassicurante in CLI mentre il front gira su un’altra stack.

Altro caso comune: un pacchetto fornito dall’OS o dall’hoster include il fix senza mostrare il numero di versione upstream più recente. Su VPS, dedicato o offerte gestite, la buona pratica è incrociare tre elementi: la versione vista dal CMS, la versione dei pacchetti e la comunicazione del fornitore.

Cosa fare adesso, nell’ordine corretto

Il giusto ordine evita due errori: applicare il patch a metà o riavviare troppo tardi. Ecco la sequenza utile per un sito in produzione.

Aggiornare PHP o selezionare la branch corretta nel pannello hosting

Primo riflesso: applica la versione corretta se disponibile. In shared hosting può voler dire selezionare la branch giusta nel pannello. Su VPS o dedicato significa aggiornare i pacchetti forniti dalla distribuzione o dal tuo fornitore.

Se sei merchant PrestaShop e la boutique è già sensibile sulla disponibilità, prevedi in parallelo un intervento d’urgenza su PrestaShop nel caso in cui il cambio di branch rompa il front, il back-office o il funnel. E se vuoi ridurre il rischio di interruzioni ai prossimi incidenti tecnici, tieni a portata di mano i controlli che evitano che una panne fermi il tuo negozio.

Riavviare PHP-FPM o Apache dopo l’aggiornamento

Su VPS o server dedicato l’aggiornamento non basta se i processi non vengono riavviati. Occorre riavviare PHP-FPM o Apache a seconda del modo d’esecuzione usato dal sito. Il riavvio è parte delle azioni anche dopo una mitigazione temporanea.

Errore frequente: aggiornare un pacchetto, controllare rapidamente il sito e poi dimenticare che worker in memoria usano ancora lo stato precedente. Su una vulnerabilità che riguarda processi e memoria questo dettaglio è cruciale.

Perché un WAF o una mitigazione temporanea non bastano

PHP dichiara che non esiste una mitigazione completa e che l’aggiornamento è l’unica opzione sicura. I workaround provvisori hanno utilità ma non correggono PHP. Quelli citati ufficialmente sono session.upload_progress.enabled=0 per ridurre il perimetro di CVE-2026-109619, il blocco delle richieste multipart non necessarie, fatal_error_backtraces=0 su 8.5 e poi il riavvio dei processi PHP. L’avviso GHSA aggiunge anche che pm.max_requests=1 può ridurre il rischio se la performance non è prioritaria.

Un WAF aiuta a guadagnare tempo. Cloudflare ha spinto protezioni di default per i clienti WAF. Ma il filtraggio non elimina la vulnerabilità del motore PHP. Se la branch rimane esposta, rimane un rischio residuo.

Se il tuo negozio è bloccato su PHP 7.x o 8.1, avvia subito un progetto strutturato

È il caso più scomodo. In emergenza vuoi ridurre il rischio. Nella pratica una vecchia boutique non sempre sale di versione senza problemi. Occorre quindi trattare la questione come un vero progetto, non come un semplice clic nel pannello hosting.

Perché l’upgrade di versione a volte rompe un negozio vecchio

Quando un negozio resta su 7.x o 8.1 il blocco deriva spesso da un insieme noto: moduli incompatibili, tema obsoleto, override fragili, connettori non più mantenuti. Finché questo non viene risolto rimani dipendente da una branch che non offre più le stesse garanzie di supporto.

Su PrestaShop è spesso il momento di rivedere i componenti più rischiosi e di individuare un modulo PrestaShop mal codificato prima di lasciarlo in produzione. Il vantaggio non è solo la compatibilità: è anche la riduzione del rischio alle prossime aggiornamenti.

Quali controlli fare se sospetti già una compromissione

Dopo il patch, l’assenza di errori visibili non prova l’assenza di compromissione. Se la tua branch PHP era esposta, occorre controllare i log HTTP e PHP, confermare il modo d’esecuzione effettivo e poi valutare l’esposizione possibile di password, token e chiavi API presenti sul server.

Il criterio decisionale è semplice: se non puoi escludere l’esposizione di segreti applicativi, prevedi la loro rotazione nel perimetro interessato. Aspettare un sintomo evidente non è una buona strategia su un problema di perdita di memoria.

Quando passare da un correttivo immediato a un progetto di compatibilità strutturato

Se l’aggiornamento di PHP rompe il sito, il funnel o l’amministrazione, torna in modalità progetto appena l’urgenza è contenuta. Bisogna elencare le incompatibilità, decidere cosa correggere rapidamente e cosa sostituire, quindi testare l’upgrade in un ambiente separato prima del ritorno in produzione.

Se il tuo negozio PrestaShop è bloccato su una branch vecchia PHP, posso intervenire in supporto PrestaShop puntuale o mensile per gestire l’upgrade, poi assicurare la manutenzione mensile di una boutique PrestaShop. Diagnosi gratuita, risposta entro 24 h, preventivo in 24 h lavorative.

Domande frequenti

Il mio sito PrestaShop, WordPress o WooCommerce è interessato se non tocco mai direttamente il codice PHP?

Sì, potenzialmente. PHP2Shell colpisce il cuore di PHP, non solo codice personalizzato. Se il tuo sito esegue una branch PHP esposta, il rischio esiste anche senza sviluppo interno recente. Il buon reflex è quindi verificare la versione PHP effettiva usata dal sito e confermare se è corretta o se il fornitore ha pubblicato un backport documentato.

Come verificare la vera versione PHP utilizzata dal mio sito, e non solo quella mostrata in linea di comando?

Su PrestaShop guarda in Parametri avanzati > Informazioni. Su WordPress e WooCommerce vai in Strumenti > Stato di salute del sito. È più affidabile per il sito web rispetto al solo comando php -v. Su VPS o dedicato la versione CLI può differire da quella del front; incrocia la versione vista nel CMS, i pacchetti installati e la comunicazione del fornitore.

Il mio host condiviso ha già corretto la vulnerabilità o devo agire io nel pannello hosting?

Contano entrambi i punti. Un host condiviso può aver applicato fix o protezioni sui cluster, ma la branch PHP scelta per il tuo sito va comunque verificata. Se il pannello cliente lascia ancora il negozio su 8.1 o una branch più vecchia, non presumere che tutto sia risolto. Controlla la versione usata dal sito e le comunicazioni ufficiali dell’host.

Una regola WAF o la disattivazione di session.upload_progress è sufficiente, o devo comunque aggiornare PHP?

Devi comunque aggiornare PHP. Gli avvisi ufficiali indicano che l’aggiornamento è l’unica opzione sicura. Un WAF può ridurre rapidamente il rischio, e session.upload_progress.enabled=0 può limitare parte del perimetro di CVE-2026-109619, ma queste misure restano temporanee e incomplete. Servono per guadagnare tempo, non per correggere il motore PHP.

Sono ancora su PHP 8.1, 8.0 o 7.x: sono sempre vulnerabile e c’è un fix disponibile?

Devi considerare queste branch a rischio finché un fix o un backport del fornitore non è confermato esplicitamente. Per 8.1 e precedenti non c’è più supporto upstream. Possono esserci retroporting da fornitori per 7.4, 8.0 e 8.1, ma sono limitati. Sotto 7.4 non è annunciato nulla. Su un negozio vecchio la difficoltà reale è spesso la compatibilità di moduli, tema e connettori.

Quali segnali semplici devono farmi sospettare una compromissione prima o dopo il patch?

Ogni comportamento anomalo su un negozio esposto richiede verifica, ma l’assenza di sintomi visibili non basta a rassicurare. Con PHP2Shell il punto sensibile è anche la perdita di memoria. Se il sito girava su una branch vulnerabile, fai controllare i log HTTP e PHP, il modo d’esecuzione effettivo e l’esposizione possibile di password, token e chiavi API. Se il dubbio persiste, pianifica la rotazione dei segreti interessati.