SimpleHelp CVE-2026-48558: il bypass RMM da CVSS 10 che ruba credenziali cloud e AI

Il 29 giugno 2026 BleepingComputer ha riportato che alcuni attaccanti stavano sfruttando una falla critica di SimpleHelp per distribuire un infostealer del tutto nuovo. Il bug, CVE-2026-48558, ha un punteggio CVSS perfetto di 10.0 ed è stato divulgato da Horizon3.ai il 12 giugno. Lo stesso giorno CISA ha aggiunto la falla al suo catalogo delle Known Exploited Vulnerabilities, mettendola sull'orologio di remediation federale ai sensi della BOD 26-04. SimpleHelp è software di remote monitoring and management (RMM): lo strumento che un managed service provider usa per raggiungere ogni endpoint dei clienti che amministra. La vulnerabilità consente a un attaccante non autenticato di creare un account tecnico privilegiato, e la catena osservata in the wild usa quell'appiglio per installare uno stealer la cui lista della spesa è insolitamente "2026": non solo password e cookie del browser, ma chiavi SSH, credenziali Docker, stato Terraform, token della GitHub CLI e i file di configurazione degli assistenti AI. Il server RMM a cui avevi affidato la gestione di tutto è appena diventato il punto migliore da cui derubarti.

Cos'è davvero CVE-2026-48558

La falla risiede nel flusso di login OpenID Connect (OIDC) di SimpleHelp, e la causa radice è quasi imbarazzante per pulizia. Secondo la scheda NVD, il server accetta il token di identità OIDC che il client presenta al login senza verificarne la firma crittografica. È tutto qui il bug — CWE-347, verifica impropria di una firma crittografica — ed è il motivo per cui prende un 10.0 con vettore AV:N/AC:L/PR:N/UI:N/S:C.

Pensa a cos'è un ID token OIDC: un JWT che asserisce "questo utente è alice@corp, garantito dal tuo identity provider". Il provider lo firma proprio perché la relying party possa fidarsi della dichiarazione. SimpleHelp salta il controllo della firma. Quindi all'attaccante non serve rubare un token o fare phishing di una sessione: se ne forgia uno. Costruisci a mano un JWT che dichiara l'appartenenza a un gruppo tecnico, presentalo, e il server legge le claim, si fida e rilascia una sessione tecnico pienamente privilegiata. Nessuna password, nessun prompt MFA, nessun round-trip verso il provider che smaschererebbe la contraffazione.

Devono valere tre condizioni sul bersaglio perché la porta si apra:

• Almeno un provider OIDC è configurato sul server.
• Un TechnicianGroup è associato a quel provider OIDC.
• L'opzione "Allow group authenticated logins" è abilitata sul TechnicianGroup.

È una configurazione comune e documentata dal vendor — esattamente il modo in cui un MSP collega SimpleHelp al proprio SSO aziendale, così che i tecnici accedano con la loro identità abituale. La funzione che rende comodo l'onboarding è la stessa che, senza firma, consegna le chiavi a chiunque su internet.

Perché un server RMM è la scatola peggiore da perdere

Una piattaforma RMM non è una web app qualunque con un brutto bug. È, per progettazione, un hub di accesso remoto privilegiato con una connessione permanente verso ogni macchina che gestisce. Comprometti l'RMM e non ottieni un host: ottieni l'intera flotta, attraverso l'unico canale che dovrebbe inviare comandi remoti agli endpoint. Non esiste esempio più limpido di abuso di T1219 (Remote Access Software): a livello di protocollo, l'attività malevola è indistinguibile dallo scopo legittimo dello strumento.

E per SimpleHelp non è teoria. Nel 2025 CISA ha pubblicato l'advisory AA25-163A dopo che attori ransomware avevano sfruttato istanze SimpleHelp non aggiornate per raggiungere un fornitore di software di fatturazione per utility — e, attraverso di esso, i clienti a valle di quel fornitore. L'RMM è stato il pivot da una violazione a molte.

I numeri di esposizione di CVE-2026-48558 dicono che andrà allo stesso modo. I ricercatori hanno trovato quasi 14.000 server SimpleHelp raggiungibili da internet, di cui circa il 7,2% — nell'ordine del migliaio — con la configurazione OIDC vulnerabile attiva. Mille server RMM, ciascuno una porta d'ingresso nel parco che gestisce, con un CVSS 10.0 che non richiede credenziali.

Djinn Stealer punta alle chiavi del tuo cloud e della tua AI

È qui che l'incidente smette di sembrare un ransomware del 2020 e inizia a sembrarne uno del 2026. La catena osservata non cifra nulla. Esfiltra.

Dopo aver sfruttato CVE-2026-48558 per stabilire una sessione tecnico, l'attore distribuisce TaskWeaver, un loader JavaScript offuscato camuffato da jquery.js, prelevato da un dominio usa-e-getta dietro Cloudflare (T1105, Ingress Tool Transfer). TaskWeaver installa poi Djinn, uno stealer cross-platform finora non documentato che gira su Windows, macOS e Linux. È la sua lista di bersagli a renderlo degno di nota:

• Credenziali dei cloud provider e token dei servizi di identità.
• Chiavi private SSH e configurazione Git.
• Credenziali Docker e stato Terraform.
• Token della GitHub CLI e autenticazione di registry di pacchetti e strumenti di build.
• I file di configurazione degli assistenti di codice AI — inclusi i config dei server MCP di Claude.
• Wallet di criptovalute, dati del browser e, su Linux, le variabili d'ambiente dei processi.

Rileggi quella lista. Non è l'inventario di chi cerca un guadagno rapido da credential stuffing. È l'inventario di chi vuole muoversi lateralmente dentro la tua supply chain. Chiavi SSH e config Git lo portano nel tuo codice sorgente. Token Docker e di registry lo portano nella tua pipeline di build. Lo stato Terraform gli consegna la mappa dell'intero cloud, spesso con segreti incorporati. E i config MCP e degli assistenti AI sono il nuovo ventre molle: quei file contengono spesso API key e i dettagli di connessione degli strumenti che un agente AI è autorizzato a invocare — una classe di credenziali di cui la maggior parte delle organizzazioni non ha né inventario né policy di rotazione. Una compromissione RMM partita da un JWT senza firma finisce come una chiave permanente verso il cloud, il codice e il tooling AI.

La patch chiude la porta — non cancella il tecnico

SimpleHelp ha corretto il difetto di verifica della firma nella versione 5.5.16 (stabile) e in 6.0 RC2. Applicarla è necessario e urgente. Non è però la stessa cosa che essere puliti, e confondere le due cose è il modo in cui questo incidente sopravvive silenziosamente alla tua remediation.

Il primo atto dell'exploit è creare un account: un tecnico privilegiato. Applicare la patch al flusso OIDC ferma i nuovi login contraffatti. Non rimuove un account tecnico che un attaccante ha già creato durante la finestra di esposizione, esattamente come cambiare la serratura non rimuove la copia della chiave che il ladro ha fatto mentre era aperta. Quell'account è ora una credenziale legittima e registrata a database: T1078, Valid Accounts. Sopravvivrà all'aggiornamento, al riavvio e al report di stato "siamo a posto".

"Siamo su 5.5.16 su tutti i server SimpleHelp — l'abbiamo chiusa." "Hai chiuso il bypass. Hai cancellato gli account tecnico creati attraverso di esso? Tira fuori l'elenco account con i timestamp di creazione — quale di quelli l'ha verificato l'audit?"

È la stessa trappola strutturale di cui abbiamo scritto a proposito degli account admin fittizi 'John Sim' di Ubiquiti UniFi: uno scanner di versione conferma il fix e diventa verde, mentre l'account piantato, il loader ancora su disco e le credenziali già esfiltrate restano completamente fuori dal suo campo visivo.

Cosa vede davvero ciascun controllo

Metti i controlli abituali contro questa catena specifica e i punti ciechi si allineano:

Controllo	Vede la falla non patchata?	Vede l'account tecnico fittizio?	Vede Djinn esfiltrare le chiavi?
Scanner di versione / patch	Sì, una volta che esistono CVE + versione corretta	No — la versione risulta "fixed", l'account è invisibile	No
EDR sugli endpoint	n/d sull'appliance	No	In parte — se un agent gira dove atterra Djinn
SIEM (log del giorno dopo)	No	Solo se sapevi di interrogare la creazione account	A posteriori, se i log sono sopravvissuti
ML sul traffico di rete	Indirettamente	Il fetch del loader e le nuove sessioni in uscita sono sul filo	Sì — l'egress di esfiltrazione è l'evento
Re-test offensivo (assumed breach)	Riproduce la catena	Sì — enumera l'account piantato	A posteriori, ma in modo conclusivo

Due colonne reggono l'incidente: quella dell'account fittizio, dove ogni controllo passivo fallisce, e quella dell'esfiltrazione, dove l'unica cosa che osserva in tempo reale è ciò che modella il traffico.

Remediation

Un runbook completo, ordinato come dovresti davvero lavorarlo. La patch è il passo due, non la fine.

1. Sono interessato?

• Verifica la versione in esecuzione nella console di amministrazione di SimpleHelp. Interessate: dalla 5.5.0 alla 5.5.15 e tutte le build pre-release 6.0 fino alla RC1.
• Stabilisci se la configurazione vulnerabile è attiva: un provider OIDC configurato, un TechnicianGroup ad esso associato e "Allow group authenticated logins" abilitato. Se valgono tutte e tre, eri sfruttabile; il 7,2% è proprio questa combinazione.
• Stabilisci l'esposizione: il server SimpleHelp è raggiungibile da internet? Tratta ogni istanza esposta che era su una build vulnerabile con OIDC attivo come presunta-compromessa fino a prova contraria, non il contrario.

2. Patch — versioni corrette esatte

• Aggiorna a SimpleHelp 5.5.16 (ramo stabile) o 6.0 RC2 (ramo 6.0). Queste verificano la firma del token OIDC. Non esiste un fix di sola configurazione che ripristini il controllo della firma su una build non patchata.
• Questo ferma i nuovi login contraffatti. Non fa nulla per un account già creato — procedi ai passi 4 e 5 a prescindere da quanto in fretta hai applicato la patch.

3. Non puoi patchare subito? — controlli compensativi

• Togli immediatamente l'interfaccia web di SimpleHelp da internet pubblico: limitala a VPN / rete di management / IP in allow-list. Una console RMM non ha motivo di essere aperta al mondo.
• Se puoi tollerarne l'impatto operativo, disabilita i login OIDC di gruppo fino alla patch — rimuovere una qualunque delle tre precondizioni rimuove il percorso d'attacco.
• Metti il server dietro un reverse proxy o WAF che imponga l'allow-listing per IP sorgente sugli endpoint di login. È contenimento, non un fix.

4. Caccia alla compromissione

• Enumera tutti gli account tecnico e ordinali per timestamp di creazione. Qualsiasi account creato durante o dopo la finestra di esposizione che non riesci a ricondurre a un onboarding noto è sospetto. Mappa su T1136 (Create Account) e T1078 (Valid Accounts).
• Esamina i log di login e di sessione dei tecnici alla ricerca di autenticazioni da IP, ASN o geografie non riconosciuti — in particolare sessioni che hanno eseguito strumenti o spinto file verso endpoint gestiti.
• Cerca sugli endpoint gestiti e sul server jquery.js in percorsi inattesi (il loader TaskWeaver) e fetch in uscita verso domini Cloudflare registrati di recente (T1105, T1059.007 JavaScript).
• Dai la caccia ad accesso e staging di credenziali: letture di ~/.ssh, ~/.docker/config.json, file di stato Terraform, config della CLI gh e file di configurazione di assistenti AI / MCP (T1552.001 Credentials in Files, T1552.004 Private Keys).
• Sorveglia l'egress di esfiltrazione — traffico in uscita sostenuto o a raffica da host che normalmente ricevono solo traffico di management (T1041 / T1567).

5. Eradica + verifica

• Cancella ogni account tecnico confermato come fittizio e revoca le sue sessioni.
• Rimuovi gli artefatti TaskWeaver / Djinn dal server e da ogni endpoint gestito che hanno raggiunto.
• Ruota tutto ciò che Djinn tocca come se fosse già pubblico: chiavi SSH, token cloud e di identità, credenziali Docker e di registry, token GitHub CLI / PAT, segreti incorporati in Terraform e qualunque API key nei config di assistenti AI / MCP. È la rotazione, non la patch, a chiudere davvero questo incidente.
• Verifica dopo la patch ri-attestando che non esista alcun account tecnico inspiegato e che le credenziali ruotate siano le uniche accettate ovunque fossero valide.

Dove si colloca Zero Hunt

Questa catena espone due fallimenti che lo stack convenzionale non può chiudere da solo: una campagna di esfiltrazione che nessun controllo basato su host vede mentre è in corso, e un account piantato che sopravvive alla patch che ha "corretto" il bug.

La risposta primaria è sul filo. La AI Traffic Analysis di Zero Hunt esegue un modello di deep learning proprietario con quattro teste di inferenza parallele — traffico sospetto, classificazione malware, identificazione del tipo di attacco e fingerprinting applicativo — localmente sulla GPU dell'appliance a oltre 2,7 Gbit/s, senza alcun callback verso il cloud. Non le serve un IOC di TaskWeaver per notare che un server che ha sempre e solo parlato protocollo RMM ha appena prelevato uno script offuscato da un dominio vecchio di un giorno, o che un endpoint gestito sta improvvisamente spingendo un flusso in uscita sostenuto verso un ASN mai visto. L'intero scopo di Djinn è l'esfiltrazione, e l'esfiltrazione è un evento di traffico: lo staging e l'egress sono visibili mentre accadono, non ricostruiti dal digest SIEM di domani quando le chiavi sono già sparite. È il caso per cui il modello è stato costruito: cogliere il furto durante il furto.

La risposta secondaria è la bonifica che la dashboard delle patch non può eseguire. Il pentest generativo a 10 agenti di Zero Hunt tratta l'RMM come lo tratta un attaccante. L'agente Recon mappa le istanze SimpleHelp effettivamente esposte sul tuo perimetro; l'agente Exploit ricostruisce localmente il salto della firma OIDC per il tuo ambiente invece di eseguire un PoC pubblico; e gli agenti Credential, Post-Exploit e Pivot fanno il lavoro che uno scanner di versione strutturalmente non può — enumerare l'account tecnico piantato, trovare il loader ancora su disco e dimostrare quali credenziali esfiltrate si autenticano ancora dove non dovrebbero. Ogni nuova skill viene testata in backtest nell'AI Gym prima di toccare un bersaglio di produzione, e ogni finding è firmato con ECDSA al momento della scrittura, così che il bundle di evidenze dimostri che il server non è soltanto sulla 5.5.16 ma pulito — che è la domanda a cui la tua risposta agli incidenti deve davvero rispondere.

Mille server SimpleHelp saranno per lo più patchati entro la prossima settimana. Il numero che vale la pena conoscere è quanti portano ancora un account tecnico che nessuno ha creato di proposito — e quante chiavi cloud, Git e AI sono già in mano a qualcun altro. Per una lettura collegata sul perché un CVE chiuso non è un incidente chiuso, vedi la nostra analisi del divario di patch sugli admin fittizi di UniFi.