{"id":842429,"date":"2026-10-22T11:49:18","date_gmt":"2026-10-22T11:49:18","guid":{"rendered":"https:\/\/www.knowband.com\/blog\/?p=842411\/"},"modified":"2026-10-22T11:58:28","modified_gmt":"2026-10-22T11:58:28","slug":"vulnerabilit%c3%a0-critiche-di-php-ottobre-2026-cosa-deve-fare-subito-ogni-proprietario-di-un-negozio-prestashop","status":"publish","type":"post","link":"https:\/\/www.knowband.com\/blog\/it\/notizia\/vulnerabilit%c3%a0-critiche-di-php-ottobre-2026-cosa-deve-fare-subito-ogni-proprietario-di-un-negozio-prestashop\/","title":{"rendered":"Vulnerabilit\u00e0 critiche di PHP (ottobre 2026): cosa deve fare subito ogni proprietario di un negozio PrestaShop"},"content":{"rendered":"

Leggete prima questo. Il 21 ottobre PHP ha rilasciato delle patch per due vulnerabilit\u00e0 critiche. Se il vostro negozio utilizza una versione di PHP non aggiornata, un utente malintenzionato potrebbe essere in grado di eseguire codice sul server senza effettuare l’accesso. Nessuna delle due vulnerabilit\u00e0 \u00e8 presente in PrestaShop. Oggi avete bisogno di tre informazioni: quale versione di PHP \u00e8 in esecuzione, se il vostro provider di hosting ha applicato la patch (assicuratevelo per iscritto) e se PHP \u00e8 stato riavviato da allora.<\/p>\n

La maggior parte delle notizie sulla sicurezza riguarda un plugin o un tema, e la soluzione si riduce a un pulsante con la scritta “Aggiorna”. Questo caso \u00e8 diverso. Il problema risiede nel motore del tuo negozio online, e la soluzione si trova sul server, al di fuori della portata del back office. Ecco perch\u00e9 \u00e8 facile non accorgersene, ed ecco perch\u00e9 devi dedicare un pomeriggio a risolverlo con calma e metodo.<\/span><\/p>\n

Come si sono svolti i fatti<\/b><\/h2>\n

Il team PHP ha avvertito il 20 ottobre dell’imminente rilascio di vulnerabilit\u00e0 di sicurezza. Queste sono state scoperte il 21 ottobre e hanno ricevuto i numeri CVE CVE-2026-109618 e CVE-2026-109619. Entrambe le vulnerabilit\u00e0 hanno ottenuto un punteggio di 9.2 sulla scala CVSS v4.0, sono considerate critiche e si sono guadagnate il soprannome di “php2shell”. Un avviso congiunto \u00e8 stato emesso dalla Commissione europea (DG CNECT), ENISA, CERT-EU, Europol EC3 e CSIRTs Network.<\/span><\/p>\n

La Commissione europea (DG CNECT), ENISA, CERT-EU, Europol EC3 e la rete CSIRTs hanno quindi rilasciato una dichiarazione congiunta invitando le organizzazioni ad agire. <\/span><\/p>\n

Versioni corrette: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.<\/span><\/p>\n

Cosa \u00e8 effettivamente rotto?<\/b><\/h2>\n

\"\"<\/a><\/p>\n

Entrambe le vulnerabilit\u00e0 possono portare all’esecuzione di codice remoto senza autenticazione. In altre parole: uno sconosciuto su internet potrebbe far s\u00ec che il tuo server esegua le sue istruzioni.<\/span><\/p>\n

La vulnerabilit\u00e0 CVE-2026-109618 riguarda un problema di gestione della memoria. Immaginiamo che PHP stia creando l’area di lavoro per una richiesta in arrivo e che il server esaurisca la memoria a met\u00e0 dell’operazione. PHP si arresta, ma la successiva routine di pulizia presuppone che l’area di lavoro parzialmente completata sia terminata e agisce di conseguenza.<\/span><\/p>\n

La vulnerabilit\u00e0 CVE-2026-109619 \u00e8 pi\u00f9 simile a un residuo di una sbornia. Un elemento appartenuto a una richiesta rimane in memoria anche dopo che quest’ultima \u00e8 stata rilasciata, e una richiesta successiva sullo stesso worker pu\u00f2 recuperarlo e considerarlo attendibile.<\/span><\/p>\n

Notate dove risiedono entrambi: all’interno di PHP. PrestaShop non \u00e8 responsabile e non pu\u00f2 difendersi da questo tipo di attacco, poich\u00e9 pu\u00f2 verificarsi prima ancora che venga eseguita una singola riga di codice di PrestaShop. Pertanto, un aggiornamento del modulo o del core non cambia nulla in questo caso. <\/span>L’aggiornamento di PHP risolve il problema.<\/b><\/p>\n

Di chi \u00e8 il problema?<\/b><\/h2>\n

Sono inclusi tutti i metodi di esecuzione di PHP per il web: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. Apache con mod_php rappresenta il caso peggiore, poich\u00e9 l’attacco pu\u00f2 essere eseguito prima di qualsiasi codice applicativo.<\/span><\/p>\n

La procedura da seguire dipende dal tuo ambiente di hosting e da chi gestisce l’installazione di PHP:<\/p>\n\n\n\n\n\n\n\n\n
Ambiente ospitante<\/th>\nChi gestisce PHP?<\/th>\nAzione raccomandata<\/th>\n<\/tr>\n<\/thead>\n
Hosting Condiviso<\/td>\nIl tuo provider di hosting<\/td>\nContatta il tuo provider di hosting e richiedi conferma dell’avvenuta applicazione delle patch di sicurezza PHP pertinenti al tuo ambiente.<\/td>\n<\/tr>\n
VPS o Server Dedicato<\/td>\nTu o il tuo amministratore di sistema<\/td>\nInstalla gli aggiornamenti di sicurezza appropriati per la tua versione di PHP o per il pacchetto del sistema operativo, quindi riavvia i relativi servizi PHP se necessario.<\/td>\n<\/tr>\n
Hosting basato su Docker o container<\/td>\nIl team responsabile dell’immagine del container<\/td>\nRicrea l’immagine utilizzando un’immagine base PHP con le correzioni di sicurezza applicabili, quindi ridistribuiscila e verifica l’ambiente di esecuzione.<\/td>\n<\/tr>\n
Versioni di PHP obsolete o non supportate<\/td>\nIl tuo provider di hosting o l’amministratore del server<\/td>\nVerifica se \u00e8 disponibile un backport di sicurezza del fornitore. In caso contrario, pianifica il passaggio a una versione di PHP supportata dopo averne verificato la compatibilit\u00e0 con il tuo negozio, il tema e i moduli.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

La tua lista di cose da fare oggi<\/b><\/h2>\n
    \n
  1. Cerca la versione di PHP.<\/b> Back Office, Parametri avanzati, Informazioni.<\/span><\/li>\n
  2. Scrivi al tuo ospite.<\/b> Chiedete direttamente: “I nostri server sono stati aggiornati per le vulnerabilit\u00e0 CVE-2026-109618 e CVE-2026-109619? Tutti i processi PHP sono stati riavviati?”. Conservate la risposta che ricevete. Suggerimento: alcune distribuzioni applicano la patch in modo silenzioso, lasciando invariato il numero di versione; pertanto, l’anzianit\u00e0 del numero di versione non pu\u00f2 essere utilizzata per determinare se il server \u00e8 vulnerabile o meno.<\/span><\/li>\n
  3. Aggiorna, quindi riavvia.<\/b> Passa a una versione stabile o a un pacchetto con patch del fornitore. Riavvia tutti i processi worker di PHP. Il riavvio \u00e8 un passaggio che spesso viene dimenticato. Su Docker, ricostruisci le immagini.<\/span><\/li>\n
  4. Utilizzi PHP 8.1 o versioni precedenti?<\/b> Il progetto PHP ha pubblicato dei backport minimi per le versioni 7.4, 8.0 e 8.1, e molte distribuzioni Linux e fornitori di versioni LTS distribuiscono pacchetti patchati. Verifica se la tua lo fa. In ogni caso, inizia a pianificare il passaggio a una versione supportata.<\/span><\/li>\n
  5. Prendi in considerazione PrestaShop in seguito.<\/b> Scegli una versione che supporti la tua versione di PHP (vedi la tabella sottostante). Questa operazione va eseguita dopo l’applicazione della patch, non prima.<\/span><\/li>\n<\/ol>\n

    Impossibile applicare la patch? Le linee guida dell’UE suggeriscono una soluzione: isolare l’applicazione vulnerabile dalla rete pubblica fino a quando non viene corretta. Una soluzione drastica per un negozio, certo. Ma \u00e8 comunque un’opzione da tenere in considerazione.<\/span><\/p>\n

    Soluzioni temporanee in attesa<\/b><\/h2>\n

    La posizione ufficiale di PHP \u00e8 che nessuna misura di mitigazione \u00e8 completa e l’aggiornamento \u00e8 l’unica via sicura. Considerate tutto ci\u00f2 che \u00e8 descritto in questa sezione come un modo per ridurre l’esposizione al rischio per alcuni giorni, niente di pi\u00f9.<\/span><\/p>\n