1. Un protocollo nato per un mondo che non esiste più
DICOM (Digital Imaging and Communications in Medicine) è lo standard che dagli anni ’90 regge l’intera interoperabilità dell’imaging medico: dalla TAC allo scanner PACS, passando per ogni workstation di refertazione. È stato progettato in un’epoca in cui le reti ospedaliere erano isolate, chiuse, basate su fiducia implicita tra i nodi. Nessuna crittografia obbligatoria, nessuna autenticazione forte, nessuna validazione formale dei dati: il protocollo si fidava della rete, non del contenuto.
Quel presupposto è invecchiato male. Oggi i sistemi PACS comunicano ancora in gran parte in chiaro sulle porte TCP 104 e 11112, e anche dove lo standard prevede un profilo di sicurezza TLS (PS3.15, porta 2762), l’adozione reale resta marginale. Il risultato è un’infrastruttura clinica che espone contemporaneamente dati sensibili dei pazienti, continuità operativa degli ospedali e — nei casi più estremi — l’affidabilità stessa della diagnosi.
2. Un’esposizione misurabile, non teorica
Non si tratta di un rischio astratto: è stato misurato, ripetutamente, per quasi un decennio.
- 2017 — una scansione dell’intero spazio IPv4 condotta dal Massachusetts General Hospital (ospedale universitario di Boston, affiliato a Harvard) in 22 ore ha individuato 2.782 server DICOM non protetti a livello globale.
- 2018 — un ricercatore di McAfee (azienda statunitense di sicurezza informatica), usando Shodan (motore di ricerca specializzato nell’indicizzazione di dispositivi connessi a Internet), ha trovato oltre 1.100 server DICOM esposti senza alcuna protezione, arrivando a scaricare immagini di un paziente ignaro e a stamparne in 3D il bacino.
- 2019-2020 — l’indagine di Greenbone Networks (azienda tedesca di vulnerability management, confermata da ProPublica e TechCrunch, testate giornalistiche statunitensi specializzate rispettivamente in giornalismo investigativo e tecnologia) ha rivelato oltre un miliardo di immagini mediche liberamente accessibili online, per la semplice abitudine di collegare i server PACS direttamente a Internet senza password, firewall o VPN.
- 2024-2025 — Trend Micro (multinazionale giapponese di cybersecurity) ha censito 3.627 server DICOM esposti in 334 organizzazioni sanitarie: solo lo 0,14% cifrava il traffico in TLS, il 99,56% accettava connessioni senza validare l’AE Title. Il 31% di questi server era ospitato su cloud pubblico, e il 44% condivideva la stessa configurazione software (spesso DCMTK) — condizione che trasforma un singolo exploit in una vulnerabilità sistemica su scala di filiera.
Il pattern è chiaro: la superficie d’attacco non si è ridotta migrando al cloud, si è semplicemente spostata.
3. Il difetto architetturale: i file “poliglotti”
Alla debolezza di rete si somma una fragilità strutturale del formato stesso. Ogni file DICOM (.dcm) inizia con un preambolo di 128 byte che lo standard lascia deliberatamente indefinito — il marcatore identificativo “DICM” compare solo dopo, all’offset 128. Una scelta pensata per la compatibilità con formati ibridi, che è diventata la vulnerabilità CVE-2019-11687.
Nel 2019 i ricercatori di Cylera (azienda di sicurezza informatica specializzata nella protezione dei dispositivi medici connessi) hanno dimostrato PEDICOM: un file DICOM che nasconde nel preambolo l’header di un eseguibile Windows (PE). Il visualizzatore PACS ignora i 128 byte e mostra l’immagine come sempre; se lo stesso file viene interpretato dal sistema operativo come eseguibile, attiva il payload. Nessuna anomalia visibile, nessun allarme per l’antivirus o l’EDR, che tipicamente escludono le immagini mediche dalle scansioni profonde.
Praetorian (società statunitense di sicurezza offensiva e penetration testing) ha poi esteso il concetto a Linux con ELFDICOM e con una variante “shebang” ancora più semplice: bastano 119 caratteri nel preambolo per invocare uno script remoto ed eseguire codice arbitrario. La mitigazione più ovvia — eliminare la tolleranza sul preambolo — non è praticabile: invaliderebbe retroattivamente milioni di file clinici esistenti.
4. Dall’accesso all’esfiltrazione: come si muove un attacco reale
Una volta dentro la rete, gli attaccanti non hanno bisogno di strumenti esotici: usano lo stesso toolkit open-source (DCMTK) impiegato ogni giorno dal personale tecnico.
L’AE Title, l’identificatore che il PACS usa per riconoscere un nodo affidabile, è una stringa di testo priva di password: si intercetta con uno sniffer di rete (le associazioni DICOM viaggiano in chiaro) o si forza con dizionari. Da lì, echoscu mappa l’infrastruttura, findscu enumera i pazienti tramite query C-FIND senza controlli granulari sugli accessi, e dcmsend/dcmodify permettono di iniettare file fraudolenti — inclusi i poliglotti descritti sopra — direttamente nel PACS. In parallelo, tecniche di fuzzing (Radamsa per il black-box, AFLNet per il grey-box guidato dalla copertura del codice) continuano a scoprire nuove condizioni di crash sfruttabili nei parser.
Il denominatore comune: nessuna di queste tecniche richiede lo sfruttamento di uno zero-day sofisticato. Sfruttano l’assenza di autenticazione forte e di crittografia che il protocollo porta con sé da trent’anni.
5. Quando l’attacco smette di essere solo un problema IT
Due episodi segnano il punto in cui la vulnerabilità DICOM smette di essere un rischio di conformità e diventa un rischio clinico diretto.
Il ransomware chirurgico. Nel 2023 il gruppo BlackCat/ALPHV (collettivo di cybercriminali che opera con un modello Ransomware-as-a-Service, cioè affitta i propri strumenti di estorsione ad altri attori) ha colpito il Lehigh Valley Health Network (rete ospedaliera della Pennsylvania, USA) puntando specificamente ai server PACS radiologici, non ai sistemi IT generici. Dopo aver esfiltrato le immagini tramite query C-FIND/C-MOVE, ha cifrato i server e, di fronte al rifiuto di pagare, ha pubblicato online le scansioni di pazienti oncologici con i relativi dati anagrafici. Gli studi sugli effetti di questi downtime sono inequivocabili: i ritardi indotti nelle emergenze tempo-dipendenti (ictus, arresto cardiaco) si traducono in un aumento misurabile della mortalità ospedaliera.
La manipolazione algoritmica. Nel 2019 un team dell’Università Ben-Gurion (ateneo israeliano con un centro di ricerca in cybersecurity tra i più attivi al mondo) ha dimostrato CT-GAN: un attacco man-in-the-middle che intercetta una scansione CT/MRI in transito sulla rete locale (priva di TLS e di firme digitali) e usa una rete generativa avversaria per inserire o rimuovere noduli polmonari in tempo reale, prima che l’immagine raggiunga il PACS. Nei test, i radiologi hanno diagnosticato erroneamente un cancro nel 99% delle scansioni manipolate con iniezione, e hanno dichiarato sani il 94% dei pazienti con tumori digitalmente rimossi — anche dopo essere stati avvertiti che alcune immagini erano falsificate. Gli strumenti di screening basati su IA difensiva hanno fallito il 100% delle volte.
A quel punto, la sicurezza informatica non protegge più solo i dati: protegge l’affidabilità della diagnosi stessa.
6. Alcune vulnerabilità recenti, in sintesi
| CVE | Software | Impatto |
|—|—|—|
| CVE-2023-33466 | Orthanc (< 1.12.0) | Sovrascrittura file arbitraria → RCE via Lua |
| CVE-2026-50003 | DCMTK (< 3.7.0) | Path traversal, CVSS 9.8 |
| CVE-2024-25578 | MicroDicom Viewer | Buffer overflow all’apertura del file |
| CVE-2026-3650 | GDCM 3.2.2 | Memory leak → DoS |
| CVE-2026-5437/45 | Orthanc (< 1.12.11) | Nove falle, da GZIP bomb a heap overflow |
| CVE-2026-17264 | RadiAnt Viewer | Heap out-of-bounds write su JPEG malformato |
| CVE-2026-12473 | OHIF Web Viewer | SSRF con leak di token OIDC |
Il filo conduttore: la maggior parte dei bug si concentra nell’ingestion e nella decodifica delle immagini, cioè esattamente nel punto in cui un file “clinico” viene trasformato in dato eseguito dal sistema.
7. L’approccio di D/Vision Lab: la sicurezza come requisito di progettazione
Le contromisure a livello di infrastruttura ospedaliera esistono e sono note — segmentazione di rete, TLS end-to-end, monitoraggio comportamentale. Ma buona parte del rischio descritto finora nasce a monte, nel modo in cui il software di imaging viene progettato. Ed è qui che, come team che costruisce quotidianamente strumenti DICOM, scegliamo di intervenire.
- Uno stack che evita per costruzione un’intera classe di vulnerabilità. Gran parte dei CVE più gravi degli ultimi anni (Orthanc, DCMTK, GDCM) nasce dalla gestione manuale della memoria in librerie C/C++ scritte decenni fa. Il nostro motore di imaging Lumen, basato su Cornerstone3D e sviluppato in ambiente web moderno, elimina alla radice i buffer overflow e le corruzioni di heap che affliggono i parser legacy: non è un livello di protezione aggiunto sopra il rendering, è una conseguenza della scelta tecnologica.
- Accesso controllato invece di esposizione diretta. La nostra piattaforma D/Vision, il viewer cloud che sviluppiamo per l’archiviazione, la condivisione e il second opinion, non replica il modello “PACS aperto in rete” che ha causato la maggior parte delle esposizioni documentate: l’accesso alle immagini passa sempre da autenticazione e permessi granulari, mai da una porta DICOM raggiungibile direttamente da Internet.
- Rendering server-side quando il dato non deve mai lasciare il perimetro. Per i contesti in cui la proprietà intellettuale o la riservatezza clinica sono vincoli non negoziabili, la nostra architettura di Server-Side Rendering (di cui abbiamo scritto anche in un approfondimento tecnico separato) permette di visualizzare dataset DICOM completi senza che i dati grezzi transitino mai verso il client: al browser arrivano solo pixel, non file.
- Competenza end-to-end, non solo su imaging o solo su sicurezza. Il team unisce competenze di visualizzazione 3D (VTK, three.js), gestione nativa dello standard DICOM e ingegneria web moderna: una combinazione che ci permette di valutare il rischio di un progetto di imaging clinico nel suo complesso, invece di lasciare che il tema sicurezza resti un capitolo separato affidato a terzi a integrazione già avvenuta.
Le protezioni a livello di rete restano indispensabili e competono in larga parte a chi gestisce l’infrastruttura ospedaliera — ma la parte di rischio che dipende dal software, dalla progettazione della piattaforma di imaging fino alle scelte architetturali di rendering, è quella su cui costruiamo la nostra proposta.
8. Conclusione
DICOM continua a essere, allo stesso tempo, lo strumento diagnostico primario della medicina moderna e — per costruzione — una delle superfici d’attacco più trascurate del settore sanitario. Non per un singolo difetto risolvibile con una patch, ma per la somma di tre debiti tecnici distinti: infrastrutture esposte per negligenza di configurazione, un formato file che tollera l’ambiguità per compatibilità storica, e parser scritti in C/C++ che ereditano decenni di rischio di gestione della memoria.
Chi progetta software per l’imaging medico — noi compresi — non può trattare questi tre livelli separatamente. La stessa logica che ci ha guidato nella scelta tra architetture di rendering server-side e client-side, dove la domanda di fondo è sempre “chi ha accesso al dato grezzo e a quali condizioni”, si applica qui su scala ben più ampia: finché il trasporto e la validazione dei file DICOM resteranno un’eccezione anziché un requisito di base, l’immagine medica continuerà a essere, insieme, la prova diagnostica più preziosa e l’arma più silenziosa a disposizione di chi la vuole compromettere.
