PHP2Shell 2026: falle critiche PHP, rischi e come aggiornare i server

Se gestisci un sito, un gestionale web o un portale clienti sviluppato in PHP, le vulnerabilità CVE-2026-109618 e CVE-2026-109619 richiedono una valutazione immediata e un intervento prioritario sul runtime esposto. Il 21 ottobre 2026 il PHP Security Team ha pubblicato i rilasci correttivi 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le due falle sono critiche (CVSS v4.0: 9,2) e possono consentire, in specifiche condizioni, esecuzione di codice da remoto senza autenticazione; i ricercatori hanno inoltre dimostrato scenari di divulgazione della memoria dei processi PHP.

Il punto da chiarire subito è questo: non è una falla “di WordPress”. WordPress, Drupal, Joomla e molte applicazioni personalizzate usano PHP, ma in questo caso il difetto è nell’interprete/runtime PHP, il livello che esegue il codice applicativo. Aggiornare il CMS o installare un plugin di sicurezza non sostituisce l’aggiornamento del runtime.

Questa guida è pensata per CTO, responsabili IT, sviluppatori, system administrator e aziende che devono decidere che cosa verificare oggi, come distribuire le patch senza interrompere i servizi e quando attivare una risposta a un possibile incidente.

PHP non è WordPress: dove si trova davvero la vulnerabilità

PHP è un linguaggio di programmazione e il relativo runtime di esecuzione lato server. Quando un browser chiama una pagina dinamica, il server web e l’infrastruttura di esecuzione attivano PHP, che elabora codice, accede eventualmente al database, compone la risposta HTTP e la restituisce al client. WordPress è un’applicazione costruita in PHP, non un sinonimo di PHP.

In produzione possiamo avere più livelli indipendenti: CDN/WAF, reverse proxy (per esempio Nginx), web server (Apache, Nginx o LiteSpeed), interfaccia verso PHP (mod_php, PHP-FPM, php-cgi, LSAPI, FrankenPHP), runtime PHP e infine applicazione, estensioni e database. L’aggiornamento di uno strato non aggiorna automaticamente gli altri.

Da qui derivano tre conseguenze operative. Primo: un WordPress aggiornato può continuare a girare su un PHP vulnerabile. Secondo: un’applicazione proprietaria, anche se sviluppata con ottime pratiche, può essere esposta per colpa del runtime. Terzo: una stessa macchina può ospitare più istanze PHP e più versioni contemporaneamente; verificare soltanto quella mostrata da una sessione SSH non basta.

Le due falle PHP2Shell: analisi tecnica delle cause

I ricercatori e gli advisory del progetto PHP descrivono due classi di problemi nella gestione della memoria e dello stato tra richieste. La denominazione PHP2Shell è usata nel settore per riferirsi all’insieme di queste vulnerabilità. Non sono normali bug applicativi come SQL injection, XSS o upload arbitrario di file: interessano strutture interne del motore PHP.

CVE-2026-109618: corruzione durante le condizioni out-of-memory

PHP utilizza meccanismi di uscita non locale, fra cui longjmp(), per interrompere alcune elaborazioni in presenza di errori di memoria. Se l’errore si verifica quando alcune strutture della richiesta non sono ancora completamente inizializzate, la normale procedura di pulizia può ritrovarsi a interpretare come validi puntatori o campi che non lo sono. Il risultato può essere corruzione della memoria e, in catene di sfruttamento dimostrate, esecuzione arbitraria.

Un aspetto rilevante riguarda la gestione di input HTTP complessi, comprese richieste multipart/form-data. La dimensione effettiva delle strutture allocate internamente non coincide necessariamente con il peso del corpo HTTP sulla rete: intestazioni, annidamenti e metadati possono produrre un consumo di memoria più elevato di quanto un controllo superficiale lasci intendere.

Nel caso Apache con mod_php, l’advisory ufficiale evidenzia un rischio particolarmente alto perché la fase di shutdown può processare stato non valido anche quando l’inizializzazione della richiesta è fallita, prima dell’esecuzione del codice dell’applicazione. PHP-FPM ha differenze importanti nel comportamento all’errore: l’advisory PHP documenta una suscettibilità teorica per questa CVE dopo l’avvio della richiesta, precisando che, per CVE-2026-109618 su PHP-FPM, al momento della pubblicazione non è stata dimostrata una catena completa di sfruttamento. Questa distinzione non autorizza a rimandare l’aggiornamento: l’altra vulnerabilità è stata validata anche in uno specifico scenario PHP-FPM.

CVE-2026-109619: stato globale obsoleto e memoria già liberata

Un worker PHP può servire molte richieste nel tempo. Alcuni dati globali del runtime possono temporaneamente riferirsi a memoria che appartiene invece a una singola richiesta. Al termine della richiesta quei riferimenti devono essere azzerati prima che la memoria venga liberata. Se un errore fatale, un timeout o determinate operazioni diagnostiche interrompono la corretta sequenza di pulizia, può rimanere uno stale pointer: un riferimento a memoria non più valida.

Quando lo stesso worker gestisce una richiesta successiva, una fase di inizializzazione o elaborazione può utilizzare quello stato precedente. Si configura così un use-after-free, che può permettere accesso indebito alla memoria, corruzione e, a seconda della catena di sfruttamento, remote code execution. Le analisi pubbliche descrivono fra i percorsi tecnici coinvolti il monitoraggio degli upload di sessione, i backtrace degli errori fatali e componenti OPcache.

Esempio concettuale, non exploit: la richiesta A termina in modo anomalo e lascia un riferimento interno a una struttura appena liberata; il worker viene riutilizzato per la richiesta B; una routine di inizializzazione consulta il riferimento prima di reimpostarlo. Il problema non è la pagina visitata, ma il ciclo di vita della memoria nel processo PHP.

Che cosa rischia concretamente un’azienda

L’esecuzione remota di codice (RCE) può consentire a un attaccante non autenticato di eseguire istruzioni con i privilegi del processo PHP compromesso. L’impatto operativo dipende da privilegi, segmentazione, segreti accessibili, hardening e altri controlli. In termini realistici, i possibili effetti comprendono:

• accesso a file di configurazione e credenziali di database leggibili dal worker PHP;
• accesso a informazioni in memoria, sessioni, token e segreti applicativi presenti nel processo;
• modifica o inserimento di file dell’applicazione, inclusi possibili web shell, se i permessi lo consentono;
• alterazione di contenuti, interruzione dei servizi, manipolazione delle transazioni o uso improprio di API;
• movimenti verso altri sistemi solo se rete, identità e permessi lo rendono possibile.

Per un e-commerce il rischio non riguarda soltanto la home page: può toccare checkout, area amministrativa, integrazioni con ERP e CRM, feed e processi batch. Per un portale B2B possono essere coinvolti documenti riservati, informazioni clienti e credenziali d’integrazione. Una compromissione potenziale non equivale automaticamente a una violazione dei dati: l’accertamento richiede evidenze tecniche, log e analisi forense.

Quali sistemi mettere in cima alla coda

In una finestra di manutenzione limitata, la sequenza ragionevole parte dai servizi PHP raggiungibili da Internet, in particolare dagli stack con mod_php. Seguono PHP-FPM, altri SAPI esposti, ambienti containerizzati e applicazioni che accettano input non attendibile. Non dimenticare pannelli di controllo, appliance di terze parti, servizi secondari e ambienti pre-produzione raggiungibili pubblicamente.

Qual è la prima decisione da prendere? Tre scenari operativi

La procedura di remediation dipende dall’ownership del runtime. Chi controlla il codice dell’applicazione potrebbe non avere alcun potere sui pacchetti del server; viceversa, un team infrastrutturale può applicare la patch ma non conoscere tutte le dipendenze applicative. Questo è il motivo per cui la responsabilità deve essere assegnata per singolo servizio, e non in modo generico a “chi gestisce il sito”.

La regola di priorità: applicazioni pubbliche prima di ambienti interni isolati, processi con privilegi e segreti rilevanti prima di servizi a basso impatto, ma senza assumere che un WAF renda un sistema sicuro. La superficie di attacco si estende anche a pannelli, cron web, gateway API e software di terze parti che incorporano PHP.

Versioni PHP interessate e aggiornamenti disponibili

Alla data di questo approfondimento, il progetto PHP ha pubblicato le seguenti versioni correttive ufficiali. La tabella si riferisce ai rilasci upstream: i pacchetti Linux distribuiti da Ubuntu, Debian, Red Hat o da un fornitore di hosting possono contenere backport di sicurezza pur mostrando numeri di versione precedenti.

Attenzione a PHP 8.6: nel giorno dell’advisory era ancora in ciclo di release candidate; non va trattato come scorciatoia per un aggiornamento urgente in produzione. Per le installazioni aziendali bisogna utilizzare rilasci stabili e pacchetti che dichiarano la correzione delle specifiche CVE.

Perché il risultato di php -v non basta

Su Ubuntu 24.04, per esempio, Canonical ha pubblicato un proprio security notice con pacchetti della famiglia php8.3 che mantengono la numerazione di base della distribuzione. Questo è normale: il manutentore integra le correzioni senza necessariamente sostituire il runtime con l’ultimo tarball upstream. Un audit che segnala “PHP 8.3.6 = vulnerabile” senza consultare il changelog del pacchetto può produrre falsi positivi.

Al contrario, una shell che mostra PHP 8.5.12 non dimostra che il sito passi davvero da quella versione: il servizio web potrebbe usare un pool PHP-FPM 8.3, un contenitore diverso o un binario compilato localmente. Verifica processo in uso, pacchetto, provenance e configurazione reale.

Come verificare se il server usa PHP vulnerabile

Le verifiche seguenti sono diagnostiche e non intrusive. Esegui i comandi solo su sistemi che amministri o per i quali hai autorizzazione. Personalizzali in base alla distribuzione: non sono script universali da eseguire alla cieca.

1. Inventario del runtime CLI

php -v
php -i | grep -E '^(Server API|Loaded Configuration File|Scan this dir for additional .ini files)'
command -v php

Questi comandi identificano il binario della shell e alcune impostazioni di configurazione. Non certificano la versione servita via HTTP. Il valore Server API per la shell sarà di norma Command Line Interface.

2. Processi PHP effettivamente attivi

ps -eo pid,user,command | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp|[p]hp-cgi'
systemctl list-units --type=service | grep -E 'php.*fpm|apache2|httpd|lsws'

Per il server web verifica VirtualHost, direttive SetHandler e socket FPM configurati. Su Nginx controlla gli upstream fastcgi_pass. Più pool possono avere versioni o php.ini differenti.

3. Verifica dei pacchetti e delle correzioni del distributore

Debian/Ubuntu:

dpkg-query -W 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
apt changelog php8.3-fpm

Il nome php8.3-fpm è un esempio: sostituiscilo con quello installato. Confronta versione e changelog con l’advisory della tua distribuzione, ad esempio il notice Ubuntu USN-8948-1.

RHEL/AlmaLinux/Rocky/cPanel:

rpm -qa | grep -E 'php|ea-php' | sort
rpm -q --changelog php-fpm | grep -m 5 -E 'CVE-2026-109618|CVE-2026-109619'

Il nome del pacchetto varia. Su cPanel EasyApache i pacchetti possono essere chiamati ea-php83-php-cli, ea-php84-php-fpm e così via. L’advisory cPanel illustra il controllo del changelog per le due CVE.

4. Immagini Docker, Kubernetes e servizi gestiti

docker ps --format 'table {{.Names}}\t{{.Image}}'
docker exec NOME_CONTAINER php -v
kubectl get pods -A -o wide

Qui NOME_CONTAINER è un segnaposto. Nei cluster occorre controllare l’immagine realmente avviata (meglio ancora il digest), non soltanto il tag presente nel repository. La patch deve arrivare tramite rebuild dell’immagine e rollout dei pod, verificando che nessuna replica vulnerabile continui a ricevere traffico.

5. Verifica dopo il riavvio: chi risponde davvero alle richieste?

Il cambio di pacchetto installato e la sostituzione del processo in esecuzione sono due eventi diversi. Dopo l’aggiornamento, controlla che il servizio corretto sia ripartito, che i processi worker pre-patch non siano più in esecuzione e che il monitoraggio applicativo non mostri una regressione su 4xx/5xx, latenza e connessioni database. In un ambiente con bilanciamento, ripeti la verifica per ciascuna replica, non solo sul nodo raggiunto durante il test.

Come evidenza di change conserva release del pacchetto, riferimento al bollettino del vendor, orario del riavvio, versione HTTP e risultato dei test applicativi. In caso di managed hosting chiedi il dettaglio al provider invece di introdurre endpoint diagnostici pubblici.

6. CMS e pannelli hosting

In WordPress, la sezione Salute del sito può aiutare a identificare la versione PHP utilizzata da una specifica installazione, ma non sostituisce l’inventario dell’infrastruttura. Nei pannelli hosting verifica PHP per singolo dominio, pool FPM e policy del provider. Non pubblicare un file phpinfo() accessibile da Internet per effettuare questo controllo: esporrebbe configurazioni e dettagli non necessari.

Come aggiornare PHP: procedura tecnica senza improvvisare

Una patch di sicurezza non deve diventare un cambio di versione gestito come un clic casuale. In ambienti complessi è necessario separare la correzione urgente all’interno dello stesso ramo dall’eventuale migrazione di ramo (per esempio da PHP 8.1 a 8.4), che può richiedere test e adattamenti maggiori.

Hosting condiviso, managed hosting e pannelli

Apri un ticket al provider richiedendo conferma specifica di CVE-2026-109618 e CVE-2026-109619, versione runtime effettivamente servita, data di deployment del pacchetto e possibilità di cambio PHP per il dominio. Non accontentarti di una risposta generica come “il CMS è aggiornato”. Se il fornitore usa backport, chiedi il riferimento all’advisory o alla build corretta.

Ubuntu/Debian: pacchetti del vendor e riavvio del pool

Su sistemi amministrati, dopo snapshot/backup verificato e test nell’ambiente disponibile, utilizza i repository supportati dal sistema. I seguenti comandi sono esempi amministrativi e vanno validati contro l’inventario locale:

sudo apt update
sudo apt list --upgradable | grep -E 'php|apache'
sudo apt install --only-upgrade php8.3-fpm php8.3-cli
sudo systemctl restart php8.3-fpm
sudo systemctl is-active php8.3-fpm

Sostituisci 8.3 con la release effettivamente installata e includi i moduli correlati che il package manager propone. Se PHP è integrato come mod_php, il riavvio del servizio Apache può essere necessario; se il sito usa un altro FPM, il comando mostrato non riavvierà il worker corretto. Gli aggiornamenti di sicurezza della distribuzione devono essere verificati nel changelog, non soltanto nel numero stampato da PHP.

RHEL, AlmaLinux, Rocky Linux e cPanel

Per sistemi RPM, controlla i repository abilitati, gli stream modulari e i pacchetti runtime utilizzati dal web server. Esegui gli aggiornamenti con il package manager previsto dalla distribuzione e riavvia i servizi applicativi interessati. Per cPanel/WHM, il produttore ha pubblicato build e istruzioni dedicate per EasyApache; è opportuno seguire l’advisory ufficiale cPanel, non una procedura generica riciclata da un’altra piattaforma.

Docker/Kubernetes e pipeline CI/CD

Se utilizzi immagini applicative, la strategia è ricostruire da una base corretta e testata, congelare un digest noto, pubblicare in registry e distribuire progressivamente. Controlla le estensioni native, la compatibilità con Composer, i job CLI e cron e gli health check. In Kubernetes usa un rollout graduale con osservabilità su errori 5xx, latenze e riavvii, poi verifica che i vecchi pod siano terminati. Aggiornare PHP sull’host non corregge automaticamente PHP dentro i container.

Server Windows e stack particolari

Su Windows verifica l’eseguibile PHP effettivamente utilizzato dal web server, il build provider e i moduli compatibili. Il progetto PHP pubblica binari Windows per i rami corretti. In ambienti con IIS/FastCGI o altri gestori, pianifica la sostituzione del runtime, riavvio dei processi interessati e validazione delle applicazioni. FrankenPHP, LiteSpeed e altri stack richiedono il rispettivo pacchetto o artefatto aggiornato.

Controlli di compatibilità da eseguire prima e dopo

Prima del deployment valida backup ripristinabili, estensioni intl, mbstring, gd, imagick, redis, opcache, driver database, Composer e requisiti delle librerie. Poi testa login, reset password, form, sessioni, file upload, pagamenti, checkout, integrazioni API, webhooks, import/export, attività schedulate e messaggistica. Un semplice “la home page si apre” non è una verifica sufficiente.

Gestione del rollback: prepara il ripristino applicativo, ma non riportare una versione PHP vulnerabile su un endpoint Internet per risolvere un problema di compatibilità. Se non puoi mantenere la release corretta, isola temporaneamente il servizio e pianifica un ripristino controllato.

Se oggi non puoi aggiornare: mitigazioni temporanee e loro limiti

L’advisory ufficiale del progetto PHP è chiaro: nessuna delle misure seguenti è una correzione completa. Sono controlli provvisori, da valutare con un sistemista e con il responsabile della sicurezza, finché non viene distribuito un runtime corretto.

• Ridurre la superficie esposta. Limitare l’accesso ai servizi non pubblici via VPN, allowlist o segmentazione; se necessario sospendere temporaneamente gli endpoint vulnerabili.
• Gestire i percorsi OOM. L’advisory suggerisce, come mitigazione incompleta del percorso CVE-2026-109618, memory_limit=-1 imposto amministrativamente e non sovrascrivibile, associato a limiti conservativi per le richieste e a controlli di memoria tramite cgroup/container. Questa impostazione non è un hardening generale consigliabile senza analisi: elimina un limite applicativo e può aumentare il rischio di saturazione delle risorse se non si configurano limiti esterni appropriati.
• Ridurre gli input costosi. Valutare post_max_size, upload_max_filesize, numero di campi e limiti di dimensione e struttura dei multipart sul proxy. Qualsiasi modifica va confrontata con le esigenze dei caricamenti legittimi.
• Interrompere alcuni percorsi di stato globale. Impostare session.upload_progress.enabled=0 prima del parsing della richiesta e riavviare tutti i worker; su PHP 8.5 valutare fatal_error_backtraces=0. Questi switch coprono soltanto percorsi confermati, non l’intera classe di bug.
• WAF e CDN. Le regole di protezione possono intercettare alcuni tentativi ma non offrono una garanzia assoluta, soprattutto con problemi sfruttabili a livello di runtime. Evita di usarle come giustificazione per rimandare il patching.

Le direttive devono essere applicate nel punto corretto della catena di configurazione. Impostazioni inserite tardivamente tramite ini_set() o .user.ini non proteggono necessariamente le fasi iniziali coinvolte. Non confondere il riavvio di un singolo servizio con la sostituzione di ogni worker coinvolto.

Quattro errori di valutazione da evitare durante l’emergenza

1. «Il sito è aggiornato, quindi PHP è aggiornato». L’aggiornamento di WordPress, Laravel o del tema non modifica il binario PHP installato dal provider o incluso nell’immagine container.
2. «Il comando php -v è sufficiente». La versione della CLI può differire dal runtime HTTP. Occorre mappare VirtualHost, FastCGI socket, immagini e worker effettivamente in servizio.
3. «La versione riportata sembra vecchia, quindi la patch manca». Nei sistemi con supporto enterprise i fix possono essere distribuiti come backport. Serve il riferimento verificabile al pacchetto e al bollettino di sicurezza del maintainer.
4. «Abbiamo applicato l’update, quindi non serve controllare la sicurezza». Il patching interrompe un vettore noto ma non elimina eventuali persistenze, file malevoli o credenziali già sottratte. In presenza di indicatori, la risposta all’incidente è un processo distinto.

Inoltre, una prova di concetto pubblicata online non equivale di per sé a evidenza di sfruttamento massivo. Al 22 ottobre 2026 esistono dimostrazioni tecniche di sfruttabilità e avvisi istituzionali, ma la misurazione affidabile delle compromissioni in corso richiede fonti e telemetria aggiornate. L’incertezza sul numero di attacchi non riduce l’urgenza della correzione.

Come capire se il sistema potrebbe essere già stato compromesso

Aggiornare chiude la falla nota ma non dimostra che il server fosse integro. Se un servizio vulnerabile era esposto, la verifica dei log deve essere parallela al patching. Evita conclusioni affrettate: un picco di errori di memoria non è prova di sfruttamento, ma può essere un elemento di contesto.

Telemetria e segnali da correlare

• richieste HTTP anomale con multipart e volumi o strutture insolite, ove registrate dal proxy;
• errori PHP out-of-memory, crash/restart ripetuti, anomalie di pool e log di errori fatali;
• processi figli inattesi avviati da utenti del web server o da php-fpm;
• nuovi file eseguibili o modifiche non previste nelle directory dell’applicazione;
• cron job, servizi, utenti o chiavi di accesso aggiunti senza change ticket;
• connessioni in uscita insolite e accessi a segreti o storage non coerenti con l’applicazione.

Un SIEM/EDR con visibilità sul processo permette correlazioni più affidabili dei soli access log. Se emergono indicatori concreti, attiva il processo di incident response: acquisisci le evidenze, preserva log e timestamp, isola l’host quando necessario, valuta la rotazione dei segreti e determina l’effettivo perimetro di esposizione. Non eseguire script di exploit pubblici in produzione per “verificare” la vulnerabilità: il controllo di versione e le attestazioni del vendor sono il metodo iniziale corretto.

In caso di sospetto accesso indebito ai dati personali, il coinvolgimento del responsabile privacy e la valutazione degli eventuali adempimenti previsti dalla normativa devono seguire l’accertamento dell’incidente. Non ogni tentativo di attacco implica automaticamente un data breach.

Checklist: piano di intervento tecnico per le prime 24 ore

È utile assegnare un responsabile per ogni asset: la domanda non è soltanto “abbiamo aggiornato il server?”, ma “quali istanze PHP stanno ancora rispondendo a traffico reale, con quale binario e con quale evidenza di correzione?”.

Azienda e non sai cosa fare? Supporto ingegneristico e sistemistico

Un aggiornamento PHP può essere banale su un piccolo sito gestito, ma diventare un intervento delicato quando entrano in gioco server dedicati, cluster, e-commerce, sistemi legacy, flussi finanziari o integrazioni aziendali. Il rischio, in questi casi, non è soltanto rimandare la patch: è applicarla senza un inventario e provocare indisponibilità evitabili, oppure credere di aver corretto sistemi che utilizzano un runtime differente.

YourDigitalWeb può affiancare la tua azienda nella raccolta delle informazioni tecniche, nell’analisi della superficie esposta, nella definizione di un piano di aggiornamento e nella verifica delle applicazioni dopo l’intervento, coordinando le competenze di sviluppo, infrastruttura, sicurezza e sistemistica richieste dal caso. Se gestisci asset complessi o sospetti una compromissione, descrivi architettura, ambiente, provider e vincoli di disponibilità: servono per individuare il percorso corretto.

Contattaci per un confronto tecnico: richiedi supporto per la messa in sicurezza dei server PHP, scrivi a info@yourdigitalweb.com oppure chiama +39 02 82955180. Per motivi di sicurezza, non inviare password, chiavi private o dump di database tramite moduli o email non protette.

FAQ tecniche: le domande che un responsabile IT dovrebbe fare

Si tratta di una falla di PHP, WordPress, WooCommerce o del server?

Il difetto risiede nel runtime PHP scritto in C e utilizzato dalle applicazioni web. WordPress e WooCommerce possono essere esposti se eseguiti su un runtime vulnerabile; il sistema operativo e il provider determinano come ricevere il pacchetto corretto. Non esiste una patch di WordPress che sostituisca la patch dell’interprete.

Se WordPress e tutti i plugin sono aggiornati, il problema è risolto?

No. Queste CVE riguardano il runtime PHP. Occorre correggere PHP nell’ambiente che gestisce le richieste del sito, poi continuare a mantenere aggiornati anche CMS e plugin perché introducono rischi separati.

Un server Nginx con PHP-FPM è immune?

No. Il rischio e i percorsi di sfruttamento non sono identici a quelli di Apache con mod_php, ma PHP-FPM è esplicitamente incluso nei sistemi a rischio secondo PHP. Va aggiornato.

È sufficiente controllare la versione PHP dal terminale?

No. Il binario CLI può essere diverso da quello utilizzato via HTTP. Bisogna verificare il pool, il socket, il container e la build del pacchetto in servizio.

Se la versione è 8.3.6, devo passare direttamente a 8.5?

Non necessariamente. La scelta dipende dal canale di distribuzione: se un vendor supportato ha backportato entrambe le patch e ne documenta la presenza, la build potrebbe essere corretta. In caso contrario occorre aggiornare a una release sicura e supportata, con test di compatibilità. Non dedurre lo stato delle CVE soltanto dal numero.

Disabilitare session.upload_progress elimina il rischio?

No. È una mitigazione parziale per alcuni percorsi di CVE-2026-109619 e richiede il riavvio dei worker. Non corregge tutte le varianti e non sostituisce la patch.

Il WAF o Cloudflare possono bloccare l’attacco?

Un WAF può ridurre l’esposizione ad alcune richieste, ma non c’è garanzia di copertura completa. La raccomandazione del PHP Security Team è aggiornare il runtime. Le protezioni perimetrali sono complementari.

Devo considerare compromesso ogni sito vulnerabile?

No. Vulnerabilità ed effettiva compromissione sono due stati diversi. Vanno correlati indicatori tecnici, esposizione e telemetria. In presenza di sospetti concreti serve un’indagine strutturata.

Posso aggiornare direttamente dalla dashboard WordPress?

In genere no: la dashboard WordPress aggiorna il CMS, i temi e i plugin, ma il runtime PHP è amministrato tramite hosting, sistema operativo, stack container o pannello server.

Fonti tecniche e note metodologiche

Questo approfondimento è redatto sulla base degli advisory e dei materiali pubblici consultati il 22 ottobre 2026. Poiché indicazioni e coperture dei pacchetti possono evolvere, prima di eseguire interventi su sistemi di produzione è necessario consultare le note del produttore e del fornitore effettivamente utilizzato.

1. PHP.net — Security advisory e rilasci correttivi del 21 ottobre 2026.
2. PHP Security Advisory — CVE-2026-109618 (out-of-memory corruption).
3. PHP Security Advisory — CVE-2026-109619 (stale global state).
4. PHP.net — Supported Versions.
5. CERT-AGID — Allerta nazionale, versioni e raccomandazioni.
6. ENISA e istituzioni europee — Joint statement.
7. Wiz Research — Analisi tecnica e scenari dimostrati.
8. Ubuntu — USN-8948-1, correzioni nei pacchetti distribuiti.
9. NCSC-NL — Informazioni operative PHP2Shell.
10. Canadian Centre for Cyber Security — AL26-026 e raccomandazioni sui backport.
11. NHS England — Alert CC-4875 e modalità di correzione.