Android zero-day sui Pixel e WSO2 sotto attacco: due exploit mostrano quanto si è accorciata la finestra di patch

🛡️ Executive Summary

• Google corregge CVE-2026-58704 sui Pixel e conferma indicazioni di sfruttamento limitato e mirato: serve la patch di sicurezza 2026-09-05.
• WSO2 CVE-2026-5430 permette di bypassare l’autenticazione JWT e può portare alla compromissione completa degli account amministrativi.
• watchTowr ha osservato token JWT falsificati con privilegi admin contro honeypot WSO2: la vulnerabilità pubblicata a maggio è ora sotto exploitation reale.

Due vulnerabilità completamente diverse mostrano la stessa evoluzione della superficie di attacco moderna: quando una falla diventa utilizzabile, la finestra tra disponibilità della correzione e sfruttamento reale può ridursi drasticamente. Google ha pubblicato l’aggiornamento Pixel di settembre correggendo CVE-2026-58704, vulnerabilità per la quale esistono indicazioni di sfruttamento limitato e mirato. Contemporaneamente, infrastrutture WSO2 API Manager vengono raggiunte da token JWT falsificati che sfruttano CVE-2026-5430, falla critica corretta mesi fa ma ancora presente su sistemi esposti. Non sono campagne collegate. Il punto comune è operativo: smartphone e API gateway occupano due estremi della rete, ma entrambi diventano bersagli immediati quando una vulnerabilità lascia agli attaccanti una strada sufficientemente affidabile.

Google conferma lo sfruttamento mirato di CVE-2026-58704 sui Pixel

Il bollettino Pixel pubblicato il 15 settembre 2026 contiene una frase che cambia completamente la priorità dell’aggiornamento: Google afferma che esistono indicazioni secondo cui CVE-2026-58704 potrebbe essere sottoposta a sfruttamento limitato e mirato. L’azienda non attribuisce pubblicamente gli attacchi, non descrive la catena utilizzata e non indica quante vittime siano state individuate. La formulazione scelta suggerisce quindi un’attività circoscritta e non uno sfruttamento indiscriminato contro l’intera base Android. Google distribuisce la correzione a tutti i Pixel supportati attraverso il livello patch 2026-09-05 e invita gli utenti ad accettare l’aggiornamento. La distinzione tra il Pixel Update Bulletin e il normale bollettino Android è importante. Il pacchetto generale di settembre corregge numerose vulnerabilità della piattaforma, comprese diverse RCE Critical nel componente System, ma CVE-2026-58704 compare nell’avviso specifico per i dispositivi Google. Il bollettino Android del mese include, tra le altre, CVE-2026-28604, CVE-2026-28618, CVE-2026-28639, CVE-2026-49882 e CVE-2026-49921, tutte classificate come vulnerabilità capaci di portare a remote code execution in determinate versioni della piattaforma. Per alcune di queste non è richiesta interazione dell’utente.

Il bollettino Pixel contiene una superficie molto più ampia del singolo zero-day

Concentrarsi esclusivamente su CVE-2026-58704 rischia inoltre di nascondere la dimensione dell’aggiornamento. Il bollettino Pixel di settembre corregge vulnerabilità critiche in modem, telefonia, VPU, IP Multimedia Subsystem, Trusted Execution Environment, bootloader, KeyMint e componenti biometrici Goodix, oltre a diversi problemi di privilege escalation. Tra le RCE Critical compaiono CVE-2026-55318 nell’IP Multimedia Subsystem, CVE-2026-55343 in libpixelimsmedia, CVE-2026-56920 nella VPU, CVE-2026-56967 nel modem e CVE-2026-58683 nella telefonia. Questa stratificazione è particolarmente rilevante sui Pixel recenti, dove la sicurezza dipende dalla collaborazione tra Android, firmware, Tensor, modem e ambienti trusted. Il dibattito sull’implementazione di Memory Tagging Extension nei Pixel 11 aveva già mostrato quanto le mitigazioni hardware siano diventate importanti contro le vulnerabilità di memory corruption. Una mitigazione, però, non sostituisce una patch: serve a rendere lo sfruttamento più difficile o meno affidabile, non elimina necessariamente il bug.

Leggi anche: Pixel 11 riceve l’aggiornamento di settembre mentre Google interviene sulle prime anomalie software

WSO2 CVE-2026-5430 trasforma un errore JWT in takeover amministrativo

Il secondo caso è completamente diverso e riguarda infrastrutture enterprise. CVE-2026-5430 colpisce WSO2 API Manager e altri componenti della stessa piattaforma ed è causata da una verifica errata della firma dei JSON Web Token. In determinate condizioni il sistema può accettare un token firmato utilizzando un algoritmo non supportato e consentire così di bypassare l’autenticazione. Il risultato può essere accesso non autorizzato, compromissione di account amministrativi e completo account takeover.

WSO2 assegna alla falla un punteggio CVSS 10.0 negli scenari più gravi e 9.8 nelle distribuzioni single-tenant. La vulnerabilità interessa WSO2 API Manager dalla 4.1.0 alla 4.6.0, API Control Plane 4.5.0 e 4.6.0, Traffic Manager 4.5.0 e 4.6.0 e Universal Gateway nelle stesse versioni. WSO2 aveva pubblicato l’advisory il 3 maggio 2026, insieme alle correzioni open source e agli update level necessari per i clienti con support subscription. Questo dettaglio rende l’attività osservata a settembre particolarmente significativa: non siamo davanti a una zero-day, ma a una N-day critica per la quale le patch sono disponibili da oltre quattro mesi.

I token osservati negli honeypot arrivano già con privilegi amministrativi

La trasformazione da vulnerabilità teorica ad attacco reale emerge dalle osservazioni di watchTowr riportate il 16 settembre. La rete di honeypot dell’azienda ha iniziato a ricevere il 13 settembre token JWT costruiti con privilegi amministrativi già incorporati. Lo scenario descritto è particolarmente pericoloso perché un API Manager non contiene soltanto un pannello web: occupa una posizione privilegiata tra client, API e servizi backend. Un account amministrativo compromesso può quindi esporre credenziali, consumer key, secret delle applicazioni registrate e accesso agli endpoint interni. Il problema va oltre il semplice furto dell’account. Un API gateway esiste precisamente per intercettare e gestire traffico destinato ai servizi interni. Se un attaccante ottiene il controllo amministrativo, quella funzione può trasformarsi in un punto di osservazione e pivot verso segmenti che normalmente non sono esposti direttamente a Internet. È il motivo per cui watchTowr descrive provocatoriamente il prodotto compromesso come una possibile infrastruttura di lateral movement-as-a-service. La definizione è del ricercatore, ma individua correttamente l’asimmetria: compromettere il punto che governa le API può essere molto più utile che compromettere una singola applicazione.

La firma JWT fallisce nel punto in cui dovrebbe costruire la fiducia

CVE-2026-5430 è interessante anche dal punto di vista architetturale. Un JWT viene utilizzato proprio per consentire a un servizio di verificare identità e attributi senza dover ricostruire ogni volta l’intero processo di autenticazione. La firma crittografica è quindi la parte che permette di stabilire se il token è autentico e se i claim contenuti al suo interno possono essere considerati affidabili. Quando l’applicazione accetta un token che utilizza un algoritmo che non dovrebbe essere valido, l’intera catena di fiducia collassa. Non serve necessariamente sottrarre la password dell’amministratore: l’attaccante può tentare di presentarsi direttamente come amministratore costruendo un token che il sistema interpreta erroneamente come valido. La vulnerabilità ricorda perché errori apparentemente piccoli nella gestione di algoritmi, chiavi e verifica delle firme abbiano conseguenze sproporzionate nei sistemi di autenticazione. Per le installazioni WSO2 ancora vulnerabili la mitigazione non consiste quindi in una nuova regola WAF generica. Il vendor richiede l’applicazione delle correzioni corrispondenti o la migrazione verso una versione non affetta. Per i clienti supportati, WSO2 indica livelli di aggiornamento precisi per ciascuna release.

Continua con:

• Samsung corregge 90 vulnerabilità nel pacchetto Galaxy di settembre
• WeWorm mostra quanto può diventare pericolosa una vulnerabilità zero-click anche su Android

Pixel e WSO2 mostrano due problemi opposti della gestione delle vulnerabilità

I due casi non devono essere confusi. CVE-2026-58704 rappresenta il problema della zero-day o quasi-zero-day impiegata in operazioni mirate prima che la maggioranza degli utenti abbia avuto la possibilità di proteggersi. CVE-2026-5430 rappresenta invece il problema opposto: una falla critica documentata e corretta che continua a produrre rischio perché sistemi vulnerabili rimangono raggiungibili mesi dopo la pubblicazione della patch. Per i Pixel la priorità operativa è semplice: installare un livello patch 2026-09-05 o successivo. Per WSO2 è necessario verificare versione e update level, applicare gli aggiornamenti indicati dal vendor e analizzare i log alla ricerca di autenticazioni anomale, token sospetti e accessi amministrativi inattesi. Il punto comune riguarda la velocità. Nel mobile gli exploit mirati possono arrivare prima della disclosure pubblica; nell’enterprise la pubblicazione di una correzione può fornire indirettamente agli attaccanti abbastanza informazioni per studiare il bug e cercare sistemi rimasti indietro. La patch non chiude una vulnerabilità quando viene pubblicata: la chiude soltanto quando raggiunge il sistema esposto. Nel 2026, tra exploit mirati e scansioni automatizzate, il tempo che separa questi due momenti continua a diventare uno degli elementi più importanti della sicurezza operativa.