CISA e AWS affrontano exploit in Langflow, N-central, Tomcat, AgentCore e Kiro

🛡️ Executive Summary

• CISA conferma lo sfruttamento attivo di vulnerabilità in IBM Langflow, N-able N-central e Apache Tomcat.
• Amazon Bedrock AgentCore consentiva a utenti autenticati di eseguire direttamente gli strumenti configurati aggirando modello e controlli associati.
• Kiro IDE e CLI per Windows potevano eseguire binari inseriti in directory di progetto malevole prima di quelli presenti nel PATH.

CISA ha aggiunto al catalogo Known Exploited Vulnerabilities tre falle che interessano IBM Langflow, N-able N-central e Apache Tomcat, confermando che le vulnerabilità vengono sfruttate in attacchi reali. Parallelamente, AWS ha corretto un problema nel servizio gestito Amazon Bedrock AgentCore che permetteva di richiamare direttamente gli strumenti configurati senza passare attraverso il modello e i relativi controlli, oltre a due vulnerabilità di ricerca del percorso eseguibile in Kiro IDE e Kiro CLI per Windows. Gli avvisi collegano piattaforme RMM, framework per agenti AI, application server e strumenti di sviluppo attraverso un unico rischio: funzionalità legittime capaci di eseguire codice diventano pericolose quando autenticazione, validazione degli input o risoluzione dei binari possono essere aggirate.

CISA conferma gli attacchi contro Langflow, N-central e Tomcat

Nel nuovo aggiornamento del catalogo KEV, CISA ha inserito CVE-2026-9198, CVE-2026-18556 e CVE-2026-34486, indicando l’esistenza di evidenze affidabili di sfruttamento attivo. L’ingresso nel catalogo non dipende soltanto dal punteggio CVSS, ma dalla conferma che attori malevoli stanno utilizzando concretamente le falle. Le organizzazioni devono quindi spostare queste vulnerabilità nelle fasce più alte delle code di remediation, verificando non soltanto la disponibilità della patch ma anche l’eventuale esposizione pregressa dei sistemi. La nuova tornata rafforza il ruolo del KEV come segnale operativo, già emerso quando CISA aveva inserito SharePoint e Check Point tra le vulnerabilità sfruttate e nelle successive campagne che hanno interessato FortiOS, VeloCloud e Fastjson. Nel caso attuale, le tre falle appartengono a superfici differenti: Langflow espone direttamente l’esecuzione di codice Python, N-central controlla gli endpoint dei clienti degli MSP e Tomcat protegge le comunicazioni interne dei cluster applicativi. La loro presenza nello stesso aggiornamento mostra come gli attaccanti si muovano contemporaneamente tra AI, gestione remota e infrastrutture Java, privilegiando prodotti capaci di amplificare l’accesso iniziale.

Langflow concatena autenticazione assente ed esecuzione di codice Python

CVE-2026-9198, con punteggio CVSS 9,8, interessa Langflow OSS dalla versione 1.0.0 alla 1.10.0 e permette a un attaccante remoto non autenticato di ottenere l’esecuzione arbitraria di codice su una configurazione predefinita. La catena sfrutta due endpoint distinti. Il primo, /api/v1/auto_login, poteva emettere un bearer token con privilegi SUPERUSER a qualsiasi soggetto capace di raggiungere il servizio. Il secondo, /api/v1/validate/code, utilizzava exec() per analizzare codice Python fornito dall’utente e ne eseguiva decoratori, argomenti predefiniti e annotazioni già durante la definizione delle funzioni. Un attaccante poteva quindi ottenere il token amministrativo e usarlo per sottoporre codice malevolo al validatore, acquisendo il controllo del processo Langflow e delle risorse accessibili con i suoi privilegi. Nel bollettino di sicurezza ufficiale di IBM dedicato alla falla, l’azienda indica l’aggiornamento a Langflow 1.10.1 e precisa che non sono disponibili mitigazioni alternative. La vulnerabilità conferma il rischio già evidenziato quando CISA aveva segnalato exploit contro Langflow insieme alle campagne WordPress: una piattaforma pensata per costruire flussi e agenti AI può diventare una superficie RCE quando componenti destinati alla sperimentazione rimangono accessibili dalla rete senza controlli coerenti. Le istanze aggiornate devono comunque essere esaminate per individuare token anomali, componenti personalizzati, processi figli inattesi e connessioni in uscita avviate dal servizio.

N-central aggiunge al KEV anche la prima falla di autenticazione

CVE-2026-18556 interessa N-able N-central fino alla versione 2026.1 e consente di aggirare l’autenticazione attraverso un percorso alternativo, ottenendo accesso alla piattaforma senza credenziali valide. La vulnerabilità era stata corretta nelle versioni 2026.2 e 2026.3, ma l’analisi dell’incidente ha successivamente rivelato un secondo vettore, identificato come CVE-2026-18577, capace di superare la prima correzione. CISA aveva già inserito CVE-2026-18577 nel KEV il 3 agosto e ora aggiunge anche il difetto originario, confermando lo sfruttamento di entrambe le condizioni collegate. Nella ricostruzione ufficiale pubblicata da N-able, l’azienda spiega che gli attaccanti hanno ottenuto accesso amministrativo remoto ai server e utilizzato le funzioni della piattaforma per raggiungere gli endpoint gestiti. La build da considerare corretta resta N-central 2026.3.1.7, perché chiude anche il percorso individuato dopo la prima patch. L’impatto supera quello di una normale violazione applicativa: un server RMM compromesso possiede già agenti distribuiti, privilegi amministrativi e canali di supporto verso numerosi clienti. La criticità delle piattaforme N-able era già emersa con precedenti falle e violazioni dei server dedicati alla gestione remota. Gli MSP devono aggiornare il server, controllare account e ruoli amministrativi, ricostruire le sessioni Take Control e cercare servizi, tunnel o strumenti distribuiti sugli endpoint prima dell’applicazione del hotfix.

Tomcat espone i dati dei cluster dopo una patch incompleta

CVE-2026-34486 riguarda Apache Tomcat 11.0.20, 10.1.53 e 9.0.116 e nasce da un errore nella correzione di CVE-2026-29146. La vulnerabilità precedente interessava EncryptInterceptor, componente utilizzato dal sistema di clustering Tribes per cifrare i messaggi scambiati tra i nodi. La prima patch poteva essere aggirata, permettendo a determinate comunicazioni di attraversare il cluster senza la protezione crittografica attesa e creando un rischio di esposizione dei dati sensibili. La pagina ufficiale delle vulnerabilità di Apache Tomcat indica come versioni corrette 11.0.21, 10.1.54 e 9.0.117. La presenza della falla nel KEV segnala che l’aggiramento non è rimasto soltanto teorico, anche se CISA non attribuisce pubblicamente gli attacchi a un gruppo specifico. Il rischio riguarda soprattutto architetture che utilizzano clustering Tomcat in reti non completamente affidabili o nelle quali un attaccante abbia già ottenuto una posizione utile per osservare o manipolare il traffico tra nodi. Gli amministratori devono verificare la versione effettivamente utilizzata dalle applicazioni, comprese le copie incorporate in prodotti enterprise, appliance e distribuzioni Java mantenute da terze parti. Aggiornare soltanto il pacchetto di sistema può non bastare quando l’application server viene distribuito insieme al prodotto o all’interno di immagini container non ricostruite.

Bedrock AgentCore eseguiva strumenti senza mediazione del modello

AWS ha corretto CVE-2026-18830 nell’API InvokeHarness di Amazon Bedrock AgentCore harness, servizio utilizzato per eseguire agenti e collegarli a strumenti configurati dagli sviluppatori. Il problema derivava da una validazione insufficiente dell’ultimo messaggio ricevuto dall’API. Quando la richiesta terminava con un blocco tool-use, il ciclo degli eventi poteva interpretarlo come una decisione già prodotta dal modello e invocare direttamente lo strumento indicato. Un utente autenticato in grado di chiamare InvokeHarness poteva quindi aggirare l’invocazione del modello e i controlli associati alla sua mediazione, chiedendo l’esecuzione di una funzione configurata sul relativo harness. L’impatto restava limitato agli strumenti effettivamente disponibili: un harness privo di tool non poteva eseguire operazioni, mentre uno configurato con un insieme ristretto rimaneva confinato a quelle capacità. Nel bollettino AWS relativo a CVE-2026-18830, il gruppo spiega di avere applicato entro il 31 luglio 2026 una validazione server-side che rifiuta i blocchi tool-use inseriti dal chiamante nell’ultimo messaggio. La mitigazione è automatica e non richiede aggiornamenti da parte dei clienti. Il difetto rafforza quanto emerso con le precedenti vulnerabilità di AgentCore e Strands Agents: le decisioni che autorizzano strumenti ad alto impatto non possono dipendere da contenuti controllabili dal chiamante o dal modello, ma devono essere validate in modo deterministico dal runtime.

Kiro eseguiva binari collocati nelle directory dei progetti

Le vulnerabilità CVE-2026-18656 e CVE-2026-18657 interessano rispettivamente Kiro IDE per Windows dalla versione 1.0.0 alla 1.0.212 e Kiro CLI per Windows nelle versioni precedenti alla 2.10.0. Il problema riguarda un elemento non controllato nel percorso di ricerca degli eseguibili. Quando un utente locale apriva una directory di progetto costruita in modo malevolo, Kiro poteva risolvere e avviare un binario collocato nella cartella prima dell’eseguibile legittimo presente nel PATH di sistema. Un repository scaricato, clonato o ricevuto da terzi poteva quindi includere un file con il nome atteso da una funzione dell’IDE o della CLI e ottenere esecuzione di codice nel momento in cui il progetto veniva elaborato. Il bollettino AWS dedicato alle due falle di Kiro indica come versioni corrette Kiro IDE 1.0.228 e Kiro CLI 2.10.0, senza workaround alternativi. L’attacco richiede che la vittima apra una directory preparata dall’aggressore, ma sfrutta un comportamento particolarmente pericoloso negli strumenti di sviluppo, dove repository non affidabili vengono analizzati, indicizzati ed eseguiti con frequenza. Kiro era già finito al centro dell’attenzione quando pagine web avvelenate potevano indurre l’agente a eseguire comandi. Le nuove CVE mostrano un vettore differente ma complementare: anche eliminando la prompt injection, l’ambiente resta esposto se la risoluzione dei programmi assegna priorità alla directory controllata dal progetto. Gli sviluppatori devono aggiornare entrambe le componenti e trattare i repository sconosciuti come contenuti attivi, aprendoli in ambienti isolati quando provenienza e integrità non possono essere verificate.