Un operatore umano sfrutta una RCE di Marimo e raggiunge un bastion host SSH in otto secondi

Un attaccante umano ha sfruttato una grave vulnerabilità di autenticazione nella piattaforma per notebook Python Marimo, ha estratto credenziali cloud, recuperato una chiave SSH privata e ottenuto l’accesso a un bastion host nell’arco di otto secondi.

Sysdig ha osservato oltre 850 comandi interattivi durante un’intrusione durata circa nove ore. Invece di utilizzare un framework di exploit noto o un agente AI, l’operatore ha creato e corretto script Python personalizzati direttamente nell’ambiente compromesso.

La vulnerabilità che ha consentito l’accesso iniziale, CVE-2026-39987, interessa le versioni di CoreWeave Marimo precedenti alla 0.23.0. È già presente nel catalogo Known Exploited Vulnerabilities della Cybersecurity and Infrastructure Security Agency statunitense, a conferma del fatto che viene sfruttata anche al di là di una semplice prova di fattibilità teorica.

Un WebSocket senza autenticazione ha aperto una shell completa

Marimo è un’applicazione per notebook Python reattivi. Nelle versioni vulnerabili, l’endpoint WebSocket /terminal/ws può fornire a un utente remoto non autenticato una shell pseudo-terminale completa.

Il problema di fondo è l’assenza di autenticazione, classificata come CWE-306. L’endpoint verifica la modalità operativa di Marimo e se la piattaforma supporta la funzionalità terminale richiesta, ma non applica il controllo di autenticazione presente su altri percorsi WebSocket, tra cui /ws.

Di conseguenza, un’istanza esposta su Internet può consentire a un attaccante di eseguire comandi arbitrari sul sistema operativo senza credenziali né interazione da parte dell’utente.

L’operatore osservato si è connesso a /terminal/ws dall’indirizzo 172.236.12[.]17. L’attività è proseguita dalle 12:52 alle 21:50, anche se la data dell’intrusione non è stata resa nota.

NVD assegna alla vulnerabilità un punteggio CVSS v3.1 di 9,8, con il seguente vettore:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

La valutazione descrive una vulnerabilità raggiungibile dalla rete, con bassa complessità di attacco, nessun privilegio richiesto e senza interazione da parte dell’utente, che può avere conseguenze gravi su riservatezza, integrità e disponibilità. Un rapporto separato assegna alla vulnerabilità un punteggio di 9,3, ma la definizione delle versioni interessate fornita da NVD è più specifica: le versioni di CoreWeave Marimo precedenti alla 0.23.0.

Marimo 0.23.0 contiene la correzione.

Dall’accesso al notebook al bastion host in pochi secondi

L’attaccante non ha eseguito immediatamente un payload già pronto. Durante l’intrusione, l’operatore ha scritto, testato e corretto ripetutamente codice Python, fino a ridurre il flusso operativo a un unico comando python3 eseguito in background.

Il comando ha automatizzato un pivot in cinque fasi:

1. Leggere le credenziali disponibili nell’ambiente Marimo compromesso.
2. Utilizzare le credenziali AWS raccolte per interrogare AWS Secrets Manager.
3. Recuperare una chiave SSH privata archiviata.
4. Salvare la chiave nel filesystem locale.
5. Autenticarsi a un bastion host SSH.

La sequenza decisiva è durata otto secondi. Alle 18:57:22, l’attaccante ha stabilito una nuova connessione WebSocket. Alle 18:57:26, una query ha restituito la chiave AWS archiviata dall’applicazione. Alle 18:57:30 è seguita l’autenticazione SSH al bastion host.

Questa tempistica è rilevante dal punto di vista operativo. I difensori che si affidano a revisioni manuali o ad analisi batch lente avrebbero quasi nessuna possibilità di interrompere il passaggio alla fase successiva dopo il primo evento WebSocket visibile. Prevenzione, isolamento delle credenziali e contenimento automatizzato sono quindi strategie più affidabili dell’aspettativa che un analista riesca a reagire durante il pivot.

L’operatore ha inoltre sperimentato una configurazione di listener in stile asyncssh, che coinvolgeva un virtual private server sotto il controllo dell’attaccante. Nella cronologia dei comandi non è stato identificato alcun toolkit offensivo pubblico riconoscibile.

Automazione rapida senza un agente AI

L’intrusione ricorda un’attività agentica per la sua velocità, ma gli elementi disponibili indicano che l’automazione personalizzata era diretta da un essere umano.

Oltre 850 comandi interattivi, insieme allo sviluppo e al debugging visibili degli script, indicano che l’operatore stava perfezionando attivamente l’attacco. Una volta verificate le procedure necessarie, l’attaccante le ha riunite in un processo Python compatto, capace di completare a velocità macchina la catena dalle credenziali all’accesso SSH.

Sysdig aveva inoltre osservato operatori automatizzati o agentici prendere di mira la stessa vulnerabilità. Questi operatori si sono imbattuti in una trappola difensiva che ha bloccato o disturbato il loro flusso di lavoro; l’attaccante umano l’ha evitata.

Il confronto evidenzia un limite dei controlli progettati intorno ad automazioni prevedibili. Gli agenti AI e gli strumenti standardizzati possono ripetere sequenze riconoscibili, fidarsi di risposte ingannevoli o fallire quando cambiano le condizioni dell’ambiente. Un essere umano esperto può esaminare il sistema, riconoscere comportamenti anomali e modificare il percorso di esecuzione.

Questo non significa che gli attaccanti umani siano intrinsecamente più veloci dei sistemi autonomi. Dimostra piuttosto che una persona può preparare e avviare un’automazione dopo aver compreso il bersaglio, combinando capacità di adattamento e un’esecuzione quasi istantanea.

CISA aveva già classificato la vulnerabilità come sfruttata

CISA ha aggiunto CVE-2026-39987 al catalogo Known Exploited Vulnerabilities il 23/04/2026. Il termine per la remediation delle agenzie federali statunitensi interessate era il 07/05/2026.

L’azione richiesta consiste nell’applicare le mitigazioni del fornitore, seguire le indicazioni BOD 22-01 applicabili ai servizi cloud oppure interrompere l’utilizzo del prodotto se le mitigazioni non sono disponibili.

La presenza nel catalogo KEV significa che le installazioni vulnerabili esposte non devono essere considerate una fonte di rischio meramente potenziale. Lo sfruttamento è stato documentato e l’incidente appena segnalato dimostra un percorso dalla compromissione del notebook ai segreti cloud sensibili e all’infrastruttura SSH interna.

Nelle informazioni disponibili non sono identificate altre vulnerabilità recenti di Marimo presenti nel catalogo KEV. La priorità immediata è quindi CVE-2026-39987 e tutte le credenziali esposte attraverso istanze vulnerabili dei notebook.

Cosa devono verificare gli operatori di Marimo

Gli amministratori devono aggiornare ogni deployment Marimo interessato alla versione 0.23.0 o successiva. L’accesso a /terminal/ws dovrebbe inoltre essere limitato a livello di rete o di reverse proxy, soprattutto nei casi in cui i sistemi notebook non debbano essere raggiungibili pubblicamente.

Applicare la patch non è sufficiente se lo sfruttamento potrebbe già essere avvenuto. I responsabili della risposta agli incidenti dovrebbero presumere che le credenziali accessibili al processo Marimo possano essere state raccolte.

Le azioni consigliate includono:

• Ruotare le credenziali AWS archiviate nell’istanza interessata o esposte a essa.
• Esaminare gli accessi ad AWS Secrets Manager alla ricerca di recuperi imprevisti da parte dei workload dei notebook.
• Revocare e sostituire le chiavi SSH private a cui l’ambiente compromesso poteva accedere.
• Cercare chiavi private scritte in modo imprevisto nello storage locale.
• Esaminare i log del bastion host alla ricerca di accessi SSH avvenuti subito dopo sessioni WebSocket di Marimo.
• Analizzare le connessioni che coinvolgono 172.236.12[.]17.
• Cercare processi Python eseguiti in background e listener in stile asyncssh non riconosciuti.
• Correlare le connessioni a /terminal/ws con chiamate alle API cloud, recuperi di segreti, scritture nel filesystem e autenticazioni SSH.

I team dovrebbero inoltre verificare se i ruoli di esecuzione dei notebook dispongono dell’autorizzazione a recuperare chiavi SSH di produzione. Eliminare questo accesso può impedire che la compromissione di un notebook si trasformi in un pivot verso le credenziali dell’intera infrastruttura.

Campagne separate prendono di mira Redis e le telecamere Dahua

Il rapporto descrive inoltre due operazioni separate, non attribuite all’attaccante di Marimo.

Una campagna di cryptomining ha compromesso 3.562 server Redis dopo aver analizzato la rete alla ricerca di servizi esposti sulla porta TCP 6379. L’operazione ha utilizzato il comando Redis SLAVEOF per trasferire contenuti sotto il controllo dell’attaccante e installare il miner XMRig.

Le vittime utilizzavano versioni comprese tra Redis 2.8.17 e 7.2.0 e includevano ambienti Linux obsoleti e aggiornati. L’esposizione comune sembra essere stata l’assenza di autenticazione, più che una vulnerabilità esclusiva di una singola versione di Redis.

I difensori dovrebbero rimuovere Redis dall’esposizione diretta a Internet, richiedere l’autenticazione, verificare le impostazioni di replica e cercare attività SLAVEOF impreviste, modifiche ai file append-only, chiavi SSH e processi XMRig.

Un’ulteriore campagna, Operation CameraSwarm, ha compromesso oltre 14.000 telecamere IP Dahua utilizzando attacchi brute-force, inoltro peer-to-peer e le vulnerabilità di bypass dell’autenticazione CVE-2021-33044 e CVE-2021-33045.

Entrambe le vulnerabilità Dahua hanno un punteggio CVSS di 9,8 e sono presenti nel catalogo KEV di CISA dal 21/08/2024. Il termine per la remediation federale era l’11/09/2024. Le organizzazioni devono applicare le mitigazioni di Dahua oppure dismettere i dispositivi interessati nei casi in cui non sia disponibile una mitigazione.