What the advisory actually says
On June 30, 2026, the Cybersecurity and Infrastructure Security Agency — the arm of the U.S. Department of Homeland Security that coordinates critical-infrastructure defense — published advisory ICSMA-26-181-01. It describes five vulnerabilities in OFFIS DCMTK, an open-source collection of DICOM libraries and utilities maintained by the German research institute OFFIS.
DCMTK is not a niche tool. It is one of the most widely used DICOM implementations in the world, downloaded roughly 100,000 times a year and embedded inside commercial viewers, archives, and worklist and storage servers across the imaging ecosystem. That reach is exactly why the advisory matters: a flaw in shared plumbing propagates into every product that builds on it.
The vulnerabilities affect DCMTK versions before 3.7.0, with version 3.7.1 or later resolving all five. According to the advisory, successful exploitation could allow an attacker to write files outside the intended output directory, gain unauthorized access to worklist records, exhaust memory, or crash affected client or server processes. CISA notes the flaws were reported to the agency in May 2026 by independent security researcher Abhinav Agarwal.
The five flaws, in plain terms
One vulnerability is rated critical; four are rated high. All are network-based and, per the advisory's CVSS vectors, require no authentication and no user interaction to attempt.
| CVE | Severity (CVSS v3.1) | What it allows |
|---|---|---|
| CVE-2026-50003 | Critical — 9.8 | A malicious or compromised server makes a DCMTK client write files outside the chosen output directory (path traversal). |
| CVE-2026-52868 | High — 8.2 | Path traversal lets a client read worklist records outside its intended per-application storage area — the scheduling and procedure metadata that can contain patient PHI. |
| CVE-2026-50254 | High — 7.5 | Memory leak via crafted connection requests, gradually exhausting memory and disrupting availability. |
| CVE-2026-35505 | High — 7.5 | A second memory-leak path leading to service crashes under repeated connection attempts. |
| CVE-2026-44628 | High — 7.5 | Type confusion that crashes the worklist server via crafted queries. |
Two themes stand out for imaging leaders. The critical file-write flaw is an integrity problem — an attacker could tamper with where files land. And the worklist flaw is a confidentiality problem — worklist metadata routinely carries names, IDs, and procedure details, so unauthorized access is a PHI exposure, not just a nuisance crash. CISA is not aware of public exploitation, but the fix is straightforward: update to a patched build and follow the agency's network-hardening guidance.
Why this is a supply-chain story, not an AI story
None of these CVEs live in an AI reporting product. They live in the DICOM libraries underneath the whole department. But that is precisely the lesson for anyone buying AI CT reporting: your real threat surface is the sum of the components your vendors build on, not just the code they wrote themselves. An AI tool that ingests studies over DICOM inherits the security of that pipeline.
This is also why threat posture and HIPAA compliance are different questions. Compliance is the legal and administrative baseline — safeguards, accountability, business-associate agreements. Threat and vulnerability posture is the technical reality of how a system resists attack: what it depends on, how large its attack surface is, and how fast it patches. A vendor can satisfy the compliance checklist and still ship software built on an unpatched, vulnerable library. We cover the compliance side separately in Is AI Radiology Reporting HIPAA Compliant? — this article is about the other half of due diligence.
The security questions to ask any AI CT reporting vendor
Use the advisory as a prompt. If a single shared DICOM component can expose PHI or crash a service, then how a vendor handles data, structures its deployment, and manages its dependencies deserves direct questions. Four areas to press on:
1. PHI flow and data handling
Where does patient data go once a study enters the system? Is it de-identified for any processing? Where is it stored, for how long, and what happens to it after the report is generated? Ask for a data-flow diagram, not a reassurance.
2. Deployment model — cloud vs on-prem
Is the tool on-premise, single-tenant private cloud, or multi-tenant cloud? Multi-tenant is not inherently unsafe, but it changes the blast radius and the isolation questions. Match the model to your risk tolerance and your existing network segmentation.
3. Software bill of materials and third-party components
Does the vendor maintain an SBOM? Do they know whether they ship a DICOM library like DCMTK, and which version? A vendor who can answer this quickly is one who tracks their own supply chain — the exact discipline this advisory rewards.
4. Vulnerability tracking and patch cadence
How does the vendor learn about advisories like ICSMA-26-181-01, and how fast do they patch? Ask for their disclosure and remediation timelines. Speed of response is often a better signal than the absence of any past CVE.
Compliance posture vs threat posture
The two are complementary, and a thorough buyer evaluates both. One tells you the vendor meets the rules; the other tells you how the system behaves when someone tries to break it.
| Compliance posture | Threat / vulnerability posture | |
|---|---|---|
| Question it answers | Does the vendor meet the rules? | How does the system resist attack? |
| Evidence | BAAs, HIPAA safeguards, audit certs | SBOM, patch cadence, deployment model, data-flow |
| Fails when | Paperwork is incomplete | A dependency ships an unpatched CVE |
| What this advisory tests | — | Do you know your DICOM components and patch them? |
Where xAID fits
xAID's approach is built for exactly this kind of scrutiny. The foundation-model pipeline produces a structured, comprehensive report draft; xAID's in-house radiologist reviews every preliminary before delivery, and the client's own reading radiologist signs the final — radiologists in the loop at both ends, so no automated output reaches a chart unreviewed. On the security side, the questions above are the ones we expect buyers to ask: how PHI flows, where it is stored, which deployment model fits your network, and how third-party components are tracked and patched. An advisory like this one is not a reason to slow AI adoption; it is a reason to do the due diligence properly and pick a vendor who welcomes the questions.
Frequently asked questions
What did the CISA DICOM advisory warn about in June 2026?
On June 30, 2026, CISA issued advisory ICSMA-26-181-01 describing five vulnerabilities in OFFIS DCMTK, an open-source DICOM toolkit embedded in many commercial imaging products. One flaw (CVE-2026-50003) is rated critical with a CVSS v3.1 base score of 9.8, and four others are rated high. The vulnerabilities affect DCMTK versions before 3.7.0 (fixed in v3.7.1) and, if exploited, could let an attacker write files outside the intended directory, expose worklist data containing protected health information, exhaust memory, or crash imaging services.
Is this a vulnerability in AI radiology software specifically?
No. The advisory concerns OFFIS DCMTK, a widely used open-source DICOM library, not an AI reporting product. But because DCMTK is embedded across the imaging ecosystem — viewers, archives, worklist and storage servers — any AI CT reporting workflow sits downstream of the same DICOM plumbing. The advisory is a reminder that imaging security is a supply-chain question: your exposure depends on the components your vendors build on, not just their own code.
What security questions should you ask an AI CT reporting vendor?
Ask how PHI flows through the system and where it is stored; whether deployment is on-premise, in a private cloud, or multi-tenant; what happens to studies after a report is generated; how the vendor handles software bills of materials and third-party components like DICOM libraries; and how they track and patch published vulnerabilities. The goal is to understand the threat surface — data handling, PHI flow, and deployment model — not just to collect a compliance certificate.
How is threat and vulnerability posture different from HIPAA compliance?
HIPAA compliance is a legal and administrative baseline covering how PHI is safeguarded and who is accountable. Threat and vulnerability posture is the technical reality of how a system resists attack — the components it depends on, its attack surface, how quickly it patches, and how it isolates data. A vendor can be HIPAA-compliant on paper and still ship software built on an unpatched, vulnerable DICOM library. Both matter, and buyers should evaluate them separately.
Source: CISA advisory ICSMA-26-181-01 (June 30, 2026), as reported by Radiology Business and The HIPAA Journal. DCMTK background from OFFIS. Figures are rounded as reported.