PHP2Shell · Aggiornamento del 24 ottobre 2026
PHP2Shell: cosa verificare su siti e applicazioni aziendali
Due vulnerabilità critiche nel motore PHP richiedono aggiornamenti e verifiche sull’hosting. Come organizzare la risposta e ottenere conferma dell’intervento.

Aggiornare il CMS non significa aver aggiornato PHP. È questa distinzione che un’impresa deve chiarire subito con chi gestisce il proprio sito, ecommerce o portale. Le vulnerabilità note come PHP2Shell riguardano il motore che esegue le applicazioni: la verifica deve arrivare fino all’ambiente in produzione.
Per chiudere l’intervento servono il perimetro verificato, la correzione in produzione e il controllo delle funzioni essenziali.
Che cosa ha comunicato PHP
Il 21 ottobre 2026 il progetto PHP ha pubblicato correzioni per CVE-2026-109618 e CVE-2026-109619, che possono consentire l’esecuzione remota di codice senza autenticazione. Le release corrette indicate nell’avviso sono 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Chi utilizza pacchetti di una distribuzione deve verificare anche gli eventuali aggiornamenti applicati dal proprio fornitore.
Il 23 ottobre PHP ha pubblicato un ulteriore avviso su Session upload progress, relativo a una specifica combinazione di configurazione e codice. Chi gestisce l’infrastruttura deve leggere entrambi gli avvisi e verificare il proprio ambiente: un numero di versione, da solo, può non descrivere tutte le correzioni e le condizioni di esposizione.
Fonti: PHP — Avvisi ufficiali e release corrette · PHP — Advisory CVE-2026-109618
L’hosting deve dare una risposta verificabile
Chiedi quali applicazioni utilizzano PHP, quali ambienti sono raggiungibili dall’esterno e chi gestisce ciascun aggiornamento. Includi sottodomini, portali riservati, siti precedenti e ambienti di prova: possono avere manutentori e versioni differenti.
Per un servizio gestito, richiedi una conferma scritta dell’intervento e del perimetro coperto. Per un server amministrato internamente, assegna un responsabile tecnico e una finestra operativa. La risposta ‘il sito funziona’ non documenta la correzione del runtime.
Correggere il motore e controllare il servizio
Dopo l’intervento, verifica le funzioni che sostengono il lavoro: accesso, moduli, ordini, pagamenti e collegamenti con altri sistemi. Un aggiornamento del motore può richiedere controlli di compatibilità dell’applicazione; questi controlli vanno preparati insieme alla manutenzione.
Se emergono segnali di compromissione, coinvolgi chi può analizzare l’incidente. Aggiornare non dimostra che eventuali accessi precedenti siano stati rimossi. Anche un firewall applicativo resta una difesa aggiuntiva: non sostituisce la correzione del sistema.
La decisione da prendere dopo l’emergenza
Inserisci nel contratto di manutenzione chi riceve gli avvisi, chi autorizza interventi urgenti e quali evidenze chiudono l’attività. Affianca all’elenco dei siti una mappa di runtime, hosting e responsabili. È il documento che permette di reagire al prossimo avviso senza ricostruire tutto da capo.
PHP2Shell rende visibile un costo spesso escluso dal preventivo iniziale: mantenere operativa e aggiornata un’applicazione durante tutta la sua vita. Quel costo deve avere un proprietario e un budget, anche quando il sito non richiede nuove funzionalità.
Dall’analisi alla decisione
Tre passi da portare in azienda.
- 01
Chiedi l’elenco degli ambienti PHP e una verifica sugli avvisi del 21 e 23 ottobre.
- 02
Concorda aggiornamento, controlli applicativi e gestione delle eventuali eccezioni.
- 03
Ottieni conferma scritta dell’intervento e assegna la manutenzione futura.
Fonti e contesto
Fonti consultate il 24 ottobre 2026. I fatti sono distinti dalle nostre analisi e proposte operative; gli esempi progettuali non descrivono casi cliente.
- PHP — Avvisi ufficiali e release corrette 21 e 23 ottobre 2026
- PHP — Advisory CVE-2026-109618 21 ottobre 2026
- Cloudflare — Protezioni per PHP2Shell 21 ottobre 2026
Come si applica alla tua impresa?
Partiamo dal processo, dalle dipendenze e dalle decisioni che devi prendere.
Confrontiamoci sul tuo caso