A Hidden Vulnerability in Healthcare: Exposed DICOM Servers and the Risk to Patient Data

By Numaan Huq and Andre Alves

Key Takeaways

• Shodan.io scanning data identified 3,627 DICOM medical imaging servers across more than 100 countries that are directly accessible from the public internet, exposing patient data from hundreds of healthcare, academic, and government organizations.
• Security mechanisms built into the Digital Imaging and Communications in Medicine (DICOM) protocol remain largely unused in these exposed servers: only 0.14% of exposed servers use TLS encryption, and 99.56% accept connections without AE Title validation.
• Critical CVEs (CVSS 7.5–9.8) affect all major DICOM platforms, and 44% of exposed servers cluster into groups running identical software configurations, meaning a single exploit can scale to hundreds of targets.
• TrendAI™ solutions, including TrendAI Vision One™ for risk assessment, TrendAI™ Deep Discovery™ Inspector for network monitoring, and the TippingPoint Threat Protection System for vulnerability prevention, help secure DICOM medical imaging systems and protect sensitive healthcare data from cyber threats.

The digital backbone of medical imaging

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:

• Only 0.14% of exposed servers use TLS encryption
• 99.56% accept connections without AE Title validation
• 334 organizations were identifiable
• 44% of servers cluster into groups running identical software

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.

Understanding DICOM: How medical imaging works

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:

• Modalities: Medical imaging devices such as CT scanners, MRI machines, X-ray systems, ultrasound equipment, mammography units, PET scanners, fluoroscopy systems, angiography systems, and endoscopy imaging systems. These devices generate DICOM objects containing both image pixel data and extensive metadata about the patient and exam.
• Picture Archiving and Communication System (PACS): Central servers that store, retrieve, and distribute medical images. These systems receive images from modalities, archive them for long-term storage, and provide access to radiologists and clinicians.
• Workstations and viewers: Specialized viewing stations where radiologists interpret images. Software like OsiriX, RadiAnt, and vendor-specific viewers enable detailed examination of DICOM studies.
• Enterprise clinical systems: Systems that ingest or reference imaging data, including radiology information systems (RIS) and electronic medical record/electronic health record (EMR/EHR) platforms.
• Downstream imaging tools: DICOM supporting systems such as printers and computer-aided detection and diagnosis (CAD) solutions that process studies for review, reporting, and clinical decision support.

DICOM communication relies on several service commands:

• C-STORE: Transfers images from one system to another (for example, from a CT scanner to PACS)
• C-FIND: Queries a PACS server for patient studies matching specific criteria
• C-MOVE/C-GET: Retrieves images from a server to a requesting system

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.

The exposure problem: How DICOM servers become vulnerable

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.

Discovery and validation methodology

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 search 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.

Global distribution

The exposed servers span the globe, with the highest concentrations in developed nations with advanced healthcare infrastructure. Previous 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:

• US: 1,189 servers (33%) - The largest concentration, reflecting both the size of the US healthcare system and widespread adoption of digital imaging.
• India: 445 servers (12%) - Rapid healthcare digitization combined with inconsistent security practices accounts for this exposure.
• Brazil: 266 servers (7%) - A growing healthcare technology sector has outpaced security adoption, creating emerging security challenges.
• China: 161 servers (4%) - Despite significant healthcare infrastructure, relatively lower exposure may indicate better network segmentation.
• Germany: 138 servers (4%) - European healthcare providers with significant cloud adoption.

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

Cloud vs. on-premises infrastructure

A significant finding of our analysis is the presence of DICOM servers in cloud environments. Of the 3,627 exposed servers:

• On-premises ISP-connected: 2,508 servers (69%) - Traditional hospital and clinic deployments connected through commercial internet service providers.
• Cloud-hosted: 1,119 servers (31%) - Deployments on major cloud platforms, often for cloud PACS, teleradiology, or disaster recovery.

Among cloud-hosted servers, the distribution across major providers is notable:

• Microsoft Azure: 533 servers (48% of cloud) - The dominant cloud platform for healthcare imaging, likely due to Microsoft's healthcare industry focus and HIPAA-compliant offerings.
• Amazon Web Services: 287 servers (26% of cloud) - Significant presence, particularly in the US East region.
• Google Cloud Platform: 129 servers (12% of cloud)

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.

Technical analysis

Understanding the technical landscape of exposed DICOM servers provides insight into both the attack surface and potential remediation strategies.

Port distribution

DICOM servers operate on several standard ports, each revealing information about the underlying software and configuration:

• Port 104 (Standard DICOM): 1,594 servers (44%) - This is the default DICOM port that indicates standard implementations or legacy systems.
• Port 4242 (Common Alternate): 1,073 servers (30%) - This is a common alternate DICOM port used by various implementations such as Orthanc and DCMTK-based systems.
• Port 11112 (Common Alternate): 949 servers (26%) - Port 11112 is another common alternate DICOM port used by various implementations.
• Port 2762 (DICOM TLS): Five servers (0.14%) - The designated port for encrypted DICOM communications. This notably low number reveals that virtually no exposed servers use the designated TLS port for transport layer encryption.
• Other ports: Six servers (0.17%) are on non-standard ports (2345 and 2761), reinforcing that exposed DICOM is not limited to the usual defaults.

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.

Software implementation analysis

Identifying the software running on exposed DICOM servers helps assess vulnerability exposure. Our analysis reveals a concentrated landscape:

• OFFIS DCMTK: 1,583 servers (44%) - A widely used open-source C++ toolkit forming the foundation for many commercial and research DICOM implementations.
• Unknown/Unidentified: 1,175 servers (32%) - Servers that did not provide implementation class UID information, potentially indicating custom or proprietary systems.
• OsiriX: 526 servers (14%) - A macOS-based DICOM viewer and PACS system popular in research and smaller clinical settings.
• pynetdicom: 107 servers (3%) - A Python-based DICOM library often used in research and custom integrations.
• fo-dicom: 72 servers (2%) - A .NET-based DICOM library used primarily in Windows environments.

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 share, followed by unknown implementations at 32% and OsiriX at 14%.

Table 2. DICOM implementation distribution

Types of devices exposed

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.

Imaging modalities

While the DICOM servers themselves are often PACS systems or workstations, they serve as gateways to connected imaging modalities including:

• CT scanners: Computed tomography systems generating detailed cross-sectional images.
• MRI systems: Magnetic resonance imaging devices producing high-resolution soft tissue images.
• X-Ray equipment: Digital radiography systems including portable and fixed installations.
• Ultrasound machines: Sonography equipment used across multiple specialties.
• Mammography units: Specialized breast imaging systems containing sensitive screening data.
• PET-CT scanners: Nuclear medicine imaging systems used in oncology and cardiology.

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.

PACS and archiving systems

The central storage and distribution systems show significant variety:

• DCMTK-based systems: Over 1,000 servers using OFFIS DCMTK, ranging from research installations to commercial PACS implementations.
• Port 4242 servers: 1,073 servers on port 4242, commonly used by Orthanc and DCMTK-based implementations. Software identification requires Implementation UID verification beyond port number.
• LogiPACS: 29 identified installations of this commercial PACS solution.
• DCMOBJ-based systems: 64 servers using this implementation, whose origin could not be determined.

Radiologist workstations

• OsiriX: 526 installations of this macOS DICOM viewer, with 321 running the outdated version 3.6.1 from 2009.
• fo-dicom viewers: 72 Windows-based viewing applications using the .NET library.

Cloud PACS deployments

Significant cloud infrastructure dedicated to medical imaging:

• Azure-hosted: 533 servers, heavily concentrated in the East US 2 region (462 servers).
• AWS-hosted: 287 servers across multiple regions, primarily us-east-1.
• Google Cloud: 129 servers, including research and AI/ML applications.

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.

What information is at risk?

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.

Patient demographic information

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.

Clinical information

Beyond demographics, DICOM metadata reveals:

• Study descriptions: Why the imaging was ordered (for example, “CT chest for lung nodule follow-up”)
• Referring physician: The ordering physician’s name and often contact information
• Reading radiologist: The interpreting physician's credentials
• Diagnosis codes: International Classification of Diseases (ICD) codes indicating suspected or confirmed diagnoses
• Procedure details: Technical parameters revealing the specific examination performed

Institutional information

DICOM files also expose organizational details, such as facility names, department identifiers, equipment inventory, and network architecture information, that could enable further attacks.

Image content

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.

Attack surface and threat model

The exposed DICOM servers present multiple attack vectors that malicious actors can exploit. Understanding this threat model is essential for prioritizing defensive measures.

Discovery phase

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.

Exploitation vectors

• C-FIND patient lookup: Query patient databases to enumerate records and identify targets.
• C-GET/C-MOVE download: Retrieve actual medical images and associated PHI.
• C-STORE malicious upload: Upload modified or malicious DICOM files to corrupt medical records.
• CVE exploitation: Leverage known vulnerabilities in DICOM software for remote code execution.

Potential impact

• Protected health information (PHI) theft: Exfiltrating patient data to sell on dark web markets or use for targeted blackmail
• Image manipulation: Altering medical images to cause misdiagnosis, with potentially life-threatening consequences
• Ransomware: Encrypting medical imaging archives to extort healthcare organizations
• Lateral movement: Using compromised DICOM servers as pivot points to attack broader hospital networks

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.

The security gap: Unused safeguards

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.

TLS encryption

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.

AE Title authentication

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.

Network isolation

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.

Version updates

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.

Known vulnerabilities: CVE analysis

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.

OFFIS DCMTK vulnerabilities

As the most widely deployed DICOM toolkit (44% of exposed servers), DCMTK vulnerabilities have an outsized impact. Notable DCMTK vulnerabilities include:

• CVE-2019-1010228 (CVSS 9.8) - A critical stack buffer overflow in DcmRLEDecoder::decompress() allows remote code execution. This vulnerability affects versions 3.6.3 and earlier.
• CVE-2022-2119/CVE-2022-2120 (CVSS 9.8 NVD / 7.5 ICS-CERT) - These are path traversal vulnerabilities in SCP and SCU components that allow arbitrary file write and potential remote code execution.
• CVE-2024-47796 (CVSS 8.4) - This is an out-of-bounds write vulnerability in DCMTK 3.6.8 that allows code execution via malicious DICOM files.

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.

OsiriX vulnerabilities

The commercial product Pixmeo OsiriX MD potentially faces several recently discovered vulnerabilities:

• CVE-2025-27720 (CVSSv4.0: 9.3, v3.1: 7.4) - Cleartext transmission of credentials in the Web Portal component that allows credential interception on the network.
• CVE-2025-27578 (CVSSv4.0: 8.7, v3.1: 7.5) - Use-after-free vulnerability ia malicious DICOM file upload that causes memory corruption or denial of service.

Orthanc PACS vulnerabilities

Orthanc PACS implementations potentially face several severe vulnerabilities:

• CVE-2025-0896 (CVSS 9.8) - Orthanc does not enable authentication by default when remote access is enabled in versions prior to 1.5.8. This allows unauthorized access, data disclosure, record modification, and denial of service requiring no exploitation beyond simply connecting.
• CVE-2023-33466 (CVSS 8.8) - Arbitrary file overwrite allowing authenticated remote code execution via DICOM polyglot files. Public exploit code is available on GitHub.

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.

Attack scalability: One exploit, many victims

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.

Response fingerprinting

Analysis of DICOM association responses reveals distinct clusters of identical configurations:

• DCMTK-based group A: 459 servers (13%) with identical DCMTK responses
• DCMTK-based group B: 384 servers (11%) with another common DCMTK pattern
• OsiriX 3.6.1 identified: 321 servers (9%) running the identical outdated version from 2009
• Unknown software groups: 433 servers (12%) in two clusters with unidentified software
• All other fingerprints: 2,030 servers (56%) distributed across hundreds of smaller fingerprint groups

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.

Implications for potential attacks

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.

Types of organizations exposed

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 (69%)

Healthcare organizations represent the largest category, with 231 identifiable entities:

• Hospitals: Large medical centers with comprehensive imaging departments, often running multiple PACS systems and hundreds of connected modalities
• Clinics: Outpatient facilities with more limited imaging capabilities and often less sophisticated IT security
• Radiology centers: Dedicated imaging facilities that process high volumes of diagnostic studies
• Imaging centers: Standalone facilities that offer MRI, CT, or specialty imaging services
• Diagnostic laboratories: Facilities that combine imaging with other diagnostic services
• Specialist practices: Cardiology, oncology, and other specialties that maintain their own imaging archives

Educational institutions (19%)

This category comprises 63 academic organizations with exposed DICOM infrastructure:

• Research universities: Major research institutions with medical imaging research programs
• Medical schools: Academic medical centers with clinical training and research programs
• Teaching hospitals: Clinical facilities with academic missions and research activities
• Research laboratories: Specialized imaging research facilities often with experimental protocols

Government organizations (12%)

This category comprises 40 government-affiliated organizations with exposed servers:

• Health ministries: National health departments with centralized imaging infrastructure
• Public health systems: Government-operated healthcare networks that serve populations
• State health networks: Regional government health systems with shared imaging resources
• Health sciences agencies: Government research and regulatory bodies with imaging data

Implications for privacy and patient safety

The exposure of DICOM servers presents organizations with both regulatory and clinical risks:

Regulatory and legal consequences

Organizations with exposed DICOM servers face significant regulatory risks:

• HIPAA violations: In the US, exposed PHI constitutes a reportable breach. Penalties can reach US$2,134,831 per violation category per year (inflation-adjusted as of 2024).
• GDPR implications: European organizations face fines up to 4% of global annual revenue for inadequate protection of health data.
• State privacy laws: State-level regulations add additional compliance requirements and penalties.
• Professional liability: Healthcare providers may face malpractice claims if patient harm results from compromised imaging systems.

Clinical safety risks

Beyond regulatory concerns, exposed DICOM servers create patient safety risks:

• Misdiagnosis: Manipulated medical images could lead to incorrect diagnoses, delayed treatment, or unnecessary procedures.
• Treatment errors: Corrupted imaging data could disrupt radiation therapy planning, surgical navigation, or other image-guided treatments.
• System downtime: Ransomware or denial-of-service attacks could prevent access to critical diagnostic imaging during emergencies.

Conclusion

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:

• Encryption is absent: Only five of 3,627 servers (0.14%) used the DICOM TLS port, despite TLS support being available since 1999.
• Authentication is unenforced: 99.56% of servers accepted connections using a default AE Title, indicating no caller validation.
• Software homogeneity amplifies risk: 44% of servers run DCMTK, 14% run OsiriX (61% of which are on a 2009 release), and 44% cluster into groups with identical configurations, meaning one exploit scales to hundreds of targets.
• Known vulnerabilities are exploitable: Critical CVEs (CVSS 7.5–9.8) affect DCMTK, OsiriX, and Orthanc, with public exploit code available for some.
• Cloud hosting does not ensure security: 31% of exposed servers are cloud-hosted, with Azure accounting for 48% of cloud deployments.

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 share 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.

TrendAI Vision One™ solutions mapping

The risks and recommended actions identified in this paper map directly to capabilities within the TrendAI Vision One™ platform.

Network Detection & Response (NDR) 

• Protocol and application traffic detection. TrendAI Vision One™ has network sensors — Deep Discovery Inspector (DDI) and the Virtual Network Sensor — that perform deep packet inspection across over 100 protocols, including HTTP, DNS, SMB, RDP, LDAP, Kerberos, QUIC, and industrial protocols such as Modbus, BACnet, and DNP3. This protocol-aware analysis identifies unauthorized applications, tunneling attempts, and anomalous traffic patterns that may indicate lateral movement or data exfiltration.
• Non-encrypted traffic detection. DDI is purpose-built for detecting advanced persistent threats and targeted attacks within non-encrypted traffic. It identifies malicious content, C&C communications, and attacker behavior across every stage of the attack sequence — from initial exploitation through lateral movement to data exfiltration. Suspicious samples are automatically forwarded to TrendAI Vision One™ Sandbox Analysis for detonation and behavioral analysis.

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.

• Continuous application inventory. CREM’s Attack Surface Discovery continuously identifies known and unknown assets, applications, and services across the environment. Combined with the Network Vulnerability Scanner and daily vulnerability assessments, this provides a perpetually current inventory of what is running, where, and at what risk level.
• Continuous discovery of external and internal assets. Attack Surface Discovery identifies internet-facing domains, subdomains, and public IP addresses through WHOIS, DNS, and certificate inspection, then performs continuous risk assessments against open ports, services, and known CVEs. Internally, endpoint agents, Active Directory integration, and cloud account connections discover managed and unmanaged devices, cloud resources, and network infrastructure — surfacing coverage gaps where no security agent is present.
• Prioritization and contextualization of risk reduction measures. CREM’s Risk Reduction Measures capability lets organizations select a goal — lower the risk level, match the industry average, focus on top risks, or set a custom target — and then surfaces the specific remediation actions ranked by impact score needed to achieve it. Each risk event carries a quantified impact on the Cyber Risk Index, allowing teams to see exactly which actions yield the greatest reduction. For vulnerabilities that cannot be immediately patched, attack prevention rules can be applied directly through connected products including Endpoint Security, Server & Workload Protection, and TippingPoint Security Management System (SMS).
• Enterprise risk assessment and cyber risk quantification. The Cyber Risk Index (CRI) provides a single, continuously updated metric for organizational cyber risk posture, calculated across all risk events — not a sampled subset. The CRI incorporates vulnerability assessments, account compromise indicators, behavioral anomalies, threat detections, XDR correlations, and security configuration gaps. Organizations can benchmark against industry peers by configuring their company profile and generating scheduled executive reports that present CRI trends, risk factor breakdowns, and remediation progress in board-ready formats. Attack Path Prediction extends this with forward-looking analysis that identifies likely entry points, choke points, and potential attack paths through the environment.

TippingPoint Threat Protection System (TPS) 

• Protection against known and unknown (zero-day) CVEs. TippingPoint TPS provides inline intrusion prevention that blocks exploitation of known and zero-day vulnerabilities at wire speed. Digital Vaccine filters are updated regularly and map directly to CVEs, while TrendAI™ ZDI delivers pre-disclosure protection for vulnerabilities before vendor patches exist. ThreatDV extends coverage with reputation-based IP and DNS filters that are updated multiple times daily. When connected to TrendAI Vision One™, TPS functions as a network sensor feeding inspection events into XDR correlation.