PHP e Node.js: le vulnerabilità di ottobre 2026

Il 21 ottobre 2026 abbiamo controllato centinaia di servizi tra container, ambienti Node.js e applicazioni PHP, aggiornando in giornata tutti quelli esposti. Poi abbiamo verificato i processi realmente in esecuzione, fatto passare migliaia di test automatici su copie isolate degli ambienti applicativi e monitorato gli endpoint in produzione fino a ottenere solo risposte HTTP corrette. La parte impegnativa è stata mantenere funzionanti applicazioni, database, generazione delle fatture e personalizzazioni mentre sostituivamo i runtime.

A far partire il lavoro sono stati due annunci distinti, pubblicati lo stesso giorno: vulnerabilità critiche in PHP e aggiornamenti di sicurezza ad alta gravità per Node.js. Riguardano il software che esegue le applicazioni. Per un'azienda, questo significa che il problema può trovarsi sotto il sito o il gestionale, anche quando il codice scritto per il progetto non è cambiato.

Questa è la situazione verificata al 21 ottobre 2026. Le versioni indicate sono quelle corrette per questi bollettini; per un aggiornamento eseguito più avanti vanno controllate anche le release di sicurezza successive.

Le vulnerabilità PHP: CVE-2026-109618 e CVE-2026-109619

Il bollettino ufficiale PHP descrive due falle che possono consentire l'esecuzione remota di codice senza autenticazione. RCE, in pratica, significa che un attaccante può arrivare a eseguire codice sul sistema attraverso una vulnerabilità raggiungibile da remoto. Il fatto che un sito abbia un login non elimina un problema che può verificarsi prima che l'applicazione controlli le credenziali.

La CVE-2026-109618 riguarda la gestione dell'esaurimento della memoria: alcuni dati interni della richiesta possono rimanere inizializzati solo in parte ed essere poi trattati come validi durante la pulizia. Il caso dimostrato su Apache con mod_php può attivarsi prima dell'esecuzione del codice applicativo. L'analisi ufficiale considera suscettibile anche PHP-FPM, con differenze nei percorsi di attacco e senza una dimostrazione completa dell'exploit FPM per questa specifica falla.

La CVE-2026-109619 riguarda invece stato interno che un processo può conservare dopo la liberazione della memoria della richiesta precedente. Una richiesta successiva può accedere a quei riferimenti ormai invalidi. Le condizioni dipendono dal comportamento del worker e dalle operazioni raggiungibili: descrivere ogni installazione come già compromessa sarebbe scorretto, ma anche considerarla al sicuro senza la correzione.

Per chi gestisce un sito, la conseguenza pratica è chiara: aggiornare il CMS o i suoi plugin può essere necessario, ma la correzione di queste falle richiede anche un runtime PHP aggiornato. Il problema può riguardare un gestionale su misura quanto un sito WordPress.

Quali versioni PHP e Node.js contengono le correzioni

Le release upstream indicate dai progetti per i bollettini del 21 ottobre sono queste:

Runtime	Ramo	Release corretta
PHP	8.2	8.2.35
PHP	8.3	8.3.36
PHP	8.4	8.4.27
PHP	8.5	8.5.12
Node.js	22	22.23.4
Node.js	24	24.22.1
Node.js	26	26.12.1

La tabella riassume le release PHP e il bollettino Node.js. Non suggerisce di saltare alla versione principale più alta su ogni applicazione: prima bisogna verificare compatibilità, dipendenze ed estensioni native.

C'è anche un dettaglio che cambia la diagnosi: il numero upstream non basta per giudicare un pacchetto Linux. Una distribuzione può applicare la correzione mantenendo una versione di base apparentemente vecchia. Per PHP 8.3 su Ubuntu 24.04, per esempio, le schede ufficiali di CVE-2026-109618 e CVE-2026-109619 indicano il pacchetto corretto 8.3.6-0ubuntu0.24.04.13. Bisogna leggere la revisione completa e il bollettino del fornitore. Lo stesso principio richiede attenzione per i rami fuori supporto: serve una correzione documentata dal proprio fornitore oppure una migrazione a un ramo mantenuto.

Node.js, Brotli e il rischio dietro la compressione

Il bollettino Node.js di ottobre include CVE-2026-111497, un difetto nel decoder Brotli classificato ad alta gravità che può consentire esecuzione remota di codice. Brotli è un formato di compressione utilizzato anche nel traffico web. L'esposizione concreta dipende dai percorsi con cui l'applicazione elabora dati compressi controllabili da un attaccante; avere Node.js installato, da solo, non dimostra che un exploit sia raggiungibile.

Nello stesso rilascio ci sono correzioni riguardanti DNS, verifica dei certificati TLS e altre componenti. Per questo abbiamo aggiornato i runtime interessati e verificato anche compressione, inizializzazione TLS e crittografia. Un test che comprime e decomprime correttamente dei dati controlla la compatibilità del nuovo ambiente; la prova dell'inclusione della patch viene invece dalla versione corretta e dalla provenienza verificata del software.

Per le applicazioni ancora su Node.js 20 abbiamo preparato una migrazione a un ramo mantenuto. Le estensioni native meritano una prova separata: un modulo SQLite compilato per un runtime precedente può richiedere una ricompilazione quando si cambia versione principale.

Perché aggiornare il server non aggiorna automaticamente Docker e PM2

Su un'infrastruttura reale possono convivere il PHP del sistema, quello dentro un container Apache e quello di un'applicazione PHP-FPM. Correggerne uno lascia gli altri al loro posto. Anche la versione restituita da un comando nel terminale va confrontata con quella del processo che sta servendo le richieste.

Con Docker abbiamo controllato le immagini realmente attive, preparato i sostituti e mantenuto i volumi dei dati. Un tag chiamato latest non certifica l'inclusione di una patch, e una ricostruzione futura può annullare il lavoro se il Dockerfile o la procedura di distribuzione continuano a selezionare una base vecchia. Durante questo intervento abbiamo anche verificato i pacchetti del fornitore e, dove necessario, preparato runtime da sorgenti ufficiali con checksum controllati.

Con PM2, cambiare il Node predefinito della shell non sostituisce un eseguibile già caricato in memoria. Abbiamo verificato il demone, i processi figli e la supervisione systemd. Durante il lavoro sono serviti anche ripristini e correzioni della procedura: la possibilità di tornare a una configurazione funzionante faceva parte della preparazione.

Aggiornare PHP e Node.js senza perdere personalizzazioni e dati

Prima del cambio abbiamo conservato le immagini precedenti e preparato copie dei database e dei volumi utili alle prove. Sul sistema di monitoraggio abbiamo confrontato migliaia di file PHP e MIB con lo snapshot originale, usando gli stessi mount in sola lettura. Sul servizio di fatturazione abbiamo provato nel clone accesso, lettura di clienti e fatture, download di un PDF esistente e generazione di un documento di prova. Sulla produzione abbiamo poi ricontrollato stato del servizio e risposte HTTP.

Le suite di test dei gestionali hanno completato migliaia di test senza fallimenti. Il riavvio controllato finale di quei servizi e il passaggio definitivo del servizio di fatturazione sono avvenuti senza interruzioni: il monitor sugli endpoint in produzione ha continuato a ricevere risposte corrette. Nel lavoro complessivo ci sono stati anche tentativi e rollback, preparati proprio per non toccare gli utenti finali.

Un healthcheck verde dice che un controllo specifico funziona. Per sapere se un'applicazione resta utilizzabile servono anche prove sulle funzioni che contano: accessi, database, documenti, code di lavoro e integrazioni. È una parte concreta della gestione dell'hosting in Svizzera, da organizzare prima che arrivi il prossimo bollettino urgente.

Le domande da fare a chi gestisce il tuo sito

Un sito protetto da VPN deve essere aggiornato?

Sì. La VPN riduce chi può raggiungere un servizio attraverso gli accessi che protegge; la correzione elimina il difetto nel runtime. Sono misure con funzioni diverse. La presenza della VPN aiuta a valutare l'esposizione e l'ordine degli interventi, ma non sostituisce una patch.

Basta aggiornare WordPress, Laravel o il framework JavaScript?

Per queste vulnerabilità bisogna verificare anche PHP o Node.js. Chiedi al fornitore quale versione sta eseguendo le richieste, quale revisione del pacchetto include la correzione e quali controlli sono stati completati dopo il riavvio. Un'applicazione può continuare a usare il runtime dentro la propria immagine Docker anche dopo l'aggiornamento del sistema operativo.

Si può garantire sicurezza al 100% dopo l'aggiornamento?

Possiamo documentare le correzioni installate, i test passati e i controlli effettuati. Questo non certifica l'assenza di qualsiasi altra vulnerabilità o di una compromissione precedente. Durante le verifiche abbiamo, per esempio, registrato separatamente un avviso non fatale di una dipendenza applicativa già presente prima del cambio PHP. Tenere distinti patch di sicurezza, compatibilità e anomalie preesistenti aiuta a prendere decisioni sensate.

Possiamo fare questo controllo anche per la tua azienda

In Webcracy possiamo verificare quali versioni di PHP e Node.js stanno eseguendo il tuo sito o gestionale, controllare se le correzioni sono presenti e individuare i servizi da aggiornare prima. Ti consegniamo un quadro di ciò che abbiamo verificato, degli interventi necessari e delle questioni ancora aperte.

Possiamo occuparci anche degli aggiornamenti: preparare i backup, provare le modifiche su copie dei dati e controllare le funzioni che usi ogni giorno. Prima concordiamo tempi e modalità dell'intervento; dopo documentiamo le modifiche e i test eseguiti.

Raccontaci cosa utilizzi e chi gestisce oggi l'hosting: partiamo da lì, anche coinvolgendo il tuo fornitore attuale.

Parliamo del tuo sito o gestionale↗

Foto illustrativa: Taylor Vick su Unsplash, utilizzata secondo la licenza Unsplash. Il data center ritratto non è quello dell'intervento.