Due falle in PHP da 9,2 punti: che cosa significa per un'azienda e quanto costa aspettare

Il 21 ottobre 2026 il team di PHP ha pubblicato aggiornamenti straordinari e la squadra europea di risposta agli incidenti informatici CERT-EU ha pubblicato un avviso urgente. Due vulnerabilità con un punteggio di pericolosità di 9,2 su 10 permettono a un aggressore di eseguire codice proprio sul server — senza login, senza password e senza alcuna azione da parte dei dipendenti dell'azienda.

Per un'azienda questa non è una notizia tecnica astratta. PHP è il linguaggio in cui è scritta la maggior parte dei siti: WordPress, Joomla, OpenCart, Bitrix, Laravel, e inoltre centinaia di script fatti in casa con cui il sito viene collegato al CRM, alla posta o a 1C. Se la vostra azienda ha un sito, un negozio online o un'area clienti, l'unica domanda è se siete riusciti ad aggiornare o no.

Che cosa è stato trovato esattamente

Le vulnerabilità sono due, entrambe valutate 9,2 punti ed entrambe portano allo stesso risultato: l'esecuzione di codice estraneo sul server senza autenticazione.

CVE-2026-109618 — interruzione quando manca la memoria

In PHP esiste l'impostazione memory_limit: una richiesta che ha consumato troppa memoria viene interrotta a forza. Il problema è come esattamente viene interrotta. PHP può fermarsi nel momento in cui i dati interni della richiesta sono riempiti solo a metà — per esempio mentre viene analizzato un file inviato tramite un modulo di caricamento. La pulizia dopo una richiesta del genere prende i dati incompleti per dati veri e prova a liberare memoria che non è mai esistita. E in quella memoria può trovarsi ciò che l'aggressore vi ha messo con richieste precedenti.

CVE-2026-109619 — residui della richiesta precedente

La seconda falla riguarda il fatto che il server non «dimentica» del tutto il visitatore precedente. Lo stato interno che apparteneva a una richiesta a volte sopravvive alla liberazione della memoria, per esempio dopo un errore fatale. La richiesta successiva, finita nello stesso processo di lavoro, riesce a sfruttare quei residui prima che la normale inizializzazione li azzeri.

È a rischio qualsiasi installazione di PHP che serve richieste web: PHP-FPM, Apache con il modulo mod_php, php-cgi, FrankenPHP, LiteSpeed. La combinazione più rischiosa, secondo il team di PHP, è proprio quella di Apache con mod_php — è ancora quella standard su molti hosting economici.

L'exploit dimostrativo funziona con una sola richiesta non autenticata, prima ancora che inizi a girare il codice del sito stesso. Qui dunque non servono né i plugin di sicurezza, né le password complesse, né l'autenticazione a due fattori: l'attacco avviene un livello più in basso.

Quali versioni sono a rischio

Tutto ciò che è inferiore a queste versioni è vulnerabile:

Ramo di PHP	Versione sicura
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 e precedenti	nessun supporto

Una categoria di rischio a parte sono i prodotti commerciali e open source che hanno PHP incorporato, anche se da fuori non si vede: pannelli di gestione, dispositivi di rete, sistemi di videosorveglianza, portali aziendali. L'elenco di questo software è tenuto nel repository del NCSC olandese.

Quanto costa questo a un'azienda

Nessuno cerca la vostra azienda in particolare. Quando gli esempi di sfruttamento diventano pubblici — e sono già pubblici — in poche ore partono scanner automatici che passano in rassegna tutta la rete uno dopo l'altro. Non fa differenza se è il sito di una fabbrica o la pagina di un parrucchiere: conta solo se il server risponde con una versione vulnerabile.

Poi inizia la parte che si conta in denaro. Sul server viene caricata una web shell, il sito distribuisce spam o pubblicità altrui, il dominio finisce nelle liste nere — e la posta che parte da esso non arriva più a clienti e partner. Nel frattempo il negozio non vende, i commerciali non ricevono richieste e i motori di ricerca fanno in tempo a segnalare il sito come pericoloso. Il ripristino non è una notte di lavoro, ma pulizia, riemissione delle chiavi, cambio delle password e rimozione del dominio dalle liste nere, cosa che va avanti per settimane.

Un rischio a parte sono i dati. Se sul server c'è un database dei clienti o lo storico degli ordini, la loro fuga significa anche domande all'azienda da parte dei clienti e dell'autorità di controllo, non solo un incidente tecnico.

Cosa fare — passo per passo

1. Scoprite la vostra versione. Nel pannello dell'hosting è la sezione «Versione PHP» o «PHP Selector»; su un server proprio, il comando php -v. È importante controllare la versione con cui gira davvero il sito, non quella presente nella riga di comando: spesso sono diverse.
2. Aggiornate all'interno del vostro ramo. Passare da 8.2.29 a 8.2.35 è una correzione all'interno di un solo ramo: la compatibilità è mantenuta e il sito non si rompe. Non confondetelo con il passaggio da 8.2 a 8.4 — quello sì richiede verifiche.
3. Se avete la 8.1 o una versione più vecchia — questi rami non hanno supporto. Data la gravità della situazione il team di sicurezza di PHP ha pubblicato correzioni minime anche per 7.4, 8.0 e 8.1, e una parte degli hoster mantiene build proprie. La scelta giusta resta però il passaggio a un ramo supportato, e conviene pianificarlo adesso e non la prossima volta.
4. Riavviate i gestori. Senza riavviare php-fpm o Apache i processi di lavoro continuano a girare sul codice vecchio e l'aggiornamento di fatto non ha effetto.
5. Verificate il risultato. La cosa più semplice è una pagina temporanea con phpinfo(), che va cancellata subito dopo il controllo, oppure la sezione «Versione PHP» nel pannello dopo il riavvio.

Ai clienti di un hosting di solito non toccherà fare nulla a mano: i grandi provider hanno ricevuto le correzioni in anticipo e aggiornano le proprie macchine da sé. Vale la pena scrivere una riga all'assistenza — «PHP è stato aggiornato alle versioni del 21 ottobre 2026?» — e ottenere la risposta per iscritto.

Se aggiornare subito non è possibile

Capita che il sito sia vecchio e che l'aggiornamento richieda preparazione. Allora esistono misure temporanee che restringono la finestra per un attacco:

• chiudere l'esaurimento della memoria come punto d'ingresso: memory_limit=-1, impostato in modo che l'applicazione non possa sovrascriverlo, e una verifica che nessun pool o directory riporti indietro il limite;
• ridurre post_max_size — 8M per i siti senza caricamento di file, 32M se i caricamenti servono, e upload_max_filesize tenerlo più basso;
• disattivare session.upload_progress.enabled e riavviare tutti i processi di lavoro;
• su PHP 8.5 disattivare inoltre fatal_error_backtraces;
• limitare dimensione e complessità delle richieste a livello di server web o proxy.

Nessuna di queste misure rende sicura l'installazione. Chiudono solo le vie note: il problema lo chiude del tutto soltanto l'aggiornamento.

Se nemmeno questo è possibile, CERT-EU consiglia una soluzione semplice e impopolare: togliere il servizio vulnerabile dall'internet pubblico finché la correzione non è installata e verificata.

Da dove vengono questi dati

• CERT-EU, Security Advisory 2026-018 «Critical Vulnerabilities in PHP»
• L'annuncio del rilascio degli aggiornamenti su php.net
• Descrizione tecnica di CVE-2026-109618 e CVE-2026-109619

---

Se nella vostra azienda non c'è una persona che risponde delle versioni e degli aggiornamenti sul server, l'audit si può ordinare all'esterno — per esempio a SmartGT: verificheranno le risorse e diranno chiaramente se c'è una minaccia e cosa farne.

Autore del materiale — SmartGT. Fonte originale: «Vulnerabilità critiche di PHP: l'aggiornamento non può aspettare».