Il tuo software gira su PHP 5 o Windows Server 2012: cosa rischi davvero

Conclusione anticipata: un software che gira su tecnologie fuori supporto non è un debito tecnico da gestire con calma — è una vulnerabilità attiva che cresce ogni giorno. Quello che segue dimostra perché, con esempi tratti da situazioni reali.

PHP 5, Windows Server 2012 e la fine del supporto: cosa significa davvero

PHP 5 ha perso il supporto ufficiale nel 2018. Windows Server 2012 è uscito dal supporto esteso di Microsoft a fine 2023. Nessuna patch di sicurezza, nessuna correzione di bug, nessun aggiornamento. Per chi li usa ancora oggi, questo significa una cosa sola: ogni vulnerabilità scoperta da quel momento in poi rimane aperta, per sempre.
Non è una questione teorica. Le CVE (Common Vulnerabilities and Exposures) continuano ad accumularsi anche sulle versioni dismesse: i ricercatori le trovano, le pubblicano, e chi ha ancora quel software in produzione diventa un bersaglio con l’indirizzo scritto sopra.
Il problema più sottile è che molte PMI non sanno su cosa gira il loro gestionale o il loro portale. L’hanno commissionato anni fa, funziona, e nessuno ha mai aperto il cofano. Scoprirlo solo quando qualcosa va storto è il modo più costoso possibile di fare manutenzione.

Errore 1 — Nessun inventario della versione software in produzione

Come si manifesta. L’azienda usa un’applicazione web sviluppata tra il 2010 e il 2015. Il fornitore originale non c’è più o non segue più il progetto. Nessuno sa con certezza quale versione di PHP gira sul server, né quale sistema operativo lo ospita. Si scopre solo quando arriva un avviso dall’hosting, o quando il sito smette di funzionare dopo un aggiornamento del provider.
Quanto costa. Un’analisi d’urgenza su un’applicazione di cui non si ha documentazione può richiedere settimane. Se nel frattempo il software è irraggiungibile, il costo operativo si somma a quello tecnico.
Come si evita. Bastano tre cose: un documento aggiornato con le versioni software in produzione (PHP, framework, sistema operativo), un contatto tecnico che sappia rispondere a queste domande, e una revisione annuale. Se non hai nessuno che possa farlo internamente, è il momento di coinvolgere chi gestisce la manutenzione software custom come attività continuativa, non emergenziale.

Errore 2 — Credere che “funziona” significhi “è sicuro”

Un’applicazione PHP 5 che risponde correttamente alle richieste degli utenti sembra sana. Non lo è.
La stabilità operativa e la sicurezza sono due piani separati. Un’applicazione può elaborare ordini, generare report e inviare email senza mai dare un errore visibile, e allo stesso tempo avere una porta aperta sul database accessibile dall’esterno. Questo tipo di vulnerabilità non produce sintomi fino al giorno in cui qualcuno la sfrutta.
Come si manifesta. L’azienda non ha mai subito attacchi visibili, quindi conclude che il rischio è basso. Nel frattempo, un bot automatizzato scansiona gli IP alla ricerca di versioni PHP vecchie — operazione banale, automatizzata, che avviene continuamente su scala globale.
Quanto costa. Una violazione dei dati comporta costi diretti (ripristino, forensics, comunicazione agli interessati) e costi indiretti (sanzioni GDPR, danni reputazionali, interruzione operativa). Le sanzioni del GDPR per mancata protezione dei dati possono arrivare fino al 4% del fatturato annuo globale: non è un numero inventato, è il tetto previsto dal regolamento.
Come si evita. Un penetration test periodico sull’applicazione, anche semplificato, rivela le vulnerabilità prima che lo facciano altri. Se il software è troppo vecchio per essere testato con strumenti moderni, è un segnale che il problema va affrontato a monte: vedi la sezione sul refactoring più avanti.

Errore 3 — Rimandare l’aggiornamento perché “costa troppo”

Questa è, secondo noi, la valutazione sbagliata più diffusa. Il ragionamento è comprensibile: aggiornare un’applicazione legacy ha un costo certo e immediato, mentre il rischio di un attacco sembra lontano e incerto. Il problema è che questo calcolo ignora i costi del non aggiornare.
Come si manifesta. L’azienda riceve da anni avvisi dall’hosting o dal consulente tecnico sulla necessità di migrare da PHP 5 a una versione supportata. Ogni anno la decisione viene posticipata. Poi arriva un aggiornamento obbligatorio del server (l’hosting dismette il supporto alla versione vecchia), e l’applicazione smette di funzionare senza preavviso utile.
Quanto costa. Una migrazione pianificata con calma, con test adeguati e documentazione, costa significativamente meno di una migrazione d’emergenza fatta in pochi giorni mentre il software è fermo. Il testing software custom in condizioni di urgenza è più superficiale per forza, e i bug che ne derivano si pagano dopo.
Come si evita. Trattare l’aggiornamento come un progetto pianificabile, non come un’emergenza futura. Definire una finestra temporale (sei mesi, un anno), allocare un budget, e procedere per fasi. La migrazione da PHP 5 a PHP 8, per esempio, non richiede necessariamente di riscrivere tutto: dipende da quanto il codice è accoppiato alle funzioni deprecate.

Se stai valutando cosa fare con un’applicazione che gira su tecnologie fuori supporto, raccontaci il progetto: un’analisi tecnica iniziale aiuta a capire l’entità reale del lavoro prima di prendere qualsiasi decisione.

Errore 4 — Confondere il fornitore dell’hosting con il responsabile della sicurezza applicativa

Come si manifesta. L’azienda paga un hosting gestito e assume che il provider si occupi di tutto. Il provider, però, gestisce l’infrastruttura: il sistema operativo del server, la rete, i backup. Non tocca il codice dell’applicazione. Se quella applicazione ha una SQL injection nel form di login, il provider non lo sa e non è tenuto a saperlo.
Questa confusione di responsabilità è frequente, e porta a una zona grigia in cui nessuno controlla davvero la sicurezza applicativa.
Quanto costa. Un attacco che sfrutta una vulnerabilità applicativa non viene bloccato dal firewall del provider, perché passa attraverso le porte legittime (HTTP/HTTPS). Il danno è tutto a carico dell’azienda.
Come si evita. Chiarire per iscritto, con il fornitore tecnico dell’applicazione, dove finisce la responsabilità dell’hosting e dove inizia quella dello sviluppatore. Se non c’è un fornitore tecnico attivo, qualcuno deve assumere quel ruolo. Lasciare il codice senza un owner tecnico è una scelta, non una situazione neutra.

Errore 5 — Sottovalutare la dipendenza da librerie e dipendenze di terze parti

Un’applicazione PHP 5 non è solo PHP 5. Porta con sé un ecosistema di librerie, spesso anch’esse fuori supporto: versioni vecchie di framework, componenti di autenticazione, librerie per la generazione di PDF o la gestione delle email. Ognuna di queste è un vettore di attacco potenziale.
Come si manifesta. L’applicazione usa una libreria per la gestione dei pagamenti che non viene aggiornata da anni. Quella libreria ha una vulnerabilità nota. L’azienda non lo sa perché non monitora le dipendenze.
Quanto costa. Se la vulnerabilità riguarda i dati di pagamento, le implicazioni vanno oltre il GDPR e coinvolgono gli standard PCI DSS. Le conseguenze possono includere la revoca della capacità di accettare pagamenti con carta.
Come si evita. Strumenti come Composer (per PHP) permettono di verificare le dipendenze di un progetto e confrontarle con i database di vulnerabilità note. Non è un’operazione complessa, ma richiede che qualcuno la faccia periodicamente. Se il codice è talmente vecchio da non usare un package manager, il refactoring software legacy non è più un’opzione da valutare: è una necessità operativa.

Quando il problema non è solo tecnico

C’è un aspetto che le guide tecniche tendono a trattare poco: la responsabilità legale di chi gestisce dati su infrastrutture obsolete.
Il GDPR richiede che i dati personali siano trattati con misure tecniche adeguate allo stato dell’arte. Usare un software su PHP 5 senza supporto di sicurezza nel 2026 è difficilmente compatibile con questo requisito. In caso di ispezione o violazione, la scelta di non aggiornare può essere interpretata come negligenza, non come sfortuna.
Questo vale anche per i software interni che trattano dati di dipendenti, fornitori o clienti. Non serve avere un e-commerce con migliaia di utenti: basta un gestionale con le anagrafiche dei dipendenti.
La decisione di rimandare l’aggiornamento, quindi, non è solo tecnica. Ha implicazioni di compliance che ricadono sull’azienda, non sul fornitore software.
Per chi vuole capire come si struttura una migrazione ordinata da un’applicazione legacy, il punto di partenza è sempre un’analisi dello stato attuale: versioni, dipendenze, dati trattati, superficie di attacco. Solo con quel quadro è possibile stimare tempi e priorità in modo realistico, come descritto in dettaglio nella guida sulle fasi di sviluppo software per progetti aziendali.

Cosa fare adesso, in ordine di priorità

Se non sai da dove partire, questo è l’ordine che ha senso:

1. Scopri su cosa gira il tuo software: versione PHP, sistema operativo del server, framework usato. Se non riesci a rispondere da solo, chiedi al tuo hosting o al fornitore tecnico.
2. Verifica se quelle versioni sono ancora in supporto attivo. PHP.net e il sito di Microsoft pubblicano le date di fine vita in modo chiaro.
3. Se sono fuori supporto, valuta l’entità del lavoro di migrazione prima di decidere se aggiornare gradualmente o riscrivere. Le due opzioni hanno costi e tempi molto diversi.
4. Nel frattempo, limita la superficie di attacco: disabilita le funzionalità non usate, verifica i permessi di accesso, assicurati che i backup siano aggiornati e testati.

Un software obsoleto non si aggiorna da solo. Ogni mese che passa è un mese in cui le vulnerabilità note restano aperte. La domanda non è se aggiornare, ma quando e come farlo senza bloccare l’operatività.
Se gestisci un’applicazione che mostra questi segnali e vuoi capire da dove partire, scrivici: un’analisi tecnica dello stato attuale è il primo passo per decidere con dati alla mano, non per istinto.