PHP security update corregge due vulnerabilità RCE sfruttate attivamente
Un PHP security update risolve due vulnerabilità critiche che potrebbero consentire a un aggressore non autenticato di eseguire codice su un web server. remote code execution (RCE) significa che un aggressore può far eseguire comandi al sistema interessato senza prima autenticarsi. Le vulnerabilità, CVE-2026-109618 e CVE-2026-109619, hanno entrambe un punteggio CVSS v4.0 di 9,2 e Sucuri ha riferito il 21 ottobre 2026 che erano già stati osservati tentativi di sfruttamento.
PHP ha pubblicato quattro versioni corrette: PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 e PHP 8.2.35. Gli amministratori che gestiscono un server o un virtual private server proprio devono installare la release appropriata tramite il sistema operativo, il fornitore dei pacchetti, il control panel o il processo di deployment consolidato. I clienti di hosting condiviso o gestito devono verificare che il proprio fornitore abbia installato una build PHP corretta o un pacchetto contenente un backport esplicito delle correzioni da parte del vendor.
Si tratta di vulnerabilità nel PHP runtime, il software del server che esegue le applicazioni PHP, e non in WordPress, in un altro content management system, in un plugin o in un theme. L'aggiornamento del core di WordPress e delle sue estensioni, quindi, non elimina il comportamento vulnerabile del server. Secondo l'advisory, ogni installazione PHP che gestisce richieste web deve essere considerata potenzialmente esposta, incluse PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. PHP considera mod_php la configurazione a più alto rischio, perché un exploit dimostrato può essere attivato da una richiesta non autenticata prima che inizi l'esecuzione del codice applicativo del sito web.
CVE-2026-109618 riguarda una out-of-memory condition, che si verifica quando un processo non riesce a ottenere la memoria di cui ha bisogno. PHP può essere interrotto mentre i dati interni della richiesta sono inizializzati solo parzialmente. Durante il cleanup, potrebbe scambiare questi dati incompleti per informazioni valide, corrompere la memoria e potenzialmente consentire remote code execution.
CVE-2026-109619 coinvolge uno stale internal state. Un PHP worker, ossia un processo che gestisce le richieste del sito web, può conservare un riferimento ai dati di una richiesta dopo che la memoria sottostante è stata rilasciata. Una richiesta successiva elaborata dallo stesso PHP worker può raggiungere le informazioni obsolete prima che PHP le reimposti. Il risultato potrebbe essere la divulgazione di informazioni o remote code execution.
Il proof-of-concept code pubblico, che dimostra come sia possibile attivare una vulnerabilità, ha iniziato a circolare prima della pubblicazione delle correzioni ufficiali. Hadrian ha dichiarato di osservare lo sfruttamento di PHP2Shell su vasta scala e ha riferito che gran parte dell'attività rilevata abusava del percorso session upload progress di PHP. Ha inoltre avvertito che probabilmente sarebbero emersi ulteriori percorsi di sfruttamento. WatchTowr, Patchstack, Cloudflare e Vega hanno segnalato separatamente attività dannose o tentativi collegati alle vulnerabilità. Un tentativo di exploit non dimostra di per sé che un server sia stato compromesso con successo, ma il codice pubblico e il volume dell'attività rendono importante applicare tempestivamente le patch.
Dopo aver installato il PHP security update, gli amministratori devono riavviare o ricaricare i processi PHP worker e tutti i servizi correlati, in modo che i processi in esecuzione utilizzino la nuova build. Devono quindi verificare la versione che sta effettivamente servendo il sito web online. La versione mostrata dal comando php -v può essere diversa da quella utilizzata dal web server. I test devono includere accessi, checkout, moduli, caricamenti di file, attività pianificate, application programming interface (API) e pagine amministrative.
I siti che utilizzano PHP 8.1 o versioni precedenti richiedono particolare attenzione. Questi branch non rientrano più nel normale ciclo di supporto di PHP e non riceveranno le point release upstream standard. Data la gravità di queste vulnerabilità, PHP ha pubblicato backport di emergenza del codice sorgente per PHP 7.4, PHP 8.0 e PHP 8.1, mentre le distribuzioni Linux e i vendor di long-term support possono fornire propri pacchetti corretti. Il numero di versione visualizzato non è sufficiente per stabilire se un'installazione meno recente sia sicura, perché i vendor possono applicare una correzione di sicurezza senza modificare il numero del branch. Gli amministratori devono verificare che il pacchetto installato risolva specificamente entrambi gli identificatori CVE. Questi backport di emergenza non ripristinano il supporto a lungo termine, quindi il passaggio a un branch PHP supportato rimane la scelta più sicura nel lungo periodo.
Sucuri ha dichiarato che il proprio web application firewall (WAF), un livello di filtraggio che esamina le richieste prima che raggiungano un sito web, stava già bloccando alcuni pattern dannosi associati alle vulnerabilità. Ha aggiunto regole di virtual patching più mirate per i percorsi PHP2Shell noti. Questi filtri possono ridurre l'esposizione durante il deployment di un aggiornamento, ma non correggono PHP e possono bloccare soltanto le richieste che riconoscono. PHP afferma che l'installazione di una build corretta è l'unica soluzione completa.
Il filtraggio del firewall dipende inoltre dal passaggio del traffico attraverso di esso. Se un aggressore riesce a connettersi direttamente all'origin server, il computer che ospita effettivamente il sito, le regole di filtraggio possono essere aggirate. Gli amministratori che utilizzano il WAF di Sucuri devono limitare l'accesso diretto tramite IPv4 e IPv6, accettare il traffico web soltanto dagli indirizzi Sucuri Firewall approvati e rimuovere i vecchi record DNS o gli hostname alternativi che rivelano l'origin. Anche gli ambienti di staging, sviluppo, test e backup devono essere protetti o sottoposti a restrizioni di accesso. I team devono verificare che i sottodomini non protetti e le porte alternative non espongano la stessa applicazione e che vecchi container, immagini server o template di autoscaling non continuino a distribuire build PHP vulnerabili.
Se non è possibile applicare immediatamente le patch, disabilitare session upload progress a livello di server con `session.upload_progress.enabled = Off` può ridurre l'esposizione ai percorsi confermati relativi alle sessioni per CVE-2026-109619. L'impostazione deve essere applicata tramite php.ini, un pool FPM o un'altra configurazione caricata prima del parsing della richiesta, seguita dal riavvio di ogni PHP worker interessato. Si tratta soltanto di una misura temporanea: non copre tutti i percorsi verso CVE-2026-109619, non offre alcuna protezione contro CVE-2026-109618 e può influire sulle applicazioni che mostrano l'avanzamento dei caricamenti PHP. PHP ha inoltre fornito indicazioni temporanee per il percorso out-of-memory nel proprio advisory completo, ma nessun workaround rende sicura un'installazione priva di patch.
Gli amministratori devono cercare file PHP sconosciuti, attività pianificate impreviste, account amministratore non riconosciuti, connessioni in uscita sospette e richieste insolite relative ai caricamenti. Per i proprietari di siti WordPress che preferiscono affidarsi a una gestione specialistica anziché occuparsi di tutto autonomamente, AEU Hosting offre un hosting WordPress gestito e protetto end to end; indipendentemente dal fornitore, i proprietari devono comunque verificare che la build PHP online contenga entrambe le correzioni. Le priorità immediate sono installare una release corretta o un backport confermato, riavviare PHP, verificare la versione web effettivamente in uso e assicurarsi che nessun firewall possa essere aggirato tramite accesso diretto all'origin.