Orthanc DICOM Vulnerabilities Lead to Crashes, RCE

Orthanc DICOM Server Vulnerabilities Enable RCE in Medical Imaging Systems

Researchers have disclosed multiple vulnerabilities in Orthanc, a widely deployed open-source DICOM server used across hospitals, radiology departments, and telehealth platforms globally. The flaws range in severity and impact, but collectively allow unauthenticated network attackers to crash the server, extract sensitive information, and in the most critical cases, achieve remote code execution on the underlying host.

Orthanc is a cornerstone of medical imaging infrastructure worldwide, functioning as a lightweight Picture Archiving and Communication System (PACS) server. It stores, processes, and transmits DICOM (Digital Imaging and Communications in Medicine) files — the standard format for medical images including CT scans, MRIs, X-rays, and ultrasounds.

Vulnerability Summary

The vulnerabilities were identified in Orthanc's handling of DICOM protocol packets and REST API inputs. Three distinct impact categories were confirmed:

The exact CVE identifiers and full technical details are expected to be published in coordination with Orthanc's maintainers and the disclosure timeline. Organizations are advised to apply available patches without waiting for full technical disclosure.

Why This Matters: Healthcare Attack Surface

Medical imaging systems represent one of the most sensitive and historically under-patched segments of healthcare IT. Several factors amplify the risk from Orthanc vulnerabilities:

Pervasive Deployment

Orthanc has been downloaded millions of times and is used in settings ranging from small private clinics to major hospital networks. Its open-source nature means it frequently appears in custom-built healthcare IT deployments where patch management may lag commercial products.

Network Accessibility

DICOM servers are designed to communicate across hospital networks, teleradiology links, and increasingly, cloud-based platforms. Orthanc instances are often reachable from multiple network segments — including segments that connect to radiology workstations, clinical systems, and sometimes directly to the internet when configured for telehealth.

Patient Data at Risk

A successful RCE exploit against an Orthanc server provides access to:

• Patient medical images (CT scans, MRIs, X-rays) — highly sensitive PHI
• DICOM metadata including patient names, dates of birth, referring physicians, and diagnoses
• HL7/FHIR integration data in connected configurations
• Server credentials stored in Orthanc's configuration files

Healthcare data breaches carry significant regulatory consequences under HIPAA (US), PIPEDA (Canada), and GDPR (EU), with per-record fines that quickly compound in large-scale incidents.

Technical Context: DICOM Protocol Attack Surface

The DICOM protocol was designed for reliability and interoperability in clinical environments, not adversarial security. It operates over TCP (default port 4242 for DICOM, 8042 for Orthanc's REST API) and involves complex negotiation and data parsing phases:

DICOM Connection Flow:
  Client → Association Request (A-ASSOCIATE-RQ)
  Server → Association Accept/Reject (A-ASSOCIATE-AC/RJ)
  Client → Data Transfer (C-STORE, C-FIND, C-MOVE, C-GET PDUs)
  Client → Association Release (A-RELEASE-RQ)

Each PDU (Protocol Data Unit) in this exchange contains variable-length fields and nested sequences. Vulnerabilities typically arise from:

• Integer overflow / underflow in length field parsing
• Buffer overflow when copying variable-length data without bounds checking
• Use-after-free in session management during association teardown
• Type confusion in DICOM attribute value representations (VRs)

Orthanc is implemented in C++ with custom DICOM parsing logic. Memory safety issues in C++ parsers handling untrusted network data are a well-established source of RCE-class vulnerabilities.

Affected Versions and Patch Status

Orthanc users should check the official Orthanc repository and the associated plugin repositories for:

• Orthanc core — update to the latest stable release
• Orthanc plugins (DICOM Web, PostgreSQL, MySQL, transfers) — each plugin may have separate patches
• Distribution-packaged versions — Ubuntu/Debian, Docker images, and vendor-bundled deployments may lag upstream releases

# Check installed Orthanc version
orthanc --version
 
# Or via REST API
curl http://localhost:8042/system | python3 -m json.tool | grep -i version
 
# Check Docker image version
docker inspect orthanc:latest | grep -i version

Remediation Steps

1. Update Orthanc Immediately

Apply the latest Orthanc release from the official source:

# Ubuntu/Debian — update from official PPA
sudo apt update && sudo apt upgrade orthanc
 
# Docker — pull the latest image
docker pull osimis/orthanc:latest
docker restart orthanc-container

2. Restrict Network Access

If Orthanc cannot be patched immediately, limit exposure through network controls:

# UFW — restrict DICOM port to trusted hosts only
sudo ufw deny 4242
sudo ufw allow from 192.168.10.0/24 to any port 4242
 
# Restrict REST API access
sudo ufw deny 8042
sudo ufw allow from 127.0.0.1 to any port 8042

3. Enable Orthanc Authentication

Orthanc supports basic HTTP authentication for its REST API. Enable it in orthanc.json:

{
  "AuthenticationEnabled": true,
  "RegisteredUsers": {
    "admin": "strong-password-here"
  }
}

Note: Authentication applies to the REST API but not to the raw DICOM port — network-level controls are still required for DICOM protocol protection.

4. Deploy Behind a Reverse Proxy

Place Orthanc behind an Nginx or Traefik reverse proxy with TLS termination and rate limiting:

location /orthanc/ {
    proxy_pass http://127.0.0.1:8042/;
    proxy_set_header Host $host;
    # Restrict to internal network
    allow 192.168.0.0/16;
    deny all;
    # Rate limiting
    limit_req zone=orthanc burst=20;
}

Detection

Monitor for signs of exploitation or reconnaissance:

# Check Orthanc logs for unexpected DICOM associations
grep -i "error\|exception\|segfault\|crash" /var/log/orthanc/*.log | tail -100
 
# Monitor for unexpected REST API access patterns
grep "4[0-9][0-9] " /var/log/nginx/access.log | grep orthanc | awk '{print $1}' | sort | uniq -c
 
# Watch for Orthanc process restarts (indicator of crash exploitation)
journalctl -u orthanc --since "1 hour ago" | grep -i "started\|stopped\|failed"
 
# Baseline — count DICOM association attempts per source IP
tcpdump -i eth0 -n port 4242 | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

Impact on Healthcare Operations

Beyond the security implications, exploitation of a DICOM server can directly impact patient care:

• Diagnostic delays — if the PACS server is unavailable, radiologists cannot access patient images
• Treatment decisions — missing imaging data can delay time-critical interventions
• Regulatory notification — HIPAA breach notification requirements trigger if PHI is accessed or exfiltrated
• Ransomware risk — healthcare is a primary target; DICOM server access is an effective foothold for ransomware deployment

Key Takeaways

1. Multiple vulnerabilities in Orthanc DICOM server (≤ latest affected version) enable DoS, information disclosure, and RCE via malformed DICOM packets
2. Orthanc is deployed globally in hospitals and clinics, making this a high-impact disclosure for healthcare IT
3. Update Orthanc immediately and restrict network access to the DICOM port (4242) and REST API (8042)
4. Enable authentication on the REST API and deploy Orthanc behind a reverse proxy
5. Monitor logs for unexpected association attempts, crashes, or unauthorized REST API access
6. Healthcare organizations should review their DICOM infrastructure inventory — unmanaged or forgotten Orthanc instances are a significant risk

Sources

• Orthanc DICOM Vulnerabilities Lead to Crashes, RCE — SecurityWeek
• Orthanc Official Documentation