Nel cuore del mondo digitale, dove un linguaggio nato nel 1995 continua a reggere una parte enorme dei siti Web, emergono due falle gravi nel motore PHP che possono permettere a un estraneo di eseguire codice su un server senza alcuna credenziale. Gli sviluppatori hanno risposto con un avviso straordinario e con versioni corrette già disponibili, ricordando che la fragilità di una fondamenta si propaga a tutto ciò che vi è costruito sopra. La vicenda invita a una riflessione semplice: anche le tecnologie più consolidate richiedono una vigilanza costante, perché il loro peso è proprio ciò che l
PHP sotto attacco: due falle critiche (CVSS 9,2) permettono esecuzione di codice da remoto, patch già disponibili
Un sito WordPress aggiornato non può difendersi da solo da un problema a monte
Mark
Perché questa vicenda preoccupa più di un normale bug in un CMS?
Mimi
Perché il difetto è nel motore, non in un'applicazione. PHP sta sotto WordPress, Drupal, Joomla e Magento, quindi la superficie coinvolta è enorme.
Mark
E un sito aggiornato non è al sicuro?
Mimi
Gli sviluppatori hanno confermato che almeno un attacco dimostrato compromette il server prima che parta il codice dell'applicazione. Aggiornare WordPress, da solo, non basta.
Luke
Va però precisato che il punteggio 9,2 non significa che ogni server sia attaccabile facilmente. La fonte dice che la complessità è elevata e servono requisiti specifici.
Mark
Quali configurazioni sono più a rischio?
Mimi
Apache con mod_php è lo scenario più esposto, con un attacco dimostrato su configurazione prefork e limiti predefiniti. FrankenPHP sembrerebbe simile.
Luke
Quel «sembrerebbe» conta: per FrankenPHP non c'è una dimostrazione citata. Per PHP-FPM non risulta un exploit completo, e per LiteSpeed LSAPI gli attacchi sono solo ritenuti probabili, non validati.
Mark
Quindi FPM è sicuro?
Mimi
No, il processo figlio viene terminato se l'avvio fallisce, ma un errore successivo può comunque raggiungere un percorso vulnerabile.
Luke
Resta ignoto se ci siano già attacchi in corso: la fonte non ne parla. Quello che è certo sono le versioni corrette: 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
O Pulso
- Due vulnerabilità con punteggio CVSS 9,2 aprono la porta all'esecuzione remota di codice senza login né interazione dell'utente.
- Il difetto risiede nel motore PHP stesso, quindi investe WordPress, Drupal, Joomla e Magento e migliaia di server che li ospitano.
- Gli amministratori sono chiamati a intervenire subito, scavalcando il consueto ciclo di manutenzione e installando PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35.
- Il rischio maggiore ricade su Apache con mod_php, mentre PHP-FPM mostra un quadro meno critico e le verifiche su altre configurazioni proseguono.
Nel cuore del mondo digitale, dove un linguaggio nato nel 1995 continua a reggere una parte enorme dei siti Web, emergono due falle gravi nel motore PHP che possono permettere a un estraneo di eseguire codice su un server senza alcuna credenziale. Gli sviluppatori hanno risposto con un avviso straordinario e con versioni corrette già disponibili, ricordando che la fragilità di una fondamenta si propaga a tutto ciò che vi è costruito sopra. La vicenda invita a una riflessione semplice: anche le tecnologie più consolidate richiedono una vigilanza costante, perché il loro peso è proprio ciò che le rende bersagli.
Il 21 ottobre 2026 il team di sviluppo di PHP ha pubblicato un avviso di sicurezza fuori calendario per due vulnerabilità critiche, già soprannominate PHP2Shell dai ricercatori. Con un punteggio CVSS 9,2, le falle possono consentire a un aggressore di eseguire codice da remoto senza credenziali, e per questo agli amministratori viene chiesto di agire senza attendere la manutenzione programmata.
Il peso della notizia nasce dalla diffusione del linguaggio. PHP alimenta ancora WordPress, Drupal, Joomla, Magento e numerosi pannelli di hosting, quindi un difetto nel motore raggiunge una platea molto più vasta di un singolo plugin. Le patch sono già disponibili nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Le falle riguardano la gestione della memoria. La prima si manifesta quando uno script esaurisce la memoria concessa e l'interprete, interrompendosi a metà inizializzazione, lascia strutture incomplete che la pulizia successiva tratta come valide. Lo scenario più esposto è Apache con mod_php, mentre con PHP-FPM un exploit completo non risulta dimostrato. La seconda è un caso di use after free: riferimenti a memoria di una richiesta conclusa vengono riutilizzati dalla successiva, e in PHP 8.5 la combinazione con la direttiva fatal_error_backtraces rende possibile lo sfruttamento.
Un dettaglio preoccupa in particolare: almeno un attacco compromette il server Web prima che il codice dell'applicazione venga eseguito, rendendo inutile la sola cura del singolo sito. Per chi gestisce server, la indicazione resta una sola: aggiornare appena possibile.
Il 21 ottobre 2026 il team di sviluppo di PHP ha pubblicato un advisory di sicurezza straordinario, fuori dal normale calendario degli aggiornamenti. Descrive due vulnerabilità critiche, già ribattezzate PHP2Shell dai ricercatori, a cui è stato assegnato un punteggio CVSS 4.0 di 9,2. In determinate condizioni permettono l'esecuzione di codice da remoto senza alcuna autenticazione. Agli amministratori di sistema viene chiesto di intervenire subito, senza aspettare il consueto ciclo di manutenzione.
Il peso della vicenda dipende da quanto è diffuso il linguaggio. PHP è nato nel 1995 e oggi sta ancora alla base di WordPress, Drupal, Joomla e Magento, oltre a molti software aziendali e pannelli di gestione dell'hosting. Un difetto nel motore stesso ha quindi una portata più ampia di un bug confinato in un singolo CMS o in un plugin.
Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, e le patch sono già scaricabili. Entrambi i difetti riguardano la gestione della memoria e lo stato interno dell'interprete, in particolare ciò che accade quando una richiesta HTTP si chiude in modo anomalo e lo stesso processo continua a servirne altre.
Gli sviluppatori hanno confermato un dettaglio inquietante: almeno uno degli attacchi dimostrati compromette un server Web prima che PHP inizi a eseguire il codice dell'applicazione ospitata. Un sito WordPress perfettamente aggiornato non può quindi difendersi da solo da un problema che si manifesta a monte.
Per entrambe le falle il vettore è la rete, e non servono credenziali né interazione dell'utente. La complessità dell'attacco resta però elevata e richiede requisiti operativi specifici. Chi ci riesce può manipolare la disposizione degli oggetti in memoria fino a eseguire codice con i privilegi dell'utente associato al processo Web. Le possibilità concrete di sfruttamento cambiano con la modalità di esecuzione, la configurazione, i moduli caricati e, a volte, il comportamento dell'applicazione.
La prima falla riguarda la gestione dell'errore di memoria esaurita. PHP limita i consumi con la direttiva memory_limit e, quando uno script raggiunge la soglia, l'interprete deve fermarsi e liberare le risorse. L'operazione può però interrompersi mentre alcune strutture interne sono inizializzate solo a metà, e le procedure di pulizia successive rischiano di trattarle come se contenessero dati validi.
Il bollettino indica come scenario più esposto Apache con mod_php, perché Apache può avviare la chiusura della richiesta anche quando l'inizializzazione è fallita. 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. Non è per questo immune, perché un errore successivo all'inizializzazione può comunque incrociare un percorso vulnerabile, ma contro FPM non risulta dimostrato un exploit completo. FrankenPHP, che integra PHP in un server basato su Caddy, sembrerebbe esposto in modo simile a mod_php. LiteSpeed LSAPI si comporta più come FPM, e gli attacchi ritenuti probabili, non ancora validati, dipenderebbero dall'applicazione.
La seconda falla nasce dalla persistenza di riferimenti a memoria appartenuta a una richiesta già conclusa. Se il processo li conserva e li riutilizza in quella seguente, accede a un'area non più valida: è il classico 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 il controllo salta. Una delle condizioni confermate coinvolge PHP 8.5 e la direttiva fatal_error_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.
Per chi gestisce server, la strada indicata è una sola: passare a una delle versioni corrette appena possibile.
Citações Notáveis
Gli amministratori devono aggiornare senza attendere il consueto ciclo di manutenzione.— Indicazione riportata da TecnoAndroid sull'aggiornamento straordinario di PHP
Quer a matéria completa?
Leia o original em TecnoAndroid ↗
War & Conflict