In questo articolo Indice dei contenuti 2 sezioni
Due vulnerabilità critiche scoperte in PHP hanno costretto il team di sviluppo a rilasciare un aggiornamento di sicurezza straordinario. Il problema, già ribattezzato PHP2Shell dai ricercatori, riguarda due falle con un punteggio CVSS 4.0 pari a 9,2 che in determinate condizioni permettono l’esecuzione di codice da remoto senza alcuna autenticazione. Gli amministratori di sistema sono chiamati a muoversi in fretta, senza aspettare il consueto ciclo di manutenzione.
Il peso della vicenda si capisce guardando quanto è diffuso il linguaggio. Nato nel 1995, PHP è ancora oggi il cuore di piattaforme come WordPress, Drupal, Joomla e Magento, oltre che di tanti software aziendali e pannelli di gestione dell’hosting. Un difetto nel motore stesso ha quindi una portata molto più ampia rispetto a un bug confinato in un singolo CMS o in un plugin.
Le patch disponibili e cosa succede dentro l’interprete
L’advisory ufficiale pubblicato il 21 ottobre 2026 descrive i meccanismi delle due falle e indica le versioni corrette, cioè PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le patch sono già scaricabili. Entrambi i difetti toccano la gestione della memoria e lo stato interno dell’interprete, in particolare quello che accade quando una richiesta HTTP si chiude in modo anomalo e lo stesso processo continua a servirne altre.
C’è poi un dettaglio piuttosto inquietante confermato dagli sviluppatori. Almeno uno degli attacchi dimostrati riesce a compromettere un server Web prima ancora che PHP cominci a eseguire il codice dell’applicazione ospitata. In pratica un sito WordPress perfettamente aggiornato non può difendersi da solo contro un problema che si manifesta a monte.
Per tutte e due le falle il vettore è la rete e non servono credenziali né interazione dell’utente. La complessità dell’attacco resta comunque elevata e richiede requisiti operativi specifici. Chi riesce nell’impresa può manipolare la disposizione degli oggetti in memoria fino a eseguire codice con i privilegi dell’utente legato al processo Web. Le possibilità concrete di sfruttamento cambiano a seconda della modalità di esecuzione, della configurazione, dei moduli caricati e talvolta del comportamento dell’applicazione.
Prima falla, l’errore di memoria esaurita
PHP limita i consumi con la direttiva memorylimit. Quando uno script tocca la soglia, l’interprete deve fermarsi e liberare le risorse. Il guaio sta proprio nella gestione di queste situazioni di Out Of Memory: l’operazione può interrompersi mentre alcune strutture interne sono ancora inizializzate a metà, e le successive procedure di pulizia rischiano di trattarle come se contenessero dati validi.
Il bollettino indica Apache con modphp come lo scenario più esposto, perché Apache può avviare la chiusura della richiesta anche quando l’inizializzazione non è andata a buon fine. Gli sviluppatori hanno dimostrato un attacco via HTTP, senza autenticazione, con i limiti predefiniti e una normale configurazione Apache prefork con più processi di lavoro. Con PHP FPM il quadro cambia: se l’avvio di una richiesta fallisce il processo figlio viene terminato. Questo non lo rende immune, dato che un errore successivo all’inizializzazione può comunque incrociare un percorso vulnerabile, anche se contro FPM non risulta dimostrato un exploit completo. FrankenPHP, che integra PHP in un server basato su Caddy, sembrerebbe esposto in modo simile a modphp. LiteSpeed LSAPI si comporta invece più come FPM e gli attacchi ritenuti probabili, ancora non validati, dipenderebbero dall’applicazione.
La seconda falla nasce dalla persistenza di riferimenti a memoria che apparteneva a una richiesta già conclusa. Se il processo li conserva e li riutilizza in quella seguente, finisce per accedere a un’area non più valida, il classico caso di use after free. Prima di liberare la memoria PHP dovrebbe assicurarsi che nessuna struttura globale punti ancora a quei dati, e il difetto compare quando questo controllo salta. Una delle condizioni confermate coinvolge PHP 8.5 e la direttiva fatalerror_backtraces, che conserva informazioni sul percorso delle chiamate responsabili di un errore fatale, sfruttata insieme a un messaggio diagnostico generato mentre l’interprete applica le proprie impostazioni.
Fonte: TecnoAndroid