Urgente un security update di PHP mentre si diffondono i tentativi di exploit
È urgentemente necessario un security update di PHP per due vulnerabilità critiche che possono consentire a un aggressore non autenticato, cioè qualcuno che non ha effettuato l’accesso, di eseguire codice su un web server interessato. Le falle, CVE-2026-109618 e CVE-2026-109619, hanno entrambe un punteggio CVSS v4.0 pari a 9,2. CVSS è una scala standard per valutare la gravità delle vulnerabilità. È disponibile materiale pubblico per l’exploit e diverse aziende di sicurezza hanno segnalato tentativi di sfruttamento.
PHP, il software server-side utilizzato per generare molti siti web e applicazioni web, ha rilasciato versioni corrette per quattro branch supportati: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Gli amministratori di server propri o virtual private server (VPS), ossia server ospitati da remoto e assegnati a un singolo cliente, devono installare immediatamente la release appropriata. I clienti che utilizzano hosting condiviso o gestito devono verificare che il proprio provider abbia distribuito una release corretta o un package esplicitamente patchato.
Entrambe le vulnerabilità riguardano il modo in cui PHP gestisce i dati interni delle request, cioè le informazioni ricevute quando un browser o un altro sistema contatta un sito web. Sono falle nel runtime PHP, il software sottostante che esegue il codice PHP, e non in WordPress, in un altro content management system, in un plugin, in un tema o in una singola applicazione. Aggiornare questi componenti resta una buona pratica di sicurezza, ma non correggerà queste due falle di PHP.
CVE-2026-109618 può verificarsi quando PHP esaurisce la memoria mentre i dati della request sono stati preparati solo in parte. Durante la pulizia, PHP può trattare come validi i dati incompleti. Ciò può causare memory corruption, situazione in cui le informazioni conservate temporaneamente da un programma vengono danneggiate o gestite in modo errato, e può infine consentire remote code execution. remote code execution, spesso abbreviato in RCE, significa che un aggressore può fare in modo che il server esegua comandi da un’altra posizione.
CVE-2026-109619 riguarda lo stale internal state, ossia uno stato interno non più valido. Un PHP worker, un processo in esecuzione che gestisce le request web, può conservare un riferimento ai dati di una request dopo che la memoria sottostante è stata rilasciata. Una request successiva elaborata dallo stesso PHP worker può raggiungere le vecchie informazioni prima che PHP le reimposti. Il risultato può essere information disclosure o remote code execution.
L’advisory di Sucuri afferma che ogni installazione PHP che gestisce request web deve essere considerata potenzialmente esposta. Ciò include PHP-FPM, o FastCGI Process Manager, che gestisce pool di PHP worker, oltre ad Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. PHP considera mod_php la configurazione a rischio più elevato perché una request non autenticata può attivare un exploit dimostrato prima che inizi l’esecuzione dell’application code del sito.
Il proof-of-concept code, che dimostra come una vulnerabilità possa essere sfruttata, è circolato prima delle correzioni ufficiali. Hadrian ha riferito di aver osservato lo sfruttamento di PHP2Shell su larga scala e ha dichiarato che la maggior parte delle attività rilevate utilizzava il path session upload progress di PHP. Ha inoltre avvertito che probabilmente sarebbero emerse ulteriori route. WatchTowr, Patchstack, Cloudflare e Vega hanno segnalato separatamente attività o tentativi malevoli collegati alle vulnerabilità. Un tentativo di exploit non dimostra di per sé che un server sia stato compromesso, ma il codice pubblico e il volume delle attività segnalate rendono ancora più urgente il patching.
Dopo aver installato PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 tramite il sistema operativo, il pannello di controllo dell’hosting, il package provider o il processo di deployment consolidato, gli amministratori devono eseguire il restart o il reload dei PHP worker e dei servizi pertinenti. Devono quindi verificare la versione che serve effettivamente il sito web in produzione. La versione restituita dal comando da command line php -v può essere diversa da quella collegata al web server. Dopo la modifica devono essere verificati accessi, flussi di checkout, moduli, upload, attività pianificate, application programming interfaces (APIs) e pagine di amministrazione.
I clienti di hosting condiviso possono cercare un selettore della versione PHP nel proprio pannello di controllo. Se non compare alcuna versione corretta, devono chiedere al provider se ha installato un vendor-backported fix, cioè se la correzione di sicurezza è stata aggiunta a un branch software precedente, oppure quando sarà disponibile una release corretta. Il solo numero di versione visualizzato non è sufficiente, perché i fornitori di sistemi operativi e long-term support talvolta aggiungono correzioni di sicurezza senza modificare il numero del branch.
PHP 8.1 e le release precedenti non rientrano più nel normale ciclo di supporto del progetto e non riceveranno le normali upstream point release. Tuttavia, a causa della gravità di queste falle, PHP ha pubblicato emergency source backports per PHP 7.4, PHP 8.0 e PHP 8.1. Anche le distribuzioni Linux e i fornitori di long-term support possono offrire package patchati. Gli operatori devono eseguire l’upgrade a un branch supportato, installare un package che risolva esplicitamente sia CVE-2026-109618 sia CVE-2026-109619 oppure applicare il relativo emergency source backport. Queste correzioni di emergenza non ripristinano il supporto a lungo termine, quindi la migrazione a un branch PHP supportato rimane la scelta più sicura nel lungo periodo.
Sucuri dichiara che le sue regole web application firewall (WAF) esistenti respingevano già alcuni pattern di request malevole associati alle falle e che sono state aggiunte regole di virtual patching più specifiche per i path PHP2Shell noti. Un WAF è un servizio di filtraggio posizionato davanti a un sito web per ispezionare le request in arrivo. virtual patching significa bloccare il traffico di exploit riconosciuto prima che raggiunga il software vulnerabile, ma non elimina il difetto e non può sostituire il security update di PHP.
Il filtraggio del firewall non funziona inoltre se un aggressore può contattare l’origin server, la macchina che ospita effettivamente il sito web, senza passare attraverso il servizio di filtraggio. Gli operatori devono limitare l’accesso diretto tramite IPv4 e IPv6, consentire il traffico web solo dagli indirizzi firewall approvati e verificare che vecchi DNS record o hostname alternativi non espongano l’origin server. Gli ambienti di staging, development, test e backup devono essere protetti o avere accesso limitato, mentre subdomain non protetti e port alternative non devono offrire un’altra route verso la stessa applicazione. Devono essere controllati anche vecchi container, server image e autoscaling template, affinché non continuino a distribuire build PHP vulnerabili.
Se il patching immediato è impossibile, PHP afferma che l’aggiornamento resta l’unica soluzione completa. Poiché gran parte delle attività osservate ha preso di mira session upload progress, gli amministratori possono impostare temporaneamente session.upload_progress.enabled = Off in php.ini, in un FPM pool o in un’altra configurazione a livello di server applicata prima del request parsing, quindi riavviare ogni PHP worker interessato. Questa misura blocca soltanto le route confermate legate alle sessioni per CVE-2026-109619. Non copre tutti i path relativi a questa falla, non ha alcun effetto contro CVE-2026-109618 e può influire sulle applicazioni che mostrano l’avanzamento degli upload PHP. PHP fornisce ulteriori indicazioni temporanee per la route out-of-memory, ma tutte queste misure devono essere considerate soluzioni provvisorie di breve durata.