Back Trendmicro A Hidden Vulnerability in Healthcare: Exposed DICOM Servers and the Risk to Patient Data
Modern healthcare relies heavily on digital imaging. From X-rays to MRIs, CT scans to ultrasounds, medical images are captured, stored, retrieved, transmitted, processed, printed, and viewed using a universal standard called Digital Imaging and Communications in Medicine (DICOM). This enables integration and interoperability across devices and systems from multiple manufacturers. However, this broad connectivity comes with unique risks. “Physical healthcare has converged with cyberspace. As a result secondary infections abound; infections that manifest in cyberspace can have critical care implications for patients,” says Tom Kellermann, Vice President of AI Security and Threat Research at TrendAI™.
Our investigation of internet-facing DICOM servers reveals that thousands of medical imaging systems are exposed to the public internet, often with minimal or no security controls. This exposure can create opportunities for malicious actors to access sensitive patient data, manipulate medical records, or disrupt critical healthcare operations.
This research explores findings from our analysis of 3,627 exposed DICOM servers discovered across more than 100 countries using Shodan.io internet scanning between November and December 2025. The exposed DICOM data reveals cybersecurity risk exposure across the global healthcare infrastructure, with serious implications for patient privacy, regulatory compliance, and clinical safety. Among our findings, we observed that:
These make attack scalability a serious risk. We present the data, examine the technical attack surface, and outline recommended actions for healthcare organizations, cloud providers, and DICOM software vendors.
DICOM is the international standard for transmitting, storing, retrieving, printing, processing, and displaying medical imaging information. Developed in the 1980s and continuously updated , DICOM defines both a file format for medical images and a network protocol for communication between imaging devices and clinical systems. In practice, DICOM enables interoperability across a wide ecosystem of equipment and software, including scanners, servers, workstations, printers, network hardware, and Picture Archiving and Communication Systems (PACS), from multiple manufacturers.
At the core of DICOM is the Information Object Definition (IOD), which encodes both pixel data and metadata produced by a wide variety of medical imaging devices used in procedures such as computed tomography (CT), magnetic resonance imaging (MRI), ultrasound, X-ray, fluoroscopy, angiography, mammography, positron emission tomography (PET), and endoscopy. This means the “image” is not just an image, it is a data package that can include patient identifiers, study details, timestamps, device identifiers, and acquisition parameters.
The DICOM ecosystem consists of several key components:
DICOM communication relies on several service commands:
Figure 1. DICOM network architecture: Medical imaging devices connect to PACS servers using DICOM protocol. External access points including Cloud PACS and Remote Consultation create potential exposure vectors.
DICOM was designed in an era when hospital networks were isolated from the internet . The protocol assumes a trusted network environment and includes some built-in security mechanisms. As healthcare organizations have embraced digital transformation, telehealth, and cloud services, DICOM servers have increasingly been exposed to the public internet.
Our analysis from November to December 2025 identified 3,627 DICOM servers accessible from the internet, representing 3,542 unique IP addresses. We discovered these servers through systematic internet scanning using Shodan.io, a engine that indexes internet-connected devices. We applied several validation steps to reduce false positives from honeypots or misconfigured non-DICOM services. These included verifying that each server responded with a valid DICOM association response, confirming that Implementation Class UIDs matched known DICOM software, and cross-referencing results against Shodan.io’s Honeyscore API. We also examined response fingerprints for consistency with genuine DICOM implementations, filtering out entries with generic banners or behaviors inconsistent with real medical imaging systems. The resulting dataset of 3,627 servers represents validated DICOM endpoints with high confidence.
The exposed servers span the globe, with the highest concentrations in developed nations with advanced healthcare infrastructure. studies have documented growing DICOM exposure over time: independent research by Aplite identified over 3,800 servers across 110 countries in 2023, and CybelAngel reported 45 million unprotected medical images in 2024. Our collection and analysis of November to December 2025 DICOM data using Shodan.io confirms this problem persists, with the following country-level distribution:
The remaining servers are distributed across over 100 countries, demonstrating that this is truly a global problem affecting healthcare systems at every level of development.
Figure 2. Global distribution of exposed DICOM servers: 3,627 servers across over 100 countries, with the US accounting for one-third of all exposures.
Table 1. Global distribution of exposed DICOM servers by country
A significant finding of our analysis is the presence of DICOM servers in cloud environments. Of the 3,627 exposed servers:
Among cloud-hosted servers, the distribution across major providers is notable:
The concentration of exposed servers on major cloud platforms is particularly concerning. While these providers offer robust security features, proper configuration remains the responsibility of the healthcare organization. A single misconfigured security group can expose a DICOM server to the entire internet.
Figure 3. Infrastructure distribution: 69% of exposed servers are on traditional on-premises connections, while 31% are cloud-hosted. Azure dominates the cloud segment with 48% of cloud deployments.
Understanding the technical landscape of exposed DICOM servers provides insight into both the attack surface and potential remediation strategies.
DICOM servers operate on several standard ports, each revealing information the underlying software and configuration:
The near-complete absence of TLS usage is a significant finding of this analysis. DICOM TLS has been available since 1999, yet only 0.14% of exposed servers implement this basic security measure.
Figure 4. DICOM port usage analysis: Port 104 leads with 1,594 servers, followed by the common alternate port 4242. Critically, only five servers (0.14%) use the DICOM TLS port, indicating near-universal lack of encryption.
Identifying the software running on exposed DICOM servers helps assess vulnerability exposure. Our analysis reveals a concentrated landscape:
The remaining implementations include dcm4che, DCMOBJ, and LogiPACS, each representing a small but notable slice of exposures. The concentration of just a few software implementations means that any vulnerabilities in these platforms carry disproportionate risk. A single critical vulnerability in DCMTK, for example, would affect nearly half of all exposed servers.
Figure 5. DICOM software implementation analysis: OFFIS DCMTK dominates with 44% market , followed by unknown implementations at 32% and OsiriX at 14%.
Table 2. DICOM implementation distribution
The exposed DICOM infrastructure represents a diverse ecosystem of medical imaging technology. Based on software signatures, port configurations, and metadata analysis, we can infer the types of devices and systems communicating with the DICOM servers.
While the DICOM servers themselves are often PACS systems or workstations, they serve as gateways to connected imaging modalities including:
It is worth noting that that we did not discover any of the aforementioned medical devices exposed in our collected Shodan.io data, but based on how DICOM works, we can infer that they communicate with the exposed DICOM servers.
The central storage and distribution systems show significant variety:
Significant cloud infrastructure dedicated to medical imaging:
Figure 6. Inferred medical device types: The DICOM ecosystem spans from imaging modalities (CT, MRI, X-ray) through PACS systems to radiologist workstations, with increasing cloud adoption.
DICOM files contain more than just medical images. Each file includes extensive metadata that represents a substantial volume of Protected Health Information (PHI) under HIPAA and similar health data protection regulations worldwide.
Our research was limited to identifying servers listed on Shodan; we did not investigate the servers directly.
DICOM files typically contain patient identifiers including full name, date of birth, and medical record number. In some deployments, files may also include social security numbers or other national identifiers. This demographic data is sufficient to enable identity theft and medical fraud.
Beyond demographics, DICOM metadata reveals:
DICOM files also expose organizational details, such as facility names, department identifiers, equipment inventory, and network architecture information, that could enable further attacks.
The images themselves reveal sensitive health conditions. Mammograms, oncology scans, psychiatric imaging, and other specialized studies can expose diagnoses that patients may wish to keep private from employers, insurers, or family members.
The exposed DICOM servers present multiple attack vectors that malicious actors can exploit. Understanding this threat model is essential for prioritizing defensive measures.
Attackers can easily discover exposed DICOM servers using internet scanning tools like Shodan.io and Censys . These platforms continuously index internet-connected devices, making DICOM servers searchable by port, protocol, and response characteristics.
Figure 7. Attack surface and threat model: Attackers discover exposed servers via Shodan and Censys then exploit them using DICOM commands or CVEs. Consequences include PHI theft, image manipulation, ransomware, and lateral movement.
A significant finding of this research is that DICOM includes security mechanisms that are not being actively used. The protocol specification provides for encryption, authentication, and access control, yet the vast majority of the exposed servers we found implement none of these protections.
DICOM Transport Layer Security (TLS) has been available since 1999. This mechanism encrypts all communication between DICOM nodes, preventing eavesdropping and man-in-the-middle attacks. Despite TLS being available, only 0.14% of exposed servers (five out of 3,627) use the designated DICOM TLS port (2762). TLS can also be configured on other ports, so actual TLS adoption may be slightly higher.
DICOM uses Application Entity (AE) Titles for identification. Properly configured servers should only accept connections from known, trusted AE Titles. Our analysis found that 99.56% of servers accepted connections using the default ANY-SCP called AE Title, suggesting that organizations are not enforcing AE Title validation.
Best practices dictate that DICOM servers should reside on isolated network segments with firewall rules restricting access to known clinical systems. The presence of 3,627 internet-exposed servers demonstrates a failure to implement this basic control.
An analysis of software versions reveals significant patch deficiencies. For example, 321 OsiriX installations (61% of all OsiriX servers) run version 3.6.1 — a release from 2009 that predates numerous security fixes and lacks support for modern security features.
Figure 8. DICOM protocol security gaps: A matrix showing adoption versus impact reveals that critical safeguards (TLS, Network Isolation, AE Authentication) remain in the "Unused" quadrant despite their availability.
The major DICOM software implementations have accumulated sizeable vulnerability histories . When combined with the lack of patching observed in exposed servers, these CVEs represent active exploitation opportunities.
As the most widely deployed DICOM toolkit (44% of exposed servers ), DCMTK vulnerabilities have an outsized impact. Notable DCMTK vulnerabilities include:
DCMTK has accumulated 14 CVEs between 2020 and 2025, including one critical (CVSS 9.0+) and seven high severity (CVSS 7.0-8.9) vulnerabilities.
The commercial product Pixmeo OsiriX MD potentially faces several recently discovered vulnerabilities :
Orthanc PACS implementations potentially face several severe vulnerabilities:
Figure 9. Known CVE vulnerability exposure: Critical vulnerabilities (CVSS 7.5-9.8) exist across all major DICOM implementations, with OFFIS DCMTK, OsiriX, and Orthanc PACS all containing exploitable flaws.
The homogeneity of the exposed server population is a critical concern. When servers run identical software versions with identical configurations, a single exploit can be weaponized against many targets simultaneously.
Analysis of DICOM association responses reveals distinct clusters of identical configurations:
Figure 10. Attack scalability: Response fingerprinting reveals that 44% of servers cluster into identifiable groups with identical configurations. One exploit targeting OsiriX 3.6.1 could potentially work against all 321 servers in that cluster.
The clustering means that developing an exploit for one target effectively develops an exploit for hundreds. The 321 identical OsiriX 3.6.1 installations represent a particularly attractive target — an attacker who successfully exploits one gains a tested, reliable exploit that works against 320 additional servers with no modification. This scalability dramatically reduces the cost-benefit ratio for attackers. The effort to develop one working exploit is amortized across hundreds of potential victims, making even sophisticated attacks economically viable.
While we deliberately avoid naming specific institutions, our analysis identified 334 distinct organizations with exposed DICOM infrastructure. These organizations span three primary sectors, each with distinct risk profiles.
Figure 11. Types of organizations exposed: 334 identifiable organizations across healthcare (69%), education (19%), and government (12%) sectors have exposed DICOM infrastructure.
Healthcare organizations represent the largest category, with 231 identifiable entities:
This category comprises 63 academic organizations with exposed DICOM infrastructure:
This category comprises 40 government-affiliated organizations with exposed servers:
The exposure of DICOM servers presents organizations with both regulatory and clinical risks:
Organizations with exposed DICOM servers face significant regulatory risks:
Beyond regulatory concerns, exposed DICOM servers create patient safety risks:
Our analysis of 3,627 internet-exposed DICOM servers across more than 100 countries found that organizations are not using the existing security controls bult into the protocol. Key findings include:
The 334 identifiable organizations — spanning healthcare providers, academic institutions, and government agencies across over 100 countries — represent only the visible portion of this exposure. Behind each server lies a population of patients whose sensitive medical information is at risk.
The path forward requires acknowledging that DICOM's original trust assumptions no longer apply in an interconnected world. Security must be treated as a fundamental requirement rather than an optional enhancement. The tools exist; they simply need to be used. Healthcare organizations, cloud providers, and DICOM software vendors all responsibility for addressing this exposure. Until they do, patient data remains at risk, clinical systems remain vulnerable, and the healthcare sector remains an attractive target for malicious actors.
The risks and recommended actions identified in this paper map directly to capabilities within the TrendAI Vision One™ platform.
Network Detection & Response (NDR)
Cyber Risk Exposure Management (CREM)
In environments like medical imaging infrastructure, effective risk prioritization should account for more than just vulnerability severity. While CVSS scores describe the technical impact of a flaw, these don't capture how likely a vulnerability would be abused and reused across hundreds of similarly configured systems. This dimension of risk is captured by Global Exploit Potential (GEP), an assessment of how likely a given vulnerability is to be exploited at scale in real‑world attacks. GEP incorporates factors like exploit availability, observed attacker behavior, zero‑day intelligence from programs like the TrendAI™ Zero Day Initiative™ (ZDI), and global threat telemetry, distinguishing theoretical weaknesses from vulnerabilities that adversaries are actively using or are likely to industrialize.
This distinction is particularly relevant for exposed DICOM infrastructure. As shown earlier in this research, 44% of internet‑accessible DICOM servers cluster into groups running identical software versions and configurations, meaning a single working exploit can be reused against hundreds of targets with minimal modification. Vulnerabilities such as CVE‑2019‑1010228 (DCMTK remote code execution), CVE‑2025‑0896 (Orthanc unauthenticated access), and CVE‑2023‑33466 (Orthanc authenticated remote code execution with public exploit code) therefore represent heightened risk not only because of their CVSS scores, but also because of their scalability across a globally exposed population.
Real‑world incidents over the years reinforce this risk model: In 2019, researchers identified large numbers of internet-accessible DICOM servers that resulted in the public exposure of hundreds of millions of PACS medical images , showing how the same misconfiguration was repeated across identical imaging systems. Similarly, a compromised radiology PACS that exposed nearly 300,000 patient records led to federal enforcement action in April 2025, illustrating the real‑world financial, and compliance impact of insecure imaging systems. CREM incorporates GEP into risk quantification and prioritization, enabling organizations to reduce not just isolated technical findings, but classes of vulnerabilities that are most likely to be weaponized against organizations.
TippingPoint Threat Protection System (TPS)
Like it? Add this infographic to your site: 1. Click on the box below. 2. Press Ctrl+A to select all. 3. Press Ctrl+C to copy. 4. Paste the code into your page (Ctrl+V).
Image will appear the same size as you see above.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
