Un token che nessuno ha firmato: SimpleHelp accettava login falsi e apriva ogni endpoint gestito

Lo strumento che tiene le chiavi di casa altrui

SimpleHelp è software di supporto remoto: lo installa chi deve entrare, con il consenso, nei computer di clienti o dipendenti per assisterli. È esattamente il tipo di prodotto in cui il livello di fiducia è totale — una sessione di tecnico autenticata può vedere lo schermo, muovere il mouse, trasferire file, eseguire comandi sugli endpoint gestiti. Per i Managed Service Provider è il pannello da cui si amministrano decine o centinaia di aziende clienti. Comprometterlo non è bucare un sito: è ottenere un passe-partout verso tutto ciò che quel server gestisce.

Il 29 giugno 2026 CISA ha aggiunto CVE-2026-48558 al catalogo delle vulnerabilità note come sfruttate. È un bypass di autenticazione da CVSS 10.0 (scala 3.1) nel flusso di single sign-on OIDC. Il difetto è di quelli che fanno male proprio perché sono semplici da spiegare.

La firma che non veniva controllata

Quando SimpleHelp è configurato per l'autenticazione OIDC, durante il login riceve un identity token: un oggetto firmato dal provider di identità che dice "questo utente è chi dice di essere". Il senso di quella firma è tutto: è la prova crittografica che il token viene davvero dal provider e non è stato fabbricato. Nelle versioni vulnerabili — SimpleHelp fino alla 5.5.15 e le pre-release 6.0 — quel token veniva accettato senza verificarne la firma.

Il risultato è meccanico. Un attaccante remoto, senza alcuna credenziale, poteva costruire da sé un token con claim di identità arbitrari — cioè scrivere "sono un tecnico autorizzato" — e presentarlo. Non essendo controllata la firma, il server lo prendeva per buono e apriva una sessione di tecnico pienamente autenticata. In alcune configurazioni, avverte la descrizione del difetto, questo consentiva anche di aggirare l'autenticazione a più fattori: se il gate è il token e il token è falsificabile, il secondo fattore non viene mai chiamato in causa.

1. 01
   Token OIDC forgiato

   claim arbitrari: "tecnico autorizzato", nessuna credenziale reale
2. 02
   Firma non verificata

   il server non controlla che il token venga dal provider
3. 03
   Sessione di tecnico piena

   accesso autenticato, in alcuni casi MFA aggirata
4. 04
   Endpoint gestiti

   da un login falso al controllo dei computer amministrati

Cosa è successo dopo l'ingresso

La falla non è rimasta teorica. Secondo la ricostruzione di Horizon3.ai — che ha scoperto e divulgato la vulnerabilità — e le analisi riportate da Blackpoint Cyber, gli attaccanti hanno usato il login forgiato per distribuire un loader Node.js chiamato TaskWeaver e un nuovo infostealer, Djinn, orientato a raccogliere credenziali attraverso strumenti cloud, di sviluppo, di intelligenza artificiale e wallet. La sequenza è quella tipica di un accesso iniziale ad alto valore: non un colpo isolato, ma il primo passo di una catena che punta a rubare altri accessi e allargarsi.

Cosa è verificato e cosa no

Alcune distinzioni vanno fatte con onestà. La descrizione tecnica del difetto e le versioni colpite vengono dalla scheda NVD e dall'advisory di sicurezza del vendor, che ha rilasciato la correzione (5.5.16 e 6.0 RC2) già a fine maggio 2026. Lo sfruttamento attivo è confermato dall'ingresso in KEV. Il collegamento con TaskWeaver e Djinn proviene dalla ricerca di Horizon3.ai e Blackpoint Cyber ripresa da più testate: è ricerca di threat intelligence solida, non un advisory di agenzia, e l'attribuzione a un attore nominato non c'è. Il catalogo KEV riporta l'uso ransomware come sconosciuto. Gli ID ATT&CK in testa — T1190, T1606, T1219 — sono una mappatura ragionata di ciò che la catena consente (colpire un servizio esposto, presentare credenziali web forgiate, abusare di software di accesso remoto), non ID copiati da una fonte primaria.

Cosa si fa, e subito

La priorità è aggiornare a 5.5.16 o 6.0 RC2 (o versioni successive). Ma per un prodotto che era esposto e sfruttabile senza credenziali, la patch da sola non basta: chi era vulnerabile deve assumere il possibile accesso e controllare gli indicatori pubblicati da Horizon3.ai, cercando sessioni di tecnico e login OIDC anomali nei log, e attività sugli endpoint gestiti che non corrisponde a interventi reali. Dove c'è evidenza di compromissione, la bonifica di un RMM è più ampia della patch: ruotare le credenziali, invalidare le sessioni, verificare gli endpoint amministrati per il loader e lo stealer. La lezione di questa CVE è la stessa che torna sui prodotti di accesso remoto: uno strumento costruito per entrare ovunque, se sbaglia a controllare chi sta entrando, non regala un singolo host — regala la lista di tutti quelli che gestisce.