In breve: chi vuole aggiornare le dipendenze ha bisogno di un processo per tre mondi di pacchetti: pacchetti Composer nel codice PHP, moduli npm nella build del frontend e plugin o temi nel CMS. Ne fanno parte una cadenza fissa, una persona responsabile, test prima della distribuzione e un piano per i pacchetti senza aggiornamento. Contro PHP2Shell non serve, perché questa vulnerabilità si trova in PHP stesso, ma serve contro le molte vulnerabilità nel codice altrui.
Tre mondi di pacchetti, un punto cieco
Nella settimana dopo il 21/10/2026 tutto ruotava intorno all'interprete PHP. Molti team hanno notato di non conoscere con precisione le versioni dei propri componenti. Il sito funziona, l'agenzia se ne occupa, il plugin si fa sentire da solo quando c'è qualcosa di nuovo: così o in modo simile suonano le ipotesi, finché qualcuno non controlla.
Un tipico progetto PHP oggi è composto da molto più codice altrui che proprio. La OWASP Top 10 riporta i componenti vulnerabili e obsoleti come categoria di rischio a sé. Il problema è raramente lo strumento mancante, ma la routine mancante: gli aggiornamenti avvengono quando qualcuno ha tempo e gli avvisi di sicurezza finiscono in una casella che nessuno legge.
Quali dipendenze si aggiornano e dove
Ogni mondo di pacchetti ha strumenti propri e insidie proprie. La panoramica seguente aiuta a non trascurare nulla.
| Mondo di pacchetti | Mostrare l'inventario | Verificare le vulnerabilità | Insidia tipica |
|---|---|---|---|
| Composer (librerie PHP) | composer show |
composer audit |
Pacchetti indiretti che nessuno conosce |
| npm (build del frontend) | npm ls |
npm audit |
Un aggiornamento senza nuova build non arriva mai al server |
| Plugin e temi CMS | Interfaccia admin o CLI | Avvisi dei produttori, servizi di sicurezza | Plugin abbandonati, plugin a pagamento senza canale di aggiornamento |
| PHP ed estensioni | Gestione dei pacchetti | Security tracker della distribuzione | La versione visualizzata dice poco sui backport |
L'ultima riga, a rigore, non fa parte delle dipendenze dell'applicazione, ma viene spesso dimenticata nello stesso momento. Lo stesso vale per gli script incorporati direttamente da server esterni, come librerie da una CDN, widget di chat o codice di tracciamento. Non compaiono in alcun file lock, ma girano nel browser dei suoi visitatori. Li includa nell'elenco e verifichi se sono incorporate versioni fisse anziché «sempre l'ultima». I dettagli su composer audit, file lock e integrazione nella build si trovano nella guida Verificare le vulnerabilità nelle dipendenze Composer. Come lavori Composer in generale lo spiega Composer: il gestore di pacchetti per PHP.
Il ciclo di manutenzione in sei passi
Un processo sostenibile non deve essere complicato. Questa sequenza si è dimostrata valida:
- Fissare l'inventario: per ogni progetto un elenco delle dipendenze dirette con versione, provenienza e scopo. I file lock (
composer.lock,package-lock.json) appartengono al repository. - Raccogliere gli avvisi: gli strumenti di verifica girano a ogni build e in più regolarmente sullo stato distribuito, anche senza modifiche al codice.
- Valutare: il pacchetto interessato è usato in produzione, la funzione interessata è raggiungibile, esiste una versione corretta?
- Aggiornare in staging e testare: prima gli aggiornamenti di sicurezza all'interno della stessa versione principale, i salti a nuove versioni principali si pianificano come progetto a sé.
- Distribuire con una via di ritorno: lo stato precedente resta disponibile come pacchetto o release, backup del database prima dell'aggiornamento.
- Documentare: che cosa è stato aggiornato e quando, che cosa deliberatamente no e perché.
Faccia attenzione alle indicazioni di versione in composer.json e package.json. Vincoli troppo stretti impediscono che le correzioni di sicurezza possano essere installate. Vincoli troppo larghi portano invece nel progetto, senza verifica, nuove versioni principali. Si è dimostrato valido consentire gli aggiornamenti all'interno della versione principale e pianificare deliberatamente il salto alla successiva.
Per i plugin nel CMS gli aggiornamenti disponibili si possono spesso mostrare anche da riga di comando, in WordPress ad esempio con WP-CLI:
# Mostrare gli aggiornamenti disponibili senza modificare nulla
wp plugin list --update=available
wp theme list --update=available
# Pacchetti del frontend: versioni obsolete e vulnerabilità note
npm outdated
npm audit --omit=dev
Gli aggiornamenti automatici dei plugin direttamente sul sistema di produzione sono comodi, ma rischiosi se nessuno controlla dopo. Li attivi solo se sono garantiti un backup prima di ogni esecuzione e un controllo dopo.
Quando non esiste un aggiornamento
Non ogni segnalazione si risolve con un clic. Il Cheat Sheet OWASP sulla gestione delle dipendenze vulnerabili distingue vari casi, ben trasferibili alla vita quotidiana:
- Patch disponibile: installare in staging, testare, distribuire. Se qualcosa si rompe, adattare il proprio codice anziché lasciare in sospeso l'aggiornamento.
- Patch annunciata, ma non ancora disponibile: attuare il workaround del produttore, disattivare o schermare se possibile la funzione interessata, annotare la decisione.
- Nessuna patch prevista: cercare un pacchetto sostitutivo o riportare da sé la correzione, con un test che distingua la vulnerabilità prima e dopo la patch.
Con i plugin CMS si presenta spesso un quarto caso: il plugin è abbandonato. Allora aiutano solo la sostituzione o la rimozione. Lo stesso vale per i plugin di fonti poco chiare, ad esempio copie «gratuite» di plugin a pagamento. Non ricevono aggiornamenti tramite il canale ufficiale e non di rado contengono a loro volta codice malevolo. Indicazioni per i gestori WordPress le riunisce WordPress e PHP2Shell.
Chiarire la responsabilità prima che arrivi il prossimo avviso
Il motivo più frequente di pacchetti obsoleti non è un ostacolo tecnico, ma una domanda aperta: chi lo fa? Nei progetti realizzati da un'agenzia e gestiti internamente spesso nessuno si sente responsabile. Stabilisca per ogni progetto chi riceve gli avvisi, chi valuta e chi autorizza, e lo metta per iscritto.
Pianifichi inoltre del tempo. Una scadenza di manutenzione fissa al mese, in cui le dipendenze vengono verificate e aggiornate, impedisce che gli aggiornamenti si accumulino per anni. Più a lungo un progetto non viene aggiornato, più grande e rischioso diventa il salto successivo. Come gli aggiornamenti di PHP e pacchetti si inseriscano in una procedura complessiva lo descrive Gestione delle patch come processo anziché pronto intervento.
Come aiuta concretamente PHP SOS?
- Rileviamo tutte le dipendenze dei suoi progetti da Composer, npm e CMS e contrassegniamo pacchetti obsoleti, vulnerabili e abbandonati.
- Impostiamo verifiche automatiche e stabiliamo chi valuta quale avviso.
- Aggiorniamo in staging, testiamo i flussi principali e distribuiamo con una via di ritorno.
- Nell'ambito di un contratto di manutenzione della sicurezza assumiamo in modo duraturo il ciclo mensile, aggiornamenti di PHP inclusi.
Conclusione: le dipendenze aggiornate non sono un progetto, ma una routine. Chi regola con ordine una volta per tutte inventario, cadenza e responsabilità, davanti al prossimo grande avviso deve solo verificare, non prima cercare.
Domande frequenti
Ogni quanto vanno aggiornate le dipendenze?
Gli aggiornamenti di sicurezza il prima possibile dopo la valutazione, gli aggiornamenti di routine con una cadenza fissa, ad esempio mensile. Più della frequenza esatta conta che la scadenza sia stabilita e che qualcuno ne sia responsabile.
Un plugin aggiornato protegge da PHP2Shell?
No. PHP2Shell si trova nell'interprete PHP stesso. Contro di esso aiuta solo un aggiornamento di PHP con riavvio di tutti i processi PHP. Plugin e pacchetti aggiornati restano comunque importanti, perché chiudono vulnerabilità proprie.
Che cosa faccio con un plugin che non è più mantenuto?
Sostituirlo o rimuoverlo. Un plugin abbandonato non riceve più correzioni, anche se oggi funziona ancora. Fino alla sostituzione dovrebbe verificare se la funzione serva davvero e documentare la decisione.
Il frontend con npm va aggiornato anche sul server?
Spesso i pacchetti npm esistono solo nella build e arrivano sul server come file già pronti. Una vulnerabilità in un pacchetto può comunque trovarsi nel JavaScript distribuito. Dopo un aggiornamento occorre quindi ricostruire e distribuire di nuovo.