Una settimana dura per chi difende: PwnEscape, eMudhra, SafePay e la patch PHP

Aggiornamento, 21 ottobre, 16:30 ora di Parigi: PHP ha rilasciato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 verso le 15:35 ora di Parigi, leggermente in anticipo rispetto alle 14:00 UTC annunciate, correggendo entrambe le falle critiche, più backport a livello di sorgente per la 7.4, la 8.0 e la 8.1. La sezione PHP qui sotto è stata aggiornata.

Se lavorate nella sicurezza, nell’amministrazione di sistemi o nell’hosting, i sette giorni che si chiudono oggi sono stati di quelli che gli addetti ai lavori descrivono in modo piatto, con un intervallo di date, perché gli aggettivi sembrano poco professionali. Una fuga critica da macchina virtuale Linux giovedì. Un’autorità di certificazione le cui chiavi private si sono rivelate recuperabili da chiunque avesse un portatile, nel fine settimana. Un avviso governativo congiunto martedì su un ransomware che riporta alle impostazioni di fabbrica i dispositivi di backup, più un’interruzione cloud che ha bloccato il funzionamento delle carte bancarie, più l’annuncio del progetto PHP che due correzioni critiche sarebbero arrivate il giorno dopo. Quel giorno dopo è oggi. Le correzioni erano annunciate per le 14:00 UTC e sono arrivate con leggero anticipo, verso le 15:35 ora di Parigi.

Una precisazione conta più di qualsiasi singolo titolo. Potreste aver letto che «molti provider di hosting sono stati violati» tramite la fuga da VM, soprannominata PwnEscape. Alle 13:30 ora di Parigi del 21 ottobre, questo è temuto, non confermato. Nessuno sfruttamento in circolazione è stato segnalato da nessuna parte. Il timore ha una base razionale, che spiegheremo, ma va etichettato come timore. Il resto di questo articolo ripercorre la settimana in ordine, separa ciò che è confermato da ciò che è previsto e si chiude con la breve lista di cose che un lettore comune o il proprietario di un piccolo sito dovrebbe davvero fare.

Perché i team di sicurezza sono così logorati?

Partiamo dalle persone, perché ogni evento di questa settimana è finito sulle stesse scrivanie. Lo ISC2 2025 Cybersecurity Workforce Study, pubblicato a dicembre 2025 sulla base di rilevazioni condotte a luglio e agosto 2025 con 16.029 rispondenti, ha rilevato che il 48% dei professionisti della sicurezza si sente esausto nel tentativo di restare aggiornato su minacce e tecnologie, il 47% si sente spesso sopraffatto dal carico di lavoro e il 32% si sente oberato a causa della carenza di personale. Il denaro non addolcisce molto il quadro: il 20% non ha ricevuto alcun aumento di stipendio nell'ultimo anno, e una retribuzione insufficiente è stata una fonte frequente di insoddisfazione per il 31%.

Il dato più tagliente riguarda la leadership. Solo il 32% dei rispondenti afferma che la propria organizzazione tratta la cybersicurezza come una funzione aziendale critica, e il 23% indica questa lacuna come causa di insoddisfazione. Il lavoro di sicurezza è strutturalmente invisibile: un trimestre tranquillo, visto dal consiglio di amministrazione, sembra esattamente una spesa inutile, e la persona che ha prevenuto dieci incidenti siede in bilancio accanto alla persona che ha chiuso dieci vendite. Lo stesso studio ISC2 ha rilevato che il 36% delle organizzazioni ha tagliato i budget di sicurezza nel 2025 e il 24% ha riportato licenziamenti nella sicurezza, mentre il 72% dei professionisti concorda che tagliare il personale di sicurezza aumenta in modo significativo il rischio di violazioni.

I dati europei non sono più benevoli. Nello State of Cybersecurity 2026 di ISACA (rilevazione maggio 2026; 494 rispondenti europei su 1.888 a livello globale), il 72% ha detto che il lavoro è più stressante rispetto a cinque anni fa, con l'ambiente di minacce complesso (72%) e le aspettative irrealistiche unite a un carico di lavoro eccessivo (57%) come cause principali. Più della metà delle organizzazioni europee si è detta a corto di personale (56%) e di fondi (55%), e il 21% delle aziende non intraprende alcuna azione contro il burnout. Tenete a mente questi numeri mentre la settimana si dipana.

Cos'è PwnEscape, e i provider di hosting sono stati davvero violati tramite questa falla?

Giovedì 15 ottobre il progetto del kernel Linux ha pubblicato la CVE-2026-99999, presto soprannominata PwnEscape: una falla nella gestione dei checksum IPv4 del kernel, valutata 9,3 Critical dal CNA del kernel (Red Hat la valuta Important). Lo scenario: una micro-VM malevola invia metadati di checksum virtio-net appositamente costruiti all'interfaccia TAP dell'host. Una fuga da guest a host è il momento in cui una macchina virtuale in affitto smette di essere un inquilino e diventa il padrone di casa: il codice dentro la VM di un cliente ottiene influenza sul server fisico che fa girare quelle di tutti gli altri. Ecco perché un 9,3 sugli host di tipo KVM ha fatto correre al caffè il personale degli hosting.

Ecco cosa è effettivamente accertato. La falla è stata trovata dai ricercatori di pwn.ai durante la Sandbox challenge di Vercel, segnalata al kernel il 4 settembre e corretta nella mainline il 14 ottobre, con sette rami stable aggiornati. La fuga di memoria dell'host è stata dimostrata contro le sandbox di produzione dell'host della challenge, come conferma il resoconto della challenge pubblicato da Vercel stessa; lo stesso articolo afferma che nessuna segnalazione ha mostrato accessi a dati dei clienti in Vercel Sandbox. I crash dell'host e il root sull'host sono stati dimostrati solo sulle macchine dei ricercatori, e pwn.ai afferma che il proprio lavoro non è una rivendicazione di esecuzione di comandi root nell'ambiente di produzione di alcun fornitore. Il pattern di codice vulnerabile risale all'incirca al 2008, secondo l'analisi di TuxCare.

E lo sfruttamento? L'arricchimento del record CVE da parte di CISA lo dice senza giri di parole: Exploitation: none. Al feed del 20 ottobre, la falla non figura nel catalogo delle Known Exploited Vulnerabilities di CISA. Nessun attacco confermato in circolazione è stato segnalato da alcuna delle testate che seguono la vicenda. I ricercatori citati da CSO e heise si aspettano exploit funzionanti contro le configurazioni più deboli entro qualche settimana, il che è una previsione, non un'osservazione.

Allora perché il timore? Tre ragioni, tutte legittime. Primo, non esistono indicatori di compromissione pubblicati per questa falla, nessun hash malevolo o infrastruttura di attacco da cercare; SOC Prime osserva che il rilevamento dipende dalla telemetria dell'host, dal monitoraggio della virtualizzazione e dall'analisi dei crash, dati che molti hosting più piccoli semplicemente non raccolgono. Questo rende difficile il rilevamento. Non rende la falla priva di tracce: nessuna fonte da noi trovata afferma che lo sfruttamento non lasci tracce. Secondo, la correzione richiede l'applicazione della patch e il riavvio del kernel dell'host; aggiornare la propria VM non serve a nulla, quindi ogni provider interessato deve affrontare una campagna di riavvii su tutta la propria flotta. Terzo, l'incertezza sta già producendo danni commerciali: un provider di hosting giapponese ha congelato le nuove iscrizioni su VPS, hosting condiviso e dedicato il 16 ottobre per precauzione, senza alcuna violazione segnalata, e un hosting tedesco sta riavviando i propri server di virtualizzazione dal fine settimana. Per i clienti vale il consiglio di heise: non dovete fare nulla, se non verificare che la vostra VM sia tornata operativa dopo il riavvio del vostro provider.

Cosa è successo con i certificati eMudhra?

Sabato è arrivata la storia dei certificati, e ha cominciato a circolare la parola «dirottati». La realtà, documentata nella segnalazione di bug di Mozilla, è diversa e per certi versi più strana: otto certificati CA intermedi appartenenti a eMudhra, un'autorità di certificazione indiana, avevano chiavi private P-384 così deboli da risultare banalmente recuperabili. Il personale stesso di Mozilla ha recuperato le chiavi entro poche ore dalla segnalazione del 17 ottobre. eMudhra attribuisce la debolezza a uno script di generazione delle chiavi difettoso usato in una cerimonia delle chiavi dell'aprile 2025, citando errori umani in più passaggi.

Quello che è seguito è stato l'ecosistema della fiducia al lavoro a tutta velocità. Secondo BleepingComputer, Firefox ha distribuito un blocco OneCRL il 17 ottobre, con gli aggiornamenti Firefox 158.0.1 ed ESR arrivati il 20 ottobre per gli utenti le cui configurazioni avevano bloccato l'aggiornamento precedente; Chrome ha bloccato i sei intermedi abilitati al TLS sempre il 17 ottobre, e Apple ha seguito il 19 ottobre; eMudhra ha revocato tutti e otto i certificati il 18 ottobre. Mozilla ha poi annunciato la rimozione d'emergenza della fiducia nella root madre emSign ECC Root CA - G3, con Chrome che si è impegnata su un percorso simile; eMudhra stima che circa 30.000 certificati dovranno essere migrati, secondo il suo stesso commento nella segnalazione di bug di Mozilla.

Due avvertenze oneste tagliano in direzioni opposte. Rassicurante: non ci sono prove che le chiavi deboli siano mai state usate in modo improprio, ed eMudhra afferma che nessun certificato end-entity è stato emesso dalle serie interessate. Meno rassicurante: una delle chiavi private è stata pubblicata su GitHub da un ricercatore, e il software che porta con sé un proprio archivio di fiducia o salta i controlli di revoca (il tracker dell'incidente di Mozilla, come riportato da BleepingComputer, cita come esempio il curl integrato in macOS) potrebbe continuare a fidarsi dei certificati finché non verrà aggiornato. Per un lettore, l'intera azione da compiere sta in una riga: aggiornate browser e sistema operativo. I problemi dei certificati sono esattamente la categoria in cui una VPN non cambia nulla, anche se vale la pena ricordare che i certificati contraffatti o erroneamente considerati affidabili contano soprattutto per un attaccante in grado di intercettare già il vostro traffico, ed è uno dei motivi per cui cifrare la connessione sul Wi-Fi pubblico (in inglese) resta una sana abitudine.

Perché il rilascio PHP di oggi contava così tanto?

Martedì pomeriggio il progetto PHP ha pubblicato un avviso insolito su php.net: un rilascio di sicurezza programmato per mercoledì 21 ottobre alle 14:00 UTC, che corregge due vulnerabilità critiche, con i dettagli completi da pubblicare insieme al rilascio. Preannunciare una correzione critica è un compromesso deliberato: dà ai difensori un giorno per programmare le finestre di manutenzione, al costo di dire agli attaccanti che sta arrivando qualcosa di prezioso. Il rilascio è poi arrivato con leggero anticipo: gli avvisi su GitHub recano l'orario delle 13:34 UTC, le 15:34 a Parigi, e l'annuncio di PHP, intitolato «Vulnerabilità critiche di esecuzione di codice remoto, aggiornate subito», indica come versioni corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Correggono le CVE-2026-109618 e CVE-2026-109619, «due vulnerabilità critiche che possono consentire l'esecuzione di codice remoto non autenticata», entrambe valutate CVSS v4.0 9,2.

Le due falle sono semplici da enunciare. La CVE-2026-109618, «RCE tramite corruzione OOM»: la gestione dell'esaurimento di memoria può interrompere PHP mentre i dati interni della richiesta sono inizializzati solo in parte, e la pulizia della richiesta può poi trattare i dati non validi come validi. La CVE-2026-109619, «RCE tramite stato globale stantio»: lo stato interno di una richiesta può sopravvivere dopo che la sua memoria è stata liberata, e una richiesta successiva gestita dallo stesso worker può usarlo, un use after free. Chi è a rischio, secondo PHP: «tutte le installazioni PHP che servono richieste web, inclusi PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed». Il rischio è massimo per mod_php, «con un exploit dimostrato in cui una richiesta non autenticata può innescare l'attacco prima che venga eseguito qualsiasi codice applicativo». Un exploit dimostrato non equivale a uno sfruttamento in circolazione; l'avviso di PHP non segnala attacchi in circolazione.

L'embargo era comunque trapelato. I resoconti delle aziende di sicurezza, tra cui quello di SecureLayer7, tracciavano le falle come CVE-2026-109618 e CVE-2026-109619 e riferivano che un proof of concept soprannominato «PHP2Shell» era emerso prima del rilascio; il progetto PHP non lo ha verificato, anche se SecureLayer7 riferisce che almeno un'azienda di sicurezza dice di aver riprodotto una delle falle. Gli avvisi di PHP del 21 ottobre non segnalano alcuno sfruttamento in circolazione.

Poi c'è chi usa un ramo vecchio. «PHP 8.1 e precedenti non ricevono più aggiornamenti dal progetto PHP», osserva l'annuncio, anche se alcune distribuzioni e fornitori LTS forniscono correzioni retroportate. «Vista la gravità», il team di sicurezza di PHP ha pubblicato anche backport minimi a livello di sorgente per PHP 7.4, 8.0 e 8.1, pensati per chi compila dai sorgenti o non ha un fornitore LTS; sono patch da applicare, non rilasci pronti all'uso. Il progetto non ha pubblicato backport per PHP 7.3 o precedenti, incluso PHP 5. Le distribuzioni Linux e i fornitori LTS hanno ricevuto le patch in anticipo, e la stessa PHP 8.2 raggiunge la fine vita il 31 dicembre 2026. L'avviso di PHP elenca misure provvisorie per chi non può aggiornare subito, come impostare memory_limit a -1, abbassare post_max_size o disattivare il session upload progress, ma dice che «riducono l'esposizione a percorsi di attacco specifici ma non rendono sicura un'installazione»; secondo le note di rilascio, «aggiornare è l'unica scelta sicura».

La scala è il punto. Secondo W3Techs, PHP gira sul 69,3% dei siti web con un linguaggio lato server noto, e tra questi siti PHP il 27,0% usa ancora la versione 7 e il 7,7% la versione 5, rami arrivati a fine vita anni fa. I siti sulla versione 7 includono PHP 7.4, che ora ha almeno un backport a livello di sorgente; i siti su PHP 5, e su PHP dalla 7.0 alla 7.3, non ricevono alcun backport dal progetto. L'avviso 2026-018 di CERT-EU avvertiva che le vulnerabilità potrebbero riguardare tutte le versioni di PHP a partire da PHP 5; quell'avvertimento resta tale, mentre gli avvisi su GitHub elencano come interessati solo i rami supportati, al di sotto di 8.2.35, 8.3.36, 8.4.27 e 8.5.12, e non enumerano le versioni a fine vita. Per i sysadmin della prima sezione, questo è il lavoro di stasera e il progetto di migrazione del prossimo trimestre, annunciato lo stesso martedì di tutto il resto.

Cos'altro è arrivato sulle scrivanie dei difensori questa settimana?

Lunedì e martedì hanno continuato ad aggiungere. L'avviso congiunto AA26-293A di CISA e FBI (20 ottobre) descrive nel dettaglio SafePay, un'operazione ransomware che ha colpito almeno 600 organizzazioni da agosto 2024. Per impedire alle vittime di recuperare i dati, dice l'avviso, SafePay arresta il servizio Volume Shadow Copy e riporta alle impostazioni di fabbrica i dispositivi di archiviazione di backup collegati in rete, in alcuni casi cancellando tutti i backup collegati in rete. Il consiglio centrale dell'avviso è vecchia saggezza con nuova urgenza: i backup devono essere offline, immutabili e davvero testati, perché le copie raggiungibili via rete sono esattamente ciò che questa banda distrugge.

Anche il catalogo delle Known Exploited Vulnerabilities di CISA ha avuto una settimana pesante: il 20 ottobre sono state aggiunte quattro falle di Plex Media Server concatenabili tra loro, un fatto rilevante perché Plex è la rara voce del KEV che abita nei salotti anziché nei data center. A inizio settimana erano arrivati BeyondTrust Remote Support e Fortinet (16 ottobre), Atlassian Data Center (15 ottobre), e Palo Alto PAN-OS, Cisco Secure Email Gateway e Ahsay (14 ottobre). Ogni voce ha prove di sfruttamento in circolazione.

Altri due elementi hanno incorniciato la settimana. Un'esclusiva Reuters del 19 ottobre ha descritto un singolo hacker che ha usato agenti IA autonomi per tentare intrusioni su oltre 1.200 siti e violare i siti di oltre 100 aziende, a un costo di circa 50 dollari per intrusione, secondo un ricercatore di NorForge; Reuters non è riuscita ad accertare quali dati siano stati sottratti. Qualunque sia il bilancio finale, la storia sta nell'economia: se una violazione costa circa 50 dollari, i tagli di budget nei dati ISC2 appaiono ancora più difficili da giustificare. E martedì un'interruzione di Google Cloud nella sua regione di Londra ha coinciso con il rifiuto delle carte Revolut in tutta Europa; Revolut stessa ha confermato la causa la sera del 20 ottobre, annunciando alle 19:39 ora di Parigi che il problema era stato risolto e i servizi ripristinati e indicando come causa un'interruzione di Google Cloud, Google attribuisce la propria interruzione a un evento di alimentazione in una zona della sua regione di Londra, e nulla la collega a PwnEscape. Ne abbiamo parlato separatamente nel nostro approfondimento sull'interruzione di Revolut.

Come appare l'intera settimana messa a confronto?

Cosa dovreste fare davvero questa settimana?

Per la maggior parte dei lettori, la risposta onesta è breve. Aggiornate browser e sistema operativo, il che risolve silenziosamente la storia dei certificati. Se usate Plex Media Server a casa, aggiornatelo oggi; quelle falle vengono sfruttate, non solo teorizzate. E aspettatevi phishing che prende in prestito i titoli di questa settimana, del tipo «il tuo account è stato esposto nella violazione PHP»; un filtro DNS che blocca i domini di phishing noti prima che si carichino, come Threat Protection di Le VPN, aiuta in questo, e se una mail sostiene che la vostra email è finita in una violazione, verificatela voi stessi rispetto alle violazioni note invece di cliccare sul link. Il nostro hub sulla sicurezza online (in inglese) copre il resto delle basi.

Se possedete un sito web: scoprite stasera quale ramo PHP usate. Sulle versioni dalla 8.2 alla 8.5, l'aggiornamento è uscito: applicate subito la 8.2.35, la 8.3.36, la 8.4.27 o la 8.5.12, oppure chiedete al vostro host se è stato applicato, dato che le distribuzioni Linux e i fornitori LTS hanno ricevuto le patch in anticipo. Sulla 7.4, la 8.0 o la 8.1, le opzioni sono i backport minimi a livello di sorgente del team di sicurezza di PHP o la correzione retroportata di un fornitore. Sulla 7.3 o precedenti, incluso PHP 5, trattate questo evento come la spinta decisiva per l'aggiornamento che state rimandando, e nel frattempo considerate il suggerimento di CERT-EU di isolare tutto ciò che è esposto a internet e non può ricevere patch. Se il vostro sito vive su un VPS, è legittimo porre al vostro provider due domande: i kernel degli host sono stati aggiornati per la CVE-2026-99999, e quando è prevista la finestra di riavvio. E verificate che i vostri backup esistano in un luogo che il ransomware non può raggiungere: SafePay riporta alle impostazioni di fabbrica o cancella i backup collegati in rete proprio perché le vittime ci fanno affidamento.

Se gestite persone che fanno questo lavoro, i numeri delle indagini all'inizio di questo articolo non sono una curiosità da risorse umane; sono un indicatore di rischio. Il Voice of the CISO 2026 di Proofpoint ha rilevato che il 77% dei CISO afferma che su di loro gravano aspettative eccessive, e la ricerca IANS/Artico sul coinvolgimento dei consigli di amministrazione ha rilevato che solo il 29% dei consiglieri giudica molto efficaci gli aggiornamenti sulla sicurezza informatica che riceve. Un team che ha passato questa settimana ad applicare patch agli host, ruotare certificati e leggere fughe di embargo a mezzanotte lo rifarà il mese prossimo. Se lo farà bene, o mentre aggiorna il curriculum, dipende in parte da una voce di bilancio.

Un altro paragrafo onesto. Una VPN non avrebbe impedito un solo evento di questa lista. Non applica patch ai server, non corregge i bug del kernel o di PHP sui siti che visitate, non ferma le interruzioni cloud e non sostituisce gli aggiornamenti del browser che hanno bloccato i certificati compromessi. Quello che fa è più circoscritto e comunque utile: cifra il traffico tra il vostro dispositivo e il server VPN, così che qualcuno sullo stesso Wi-Fi del bar non possa intercettare ciò che inviate. Sapere con precisione cosa fa uno strumento, e dirlo, ci è sembrato il modo giusto di chiudere una settimana alimentata dalla paura del non confermato.

Le correzioni sono arrivate questo pomeriggio, ora di Parigi. Da qualche parte, un amministratore stanco ha un terminale aperto e una finestra di manutenzione prenotata, e giovedì nessuno al di fuori del team ricorderà che è successo. Ecco che aspetto ha la sicurezza quando funziona: niente di visibile, assolutamente.