Il 21 ottobre 2026 PHP ha pubblicato quattro versioni di emergenza: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Non era un aggiornamento di routine. Chiudono due vulnerabilità battezzate php2shell, tracciate come CVE-2026-109618 e CVE-2026-109619, che permettono l'esecuzione di codice sul server senza autenticazione preventiva. L'agenzia federale americana di cybersicurezza ha chiesto lo stesso giorno di applicare la patch senza attendere (CISA, 2026).
L'esecuzione di codice remoto senza autenticazione è, nella lista delle cose che possono capitare a un sito, la combinazione che nessuno vuole vedere. Niente credenziali rubate. Niente sessione dirottata. Niente conoscenza interna dell'applicazione. Se il server espone una versione interessata, l'attaccante invia istruzioni e il server le esegue. Nessuna password da rubare. Nessuna difesa da forzare per entrare.
Questo pezzo non ripete il telegiornale. Risponde a ciò che il telegiornale non risponde: come capire se sei esposto, cosa fare questa settimana e chi occupa ogni parte del lavoro. Se dirigi un team tecnico con siti su PHP, tuoi, dei clienti o ereditati, è questo che hai davanti, con la differenza che stavolta il calendario non l'ha fissato il tuo piano trimestrale ma qualcuno che pubblicava due CVE di martedì mattina.
php2shell è una coppia di vulnerabilità di PHP, CVE-2026-109618 e CVE-2026-109619, che permettono l'esecuzione di codice sul server senza autenticazione. Sono state divulgate il 20 e il 21 ottobre 2026 e la patch è uscita il 21 stesso: le versioni sicure sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35 in ogni ramo (Huntress, 2026). La CISA ha chiesto di applicarle subito, perché lo sfruttamento è iniziato in ore, non in settimane. Qui sotto: come fare l'inventario delle superfici che girano su PHP, in quale ordine correggere, cosa verificare dopo (credenziali, log, webshell) e che c'entra la NIS2.
Cos'è php2shell e perché la patch è uscita in 24 ore
La sequenza è stata rapida perfino per gli standard di questo tipo di falla. Il 20 ottobre il progetto PHP ha annunciato una pubblicazione fuori calendario per il giorno dopo; il 21, alle 14:00 UTC, i dettagli tecnici e le versioni corrette sono usciti quasi insieme (Huntress, 2026). Il margine per inventariare ciò che era esposto prima dell'esistenza di un exploit pubblico è stato praticamente nullo, e non perché il progetto PHP abbia sbagliato qualcosa, ma perché l'inventario delle superfici di un'organizzazione media, spalmato tra team di piattaforma, sviluppo e un paio di fornitori esterni, non si fa in un pomeriggio né a forza di buone intenzioni.
Quasi tutte le versioni di PHP sono interessate, comprese quelle che risalgono alla 5.4, e Wiz stima la superficie esposta intorno al 70% del web (Wiz, 2026). La patch esiste per i rami sotto supporto attivo, da 8.2 a 8.5, e le versioni che chiudono i due CVE sono le quattro della tabella. Se in qualche ambiente gira una 8.2 fino a 8.5 precedente alla sua, quell'ambiente è in zona di rischio, e lo è anche se nessuno l'ha documentato, perché la mappa di ciò che gira in produzione e quella che il team crede giri in produzione divergono da anni in ogni azienda che ha ereditato sistemi, assorbito progetti o integrato team altrui.
| Ramo PHP | Versione corretta (21 ottobre 2026) |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
La differenza tra un'esecuzione di codice che richiede credenziali e una che non le richiede è la differenza tra un incidente e una campagna. La prima la sfrutta chi è già entrato. La seconda chiunque. Bastano uno script e una lista di indirizzi. Stesso giorno, su larga scala. Per questo l'allerta della CISA (2026) non parla di rischio potenziale, e per questo tentativi di sfruttamento massicci contro siti non corretti venivano registrati nelle ore successive alla pubblicazione dei dettagli (Help Net Security, 2026).
La falla l'ha trovata un'IA: cosa cambia per il tuo calendario
Le vulnerabilità sono state individuate il 19 agosto 2026 dal team di ricerca di Wiz, con modelli di IA a fare parte del lavoro di scoperta, secondo la loro stessa analisi tecnica (Wiz, 2026). Erano lì da anni. Una settimana prima della patch, CNBC (2026) raccontava l'altra metà dello stesso schema: Mythos, il modello di Anthropic dedicato a individuare falle software, aveva esposto in Bank of America difetti sufficienti perché la banca annunciasse l'assunzione di 1.000 professionisti esterni a supporto del team interno di correzione. Tradotto per il tuo calendario: la scoperta si è industrializzata, la correzione resta umana, e un avviso di ventiquattro ore diventa settimane di lavoro appena le finestre di manutenzione non dipendono dal tuo team.
Black Kite (2026) ha contato 7.551 organizzazioni pubblicate come vittime di ransomware nel 2026, il 24,9% in più dell'anno precedente. Ogni falla esposta alimenta questa macchina, e la macchina non distingue chi ha corretto in tempo da chi contava di farlo a fine sprint.
Come capire se il tuo sito è esposto
L'inventario è metà del lavoro. Cinque domande per ordinarlo.
- Quale versione di PHP serve ogni ambiente. Non quella che dice la documentazione: quella che risponde il server. Ambienti pubblici, staging dimenticati, container vecchi e quel CMS che nessuno tocca dal 2023.
- Se ce n'è una tra 8.2 e 8.5 sotto la versione corretta del suo ramo. 8.2.35, 8.3.36, 8.4.27 e 8.5.12 sono il taglio (Huntress, 2026). Sotto quella soglia, esposto.
- Cosa gestisce il hosting e cosa gestite voi. Su hosting condiviso o gestito il motore PHP lo aggiorna il fornitore. La domanda non è se esiste la patch, ma quando la applica e se avvisa i clienti, perché il calendario del fornitore e la sua politica di avvisi decidono qui più della vostra documentazione di infrastruttura.
- Cosa succede con WordPress e gli altri CMS. La vulnerabilità sta nel motore PHP, non nel CMS né nei suoi plugin: aggiornare i plugin non corregge php2shell. Il sito è coperto quando il server serve una versione corretta, non un minuto prima, e conviene chiedere per iscritto al fornitore la versione servita oggi e la data impegnativa di aggiornamento.
- Cosa gira su rami senza supporto, come PHP 7. Quelle versioni non riceveranno mai questa patch. Il rischio accumulato non ha scadenza e l'uscita ragionevole è pianificare la migrazione.
Cosa fare questa settimana
- Aggiornare alle versioni corrette su ogni superficie inventariata, partendo da quelle esposte a internet. La CISA (2026) non sfuma l'ordine: chiede immediatezza. Senza finestre di grazia.
- Se qualche superficie non si può toccare subito, ridurla o isolarla in attesa della patch, e sorvegliare cosa le arriva.
- Una volta corretto, ruotare credenziali, chiavi API e segreti che vivevano sul server, e rivedere i log di accesso e di esecuzione in cerca di webshell: quando l'esecuzione è stata possibile senza autenticazione, la patch chiude la porta ma non guarda chi era entrato prima. È il passaggio che la maggior parte dei team salta, e quello che separa una chiusura pulita da un incidente latente che risorge a gennaio.
- Verificare con un test esterno. Una patch applicata è un'affermazione; un test che prova a sfruttare la superficie e non ci riesce è un fatto, e conviene che lo esegua qualcun altro rispetto a chi ha applicato la patch, perché auditare il proprio lavoro con le proprie mani resta il modo più comodo di non trovare nulla.
E se la tua organizzazione è soggetta a regolamentazione, la gestione di queste vulnerabilità non è una buona pratica volontaria ma un obbligo con nome e cognome, come spiega la nostra guida su cos'è la direttiva NIS2 per le imprese.
Il collo di bottiglia non è la patch, è chi la applica
La patch è gratuita. Il tempo no. È pubblicata da giorni, e ciò che scarseggia è il tempo delle persone capaci di inventariare ambienti, aggiornare motori, rileggere log e firmare che la superficie è chiusa. Quando quel lavoro si accumula, spunta il conto che nessuno aveva messo a budget: ore di piattaforma, ore di sviluppo e ore di revisione, tutte in competizione con la roadmap già impegnata prima di martedì.
Il mercato italiano era già sotto tensione prima dell'evento. Secondo l'analisi di mercato di Shakers, 2.427 delle 35.623 offerte tech attive in Italia al 26 ottobre 2026 menzionano la cybersecurity, quasi il 7% del totale, e non come responsabilità laterale di profili vicini ma come requisito esplicito della descrizione. Quando due CVE con patch urgente arrivano di martedì, quella domanda non aspetta il ciclo annuale di assunzione: si copre con capacità che parta questa settimana, non con una posizione approvata per il trimestre prossimo.
Per inventario e patch, affiancare un PHP developer senior che ha attraversato aggiornamenti di versione massivi è la via rapida. Per il dopo, collaborare con un esperto di cybersicurezza che auditi la superficie e firmi ciò che è rimasto chiuso. Integrare questa capacità attraverso un'infrastruttura di assunzione, con condizioni validate e senza ampliare l'organico fisso, è la differenza tra coprire un'emergenza di due settimane e portarsi dietro un costo fisso da gennaio a dicembre.
Domande frequenti su php2shell
- Quali versioni di PHP sono sicure dopo php2shell?
Quelle pubblicate il 21 ottobre 2026: 8.5.12, 8.4.27, 8.3.36 e 8.2.35, ciascuna nel suo ramo. La patch esiste solo da 8.2 a 8.5: qualsiasi ambiente precedente resta esposto, e le versioni senza supporto, da PHP 5.4 a 8.1, non hanno rimedio.
- WordPress è interessato da php2shell?
La vulnerabilità sta nel motore PHP, non in WordPress né nei suoi plugin. Un sito su WordPress è coperto quando il hosting o il server serve una versione corretta di PHP. Aggiornare plugin e tema non sostituisce quella patch.
- Cosa significa RCE senza autenticazione?
Che un attaccante può far eseguire al server il proprio codice senza utente, senza password e senza sessione preventiva. Nessuna credenziale rubata né accesso iniziale richiesto: basta raggiungere l'URL esposta, ed è per questo che questo tipo di falla si presta a campagne automatiche e massicce.
- Si sta già sfruttando?
Sì. La CISA ha chiesto di applicare la patch immediatamente il 21 ottobre 2026, e tentativi di sfruttamento massicci contro siti non corretti venivano registrati nelle ore successive alla pubblicazione dei dettagli (Help Net Security, 2026).
- Cosa faccio se non posso aggiornare questa settimana?
Riduci la superficie esposta nell'attesa: limita l'accesso agli endpoint interessati, sorveglia cosa arriva loro e dai una data certa alla patch. E se il sistema gira su un ramo senza supporto, la patch non arriverà mai: l'uscita è pianificare la migrazione di versione.
. 