Il 20 ottobre 2026 il team di sicurezza di PHP ha pubblicato sul sito ufficiale un avviso insolito: una release di sicurezza straordinaria è prevista per oggi, mercoledì 21 ottobre, alle 14:00 UTC (le 16:00 in Italia, ora legale). Il comunicato parla di due vulnerabilità critiche, entrambe valutate 9,2 con CVSS v4.0, e invita tutti gli utenti a prepararsi in anticipo. Nessun altro dettaglio è stato fornito. Questo articolo ricostruisce che cosa è confermato, che cosa circola solo come indiscrezione e che cosa conviene fare prima delle 16:00, perché PHP è alla base di una parte enorme del web italiano, dai siti WordPress ai gestionali sviluppati su misura.

Cosa è successo

La fonte primaria è l'avviso su php.net: due falle critiche, rilascio fissato per il 21 ottobre alle 14:00 UTC, con la precisazione che il team potrebbe anticipare la pubblicazione se i dettagli dovessero diventare pubblici o se comparisse uno sfruttamento attivo. Versioni colpite, versioni corrette e identificativi CVE saranno diffusi solo con la release.

Nelle ore successive all'avviso è circolata una fuga di notizie che ha dato un nome all'episodio, "PHP2Shell", e gli identificativi CVE-2026-109618 e CVE-2026-109619. Va sottolineato che PHP non ha confermato né il nome né i numeri CVE: li riportiamo come indiscrezioni. Sulla natura tecnica le ricostruzioni indipendenti convergono solo in parte. Secondo alcuni ricercatori, almeno uno dei due difetti sarebbe un use-after-free nella gestione dello stato di avanzamento dei caricamenti (funzione legata al modulo sessioni), mentre il secondo riguarderebbe il parser dei form multipart e non dipenderebbe da quell'impostazione. Il CERT-EU, citando informazioni non ufficiali, ritiene che le falle possano consentire l'esecuzione di codice da remoto senza autenticazione.

Sullo sfruttamento: al momento della redazione non risultano attacchi in corso segnalati. Huntress ha dichiarato di non aver osservato attività nei propri ambienti e di non conoscere exploit pubblici, e le falle non sono nel catalogo KEV della CISA. Un'azienda di sicurezza sostiene però di aver riprodotto uno dei due bug in laboratorio. Lo scenario realistico è quello classico del "patch gap": quando la correzione sarà pubblica, chi analizza le differenze nel codice potrà ricostruire l'exploit in poche ore o giorni.

Sul perimetro delle versioni non c'è conferma. Le fonti secondarie indicano che le correzioni arriveranno per i rami ancora supportati (8.2, 8.3, 8.4 e 8.5) mentre PHP 8.1 e precedenti, già fuori supporto, non dovrebbero ricevere patch ufficiali. È un'indiscrezione, ma coerente con la politica di supporto del progetto. Una società di monitoraggio ha contato circa 884.000 host esposti con banner PHP 8.1 o più vecchio: sono banner dichiarati, non sistemi verificati come vulnerabili, quindi il numero va letto come ordine di grandezza dell'esposizione, non come stima dei sistemi compromettibili.

Cosa significa per le aziende italiane

Il punto non è la gravità tecnica in sé, ma la distribuzione del rischio. In Italia PHP non vive solo nei siti vetrina: è il motore di WordPress, Joomla, Drupal, Magento, PrestaShop e di moltissimi gestionali e portali scritti dieci o quindici anni fa da software house locali e mai riscritti. Molte PMI non sanno nemmeno quale versione di PHP giri sul proprio hosting, perché la gestione è delegata a un fornitore.

Ne derivano tre categorie di esposizione molto diverse. La prima sono i sistemi su hosting condiviso o gestito: qui la patch dipende dal provider, e l'unica leva dell'azienda è chiedere conferma scritta e tempi. La seconda sono i server in autogestione su rami supportati, dove l'aggiornamento è semplice ma richiede un test di compatibilità che spesso viene rimandato. La terza, la più delicata, sono le applicazioni legacy bloccate su PHP 7 o 5.x perché il codice non funziona sulle versioni successive: per queste non ci sarà una correzione ufficiale e il rischio non si risolve con un aggiornamento di routine, ma con una decisione di isolamento o di migrazione.

C'è poi un effetto di filiera che i consulenti vedono spesso. Un'appliance, un pannello di controllo del web hosting (cPanel, Plesk) o un software commerciale può incorporare un proprio runtime PHP, aggiornabile solo dal fabbricante. L'inventario non può quindi limitarsi ai server noti: occorre cercare PHP anche dentro prodotti terzi, container e runner di integrazione continua.

Per chi rientra nel perimetro NIS2 (soggetti essenziali e importanti), questa vicenda è un test concreto di due misure di sicurezza di base: la gestione delle vulnerabilità e dei patch e la sicurezza della catena di fornitura. Un'azienda che non è in grado di rispondere in poche ore alla domanda "dove usiamo PHP e in quale versione?" ha un problema di inventario che l'autorità, in caso di incidente, difficilmente considererà trascurabile. Se il sito o il portale tratta dati personali, un'eventuale compromissione attraverso una falla nota e non corretta può configurare anche una violazione dell'art. 32 del GDPR (misure di sicurezza adeguate) e, in presenza di rischio per gli interessati, l'obbligo di notifica al Garante entro 72 ore ai sensi dell'art. 33. La data di conoscenza della falla, cioè oggi, diventa un elemento che conterà nella valutazione della diligenza.

Cosa fare subito

Prima del rilascio, in vista delle 16:00 italiane:

  • Costruire l'inventario: elencare server, container, appliance e pannelli di hosting che eseguono PHP, con la versione (php -v) e il responsabile della manutenzione. Per i siti esposti, l'intestazione X-Powered-By o il cookie PHPSESSID aiutano a individuarli dall'esterno.
  • Contattare per iscritto i fornitori di hosting e le software house chiedendo tempi di applicazione della patch e conferma dei rami supportati.
  • Valutare, come misura temporanea e non sostitutiva, la disattivazione di session.upload_progress.enabled nel php.ini (non è modificabile con ini_set(); serve riavviare PHP-FPM o il web server). Le analisi disponibili concordano che potrebbe bloccare solo uno dei due difetti: non va considerata una protezione completa.
  • Per i sistemi su rami fuori supporto: ridurre l'esposizione, ad esempio dietro VPN o con filtri di rete restrittivi, come suggerito dal CERT-EU, oppure chiedere alla distribuzione Linux un backport.
  • Eseguire un backup verificato dei sistemi esposti e aumentare il livello di log di web server e PHP-FPM.

Dopo il rilascio ufficiale:

  • Applicare la versione corretta, controllare le note ufficiali su versioni e CVE (che potrebbero differire dalle indiscrezioni) e verificare con php -v.
  • Cercare segni di compromissione: file PHP creati o modificati dopo il 20 ottobre, funzioni tipiche delle web shell (eval, base64_decode, system), processi di web server che avviano shell o strumenti di download, connessioni in uscita anomale, nuovi utenti amministratori nel CMS.
  • Ruotare le credenziali presenti su host di cui non si può dimostrare l'integrità.
  • Annotare nel registro interno data di conoscenza, azioni e tempi: serve come evidenza di diligenza.

Aggiorneremo questa analisi quando saranno disponibili l'avviso completo e i dettagli ufficiali sulle versioni.