Due falle critiche in PHP richiedono attenzione immediata da chi gestisce siti, applicazioni e portali aziendali. Il rischio non riguarda solo i grandi provider: interessa anche le PMI che pubblicano servizi web su server propri, hosting gestiti o ambienti cloud.
Perché questa notizia conta
PHP ha pubblicato un aggiornamento di sicurezza che corregge due vulnerabilità critiche, identificate come CVE-2026-109618 e CVE-2026-109619. Il team PHP indica che possono portare a esecuzione remota di codice senza autenticazione, cioè a far eseguire comandi sul server a chi attacca da Internet.
La parte più importante, per un’azienda, è questa: non si parla di un problema teorico o limitato a casi particolari. PHP segnala che sono a rischio tutte le installazioni che servono richieste web, tra cui PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. In particolare, il rischio è considerato più alto con mod_php, dove esiste un exploit dimostrato che può partire da una richiesta non autenticata prima ancora che il codice applicativo intervenga.
Per una PMI questo significa che il perimetro da controllare è più ampio di quanto sembri. Non basta chiedersi “il nostro sito funziona?”. Bisogna chiedersi: “quale versione di PHP usa davvero ogni sito, pannello, app gestionale o area riservata?” e “chi la aggiorna, con quali tempi?”.
Cosa cambia per chi gestisce l’IT
Se un server web viene compromesso, l’impatto non riguarda solo la pagina pubblica. Un aggressore può usare il server come punto di ingresso per leggere dati, alterare file, installare ulteriori strumenti malevoli o spostarsi verso altri sistemi raggiungibili dalla stessa rete. Questo è il tipo di incidente che può trasformare un problema tecnico in un fermo operativo.
Per una piccola o media impresa italiana, le conseguenze tipiche sono queste:
- sito o portale fuori servizio;
- area clienti o area fornitori non raggiungibile;
- posta o integrazioni web che smettono di funzionare;
- rischio di violazione dei dati se l’attaccante ottiene accesso al server;
- lavoro urgente e non pianificato per il reparto interno o il fornitore esterno.
Questo è il punto che conta davvero per chi decide sull’IT: la vulnerabilità non va letta come “un bug di PHP”, ma come un possibile guasto di continuità e di sicurezza per servizi che spesso sostengono vendite, assistenza e amministrazione.
La prima azione: verificare le versioni
PHP ha rilasciato versioni correttive per i rami ancora supportati: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. PHP indica che non ci sono mitigazioni complete e che l’aggiornamento è l’unica scelta sicura.
Per una PMI, il lavoro da fare subito è semplice da descrivere, anche se non sempre semplice da eseguire:
- censire tutti i server e gli hosting che eseguono PHP;
- identificare la versione attiva su ciascun ambiente;
- capire se l’aggiornamento è gestito internamente o dal provider;
- aprire una richiesta urgente se l’ambiente è su servizi gestiti;
- pianificare il test rapido dopo l’aggiornamento, per verificare che siti e applicazioni restino operativi.
Se il sito è ospitato su una piattaforma cloud, il controllo non è automatico in tutti i casi. Microsoft indica che su Azure App Service la gestione della versione PHP dipende dal tipo di configurazione e dal servizio in uso; in alcuni scenari il cliente deve intervenire nella configurazione, in altri serve l’assistenza del provider.
Dove si annida il rischio operativo
Molte PMI hanno più di un ambiente PHP senza averne un inventario preciso: il sito istituzionale, il gestionale web, il portale documentale, un’area riservata, un vecchio servizio di marketing, magari un componente aggiuntivo o una vecchia installazione per un partner. È lì che spesso si nasconde il problema.
Va controllata anche la modalità di esecuzione. La documentazione PHP distingue tra uso come modulo Apache e uso in CGI o FPM; nel caso di Apache come modulo, il contesto di sicurezza è diverso e la superficie di rischio può aumentare. Questo non significa che un modello sia sempre sbagliato, ma che l’analisi non può fermarsi al numero di versione.
Un altro errore comune è affidarsi solo al fatto che “non ci sono segnali strani”. Le vulnerabilità critiche spesso vengono sfruttate prima che l’azienda noti sintomi evidenti. Per questo i cataloghi di vulnerabilità sfruttate attivamente, come quello di CISA, sono usati come riferimento per dare priorità agli interventi.
Cosa conviene fare adesso
Per un’azienda senza un team interno dedicato alla sicurezza, la strada più prudente è questa:
- trattare l’aggiornamento come urgente;
- verificare che tutti gli ambienti PHP siano inclusi, non solo il sito principale;
- chiedere conferma scritta al fornitore se la piattaforma è gestita da terzi;
- controllare i log dopo l’intervento, per individuare anomalie;
- programmare un inventario stabile delle applicazioni web, così il prossimo avviso non parta da zero.
Il punto non è inseguire ogni allarme. Il punto è capire che un server web non aggiornato può diventare un ingresso diretto nella rete aziendale. Su questo tipo di rischio, la velocità di risposta conta quanto la scelta tecnica.
Un test utile per il responsabile IT
Se oggi una persona esterna chiedesse: “quali dei vostri servizi usano PHP e con quale versione?”, l’azienda saprebbe rispondere in pochi minuti? Se la risposta è no, il problema di questa notizia non è solo PHP. È la mancanza di controllo sugli asset web.