Se in questi giorni il vostro reparto IT vi è sembrato più nervoso del solito, c’è un motivo preciso: in meno di due settimane PHP, GitLab e Node.js hanno rilasciato aggiornamenti d’emergenza per falle gravissime.
Il nome di queste tre tecnologie potrebbe non dirvi molto. Ma è probabile che il vostro sito, il vostro e-commerce, un gestionale o le applicazioni su cui lavora il vostro team ne usino almeno una.
Cosa è successo davvero
PHP è il linguaggio su cui gira una parte enorme del web, dai siti aziendali ai portali. GitLab è la piattaforma dove molte aziende custodiscono e sviluppano il proprio codice. Node.js sta dietro a moltissime applicazioni moderne.
In tutti e tre i casi sono state trovate falle che, nel caso peggiore, permettono a un aggressore di eseguire comandi sul vostro server da remoto. In alcuni scenari, senza nemmeno bisogno di una password.
PHP: una falla che ha anticipato il calendario
Il 21 ottobre il team di PHP ha pubblicato un aggiornamento di sicurezza per due vulnerabilità critiche che possono consentire l’esecuzione di codice remoto senza autenticazione. La coppia di falle è stata soprannominata PHP2Shell.
La notizia è circolata prima del previsto: i dettagli sono trapelati il 20 ottobre, prima della divulgazione programmata per il 22, e il rilascio è stato anticipato. Il problema riguarda ogni installazione PHP che risponde a richieste web. Non è un difetto di WordPress o dei suoi plugin: è nel linguaggio sottostante, quindi la correzione va applicata sul server, di solito dal vostro fornitore di hosting o dal vostro team IT.
Sul fatto che qualcuno stia già sfruttando la falla, le fonti non concordano però. Amazon ha individuato un tentativo di attacco già il 17 ottobre, mentre l’agenzia americana CISA, il 21, non ne aveva rilevati. Il consiglio è di non aspettare conferme, e il progetto PHP stesso precisa che non esistono mitigazioni complete: aggiornare è l’unica scelta sicura.
GitLab: aggiornato il 12 ottobre? Non basta
Qui il caso è quasi paradossale. GitLab ha corretto una falla con punteggio massimo di gravità il 12 ottobre, e nove giorni dopo ne ha corretta un’altra, altrettanto grave. Colpisce ogni versione del software dal 2014 e permette di eseguire codice su un server senza autenticarsi.
Il punto che sorprende molti: la prima correzione copriva solo le versioni più recenti, quindi chi aveva aggiornato allora risulta di nuovo vulnerabile. Secondo GitLab, non ci sono al momento prove di sfruttamento. Il rischio, comunque, riguarda le installazioni gestite in proprio, non il servizio ospitato da GitLab.
Node.js: il rischio nascosto nei container
Il 21 ottobre Node.js ha corretto dieci vulnerabilità su tutte le versioni supportate. La più seria riguarda Brotli, la libreria che gestisce la decompressione dei dati, e può diventare un problema quando un’applicazione elabora file o dati provenienti dall’esterno.
E c’è un dettaglio che spesso sfugge: le applicazioni impacchettate in container costruiti prima del 21 ottobre restano esposte. Aggiornare il server non basta, vanno ricostruite anche le immagini.
Perché riguarda anche voi, non solo l’IT
Questa non è una questione da lasciare in fondo alla lista dei compiti tecnici. Tre domande che dovreste porvi, e porre al vostro team:
- Sapete quali di questi software sono in uso in azienda, anche dentro strumenti che non gestite direttamente? PHP vive dietro il vostro sito, GitLab magari su un server dimenticato, Node.js dentro un’app sviluppata da un fornitore.
- Chi è responsabile degli aggiornamenti, e in quanto tempo vengono applicati? Tra l’annuncio di una falla e i primi tentativi di sfruttamento passano ormai ore, non settimane.
- Come dimostrate, a clienti e auditor, che le vulnerabilità vengono gestite? È una delle minacce da presidiare ogni giorno, e per le aziende nel perimetro della NIS2 la gestione delle vulnerabilità rientra tra le misure richieste.
Cosa fare subito
- Fate un inventario. Non si aggiorna ciò che non si sa di avere. Chiedete al vostro IT e ai fornitori quali versioni di PHP, GitLab e Node.js sono in uso.
- Partite da ciò che è visibile da Internet. Siti, portali e servizi raggiungibili dall’esterno hanno la precedenza.
- Aggiornate anche se l’avevate già fatto. Vale soprattutto per GitLab.
- Controllate che nessuno sia già entrato. Con tentativi di attacco precedenti alla patch, aggiornare non garantisce che l’intrusione non sia già avvenuta. Una verifica dei log e dei sistemi è il passo successivo.
- Pianificate l’uscita dalle versioni non più supportate. PHP 8.2, ad esempio, non riceverà più correzioni di sicurezza dopo il 31 dicembre 2026.
Da girare al vostro IT: le versioni corrette
- PHP: 8.5.12, 8.4.27, 8.3.36, 8.2.35 (CVE-2026-109618 e CVE-2026-109619)
- GitLab CE/EE: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 (CVE-2026-110264)
- Node.js: 22.23.4, 24.22.1, 26.12.1 (tra le altre, CVE-2026-111497)
Tre tecnologie diverse e un messaggio unico: la velocità fa la differenza. Le aziende che reggono meglio questi momenti non sono quelle con il budget più alto, ma quelle che hanno un inventario aggiornato, priorità chiare e un processo di patch management che funziona anche il venerdì sera.
Se volete capire quanto la vostra infrastruttura sia davvero esposta a vulnerabilità come queste, il nostro team è a disposizione per una valutazione mirata.
Le domande più frequenti
Cos’è PHP2Shell e chi riguarda?
È il nome dato a due vulnerabilità critiche del linguaggio PHP, corrette il 21 ottobre 2026, che possono consentire a un aggressore di eseguire codice su un server senza autenticarsi. Riguarda qualsiasi sito o applicazione che usi PHP su un server non ancora aggiornato.
Se ho aggiornato GitLab il 12 ottobre sono al sicuro?
No. Il 21 ottobre GitLab ha corretto una seconda falla critica, non coperta dalla correzione precedente. Serve aggiornare di nuovo alla versione indicata nell’avviso.
Un sito WordPress è a rischio?
Sì, se il server su cui gira usa una versione di PHP non aggiornata, indipendentemente dal fatto che WordPress e i plugin siano aggiornati. Conviene chiedere conferma scritta al proprio fornitore di hosting.