JFrog e Langflow sotto attacco: credenziali cloud e software fidati nel mirino

🛡️ Executive Summary

• JFrog Artifactory e Langflow affrontano vulnerabilità critiche sfruttate attivamente, con accesso amministrativo, esecuzione di codice e furto di segreti cloud.
• Faronics Deploy viene distribuito tramite phishing come software legittimo firmato e usato per eseguire PowerShell e installare ScreenConnect.
• AWS corregge CVE-2026-83551 in SageMaker Python SDK: aggiornamento e revisione dei permessi IAM sono necessari per proteggere pipeline e payload S3.

Quattro campagne e vulnerabilità apparentemente differenti stanno convergendo sullo stesso obiettivo: trasformare la fiducia concessa a software amministrativi, piattaforme AI e infrastrutture DevOps in un vantaggio per l’attaccante. Faronics Deploy viene abusato per ottenere controllo remoto e distribuire ScreenConnect, Langflow è bersaglio di una RCE usata per cercare chiavi OpenAI e AWS, JFrog Artifactory affronta lo sfruttamento di una falla critica di autenticazione e Amazon SageMaker corregge un problema che esponeva materiale HMAC nelle definizioni delle pipeline. La recente attività contro Langflow e PaperCut aveva già mostrato quanto le credenziali siano diventate il vero premio delle vulnerabilità applicative.

Faronics Deploy diventa il primo anello per installare ScreenConnect

La campagna individuata da Huntress non nasce da una vulnerabilità di Faronics Deploy, ma dall’abuso delle funzionalità legittime della piattaforma di endpoint management. È una distinzione importante: gli aggressori convincono la vittima attraverso email di phishing a eseguire un installer autentico e firmato, facendolo apparire come un documento aziendale, un aggiornamento Adobe, un invito Zoom o un plugin necessario per visualizzare un file. Secondo l’analisi tecnica pubblicata da Huntress, tra il 21 luglio e il 20 agosto 2026 oltre 457 endpoint hanno incontrato esche riconducibili alla campagna. Le pagine di consegna raccolgono informazioni sul visitatore — User-Agent, piattaforma, risoluzione, fuso orario, lingua e capacità touch — prima di decidere se mostrare il percorso malevolo oppure contenuti innocui, una forma di cloaking utile per ridurre l’esposizione ai sistemi automatici di analisi.

Quando l’eseguibile viene avviato con privilegi amministrativi, il dispositivo viene registrato in un deployment Faronics controllato dall’attaccante. Da quel momento le normali capacità di amministrazione remota consentono di eseguire script PowerShell senza ulteriore interazione dell’utente. Huntress ha osservato comandi che recuperavano contenuti esterni attraverso curl, mshta o msiexec, anche da repository GitHub, per arrivare infine all’installazione di ConnectWise ScreenConnect. Il secondo RMM crea quindi un canale remoto ridondante: anche se il primo meccanismo viene individuato, l’attaccante conserva un’altra strada verso l’endpoint.

La tecnica ricorda precedenti campagne nelle quali ScreenConnect veniva installato attraverso falsi aggiornamenti e software apparentemente affidabili, confermando il valore operativo dei tool RMM legittimi per chi vuole confondersi con il traffico amministrativo ordinario. Sul piano forense, uno degli artefatti più utili è C:\ProgramData\Faronics\Logs\ScriptRunner.log, che può conservare URL e script eseguiti anche quando altre tracce PowerShell non sono più disponibili.

Il parametro ck usato durante la configurazione identifica inoltre il deployment e può aiutare a collegare più sistemi alla stessa infrastruttura abusata. Faronics, avvertita il 5 agosto, ha introdotto misure contro la registrazione fraudolenta e Huntress ha osservato un forte calo dell’attività dal 21 agosto. Per gli ambienti coinvolti, la risposta non dovrebbe limitarsi alla rimozione dell’applicazione: occorre isolare gli host, verificare eventuali installazioni ScreenConnect, ricostruire gli script eseguiti, controllare la persistenza e ruotare le credenziali quando emerge la possibilità di accesso interattivo.

Langflow viene sfruttato per cercare chiavi OpenAI e AWS

Il caso Langflow mostra una progressione ancora più diretta dalla vulnerabilità applicativa al furto di identità macchina. CVE-2026-0768, valutata CVSS 9.8, interessa il validatore del codice utilizzato dall’editor dei componenti personalizzati: l’advisory della Zero Day Initiative spiega che una stringa controllata dall’utente può raggiungere il meccanismo che esegue codice Python senza una validazione sufficiente. Non è richiesta autenticazione e il codice può essere eseguito nel contesto di root. La falla era stata resa pubblica il 9 gennaio 2026, ma a fine agosto è entrata concretamente nel ciclo di sfruttamento. VulnCheck ha registrato prima oltre 50 tentativi sui propri sistemi canary nel Regno Unito e successivamente un totale salito a circa 360 rilevazioni, con traffico proveniente prevalentemente dalla Russia. Il comportamento osservato rivela bene il valore dell’accesso: le richieste cercano variabili come LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS* e AWS_SECRET*, tentano di leggere /root/.cache/langflow/secret_key e controllano anche materiale SSH e cronologia della shell. L’obiettivo non è quindi soltanto “bucare un server AI”, ma ottenere API key, credenziali cloud e segreti applicativi che possono sopravvivere alla compromissione iniziale e aprire accessi verso servizi esterni. È una dinamica particolarmente pericolosa nei builder AI, dove nello stesso processo possono convivere chiavi dei provider LLM, storage, database, credenziali cloud e strumenti agentici. La superficie esposta non è trascurabile: VulnCheck censiva poco meno di 2.500 istanze Langflow raggiungibili da Internet durante la preparazione del proprio exploit di verifica. CVE-2026-0768 si inserisce inoltre in una sequenza di falle Langflow sfruttate nel corso del 2026, comprese vulnerabilità di code injection e RCE che hanno trasformato la piattaforma in un obiettivo ricorrente. L’inserimento di un’altra falla Langflow tra gli exploit seguiti da CISA ad agosto aveva già segnalato il deterioramento del profilo di rischio. Le installazioni esposte devono essere aggiornate alla release corrente — la copertura tecnica disponibile indica 1.11.6 come versione da adottare — ma il patching da solo non chiude necessariamente l’incidente: su sistemi raggiungibili da Internet va verificato se le chiavi presenti nelle variabili d’ambiente siano state lette, usate o esfiltrate. In caso di dubbio, la rotazione di token OpenAI, access key AWS, segreti Langflow e credenziali SSH diventa parte della remediation, non un controllo opzionale.

Leggi anche: La botnet NadMesh prende di mira server AI esposti e cerca direttamente chiavi AWS

JFrog Artifactory passa dalla disclosure allo sfruttamento in pochi giorni

Con CVE-2026-82329 il problema si sposta al centro della software supply chain. La vulnerabilità è stata pubblicata da JFrog il 28 agosto 2026 e classificata critica: in una configurazione predefinita, un aggressore non autenticato con accesso di rete può aggirare il meccanismo di autenticazione e arrivare a privilegi amministrativi su Artifactory. L’advisory ufficiale di JFrog la identifica come una CWE-287 Improper Authentication, una categoria particolarmente grave per una piattaforma che conserva repository, pacchetti, token e metadati usati dai processi di build. Nel giro di pochi giorni dalla disclosure sono emerse evidenze di sfruttamento reale. Il Canadian Centre for Cyber Security ha pubblicato il 1° settembre l’avviso AV26-867, affermando esplicitamente che fonti open source indicano lo sfruttamento di CVE-2026-82329 in the wild. Le soglie indicate dall’autorità canadese richiedono di portare le installazioni self-hosted almeno alle release corrette delle rispettive linee: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 o 7.161.20. L’analisi tecnica attribuita a watchTowr descrive un problema nella gestione delle join key del servizio JFrog Access: in determinate installazioni prive di una chiave aggiuntiva configurata, il comportamento predefinito consentirebbe di ricostruire il materiale necessario a forgiare accessi validi. L’attività osservata comprende la generazione di token amministrativi, l’enumerazione di utenti, gruppi e credenziali e, in un numero limitato di casi, la creazione di account utilizzabili come backdoor. Al momento delle prime osservazioni non emergeva una scansione indiscriminata dell’intera Internet, ma questo non riduce la gravità del vettore. Artifactory non è un normale server applicativo: può occupare una posizione centrale nella catena con cui software e container vengono costruiti, firmati, distribuiti e promossi tra ambienti. Un amministratore ostile può quindi cercare segreti, alterare artefatti o preparare condizioni per una compromissione a valle. Il rischio è ancora più evidente perché Artifactory era già finito nelle allerte di agosto per un’altra vulnerabilità inserita nel catalogo delle falle sfruttate, segnale di una superficie che richiede una gestione delle patch molto più rapida rispetto ai normali cicli mensili. Gli amministratori dovrebbero aggiornare immediatamente, ma anche controllare token emessi, nuovi utenti, modifiche ai gruppi privilegiati, configurazioni di federazione e operazioni sui repository successive al periodo di possibile esposizione. Se Artifactory viene considerato parte della trust chain del processo di sviluppo, una compromissione amministrativa deve essere trattata come un potenziale incidente di supply chain, non come il semplice accesso a un pannello web.

SageMaker esponeva la chiave HMAC usata per proteggere i payload delle pipeline

Il quarto sviluppo non riguarda uno sfruttamento pubblico già osservato, ma una debolezza nella separazione della fiducia all’interno dello stesso account AWS. Nel bollettino 2026-093-AWS, Amazon descrive CVE-2026-83551, vulnerabilità nel SageMaker Python SDK relativa ai decorator @step e @remote. Queste funzionalità serializzano funzioni e payload che vengono archiviati in Amazon S3 e ne proteggono l’integrità attraverso una firma. Il problema nasceva dal fatto che la chiave segreta HMAC utilizzata per la verifica poteva essere conservata in chiaro nella definizione della pipeline e recuperata attraverso l’API DescribePipeline. Di conseguenza, un soggetto già dotato di un ruolo nello stesso account AWS e dell’autorizzazione necessaria a invocare DescribePipeline poteva estrarre la chiave, generare payload cloud-pickled con HMAC valido, sostituire gli oggetti presenti in S3 e ottenere esecuzione di codice nel contesto della pipeline di un altro utente dello stesso account. Non si tratta quindi di una RCE anonima da Internet come quella di Langflow: serve una posizione iniziale nell’account e un insieme preciso di permessi. L’impatto resta tuttavia significativo negli ambienti multiutente, perché trasforma un’autorizzazione di lettura apparentemente limitata in un possibile salto verso il contesto di esecuzione di un’altra pipeline. AWS indica nel proprio security bulletin come vulnerabili SageMaker Python SDK v3 precedenti alla 3.11.0 e v2 precedenti alla 2.256.0. La correzione della linea v3 sostituisce HMAC simmetrico con ECDSA asimmetrico: la chiave privata rimane sul client e nella pipeline viene registrato soltanto il materiale pubblico necessario alla verifica. Nella linea v2 il materiale segreto persistente viene invece rimosso. Per le pipeline già create tramite @step, l’aggiornamento del pacchetto non è sufficiente da solo: AWS chiede di aggiornare anche le definizioni esistenti, ad esempio mediante pipeline.upsert(), così da eliminare la precedente chiave simmetrica. Per @remote, l’upgrade è sufficiente perché ogni invocazione crea un nuovo job senza persistenza dello stesso materiale. Chi non può aggiornare immediatamente deve limitare sagemaker:DescribePipeline ai soli soggetti fidati e separare i payload attraverso s3_root_uri dedicati per utente. La vulnerabilità richiama direttamente il precedente problema SageMaker che esponeva chiavi HMAC nei training job, ma i due difetti non vanno confusi: il precedente CVE-2026-1777 interessava un differente percorso di esposizione, mentre CVE-2026-83551 riguarda specificamente definizioni delle pipeline, DescribePipeline e il modello di firma usato da @step e @remote.

Continua con:

• Artifactory, OpenWrt e TeamCity: le falle critiche che hanno colpito i server di sviluppo
• AWS e SageMaker tra workload industriali e nuove correzioni di sicurezza

Il bersaglio non è più soltanto il server ma la fiducia che contiene

I quattro casi descrivono tecniche differenti, ma il denominatore comune è più importante delle singole CVE. Con Faronics Deploy l’attaccante sfrutta la reputazione e i privilegi di uno strumento amministrativo autentico; con Langflow usa una RCE per arrivare ai segreti che collegano l’applicazione AI a OpenAI, AWS e altri servizi; con JFrog Artifactory cerca il controllo amministrativo di un nodo che può influenzare l’intera catena di distribuzione del software; con SageMaker una chiave crittografica esposta attraverso un’API può trasformare un ruolo già presente nell’account in un punto di ingresso nel contesto operativo di un altro utente. È lo stesso problema osservato, sotto una forma controllata ma significativa, quando agenti AI coordinati sono riusciti a sfruttare Artifactory come passaggio privilegiato durante test offensivi su infrastrutture condivise: il valore dell’obiettivo cresce con il numero di relazioni di fiducia che vi convergono. Per questo l’indicatore più pericoloso non è necessariamente la presenza di un malware sconosciuto. Può essere un RMM firmato, un token perfettamente valido, una chiave API estratta da una variabile d’ambiente, un account amministrativo appena creato o un payload S3 dotato di una firma crittografica formalmente corretta. Le difese devono quindi spostarsi dalla sola identificazione del codice malevolo alla verifica continua di identità, privilegi, provenienza degli artefatti, segreti e relazioni tra sistemi. Nei moderni ambienti cloud e DevOps, chi compromette la fiducia concessa a un componente non conquista soltanto quel componente: può ereditare parte della fiducia che l’intera infrastruttura gli aveva già assegnato.