PHP2Shell, rilasciate le patch PHP contro due RCE senza autenticazione

🛡️ Executive Summary

• Il team PHP pubblica quattro aggiornamenti di emergenza per due vulnerabilità RCE senza autenticazione, entrambe classificate CVSS 4.0 9,2.
• CVE-2026-109618 sfrutta la gestione degli errori di memoria; CVE-2026-109619 può riutilizzare riferimenti a memoria già liberata tra richieste successive.
• Le configurazioni temporanee e le regole WAF non eliminano le vulnerabilità. Le patch devono essere applicate al runtime PHP, indipendentemente dagli aggiornamenti di WordPress o degli altri CMS.

PHP ha rilasciato quattro aggiornamenti di emergenza per correggere due vulnerabilità critiche che consentono l’esecuzione remota di codice senza autenticazione sui server web. Le falle CVE-2026-109618 e CVE-2026-109619, conosciute collettivamente come PHP2Shell, hanno entrambe un punteggio CVSS 4.0 di 9,2 e interessano il runtime che esegue applicazioni web, CMS e servizi aziendali. Le correzioni sono disponibili dal 21 ottobre 2026 nelle versioni PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. La pubblicazione chiarisce finalmente i meccanismi tecnici delle due vulnerabilità e modifica il quadro operativo rispetto all’allerta diffusa nelle ore precedenti: non bisogna più prepararsi all’arrivo delle patch, ma installarle immediatamente e verificare che siano effettivamente utilizzate dai servizi esposti a Internet.

PHP2Shell, quali versioni aggiornare dopo il rilascio delle patch

Il team di sicurezza PHP ha pubblicato gli aggiornamenti straordinari il 21 ottobre alle 14:00 UTC, corrispondenti alle 16:00 italiane, anticipando la normale pianificazione dopo la circolazione di informazioni riservate sulle vulnerabilità. Le quattro versioni corrette riguardano i rami ufficialmente supportati: 8.5.12 per PHP 8.5, 8.4.27 per PHP 8.4, 8.3.36 per PHP 8.3 e 8.2.35 per PHP 8.2. Il bollettino originale di sicurezza pubblicato dal progetto PHP identifica entrambe le falle come possibilità di esecuzione remota di codice e segnala un rischio particolarmente elevato per le installazioni Apache mod_php, dove è stato dimostrato un percorso di sfruttamento capace di intervenire prima dell’esecuzione del codice dell’applicazione. Anche PHP-FPM, php-cgi, FrankenPHP e LiteSpeed devono essere considerati nell’inventario, sebbene le condizioni tecniche e il grado di dimostrazione degli exploit non siano identici. Gli sviluppatori hanno inoltre distribuito backport sorgente minimi per PHP 7.4, 8.0 e 8.1, destinati soprattutto ai fornitori che mantengono ambienti legacy; queste versioni rimangono fuori dal supporto ordinario del progetto. Il rilascio rappresenta il passaggio decisivo rispetto alla precedente allerta PHP2Shell che annunciava due vulnerabilità critiche senza informazioni sulle versioni corrette. La disponibilità delle patch non garantisce automaticamente che siano già state integrate negli hosting, nei container e nei repository delle distribuzioni Linux.

Leggi anche: Vulnerabilità critica in PHP: rischio esecuzione codice remoto

CVE-2026-109618: un errore di memoria può eseguire codice prima dell’applicazione

La prima vulnerabilità, CVE-2026-109618, riguarda il comportamento dell’interprete PHP quando si verifica un errore di allocazione della memoria, identificato come Out of Memory (OOM). In alcune condizioni il runtime interrompe l’elaborazione di una richiesta attraverso longjmp(), lasciando strutture interne non completamente inizializzate che possono essere successivamente interpretate come valide durante la chiusura della richiesta. Il security advisory GHSA-w8hw-w9fx-j79w pubblicato dal team PHP descrive diversi percorsi che possono provocare l’esaurimento controllato della memoria, compresa l’elaborazione delle richieste HTTP multipart. Apache mod_php rappresenta lo scenario più grave documentato, perché il comportamento vulnerabile può verificarsi durante l’inizializzazione della richiesta, prima che WordPress, Laravel o un’altra applicazione eseguano il proprio codice. La correzione modifica la gestione degli errori OOM, evitando che l’interruzione immediata lasci memoria interna in condizioni incoerenti. Per PHP-FPM l’analisi del codice indica una superficie potenzialmente vulnerabile, ma l’advisory precisa che non è stato dimostrato un exploit completo equivalente a quello di mod_php. La vulnerabilità appartiene al motore PHP e non dipende necessariamente da un plugin, da un tema o da un errore nello sviluppo del sito. È una differenza sostanziale rispetto alla CVE-2024-4577, già sfruttata per distribuire malware attraverso installazioni PHP vulnerabili, pur condividendo con quel precedente il rischio di compromissione diretta dell’ambiente server.

CVE-2026-109619: memoria già liberata e richieste HTTP successive

La seconda falla, CVE-2026-109619, deriva da un problema di stato globale persistente nei processi PHP che gestiscono più richieste consecutive. Alcune strutture interne possono conservare riferimenti a memoria appartenente a una richiesta già conclusa; quando la memoria viene liberata, il riferimento non viene sempre azzerato correttamente. Una richiesta successiva gestita dallo stesso worker può quindi utilizzare quelle informazioni non più valide, producendo una condizione di use-after-free potenzialmente sfruttabile per eseguire codice arbitrario. Nell’advisory GHSA-6wmf-4rv5-p3rp vengono descritti percorsi che coinvolgono la gestione degli errori, le impostazioni applicate prima dell’inizializzazione e la funzionalità Session Upload Progress. Su PHP 8.5 assume particolare rilievo anche fatal_error_backtraces, perché la gestione delle informazioni diagnostiche può contribuire a mantenere riferimenti ormai invalidi. Lo sfruttamento richiede condizioni più articolate della semplice presenza di una richiesta HTTP malevola, ma il problema può interessare processi persistenti e componenti condivisi da applicazioni differenti. Il quadro evidenzia un rischio diverso dalle vulnerabilità circoscritte al codice di WordPress, come la RCE Click2Shell corretta attraverso gli aggiornamenti del CMS: in PHP2Shell, l’aggiornamento del sito non corregge il motore che ne esegue il codice.

WAF e configurazioni PHP riducono il rischio ma non bloccano PHP2Shell

La pubblicazione degli advisory consente anche di chiarire quali misure temporanee siano realmente utilizzabili. Per CVE-2026-109618, il team PHP suggerisce, soltanto quando non è possibile aggiornare immediatamente, di impostare amministrativamente memory_limit=-1, ridurre le dimensioni accettate dalle richieste e applicare limiti stringenti al traffico multipart. La configurazione elimina alcuni percorsi di esaurimento controllato della memoria, ma non impedisce altri errori di allocazione e deve essere valutata attentamente per evitare problemi di disponibilità del servizio. Per CVE-2026-109619 viene indicata la disabilitazione di session.upload_progress.enabled, accompagnata dal riavvio completo dei worker; su PHP 8.5 è inoltre prevista la possibilità di disabilitare temporaneamente fatal_error_backtraces. Nessuna di queste modifiche rappresenta una protezione completa, perché interviene soltanto su determinate condizioni di sfruttamento. Il ricorso ai WAF può filtrare alcuni tentativi, ma non garantisce di intercettare tutte le richieste utilizzabili per raggiungere il codice vulnerabile. Cloudflare ha segnalato primi tentativi di attacco e aggiornato le proprie protezioni, senza che ciò equivalga alla conferma pubblica di compromissioni riuscite. Il precedente delle tecniche utilizzate per aggirare WAF ed EDR attraverso vulnerabilità applicative e infrastrutturali dimostra perché i controlli perimetrali non possano sostituire la correzione del software. La misura definitiva rimane l’installazione delle versioni PHP corrette.

Continua con:

Zero-day attivi su Windows Defender e patch critiche per Cisco, Apache e PHP

WordPress 7.1.2 corregge una vulnerabilità RCE prima dell’autenticazione

WordPress e hosting italiani: come verificare che PHP sia davvero aggiornato

La priorità operativa per aziende, pubbliche amministrazioni ed editori italiani riguarda l’identificazione della versione PHP realmente utilizzata dal server web. Controllare php -v dalla shell può non essere sufficiente, perché l’interprete da riga di comando potrebbe essere differente da quello eseguito attraverso PHP-FPM, Apache o un container applicativo. Nei servizi di hosting gestito occorre verificare con il fornitore quale pacchetto sia stato aggiornato e se il relativo processo sia stato riavviato.

Le distribuzioni Linux possono includere backport di sicurezza mantenendo un numero di versione apparentemente precedente, perciò è necessario consultare i changelog dei pacchetti e verificare esplicitamente la presenza delle correzioni per entrambe le CVE. Aggiornare WordPress, Drupal, Joomla o Magento non equivale ad aggiornare PHP, così come disporre di un CDN o di un WAF non dimostra che il runtime sia protetto. Dopo la distribuzione delle patch è opportuno esaminare i log dei server, gli errori di memoria anomali, i riavvii inattesi dei worker e l’eventuale comparsa di processi non previsti generati dal servizio web, distinguendo questi indicatori generici dalle prove di compromissione. PHP2Shell dimostra che una vulnerabilità dell’interprete può superare le difese dell’applicazione prima ancora che il CMS inizi a funzionare, rendendo essenziale un processo di aggiornamento che comprenda infrastruttura, servizi gestiti e responsabilità del provider.