Aggiornamento. Questo articolo fa seguito a PHP, release di emergenza oggi alle 14:00 UTC per due falle critiche, pubblicato quando i dettagli erano ancora sconosciuti. Ora la patch è uscita, l'exploit esiste e c'è un primo indizio di attività malevola precedente alla divulgazione.

Cosa è successo

Il 21 ottobre 2026 il team PHP ha rilasciato le versioni di sicurezza 8.5.12, 8.4.27, 8.3.36 e 8.2.35, che correggono due vulnerabilità di esecuzione di codice remoto soprannominate PHP2Shell: CVE-2026-109618 e CVE-2026-109619. Per i rami non più supportati upstream (7.4, 8.0 e 8.1) sono stati pubblicati solo backport minimi in forma di sorgenti, pensati per chi compila PHP in proprio o non ha un fornitore con supporto esteso.

Le due falle hanno natura diversa, ma lo stesso esito:

  • CVE-2026-109618 nasce da una condizione di memoria esaurita (OOM). Se PHP viene interrotto mentre i dati interni di una richiesta sono inizializzati solo in parte, la fase di pulizia della richiesta può trattare quei dati incompleti come validi, aprendo la strada alla corruzione della memoria. Il team PHP ha confermato un'esecuzione di codice completa su mod_php con i limiti predefiniti; PHP-FPM è considerato vulnerabile, ma al momento non è stato mostrato un exploit completo.
  • CVE-2026-109619 deriva da uno stato globale "stantio": dati interni appartenenti a una richiesta sopravvivono alla liberazione della memoria e una richiesta successiva sullo stesso worker può usarli prima della normale inizializzazione. L'esecuzione di codice è stata confermata tramite il meccanismo di session upload progress sia su mod_php sia su PHP-FPM; nel caso di PHP-FPM serve che l'applicazione esponga un'operazione che l'attaccante riesce a far fallire.

Secondo Help Net Security un singolo attacco non autenticato può colpire prima ancora che il codice dell'applicazione venga eseguito. Amazon Threat Intelligence riferisce che la sua rete di honeypot MadPot ha registrato un tentativo di sfruttamento il 17 ottobre, quattro giorni prima della divulgazione pubblica, da un indirizzo riconducibile a un servizio commerciale di anonimizzazione. Non è noto come l'attore abbia ottenuto i dettagli in anticipo. Va quindi tenuto distinto ciò che è dimostrato (il codice remoto funziona, c'è un tentativo anomalo registrato) da ciò che non lo è (non risultano compromissioni di massa confermate, e AlmaLinux nel proprio avviso non cita sfruttamento osservato).

Cosa significa per le aziende italiane

PHP è sotto una quota enorme del web italiano: WordPress, Joomla, Magento e PrestaShop, ma anche i gestionali web sviluppati su misura da software house locali, spesso installati anni fa su server che nessuno aggiorna con regolarità. Il rischio concreto è di tre tipi.

Primo: il problema della filiera dell'hosting. Molte PMI non gestiscono PHP direttamente: lo fa l'hosting condiviso, l'agenzia web o il pannello di controllo. L'avviso di AlmaLinux è esplicito: i pacchetti della distribuzione coprono solo il PHP della distribuzione, mentre PHP fornito da pannelli di controllo o hosting richiede la correzione del rispettivo fornitore. La domanda utile per un'azienda non è "abbiamo aggiornato?", ma "chi aggiorna per noi, e quando ce lo conferma per iscritto?".

Secondo: i rami fuori supporto. Su AlmaLinux 8 il flusso predefinito è php:7.2 e alcune versioni (7.2, 7.3, 8.0 su AlmaLinux 8; 8.1 su AlmaLinux 9) non rientrano nel primo giro di patch perché hanno superato il ciclo di vita RHEL. È lo scenario tipico di un gestionale "che funziona e quindi non si tocca": proprio i sistemi più esposti sono quelli per cui la correzione richiede una migrazione, non un semplice aggiornamento.

Terzo: la dimensione normativa. Per i soggetti NIS2 (essenziali e importanti) una vulnerabilità critica a sfruttamento non autenticato su sistemi esposti rientra nella gestione delle vulnerabilità e nella sicurezza della catena di fornitura previste dalle misure di base, con la prima scadenza operativa fissata dall'ACN al 31 ottobre 2026. Se un sito o un portale compromesso comporta una violazione di dati personali, scatta inoltre l'obbligo GDPR di notifica al Garante entro 72 ore dalla conoscenza dell'evento. Un attacco senza autenticazione e senza interazione dell'utente riduce al minimo il tempo utile per accorgersene: la notifica va preparata sapendo che l'evidenza potrebbe non essere nei log applicativi.

Un ultimo punto di ragionamento: la finestra di esposizione non coincide con la data della patch. L'indizio di Amazon suggerisce che qualcuno disponesse dei dettagli almeno dal 17 ottobre. Chi ha server esposti dovrebbe quindi non solo aggiornare, ma anche verificare retroattivamente se ci sono segnali anomali dal 17 ottobre in poi.

Cosa fare subito

  • Identificare tutte le istanze PHP: server propri, container, hosting condiviso, pannelli di controllo, appliance di terze parti. Verificare la versione effettiva con php -v (e php-fpm -v) e non quella dichiarata dal fornitore.
  • Aggiornare a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure installare i pacchetti corretti della propria distribuzione non appena disponibili (AlmaLinux li ha annunciati prima nel repository di test). Chi usa il repository Remi deve sapere che, al momento della pubblicazione dell'analisi di Help Net Security, non c'erano ancora aggiornamenti: conviene passare ai pacchetti di distribuzione o compilare dai sorgenti.
  • Riavviare i worker dopo l'aggiornamento (systemctl restart php-fpm oppure httpd con mod_php), altrimenti i processi vecchi restano attivi.
  • Mitigazioni temporanee per CVE-2026-109619: disattivare session upload progress nel php.ini, in un file in /etc/php.d/ o nel pool PHP-FPM (non con ini_set() né .user.ini).
  • Mitigazioni temporanee per CVE-2026-109618: ridurre post_max_size (8M, o 32M se servono upload), tenere upload_max_filesize più basso, applicare limiti di dimensione delle richieste al proxy e usare limiti di memoria a livello di container o cgroup invece di RLIMIT_AS.
  • Valutare un WAF: Cloudflare ha attivato regole iniziali per tutti i piani, anche gratuiti. È una misura ponte, non sostituisce la patch.
  • Sistemi non correggibili subito: il consiglio dell'NCSC britannico è metterli offline. Se non è possibile, isolarli dietro un reverse proxy con filtri restrittivi.
  • Cercare segnali di compromissione dal 17 ottobre: processi figli anomali del web server, file nuovi in directory scrivibili, richieste insolite con corpi molto grandi o forzatura di errori di memoria.
  • Documentare tutto (data di patch, fornitore, verifiche): serve come evidenza per NIS2 e per il registro delle violazioni GDPR.