72 ore di vulnerabilità: cosa aggiornare, cosa ruotare e quali certificati cambiare

Tra lunedì 19 e giovedì 22 ottobre 2026 sono usciti otto incidenti che riguardano infrastruttura molto diffusa: due falle critiche in PHP, una release di sicurezza di Node.js con dieci CVE, una RCE senza autenticazione in GitLab con CVSS 10.0, una violazione delle variabili d’ambiente di Railway, una versione malevola di LiteLLM su PyPI e Docker Hub, l’avviso di PingCAP su TiDB Cloud, la revoca di 404.607 certificati GoDaddy e la sfiducia in otto CA intermedie di eMudhra.

Come titoli sono otto notizie. Per chi gestisce i server sono tre lavori: aggiornare, ruotare i segreti e controllare i certificati. Questo post li ordina così, con le versioni corrette e i comandi per verificare.

Riepilogo: chi deve fare cosa

1. Aggiornare runtime e server

PHP: php2shell

Il 20 ottobre un post su Hacker News ha diffuso gli identificativi di due falle critiche di PHP prima della fine dell’embargo, e il progetto ha anticipato la pubblicazione al 21 ottobre alle 14:00 UTC. CVE-2026-109618 è una corruzione di memoria quando PHP esaurisce la memoria a metà dell’elaborazione della richiesta; CVE-2026-109619 è un use-after-free tra richieste dello stesso worker. Entrambe si sfruttano senza autenticazione, colpiscono tutte le installazioni che servono PHP via web e sono peggiori con mod_php, dove secondo Rapid7 si sfruttano prima che giri il codice dell’applicazione. Wiz ha dimostrato una RCE contro WordPress, Drupal e Joomla. Le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35; se usi i pacchetti della tua distribuzione Linux, guarda l’avviso del fornitore, che in molti casi ha già corretto. Se oggi non puoi aggiornare, la mitigazione ufficiale temporanea è session.upload_progress.enabled=0 in php.ini o nel pool FPM (non funzionano ini_set né .user.ini) e il riavvio di tutti i worker. Se preferisci delegare l’aggiornamento: patch di sicurezza PHP.

Node.js: Brotli e hostname TLS

Il 21 ottobre Node.js ha pubblicato dieci CVE per le linee 26.x, 24.x e 22.x. Le quattro di gravità alta:

• CVE-2026-111497: scrittura fuori dai limiti nel decompressore Brotli, con possibile RCE. Express 5 e fetch() decomprimono Brotli in automatico, quindi basta che il tuo server riceva, o il tuo codice scarichi, una risposta compressa manipolata.
• CVE-2026-106069 e CVE-2026-105483: il controllo dell’hostname di un certificato TLS si può aggirare. Un client Node potrebbe accettare un certificato valido emesso per un altro dominio.
• CVE-2026-105482: dns.resolve tronca i nomi che contengono un carattere NUL.

Versioni corrette: v26.12.1, v24.22.1 e v22.23.4. Node 20 e 25 sono fuori supporto e non ricevono patch: se li usi ancora, la correzione passa per un aggiornamento di versione maggiore. Non è stato segnalato alcuno sfruttamento. Se sei ancora su 20 o 25 e preferisci non fare il salto da solo, vedi patch di sicurezza Node.js.

node --version
# in Docker conta l'immagine base:
docker run --rm la-tua-immagine node --version

NGINX: un anno impegnativo

Nel 2026 NGINX ha accumulato diverse serie di avvisi. A maggio è uscita CVE-2026-42945, “NGINX Rift”: la piattaforma di IA di DepthFirst l’ha trovata in circa sei ore, e il difetto risaliva alla versione 0.6.27, pubblicata nel 2008. nginx.org la classifica di gravità media; la Cloud Security Alliance e Help Net Security la considerano critica (9.2), e VulnCheck ha visto tentativi di sfruttamento dal 16 maggio. È stata corretta in 1.31.0 e 1.30.1.

La serie di ottobre aggiunge cinque CVE: CVE-2026-15176, 93479, 95101 (request smuggling su HTTP/3), 97629 (falsificazione di sessione TLS che salta la verifica del certificato client) e 97205. Sono corrette in 1.31.7+ e 1.30.6+. In attesa dell’aggiornamento, nginx.org suggerisce di evitare $request_filename e alias (15176) e di usare catture con nome al posto di quelle senza nome nei blocchi location con regex (93479). L’aggiornamento e la revisione di quella configurazione sono in patch di sicurezza NGINX.

nginx -v

GitLab self-managed: CVSS 10.0

Il 21 ottobre GitLab ha pubblicato CVE-2026-110264: un overflow di intero durante la compilazione di un’espressione regolare manipolata permette a un utente non autenticato di eseguire codice sul server. Colpisce CE ed EE dalla versione 7.0, del 2014. GitLab.com e GitLab Dedicated sono già corretti; le installazioni proprie devono passare a 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 o 18.11.13, a seconda del ramo. Al 22 ottobre non risultano sfruttamenti.

Nove giorni prima, il 12 ottobre, GitLab aveva già corretto un altro 10.0 (CVE-2026-97229, sempre con espressioni regolari in CI/CD) in 19.2.8, 19.3.5 e 19.4.2, e per quello esiste un PoC pubblico. Se non l’hai applicato, le nuove versioni di quei rami includono anche quella correzione. Per farlo aggiornare a noi: aggiornare GitLab self-managed.

Perché emergono così tanti difetti vecchi

Due dei difetti di questa lista esistevano da più di dieci anni: quello di GitLab dal 2014 e NGINX Rift dal 2008. Per NGINX sappiamo come è stato trovato: uno strumento di IA ci ha messo circa sei ore. Il FIRST (Forum of Incident Response and Security Teams) prevede di chiudere il 2026 con circa 66.000 CVE e attribuisce parte dell’aumento a strumenti di IA che cercano falle da soli. La stessa fonte avverte che un’altra parte è contabilità (database che catalogano di più e registrano difetti vecchi) e che la quota di CVE effettivamente sfruttate resta stabile. Per un team piccolo significa che la lista di avvisi da leggere cresce più in fretta di quella delle urgenze, e che conviene avere un inventario delle versioni per capire in un minuto se un avviso ti riguarda.

2. Ruotare i segreti, in ordine

Tre incidenti della lista espongono credenziali invece di codice:

• Railway ha rilevato il 21 ottobre attività anomala nei sistemi che conservano le variabili d’ambiente dei clienti. Un terzo ha potuto accedere a variabili cifrate e in alcuni casi decifrarle. Railway ha sospeso tutti i deploy e chiede di ruotare le credenziali. Non ha comunicato quanti clienti siano coinvolti né come gli attaccanti siano entrati.
• LiteLLM 1.107.0, pubblicato il 21 ottobre su PyPI e Docker Hub, contiene un ladro di credenziali e un loader remoto che si attiva all’avvio di qualsiasi processo Python sull’host, non solo di LiteLLM. Gli attaccanti l’hanno pubblicato con token OAuth di GitHub CLI rubati a tre ingegneri. Il tag su GitHub non contiene il codice malevolo, che si trova solo nei pacchetti pubblicati. È la seconda volta quest’anno.
• PingCAP comunica che tra il 9 settembre e il 7 ottobre qualcuno ha usato credenziali rubate di un account di servizio per entrare nei sistemi interni e copiare dati e codice sorgente: metadati di account e progetti, testo dell’editor SQL, registri di fatturazione e valori cifrati di API key. Non ci sono prove di impatto sui dati salvati in TiDB. Il gruppo FulcrumSec dice di avere 10,6 TB; PingCAP non l’ha confermato.

L’ordine conta, perché ruotare una chiave su un host ancora compromesso consegna all’attaccante la chiave nuova.

1. Contenere. Con LiteLLM 1.107.0, ferma il servizio e ricostruisci l’host o il container da un’immagine pulita con la versione fissata a 1.106.2 (litellm==1.106.2 in requirements.txt, o il tag esatto dell’immagine, mai latest). Il loader parte con qualsiasi processo Python, quindi rimuovere solo il pacchetto non basta.
2. Fare l’inventario. Elenca cosa c’era su quell’host o in quelle variabili: chiavi dei fornitori di LLM, credenziali cloud, password del database, token di CI, webhook, chiavi del gateway di pagamento. Su Railway, l’elenco sono le variabili di ogni servizio e ambiente.
3. Partire da ciò che apre di più. Prima le credenziali con permessi ampi (IAM o account root del cloud, token CI/CD e GitHub, utenti del database), poi le API di terze parti.
4. Emettere, distribuire, revocare. Crea la credenziale nuova, distribuiscila e revoca quella vecchia. Con i deploy di Railway sospesi, revocare prima di poter aggiornare la variabile lascia il servizio fermo finché non ripartono; per chiavi di pagamento o del cloud, un fermo breve costa meno di una chiave trapelata ancora attiva.
5. Controllare l’uso della chiave vecchia. Rivedi i log di accesso del fornitore (CloudTrail, il pannello dell’API, i log del database) dal giorno dell’incidente.

Se i tuoi servizi tengono le credenziali in un secrets manager e non in variabili scritte a mano, il passo 4 si accorcia molto. È una delle cose che controlliamo nei progetti di cloud e DevOps e quando progettiamo API che dipendono da chiavi di terze parti. Se preferisci che la rotazione la facciamo noi, vedi rotazione dei segreti e API key esposte.

3. Certificati: GoDaddy ed eMudhra

GoDaddy ha revocato il 21 ottobre 404.607 certificati TLS delle gerarchie GoDaddy e Starfield perché gli OID di policy e l’URI del CPS di quei certificati non corrispondevano al CPS pubblicato (Mozilla Bug 2082703). Nessuno ha rubato chiavi; il problema è che un sito con uno di quei certificati può smettere di caricarsi se non installa il sostitutivo.

eMudhra, una CA indiana, ha generato nell’aprile 2025 otto certificati di CA intermedia TLS con chiavi deboli a causa di un difetto nella cerimonia di generazione delle chiavi, e quelle chiavi sono state ricavate dai certificati pubblici. Chrome li ha bloccati, Apple il 19 ottobre e Microsoft il 20; Go e Node.js hanno pubblicato una sfiducia esplicita (la release di Node del 21 ottobre rifiuta già quelle catene). Non ci sono attacchi confermati contro gli utenti.

Per sapere chi ha emesso il tuo certificato e quando scade:

echo | openssl s_client -connect iltuodominio.it:443 -servername iltuodominio.it 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -serial

• Se l’issuer contiene GoDaddy o Starfield, entra nel tuo account GoDaddy, controlla se per quel certificato è stato emesso un sostitutivo e installalo su tutti i server, bilanciatori e CDN dove c’è quello vecchio.
• Se il tuo sito dipende da una delle intermedie di eMudhra, Chrome, Safari e Windows non lo accettano più e devi chiedere un certificato a un’altra CA. Per vedere la catena completa, intermedie comprese, cerca eMudhra nelle righe i: (emittente) di questo output:

echo | openssl s_client -connect iltuodominio.it:443 -servername iltuodominio.it -showcerts 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:'

• Il caso che sfugge più spesso è quello in uscita: un tuo servizio in Node o Go che chiama un’API firmata da quelle intermedie comincerà a fallire con un errore TLS dopo l’aggiornamento. Se dopo la patch di Node compaiono errori di certificato nelle chiamate in uscita, controlla con lo stesso comando il dominio che stai chiamando.

Se preferisci non farlo da solo

In Soamee facciamo questo lavoro per i progetti che manteniamo: inventario delle versioni di PHP, Node, NGINX e GitLab; mitigazione immediata dove non si può ancora aggiornare; aggiornamento e verifica; controllo dei segni di compromissione; rotazione dei segreti nell’ordine sopra e sostituzione dei certificati. Nessuno può rendere un server inattaccabile, quindi non lo promettiamo. Quello che ti resta è un registro di che versione hai, cosa è stato cambiato e cosa resta da fare.

Se hai server o deploy e non sai se uno di questi otto avvisi ti riguarda, raccontacelo in una consulenza gratuita o scrivici dalla pagina contatto.

Fonti

• PHP: php.net · Rapid7 · Huntress · NCSC
• Node.js: October 2026 Security Releases
• NGINX: nginx security advisories · CSA Research Note su CVE-2026-42945 · Help Net Security, 18 maggio 2026
• GitLab: Critical Patch Release 19.5.1 · The Hacker News su CVE-2026-97229
• Railway: The CyberSec Guru
• LiteLLM: Wiz
• PingCAP: Security update, ottobre 2026
• GoDaddy: CyberPress
• eMudhra: The Hacker News
• Previsione CVE 2026: Help Net Security, 15 giugno 2026