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.
In sintesi: inventaria tutti i runtime PHP effettivamente usati dalle richieste web; verifica le patch del tuo fornitore; aggiorna prima i servizi pubblici; riavvia correttamente i worker; testa i flussi critici; controlla log e indicatori di compromissione. Le mitigazioni di configurazione descritte più avanti non equivalgono alla patch.
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.
Schema logico semplificato
Client HTTP → CDN/WAF → Web server o proxy → runtime PHP → CMS / applicazione → database e servizi
Le vulnerabilità analizzate sono nel livello evidenziato. Il loro sfruttamento può avvenire in alcuni scenari prima che il normale codice del CMS venga eseguito.
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.
Un dato da non fraintendere: gli studi pubblicati dimostrano scenari di RCE su configurazioni rappresentative e divulgazione della memoria; ciò non significa che ogni sito sia già compromesso, né che tutti i percorsi tecnici siano sfruttabili allo stesso modo in ogni installazione. La priorità di patch rimane comunque elevatissima.
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”.
| Scenario | Primo responsabile | Verifica da richiedere |
|---|---|---|
| Hosting condiviso / WordPress gestito | Hosting provider | Conferma scritta delle due CVE corrette, versione effettiva del runtime HTTP, eventuale backport |
| VPS / server bare metal | System administrator / DevOps | Package release del vendor, processo attivo, riavvio worker, test dei virtual host |
| Docker / Kubernetes / PaaS | Platform team + owner applicativo | Digest della nuova immagine, rebuild, rollout completato e assenza di repliche con vecchio PHP |
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.
| Ramo | Versioni upstream da correggere | Release corretta | Nota |
|---|---|---|---|
| PHP 8.5 | Precedenti a 8.5.12 | 8.5.12 | Preferire il rilascio stabile corretto |
| PHP 8.4 | Precedenti a 8.4.27 | 8.4.27 | Branch supportato |
| PHP 8.3 | Precedenti a 8.3.36 | 8.3.36 | Branch supportato |
| PHP 8.2 | Precedenti a 8.2.35 | 8.2.35 | Fine supporto upstream: 31 dicembre 2026 |
| PHP 8.1 e precedenti | Fuori supporto del progetto PHP | Migrazione o patch LTS/backport verificato | Controllare advisory e contratto del vendor |
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 phpQuesti 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-fpmIl 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 wideQui 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:
