DifyTap: 4 CVE svelano isolamento cross-tenant…

Zafran Security ha divulgato DifyTap, quattro vulnerabilità in Dify che permettevano lettura di conversazioni e file cross-tenant. Tre patchate in 1.14.2, una ancora

Zafran Security ha divulgato il 22 giugno 2026 quattro vulnerabilità nel bundle DifyTap che colpiscono Dify, piattaforma open-source per workflow AI con oltre 146.000 stelle GitHub. Due sono critical severity, due non richiedevano autenticazione e tre avevano impatto cross-tenant sul servizio cloud multi-tenant, permettendo a un attaccante di leggere conversazioni, file e reindirizzare flussi di dati AI tra tenant distinti. La divulgazione arriva a distanza di un mese dal rilascio della versione 1.14.2 che ha corretto tre delle quattro falle, e riapre una ferita già solcata dalla ricerca Imperva di maggio 2026 sullo stesso pattern di isolamento insufficiente.

Punti chiave

Zafran Security ha divulgato quattro vulnerabilità, denominate DifyTap, in Dify: due critical severity, due senza autenticazione richiesta, tre con impatto cross-tenant sul cloud multi-tenant.
CVE-2026-41947 (CVSS 9.1) e CVE-2026-41948 (CVSS 9.4) sono le due falle critical: la prima permette reindirizzamento persistente di messaggi a trace provider controllato dall'attaccante, la seconda consente path traversal nel Plugin Daemon API interno.
Tre vulnerabilità sono state patchate in Dify 1.14.2, rilasciata il mese precedente alla divulgazione; il fix per CVE-2026-41948 è atteso nella prossima release.
La ricerca Imperva del maggio 2026 aveva già identificato vulnerabilità cross-tenant in Dify con pattern simile, indicando un problema sistemico di isolamento nella piattaforma.

Le quattro falle: da trace hijacking a lettura file con solo UUID

CVE-2026-41947 è un authorization bypass con CVSS 9.1 che sfrutta la mancanza di tenant ownership checks negli endpoint di trace configuration. Un attaccante autenticato come editor può configurare il tracing per qualsiasi applicazione pubblica, reindirizzando tutti i messaggi e le risposte a un LLM trace provider controllato dall'attaccante. Zafran Security descrive il meccanismo come un "canale di esfiltrazione persistente": non è una lettura una tantum, ma un intercept continuo del flusso conversazionale.

CVE-2026-41948, con CVSS 9.4, è il punteggio più alto del bundle. È un path traversal nel Plugin Daemon API interno che permette di attraversare path al di fuori del tenant autorizzato usando sequenze di punti non codificate negli identificatori di task o parametri filename manipolati, accedendo a endpoint interni privati come interfacce di debug. Questa è l'unica delle quattro vulnerabilità senza fix rilasciato al momento della divulgazione.

CVE-2026-41949 (CVSS 7.5/5.9 secondo le metriche NVD) riguarda l'endpoint di file preview: qualsiasi utente autenticato può leggere fino a 3.000 caratteri di qualsiasi documento caricato attraverso tutti i tenant e i workspace, usando solo l'UUID del file. La soglia dei 3.000 caratteri è un limite tecnico che non mitiga l'impatto: basta conoscere l'UUID, un identificatore spesso esposto in log, URL o risposte API.

CVE-2026-41950 (CVSS 6.5) è un authorization bypass nell'endpoint chat-messages che permette a utenti autenticati di leggere il contenuto completo di file caricati da altri utenti nello stesso tenant, fornendo un UUID arbitrario nell'array files della richiesta. Secondo NVD il fix è in versione 1.14.0; Zafran colloca il bundle DifyTap nel fix 1.14.2. La discrepanza non è risolvibile senza accesso alle release notes complete, e il dossier non la chiarisce.

La dipendenza nascosta: PDFium vulnerabile da due anni

La stack di parsing file di Dify utilizzava una versione di PDFium vulnerabile a CVE-2024-5846, un use-after-free con CVSS 8.8 divulgato nel 2024. Zafran Security la cita come componente vulnerabile nella catena di elaborazione documenti della piattaforma, ma il dossier non documenta se questa dipendenza sia stata sfruttata in combinazione con le falle DifyTap o rappresenti un vettore aggiuntivo indipendente. La presenza di una libreria di parsing con due anni di ritardo sulle patch indica un problema di gestione delle dipendenze upstream che i tradizionali scanner di vulnerabilità nei container possono non catturare se le immagini di deployment differiscono tra ambienti.

Il contesto: da Imperva a Zafran, un pattern che si ripete

Il 18 maggio 2026 Imperva aveva già pubblicato una ricerca su vulnerabilità cross-tenant in Dify, con pattern di isolamento insufficiente su file upload e sandbox. Cybernews aveva ripreso la storia il 20 maggio, riportando oltre 10 milioni di Docker pulls come indicatore di diffusione. Le falle Imperva e quelle Zafran sono distinte: non c'è sovrapposizione di CVE o di ricercatori. Ma la convergenza di due team indipendenti sullo stesso target con lo stesso tipo di errore architetturale — mancanza di ownership checks cross-tenant — trasforma la singola advisory in un campanello d'allarme settoriale.

"Two were critical severity, two required no authentication, and three carried cross-tenant impact on Dify's multi-tenant cloud service, allowing one customer's data to be exposed to another" — Ido Shani e Gal Zaban, Zafran Security

L'assenza di autenticazione per due delle quattro vulnerabilità è particolarmente critica perché Dify Cloud permette registrazione gratuita senza verifica identità. Un attaccante può creare account a piacimento e operare dall'interno del perimetro cloud, con privilegi minimi ma sufficienti a innescare tre delle quattro falle. La superficie di attacco non è quella di un sistema blindato con accesso esterno zero: è quella di una piattaforma aperta per design, dove l'isolamento tra tenant è l'unico muro che separa i dati di aziende diverse.

Perché DifyTap sfugge agli strumenti standard

Zafran Security ha sollevato un punto specifico sulla visibilità delle vulnerabilità nei container: "DifyTap demonstrates where the challenge lies in vulnerability visibility, particularly in container images, where differences between deployments can create visibility gaps that traditional scanners cannot detect". La piattaforma Dify è distribuita via Docker con architettura modulare: API server, worker, plugin daemon, database e proxy sono servizi separati. Un aggiornamento del plugin daemon può non propagarsi istantaneamente a tutte le istanze self-hosted, o essere mascherato da personalizzazioni del deployment che alterano il fingerprint riconosciuto dagli scanner.

Il problema non è tecnicamente nuovo, ma si amplifica nel contesto AI: le piattaforme low-code/no-code per workflow agentic centralizzano dati ad alta sensitività — chiavi API di provider LLM, workflow proprietari, conversazioni utente — senza aver ereditato le hardening practices maturate in anni di SaaS tradizionale. La velocità di rilascio delle feature supera quella della revisione architetturale su isolamento, e il risultato è un "tenant illusion" che promette separazione ma implementa controlli insufficienti.

Cosa fare adesso

Aggiornare immediatamente a Dify 1.14.2 per chiudere CVE-2026-41947, CVE-2026-41949 e CVE-2026-41950; CVE-2026-41948 resta senza patch confermata e richiede monitoraggio delle release future.
Verificare la presenza di trace configuration non autorizzate nelle applicazioni Dify pubbliche: un attaccante potrebbe aver già reindirizzato flussi a provider esterni senza lasciare tracce evidenti nei log standard.
Controllare gli UUID dei file caricati: se esposti in URL, risposte API o log, sono stati utilizzabili come unici requisiti per la lettura cross-tenant fino a 3.000 caratteri o contenuto completo same-tenant.
Rivedere la catena di parsing dei documenti: la dipendenza da PDFium vulnerabile a CVE-2024-5846 richiede verifica della versione effettivamente in esecuzione, indipendentemente dal fix DifyTap.

Un settore che corre più veloce di chi lo difende

DifyTap non è una catena di exploit sofisticati: è una serie di ownership check mancanti in endpoint critici, combinata con una dipendenza non aggiornata. La semplicità è il sintomo. Quando due team di ricerca indipendenti trovano lo stesso errore architetturale a distanza di un mese su una piattaforma con 146.000 stelle GitHub, il problema non è più il singolo vendor ma il settore che ha trasformato l'AI tooling in infrastruttura critica senza trasferirvi i controlli di isolamento maturati altrove. I container nascondono le differenze di deployment, le piattaforme AI nascondono le complessità del multi-tenant dietro interfacce semplici, e gli scanner non vedono ciò che non è statico nell'immagine.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti