SimpleHelp RMM CVE-2026-48558: il token falsificato che diventa un vostro tecnico

Il 29 giugno 2026 CISA ha inserito CVE-2026-48558 nel catalogo Known Exploited Vulnerabilities con una scadenza federale di rimedio di soli tre giorni. È un bypass di autenticazione con punteggio CVSS 10.0 in SimpleHelp, uno strumento di remote monitoring and management (RMM) usato da migliaia di MSP e da team IT interni. Non è una RCE da corruzione di memoria. È più silenzioso e, per chi difende, peggio: l'attaccante falsifica un token di identità e il server gli consegna un account Technician legittimo e con privilegi. Da quel momento l'intruso non sta entrando — è a libro paga.

Questa distinzione è tutta la storia. Tutto ciò che segue l'accesso iniziale passa attraverso il canale fidato e in whitelist dell'RMM stesso: connessione remota agli endpoint, esecuzione di script, push di file. È esattamente l'attività che al vostro EDR è stato detto di ignorare.

Come CVE-2026-48558 falsifica un tecnico SimpleHelp RMM

SimpleHelp supporta il single sign-on tramite OpenID Connect (OIDC). Il difetto, segnalato da Horizon3.ai, è che il server accetta un token di identità OIDC senza verificarne la firma. La firma è l'intera ragion d'essere di un JWT — è la prova crittografica che l'identity provider, e solo lui, ha emesso quell'asserzione. Saltate quel controllo e il token diventa un semplice blocco JSON che l'attaccante può scrivere da zero: qualunque email, qualunque appartenenza a gruppo, qualunque claim voglia.

Passate un token falsificato a un server SimpleHelp vulnerabile e questo fa ciò per cui è stato costruito con un token valido — crea l'utente. Per impostazione predefinita quell'utente è un Technician che può, nelle parole stesse di SimpleHelp, connettersi da remoto agli endpoint gestiti, eseguire script e svolgere attività di gestione privilegiata. L'MFA viene bypassato al primo login perché l'asserzione falsificata afferma già un'identità fidata.

L'exploit non è universale. Devono valere contemporaneamente tre condizioni, secondo Horizon3.ai:

• Almeno un provider di autenticazione OIDC configurato sul server.
• Almeno un Technician Group con quel provider OIDC abilitato.
• L'opzione "Allow group authenticated logins" attiva su quel gruppo.

Ecco perché il banner di versione dice quasi nulla. Shodan vede circa 14.000 server SimpleHelp esposti su internet, e le analisi stimano che il 7,2% circa usi OIDC — ma sono vulnerabili solo i server con esattamente quella configurazione a tre parti. Se voi siete esposti è una domanda sulla vostra configurazione, non sul vostro livello di patch.

Perché un tecnico RMM è l'identità di cui l'EDR si fida

Ecco la parte controintuitiva. Una volta che l'attaccante possiede un account Technician, smette di sembrare un attaccante.

SimpleHelp è un agente di supporto remoto. È installato deliberatamente sugli endpoint gestiti, il suo binario è firmato, e sta nella whitelist di ogni EDR del parco macchine — perché bloccare il proprio strumento di supporto remoto significa che l'help desk non può più lavorare. Così, quando il tecnico falsificato si connette a una workstation e vi carica un payload, la telemetria host vede un RMM autorizzato che compie azioni RMM autorizzate. Nessun exploit, nessuno shellcode iniettato, nessun binario non firmato da segnalare.

La catena di payload osservata lo conferma. BlackPoint Cyber ha riportato sfruttamento attivo in cui il tecnico fraudolento distribuiva un file JavaScript offuscato chiamato jquery.js, prelevato da un URL temporaneo su Cloudflare ed eseguito tramite node.exe. Quel dropper installava TaskWeaver, un loader che rileva le caratteristiche dell'host così che gli operatori possano adattare il payload finale, e Djinn Stealer, un infostealer multipiattaforma (Windows, macOS, Linux) che raccoglie credenziali per piattaforme cloud, source-control, package registry, strumenti infrastrutturali, assistenti AI, browser, SSH e wallet di criptovalute.

Analista: "Fammi vedere l'alert." Responsabile IT: "Non c'è. L'account tecnico era valido, la sessione RMM era valida, node.exe che esegue un file JavaScript è ciò che la nostra automazione fa tutto il giorno. La prima cosa che abbiamo visto è stata la nota di estorsione."

Nessuno di quei passaggi è anomalo per un agente host. Ognuno di essi è anomalo sul filo — una sessione tecnico avviata da un ASN mai visto, un download in uscita da un hostname Cloudflare usa-e-getta, e poi un'esfiltrazione sostenuta di credenziali. La rete è dove un'intrusione via canale fidato torna leggibile.

Il raggio d'esplosione MSP: un server, tutti i clienti a valle

Il tooling RMM è un moltiplicatore di forza per costruzione, il che lo rende un moltiplicatore di forza anche per l'attaccante. Un singolo server SimpleHelp presso un MSP è un hub di accesso remoto privilegiato verso ogni cliente a valle che gestisce. Falsificate un tecnico su quel server e non avete violato una rete — avete una console di gestione puntata su decine.

Non è ipotetico per SimpleHelp nello specifico. Nel 2025 l'advisory CISA AA25-163A ha documentato attori ransomware che sfruttavano istanze SimpleHelp RMM non patchate per compromettere un fornitore di software di fatturazione per utility e, attraverso di esso, i suoi clienti a valle. Il prodotto ha una storia consolidata di attrazione esattamente di questa classe di avversari, perché il ritorno è uno-a-molti. CVE-2026-48558 consegna la stessa leva uno-a-molti a chiunque sappia costruire un JWT.

Per gli MSP la posta in gioco di compliance amplifica quella tecnica: sotto NIS2 i fornitori di servizi gestiti rientrano esplicitamente nel perimetro, e una violazione che si propaga dalla vostra console all'ambiente regolamentato di un cliente è un incidente notificabile con un orologio che scorre.

Remediation

Trattatelo come un evento assume-breach se una qualsiasi delle tre precondizioni dell'exploit è mai stata impostata su un server esposto a internet. La patch elimina la vulnerabilità; non elimina un account Technician che l'attaccante ha già creato. Lavorate la lista dall'alto verso il basso.

1. Sono interessato?

• Verificate la versione. Interessate: SimpleHelp 5.5.15 e precedenti, e tutte le build 6.0 pre-release.
• Verificate l'esposizione, non solo la versione. Nella console admin controllate se OIDC è configurato, se un Technician Group ha il provider OIDC abilitato, e se "Allow group authenticated logins" è attivo. Tutte e tre insieme = sfruttabile.
• Determinate se il server è raggiungibile da internet. ~14.000 lo sono; un server esposto e con OIDC configurato è il caso ad alta priorità.

2. Patch — versioni corrette esatte

• Aggiornate a 5.5.16 o 6.0RC2 (rilasciate il 9 giugno 2026), o successive, come da advisory di sicurezza SimpleHelp. Queste build ripristinano la verifica della firma OIDC.

3. Non potete patchare stanotte? Controlli compensativi

• Disattivate "Allow group authenticated logins" su ogni Technician Group — questo spezza la catena d'exploit anche su una build vulnerabile.
• Rimuovete l'interfaccia admin/tecnico di SimpleHelp dall'esposizione diretta a internet; mettetela dietro VPN o IP allowlist.
• Disattivate temporaneamente l'SSO OIDC e tornate all'autenticazione locale con MFA se la configurazione non è affidabile.

4. Caccia alla compromissione (mappata a MITRE ATT&CK)

• Account Technician fraudolenti — l'IOC principale. Nella console: Administration → Technicians → Icona Ingranaggio → attivate "Show Group Authenticated Users" e rivedete ogni voce cercando nomi o email sconosciuti (il PoC di Horizon3.ai usava [email protected]). Mappa su T1136.001 (Create Account) e T1078 (Valid Accounts).
• Log del server — ispezionate /opt/SimpleHelp/logs/server.log e il file con timestamp /opt/SimpleHelp/logs/<YYYYMMDD-HHMMSS>/server.log cercando righe come Registering technician login for [email sconosciuta] e Configuration save requested (Forged Attacker - ...). L'asserzione falsificata mappa su T1606 (Forge Web Credentials); il bypass OIDC su T1190 (Exploit Public-Facing Application).
• Catena di payload — cercate sugli endpoint jquery.js eseguito tramite node.exe (T1059.007 JavaScript, T1105 Ingress Tool Transfer), connessioni in uscita verso URL Cloudflare a vita breve, e artefatti TaskWeaver/Djinn Stealer (T1219 Remote Access Software, T1041 Exfiltration Over C2 Channel, T1555 Credentials from Password Stores). Eseguite lo scanner di IoC di Horizon3.ai indicato nella loro disclosure.

5. Eradicare + verificare

• Eliminate ogni account Technician non autorizzato e revocatene le sessioni.
• Ruotate ogni credenziale che l'RMM poteva raggiungere — Djinn Stealer prende di mira segreti di source-control, cloud, package registry, SSH e infrastruttura, quindi dimensionate la rotazione su ciò che quegli account potevano toccare, non solo sul login RMM.
• Rimuovete gli artefatti TaskWeaver/Djinn dagli endpoint colpiti e re-imaginate dove si sospetta persistenza.
• Verificate la pulizia dopo la patch, non prima: un banner patchato su un server che ospita ancora un tecnico falsificato è un falso via-libera. Ri-verificate la lista tecnici dopo l'aggiornamento.

Dove si colloca Zero Hunt: vedere un canale fidato che si corrompe

Il motivo per cui CVE-2026-48558 è pericoloso è che l'attività post-accesso è autorizzata. Agli agenti host è stato detto di fidarsi dell'RMM, e lo fanno. È esattamente il varco che l'AI Traffic Analysis di Zero Hunt è costruita per chiudere. Il nostro modello di deep learning proprietario gira sulla GPU dell'appliance a un baseline di 2,7+ Gbit/s con quattro inference head paralleli — traffico sospetto, classificazione malware, identificazione del tipo di attacco e fingerprinting applicativo — e legge il filo, dove la fiducia non ripulisce il comportamento. Una sessione tecnico che si apre da un ASN mai visto prima, un download in uscita da un hostname Cloudflare usa-e-getta, e un'esfiltrazione sostenuta di credenziali sono anomalie che il modello segnala mentre l'esfiltrazione sta avvenendo, non nel digest SIEM del mattino dopo — e non serve alcun agente sulla macchina RMM, l'unico host che non potete strumentare senza rompere il supporto.

Questo risolve la rilevazione. La prevenzione è un problema di validazione, ed è a forma di configurazione: solo i server con l'esatta configurazione dei gruppi OIDC sono sfruttabili, cosa che una scansione di banner non può dirvi. Lo swarm di 10 agenti per il pentest generativo di Zero Hunt testa la vostra istanza reale — gli agenti Recon e Web verificano se la vostra configurazione dei gruppi OIDC accetta un'asserzione non firmata, invece di indovinare da una stringa di versione — e ogni exploit è scritto per-target da un LLM locale, backtestato nell'AI Gym prima di essere eseguito. Provato l'accesso, gli agenti Post-Exploit e Pivot cercano esattamente gli artefatti che questa campagna lascia: un account Technician fraudolento, un punto d'appoggio TaskWeaver, un archivio di credenziali in staging. I risultati sono firmati ECDSA al momento della scrittura, così "abbiamo patchato e confermato che nessun impianto è sopravvissuto" diventa un record verificabile, non un'affermazione — e una campagna change-triggered ri-controlla nel momento in cui un nuovo asset RMM compare sul perimetro.

Patchare CVE-2026-48558 chiude la falsificazione. Non vi dice se qualcuno è già entrato ed è rimasto. Rispondere a quella domanda richiede di osservare il canale che le vostre difese sono state costruite per fidarsi.