PHP2Shell e PrestaShop: cosa fare per CVE-2026-109618 e CVE-2026-109619, anche se non puoi aggiornare il negozio

Il 21 ottobre 2026 il progetto PHP ha pubblicato un rilascio d'emergenza per due vulnerabilità critiche di PHP stesso, ora note insieme come PHP2Shell: CVE-2026-109618 e CVE-2026-109619. Entrambe possono consentire a un attaccante di eseguire codice su un server web senza autenticarsi e, in alcune configurazioni, prima ancora che venga eseguita una sola riga di codice del tuo negozio.

Per la maggior parte dei siti web il consiglio è breve: aggiorna PHP e riavvialo. Per i negozi PrestaShop non è così semplice, ed è per questo che abbiamo scritto questa guida. Tutte le versioni di PrestaShop precedenti alla 9.0 supportano ufficialmente al massimo PHP 8.1, e per PHP 8.1 e tutte le versioni precedenti non è stato pubblicato alcun rilascio ufficiale corretto. Quindi questa settimana una buona parte dei negozi PrestaShop nel mondo non può limitarsi ad "aggiornare PHP".

Questa guida spiega in cosa consistono le vulnerabilità, come capire se il tuo negozio è davvero esposto (il solo numero di versione non basta), cosa fare per ogni versione di PrestaShop e la soluzione temporanea che usiamo per i negozi che non possono essere aggiornati subito: portarli su un PHP 7.4 corretto dal fornitore, partendo da una copia di staging e sistemando le parti di codice che smettono di funzionare. È un ponte, non un punto d'arrivo. Ed è comunque molto meglio che restare esposti o chiudere il negozio.

Cos'è PHP2Shell, in parole semplici

Entrambe le falle si trovano nel motore PHP, la parte che riceve una richiesta web e la prepara prima che inizi l'esecuzione del codice del tuo negozio. Ecco perché nessun aggiornamento di PrestaShop, modulo o tema può correggerle. Serve una versione corretta di PHP.

I ricercatori hanno anche dimostrato che un attaccante può leggere la memoria dei processi worker PHP senza autenticarsi. Quella memoria può contenere password, token di sessione e chiavi API provenienti dalle richieste di altri visitatori. Per questo la sezione sui controlli e sulla bonifica alla fine della guida è importante anche se nessuno ha installato nulla sul tuo server.

È interessata qualsiasi installazione PHP che gestisca richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il progetto PHP considera il rischio più alto per mod_php, dove ha dimostrato un exploit che scatta prima dell'esecuzione di qualsiasi codice applicativo. Questo dettaglio conta per chi gestisce un negozio PrestaShop: l'accesso al back office, la modalità manutenzione del negozio e tutti i moduli di sicurezza entrano in funzione dopo che PHP ha già analizzato la richiesta, quindi nessuno di questi fa da ostacolo.

La protezione deve stare a monte di PHP. Tutto ciò che è dentro PrestaShop si avvia quando il danno è già fatto.

La cronologia

Perché per i negozi PrestaShop è più complicato

Ecco la tabella scomoda. Mostra la versione PHP massima ufficialmente supportata da ciascun ramo di PrestaShop, secondo i requisiti di sistema di PrestaShop stesso, e indica se esiste un rilascio PHP ufficiale corretto compatibile.

Un "No" nella terza colonna non significa che non esista una correzione. Significa che deve arrivare da una fonte diversa da php.net: una distribuzione Linux, il produttore del pannello di hosting, un fornitore di supporto a lungo termine oppure un PHP che compili dai sorgenti con il backport minimo del progetto PHP. È lì che questa settimana deve cercare la maggior parte dei negozi PrestaShop, ed è anche lì che si trovano le buone notizie.

Ogni riga senza una cella verde dipende da un backport del fornitore o dal ponte con PHP 7.4.

Passaggio 1: scopri quale PHP usa davvero il tuo negozio

Qui ci sono due trappole in cui cadono quasi tutti.

La prima trappola: il PHP che vedi via SSH non è necessariamente quello che gestisce il tuo negozio. Spesso sui server sono installate più versioni PHP affiancate, e la riga di comando può usarne una diversa dal server web. In PrestaShop, apri Parametri avanzati, Informazioni (Advanced Parameters, Information): la versione PHP mostrata lì è quella che gestisce davvero le richieste del tuo negozio. L'impostazione PHP del dominio nel pannello di hosting dovrebbe indicare la stessa versione.

La seconda trappola: il numero di versione non ti dice se la patch è stata applicata. Le distribuzioni e i fornitori di hosting applicano tramite backport le correzioni di sicurezza alla versione che hai già, mantenendo il vecchio numero. Un "PHP 7.4.33" può essere completamente corretto su un server e del tutto esposto su un altro. La prova è nell'avviso del fornitore relativo al tuo pacchetto esatto, oppure in una risposta scritta del tuo hosting.

# Facoltativo: alcuni server dichiarano la versione PHP. Non dimostra che la patch sia applicata.
curl -sS -I https://www.example-shop.com/ | grep -i '^X-Powered-By:'

# Indizi dai changelog dei pacchetti. Una corrispondenza per entrambe le CVE è un buon segno.
# Nessuna corrispondenza non dimostra nulla: alcuni fornitori registrano solo il cambio di versione. Chiedi al fornitore.
# Adatta il nome del pacchetto alla versione PHP e al gestore che serve il tuo negozio.

# Debian e Ubuntu
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php7.4-fpm/changelog.Debian.gz

# PHP di sistema su RHEL, AlmaLinux, Rocky e CloudLinux
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

# cPanel EasyApache (ea-php) e CloudLinux PHP Selector (alt-php)
rpm -q --changelog ea-php74-php-fpm | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog alt-php74-common | grep -E 'CVE-2026-10961[89]'

Il tuo hosting potrebbe già avere un vecchio PHP corretto, persino PHP 5

Questo è l'aspetto che molti proprietari di negozi meno recenti non conoscono. Diversi fornitori di hosting distribuiscono build proprie delle vecchie versioni PHP e hanno corretto anche quelle:

• CloudLinux PHP Selector (alt-php): le build corrette per PHP dalla 5.2 alla 5.6, dalla 7.0 alla 7.4 e dalla 8.0 alla 8.5 sono arrivate nei repository stabili il 22 ottobre, su CloudLinux 7, 8 e 9 (CloudLinux 10 le riceve tramite il repository di TuxCare).
• Build CloudLinux di cPanel PHP (ea-php): corrette da ea-php52 fino a ea-php85, mantenendo i vecchi numeri di versione.
• EasyApache PHP distribuito direttamente da cPanel: rilasci ufficiali dalla 8.2 alla 8.5 e backport per 8.1 (8.1.34-5), 8.0 (8.0.30-12) e 7.4 (7.4.33-19). Le build di cPanel della 7.3 e precedenti non hanno ricevuto una correzione; cPanel indirizza questi utenti a TuxCare.
• Red Hat e le distribuzioni che ne ricompilano i pacchetti: le correzioni vengono pubblicate per ciascuno stream. Controlla gli errata relativi all'esatto stream PHP attivo sul tuo server e non dare per scontato che un semplice aggiornamento di sistema abbia risolto il problema: le prime segnalazioni indicavano alcuni stream come corretti e altri ancora in attesa.
• TuxCare Endless Lifecycle Support: supporto a lungo termine a pagamento, con patch per le versioni PHP giunte a fine vita.

Quindi la stessa dicitura, "PHP 7.1" nel pannello di hosting, può indicare una versione corretta su un hosting e vulnerabile su un altro. Prima di pianificare interventi sul codice, fai al tuo hosting una domanda precisa. Ecco un messaggio che puoi inviare così com'è:

Oggetto: PHP2Shell (CVE-2026-109618, CVE-2026-109619) sul mio account

Ciao,
il mio negozio usa PHP X.Y (gestore: PHP-FPM / mod_php / LiteSpeed) sui tuoi server.
La build PHP che gestisce il mio sito include la correzione per CVE-2026-109618 e
CVE-2026-109619? Puoi indicarmi la versione esatta del pacchetto e confermare se i
processi PHP sono stati riavviati dopo l'installazione? Se la mia versione non ha una
correzione, a quali versioni PHP corrette posso passare con il mio piano?
Grazie.

Se la risposta è "sì, entrambe corrette e processi riavviati", la parte urgente è risolta senza toccare una riga di codice. Leggi la sezione sui controlli per una possibile compromissione, poi pianifica l'aggiornamento con calma.

Passaggio 2: scegli la strada per la tua versione di PrestaShop

Qualunque sia la tua versione, la prima scelta è la stessa: un pacchetto corretto per il ramo PHP su cui gira già il negozio. Passare a un altro ramo PHP è un cambiamento più impegnativo e richiede sempre una prova su una copia di staging, verificando moduli, override e checkout.

Chiedi al tuo hosting prima di pianificare interventi sul codice: la strada meno costosa è una build corretta già a tua disposizione.

PrestaShop 9

Aggiorna al rilascio corretto del tuo ramo: 8.2.35, 8.3.36 o 8.4.27, oppure 8.5.12 su PrestaShop 9.1. Riavvia e verifica la versione nella pagina Informazioni. Se il tuo negozio 9.0 usa ancora PHP 8.1, passare alla 8.2 o a una versione successiva significa cambiare ramo: provalo prima in staging, oppure nel frattempo usa una 8.1 corretta dal fornitore.

PrestaShop dalla 8.0 alla 8.2

Queste versioni supportano ufficialmente PHP dalla 7.2 alla 8.1, e per nessuna di esse è disponibile un rilascio corretto da php.net. Hai quindi più opzioni di quanto sembri presso i fornitori: una 8.1 corretta (la 8.1.34-5 di cPanel, alt-php81 di CloudLinux, il pacchetto php8.1 di Ubuntu 22.04, TuxCare), ma anche una 8.0 o una 7.4 corrette dagli stessi fornitori, tutte comprese nell'intervallo ufficialmente supportato da PrestaShop 8. Se non riesci a ottenere una build corretta da nessun fornitore, la soluzione duratura è aggiornare a PrestaShop 9. Finché non hai un ambiente di esecuzione corretto, applica le misure temporanee descritte più avanti.

PrestaShop 1.7.8

PHP 7.4 è il suo limite ufficiale e le build corrette della 7.4 sono relativamente facili da trovare: cPanel 7.4.33-19, CloudLinux alt-php74, TuxCare e i pacchetti delle distribuzioni, dove il fornitore li ha pubblicati. Se il tuo negozio usa un PHP più vecchio, passare a una 7.4 corretta resta entro i limiti ufficiali della 1.7.8. Provalo comunque in staging.

PrestaShop 1.6.1.x e dalla 1.7.0 alla 1.7.7

Queste versioni si fermano ufficialmente a PHP 7.1, 7.2 o 7.3. Per prima cosa, chiedi al tuo hosting se esiste una build corretta della versione che usi (vedi sopra). Se esiste, passa a quella e la parte urgente è risolta. Se non esiste, entra in gioco la nostra soluzione temporanea.

La soluzione temporanea che usiamo: PHP 7.4 corretto come ponte

È quello che facciamo concretamente per i negozi di cui ci occupiamo e che non possono essere aggiornati questo mese. L'idea è far funzionare il negozio su un PHP 7.4 per cui un fornitore distribuisce ancora patch, anche se la versione di PrestaShop in uso si ferma ufficialmente prima della 7.4, e correggere le parti di codice che non la gestiscono. Nella nostra esperienza, su PHP 7.4 il core di PrestaShop 1.6.1 e 1.7 genera soprattutto notice e avvisi di deprecazione, non errori fatali. A smettere davvero di funzionare sono di solito pochi moduli e override vecchi. È una soluzione temporanea, e lo diciamo chiaramente: per un periodo usi una combinazione che non rientra nella matrice di supporto ufficiale di PrestaShop. Ma chiude la falla e permette al negozio di continuare a vendere mentre pianifichi il vero aggiornamento.

Un ponte, non una destinazione: chiude la falla e permette al negozio di vendere fino al vero aggiornamento.

Un esempio concreto del perché la 7.4 funziona dove PHP 8 non funzionerebbe: il file Cookie.php di PrestaShop 1.6.1.23 contiene $this->_path{0}. Su PHP 7.4 quella sintassi con le parentesi graffe è solo deprecata; su PHP 8.0 genera un errore fatale. Quella singola riga fa la differenza tra un ponte che regge e un negozio che non si carica.

1. Crea una copia di staging e rendila innocua

Copia i file e il database in un ambiente separato, per esempio un sottodominio protetto da password. Poi, prima che la copia risponda anche a una sola richiesta:

• Collegala a un database tutto suo. La configurazione copiata contiene ancora le credenziali del database di produzione (config/settings.inc.php sulla 1.6, app/config/parameters.php sulla 1.7). Sostituiscile con quelle del database di staging, possibilmente usando un utente del database senza accesso alla produzione. Tutto ciò che segue presuppone che tu abbia fatto prima questo passaggio.
• Blocca le comunicazioni in uscita. Prima che la copia risponda alla prima richiesta o esegua qualsiasi attività, blocca a livello di server, indipendentemente da PrestaShop, l'invio delle email e le connessioni ai servizi di produzione (API di pagamento, corrieri e marketplace), consentendo solo i servizi sandbox che vuoi testare. Le sole impostazioni di PrestaShop non bastano: alcuni moduli inviano email o comunicano con i marketplace tramite connessioni proprie. Poi disattiva i cron job copiati e imposta tutti i moduli di pagamento in modalità test o sandbox.
• Tieni fuori visitatori e motori di ricerca con una protezione tramite password sul server web.

Poi, solo nel database di staging:

-- SOLO NEL DATABASE DI STAGING. Sostituisci ps_ con il prefisso delle tue tabelle.
-- 1. PrestaShop stesso non invia mai email da questa copia
UPDATE ps_configuration SET value = '3' WHERE name = 'PS_MAIL_METHOD';

-- 2. Assegna alla copia il suo indirizzo (negozio singolo, installato nella radice del dominio)
SELECT id_shop_url, id_shop, domain, domain_ssl, physical_uri FROM ps_shop_url;
UPDATE ps_shop_url
SET domain = 'staging.example-shop.com', domain_ssl = 'staging.example-shop.com', physical_uri = '/'
WHERE id_shop_url = 1;
UPDATE ps_configuration SET value = 'staging.example-shop.com'
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');

Su un'installazione multinegozio, configura separatamente l'URL di ogni negozio anziché usare l'esempio per il negozio singolo.

2. Passa la copia alla 7.4 corretta e raccogli tutti gli errori

Nel pannello di hosting, seleziona il PHP 7.4 corretto per il sito di staging. Imposta error_reporting su E_ALL, registra gli errori in un file e non mostrarli a schermo. Verifica che il log riceva davvero le voci, poi ordina i problemi dal più frequente:

# Ordina gli errori PHP in staging dal più frequente (formato standard del log PHP)
grep -E 'PHP (Fatal error|Parse error|Recoverable fatal error|Warning|Notice|Deprecated):' /path/to/php-error.log \
  | sed -E 's/^\[[^]]*\] //' | sort | uniq -c | sort -rn | head -40

3. Analizza il codice che di solito dà problemi

Prima di navigare nel negozio, una rapida analisi statica di moduli, override e tema ti aiuta a individuare i soliti sospetti. È una lista di controllo parziale: non rileva le chiamate indirette, quelle suddivise su più righe e alcuni accessi con parentesi graffe, quindi un risultato vuoto non dimostra la compatibilità. Esamina ogni corrispondenza.

# Funzioni rimosse o deprecate in PHP 7.x
grep -rnE --include='*.php' \
  '\beach\s*\(|create_function\s*\(|get_magic_quotes_(gpc|runtime)\s*\(|\bmysql_[a-z_]+\s*\(|\beregi?(_replace)?\s*\(|\bsplit\s*\(|mcrypt_[a-z_]+\s*\(' \
  modules override themes

# Chiamate a preg_replace: controlla ciascuna per il modificatore /e rimosso
grep -rnE --include='*.php' '\bpreg_replace\s*\(' modules override themes

# Offset delle stringhe con parentesi graffe ($str{0}), deprecati in PHP 7.4
grep -rnE --include='*.php' '\$[A-Za-z_][A-Za-z0-9_]*\{[^}$]*\}' modules override themes

# Controllo sintattico di ogni file PHP con il binario PHP di destinazione, dalla radice di staging
# (il nome varia: php7.4, php74, /opt/cpanel/ea-php74/root/usr/bin/php ...)
find . -type f -name '*.php' -exec php7.4 -l {} \; | grep -v '^No syntax errors'

Un controllo sintattico senza errori dimostra solo che i file possono essere analizzati. Non dice nulla sulle estensioni mancanti o sul comportamento del checkout: a questo serve il passaggio 5.

4. Correggi ciò che non funziona, partendo dalla modifica più piccola

Questi sono i problemi che incontriamo più spesso quando un vecchio negozio passa a PHP 7.4, con la relativa correzione:

Correggi prima gli errori fatali, poi i warning durante il percorso di checkout, infine tutto il resto. Notice e avvisi di deprecazione non sono innocui solo perché i visitatori non li vedono: il gestore degli errori di un modulo può trasformarli in eccezioni e, se sono moltissimi, possono riempire il disco. Se l'autore di un modulo ha pubblicato un aggiornamento, preferiscilo a una patch fatta da te e tieni un elenco scritto di tutti i file che modifichi: ti servirà per il passaggio in produzione e di nuovo per il vero aggiornamento. Già che intervieni sulla configurazione, rimuovi le righe php_value e php_flag in .htaccess relative a impostazioni che PHP non riconosce più. L'avviso di sicurezza PHP chiede espressamente di eliminare le impostazioni per singola richiesta non valide o deprecate.

<?php
// config/defines_custom.inc.php (PrestaShop 1.6 include questo file automaticamente)
// PHP 7.2+ viene distribuito senza mcrypt, ma la firma dei cookie della 1.6.1 legge ancora questa
// costante. Stesso valore definito da mcrypt, così i cookie esistenti restano validi.
if (!defined('MCRYPT_RIJNDAEL_128')) {
    define('MCRYPT_RIJNDAEL_128', 'rijndael-128');
}

Questo è il codice in questione, invariato rispetto a PrestaShop 1.6.1.23 (classes/Rijndael.php):

// PrestaShop 1.6.1.23, classes/Rijndael.php
protected function generateHmac($encrypted)
{
    $macKey = $this->generateKeygenS2k('sha256', $this->_key, $this->_iv, 32);
    return hash_hmac(
        'sha256',
        $this->_iv . MCRYPT_RIJNDAEL_128 . $encrypted,
        $macKey
    );
}

5. Prova tutto il percorso di vendita, poi passa in produzione con le correzioni

In staging, verifica tutto ciò che genera incassi o lavoro: home page, pagine di categoria con filtri, ricerca, schede prodotto con combinazioni, carrello, checkout con ogni corriere e ogni metodo di pagamento in modalità test, conferma d'ordine, pagina dell'ordine nel back office, PDF di fatture e bolle di consegna, pagina di configurazione di ogni modulo, importazioni e URL dei cron.

Quando il log non segnala più problemi, pianifica il passaggio in produzione in un orario tranquillo:

• Crea un backup di cui hai già provato almeno una volta il ripristino, sia dei file sia del database.
• Porta in produzione le correzioni al codice già testate e cambia PHP nello stesso momento. Le correzioni restano in staging finché non le copi in produzione. Non sovrascrivere mai il database di produzione con quello di staging.
• Controlla subito il checkout, poi tieni d'occhio il log degli errori per 48 ore.
• Se devi tornare indietro al vecchio PHP senza patch, limita l'accesso al negozio durante il ripristino e mantieni la limitazione finché non è di nuovo attivo un ambiente di esecuzione corretto.

Finché non hai applicato la patch: misure temporanee

Il progetto PHP ha pubblicato alcune misure che riducono l'esposizione a specifiche modalità di attacco. Come precisa lo stesso progetto, non rendono sicura un'installazione e solo un aggiornamento risolve completamente il problema. Non garantiscono nemmeno un periodo di attesa sicuro. Vale la pena applicarle per le ore o i giorni che servono a far funzionare il negozio su un PHP corretto. Ecco come si applicano a un negozio PrestaShop.

Impostazioni PHP

Vanno configurate in php.ini, nel pool PHP-FPM o nella configurazione del server, non in .user.ini e nemmeno con ini_set(). Poi riavvia tutti i processi worker PHP.

; Misure temporanee per PHP2Shell in php.ini (poi riavvia PHP)
; Il core di PrestaShop non monitora l'avanzamento dei caricamenti: puoi disattivare questa funzione
session.upload_progress.enabled = 0
; Corpi delle richieste più piccoli. Valori di esempio: adattali alle esigenze reali del negozio,
; senza mai aumentare un limite già più basso
post_max_size = 32M
upload_max_filesize = 24M
max_file_uploads = 10

; In un file di pool PHP-FPM (per esempio /etc/php/7.4/fpm/pool.d/shop.conf) le stesse
; impostazioni si scrivono così; rimuovi i punti e virgola iniziali per attivarle:
; php_admin_flag[session.upload_progress.enabled] = off
; php_admin_value[post_max_size] = 32M
; php_admin_value[upload_max_filesize] = 24M

Dopo aver modificato i limiti, prova i caricamenti che il tuo team usa davvero: un archivio di un modulo particolarmente grande o un'immagine prodotto pesante potrebbero superarli. L'elenco ufficiale suggerisce anche memory_limit = -1 contro la falla legata all'esaurimento della memoria, imponendo il valore in modo che nessuna impostazione applicativa possa reintrodurre un limite. Questo permette a una singola richiesta di usare tutta la memoria del server, quindi è una misura riservata agli amministratori che possono limitare la memoria di PHP tramite un container o un cgroup e sanno cosa succede quando il limite viene raggiunto. Non chiude completamente la falla e l'avviso sconsiglia di usare RLIMIT_AS o RLIMIT_DATA al suo posto. Su un hosting condiviso, lascia che se ne occupi il tuo fornitore. Per PHP 8.5 l'avviso elenca anche fatal_error_backtraces = 0.

Rifiuta i caricamenti dove non servono al negozio

L'exploit noto arriva sotto forma di richiesta multipart/form-data, il formato che i browser usano per caricare file. Alla maggior parte delle pagine del front office di un negozio PrestaShop non serve mai. Bloccarlo al di fuori del back office interrompe quel percorso di attacco noto. Cosa smette di funzionare: gli allegati nel modulo di contatto, i campi per caricare file nella personalizzazione dei prodotti e qualsiasi modulo che consenta ai clienti di caricare file. Per la maggior parte dei negozi è un compromesso accettabile per qualche giorno.

Prima, una condizione: l'eccezione per il back office ha senso solo se, a livello di server web, il suo accesso è limitato ai tuoi indirizzi IP, in modo che le richieste provenienti da qualsiasi altro indirizzo non raggiungano mai PHP. Una pagina di accesso di PrestaShop non può proteggere da una falla che scatta prima che PrestaShop venga eseguito. Il nostro articolo sulla sicurezza del back office contiene liste di IP consentiti già pronte per Apache e nginx. Se non puoi limitare l'accesso al back office, ometti l'eccezione e sospendi per qualche giorno anche i caricamenti dal back office.

Su Apache, inserisci questo codice all'inizio del file .htaccess del negozio, sopra la riga # ~~start~~, così PrestaShop lo conserva quando rigenera il file. Sostituisci admin-folder-name con la cartella del tuo back office:

# Misura temporanea per PHP2Shell: rifiuta le richieste multipart fuori dal back office.
# Rimuovi dopo aver applicato la patch.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/admin-folder-name/
RewriteRule ^ - [F]
</IfModule>

La regola funziona solo dove mod_rewrite è attivo e i file .htaccess sono autorizzati a usarlo, quindi provala: un caricamento innocuo dal modulo di contatto dovrebbe ora restituire una pagina di errore 403, e quella pagina di errore non deve essere a sua volta uno script PHP.

Su nginx, nel blocco server del negozio:

# Misura temporanea per PHP2Shell: rifiuta le richieste multipart fuori dal back office.
set $block_multipart 0;
if ($http_content_type ~* "multipart/form-data") { set $block_multipart 1; }
if ($uri ~ "^/admin-folder-name/") { set $block_multipart 0; }
if ($block_multipart) { return 403; }

Usa $uri, il percorso normalizzato, come nell'esempio. Il valore grezzo $request_uri potrebbe essere ingannato con un percorso come /admin-folder-name/../index.php.

Le protezioni a monte del tuo negozio

• Cloudflare ha attivato regole WAF per i vettori di attacco noti, anche sui piani gratuiti. Aiutano solo se tutto il traffico verso il negozio passa davvero da Cloudflare e nessuno può raggiungere direttamente il server; sui piani a pagamento, verifica inoltre che le regole gestite siano impostate per bloccare. Sono stati segnalati tentativi degli attaccanti di aggirare le regole.
• Imunify360, diffuso sugli hosting condivisi, ha pubblicato regole che bloccano lo strumento di exploit pubblico e le varianti di CVE-2026-109619. Secondo CloudLinux, le sue regole non coprono ancora CVE-2026-109618. Gli altri firewall offrono coperture proprie, differenti.
• La modalità manutenzione non aiuta. PrestaShop decide di mostrare la pagina di manutenzione dopo che PHP ha già elaborato la richiesta. Se il tuo hosting non può applicare presto la patch, chiedi se può impedire del tutto alle richieste non attendibili di raggiungere PHP.

Dopo la patch: verifica una possibile compromissione

Sono stati osservati tentativi prima della divulgazione e la falla che espone la memoria può far trapelare segreti senza lasciare tracce nel tuo negozio. Se il negozio è stato esposto su Internet con un PHP senza patch dopo metà ottobre, dedica un'ora a questi controlli. Individuano le tracce più comuni; un risultato pulito non dimostra che non sia successo nulla.

# File eseguibili nelle cartelle che dovrebbero contenere immagini e file caricati.
# PrestaShop include un index.php in quasi ogni cartella: confronta anche quelli con una copia pulita.
find img upload download -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \)

# File modificati dai primi tentativi di sfruttamento (17 ottobre 2026), cache comprese.
# Sono solo indizi: le date di modifica possono essere falsificate. Leggi tutto l'elenco.
find . -type f -newermt '2026-10-17 00:00:00 UTC'

-- Account del back office, dal più recente. Qualcosa che non riconosci?
SELECT id_employee, firstname, lastname, email, active, last_connection_date
FROM ps_employee
ORDER BY id_employee DESC;

Il confronto più affidabile è con una copia pulita della tua versione di PrestaShop, dei tuoi moduli e con un backup precedente al 17 ottobre, includendo i file JavaScript, perché è lì che si annidano gli skimmer iniettati per rubare i dati di pagamento. Se trovi qualcosa, conserva le prove e contieni la compromissione prima di cambiare qualsiasi password, altrimenti le nuove credenziali trapeleranno nello stesso modo.

Poi, da un dispositivo di cui ti fidi, sostituisci i segreti che una lettura della memoria potrebbe aver esposto: tutte le password del back office, le chiavi API dei moduli di pagamento, corrieri e marketplace, le chiavi webservice e le password SMTP. La password del database va cambiata contemporaneamente sul server del database e nella configurazione del negozio (config/settings.inc.php sulla 1.6, app/config/parameters.php dalla 1.7 in poi), oltre che in qualsiasi altro sistema che la usa per connettersi, altrimenti il negozio smette di funzionare.

Domande frequenti

Fonti

• Progetto PHP: avviso di sicurezza e annunci dei rilasci, con gli avvisi GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp
• PrestaShop: requisiti di sistema per 1.6 e 1.7, 8 e 9
• CloudLinux: copertura di PHP2Shell e stato dei pacchetti
• Sansec: ricerca su PHP2Shell per l'e-commerce