Orthanc DICOM Server Authenticated DoS Vulnerability — Detection and Remediation Guide for Healthcare Defenders

A high-severity vulnerability has been disclosed in Orthanc, the lightweight, open-source DICOM server widely deployed in hospitals, imaging centers, and research institutions to store and route medical imaging studies. According to the disclosure reported by The HIPAA Journal, the flaw can be exploited by an authenticated remote attacker to cause a denial of service (DoS) condition on the server.

For defenders in healthcare environments, this is not a theoretical nuisance. Orthanc frequently sits at the heart of imaging workflows — receiving studies from modalities (CT, MRI, X-ray), routing to PACS and VNA archives, and exposing REST APIs used by clinical applications, AI inference pipelines, and teleradiology integrations. A sustained DoS against Orthanc means interrupted image availability, delayed diagnoses, and a potential patient safety event — not just an IT outage.

The exploitation requirement — valid authentication — might tempt some teams to deprioritize this. Don't. Orthanc instances are routinely deployed with default or weak credentials, shared service accounts embedded in integration scripts, and in too many cases, exposed directly to the internet or flat clinical networks where any compromised workstation can reach them. This vulnerability converts a single leaked or guessed credential into the ability to take down your imaging infrastructure.

Technical Analysis

Affected Product and Platform

• Product: Orthanc DICOM Server (open-source, maintained by Sébastien Jodogne / Osimis)
• Platforms: Linux (most common in production), Windows, and Docker container deployments
• Default exposure: Orthanc's built-in HTTP/REST API listens on TCP port 8042 by default, and the DICOM service (C-STORE/C-FIND/C-MOVE) listens on TCP port 4242 (configurable). The REST API is the primary management and integration surface.

Vulnerability Mechanics (Defender's Perspective)

Based on the disclosure, the vulnerability allows a remote attacker with valid credentials to trigger a denial of service condition in the Orthanc server process. In practical terms, this class of flaw in a DICOM server typically manifests as one of:

1. Malformed input handling — a specially crafted request to the REST API or a malformed DICOM dataset that causes the server process to crash, hang, or enter an unrecoverable state.
2. Resource exhaustion — requests that cause unbounded memory allocation or thread/connection exhaustion, degrading or halting service for legitimate users.

The critical exploitation prerequisite is authentication. Orthanc's REST API supports HTTP Basic authentication with registered users defined in orthanc.json (the RegisteredUsers block). An attacker needs any valid credential pair — and given that Orthanc historically ships with RemoteAccessAllowed disabled by default but is frequently reconfigured for integration access, credential hygiene is the real control plane here.

Attack chain (defensive view):

1. Attacker obtains Orthanc credentials — via credential stuffing against exposed port 8042, phishing of a radiology integration account, secrets leaked in scripts/config repositories, or lateral movement from a compromised clinical workstation.
2. Attacker authenticates to the REST API.
3. Attacker issues the malicious request sequence that triggers the DoS condition.
4. The Orthanc process crashes or becomes unresponsive; DICOM ingest, query/retrieve, and REST integrations fail.
5. Clinical impact: modalities queue or error out, radiologists lose access to priors, downstream AI/VNA pipelines stall.

Exploitation Status

At the time of writing, there are no confirmed reports of in-the-wild exploitation, and the vulnerability has not been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. However, Orthanc's popularity in healthcare — and the well-documented history of exposed DICOM services being indexed by Shodan and probed by opportunistic actors — means defenders should treat this as a near-term risk, particularly for any instance reachable beyond a tightly segmented clinical VLAN. The absence of active exploitation today is a window for remediation, not a reason for delay.

Detection & Response

The detection strategy for this threat centers on three observable behaviors: (1) the Orthanc process crashing or restarting unexpectedly, (2) anomalous authenticated REST API activity — particularly bursts of requests from a single authenticated identity or source IP, and (3) authentication anomalies against the Orthanc HTTP service. Because Orthanc is most commonly deployed on Linux, the rules below lean on process monitoring and syslog/CEF ingestion patterns.

Sigma Rules

---
title: Orthanc DICOM Server Process Crash or Abnormal Termination
id: 3f8a2c14-7b6d-4e19-a2c5-9d1e4f6a8b3c
status: experimental
description: Detects the Orthanc server process terminating abnormally, crashing, or spawning unexpected child processes, which may indicate exploitation of a denial of service vulnerability or post-exploitation activity on the DICOM host.
references:
  - https://www.hipaajournal.com/orthanc-dicom-server-vulnerability-denial-of-service/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.impact
  - attack.t1499
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/orthanc'
      - '/Orthanc'
  selection_children:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/python'
      - '/python3'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_children
falsepositives:
  - Legitimate Orthanc plugin or Lua script invocations (review CommandLine for expected paths)
level: high
---
title: Orthanc REST API Request Flood from Single Source
id: 8b4e6d21-2a9f-4c38-b7e1-5f3a9c2d7e40
status: experimental
description: Detects a high volume of HTTP requests directed at the Orthanc REST API (default TCP 8042) from a single source, consistent with denial of service attempts, credential stuffing, or automated abuse of an authenticated session.
references:
  - https://www.hipaajournal.com/orthanc-dicom-server-vulnerability-denial-of-service/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.impact
  - attack.t1499
  - attack.t1499.004
logsource:
  category: webserver
detection:
  selection:
    c-uri|contains:
      - '/studies'
      - '/patients'
      - '/series'
      - '/instances'
      - '/tools/'
      - '/system'
  condition: selection | count(c-ip) by cs-host > 500
falsepositives:
  - Legitimate bulk DICOM ingestion or scripted archive migrations (whitelist known integration service IPs and tune threshold)
level: medium
---
title: Repeated Authentication Failures Against Orthanc HTTP Service
id: c17a9f43-5e2b-4d71-93a8-6b2d8e1f4a65
status: experimental
description: Detects repeated failed HTTP Basic authentication attempts against the Orthanc REST API, indicating potential credential stuffing or brute-force activity preceding authenticated exploitation.
references:
  - https://www.hipaajournal.com/orthanc-dicom-server-vulnerability-denial-of-service/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.credential_access
  - attack.t1110
logsource:
  category: webserver
detection:
  selection:
    sc-status: 401
  condition: selection | count() by c-ip > 20
falsepositives:
  - Misconfigured integration clients retrying with stale credentials (investigate and fix the client, do not suppress blindly)
level: medium

KQL (Microsoft Sentinel / Defender)

The following hunt query targets environments ingesting Orthanc host logs via Syslog/CEF or a reverse proxy in front of the Orthanc REST API. It looks for three correlated signals: 401 authentication failures against Orthanc ports, high request rates from single sources, and process restarts on the Orthanc host.

// Hunt: Orthanc DoS precursor activity - auth failures + request floods + service restarts
let OrthancPorts = dynamic([8042, 4242]);
let Lookback = 24h;
let AuthFailures =
    CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where DestinationPort in (OrthancPorts) or DestinationHostName has "orthanc"
    | where Activity has_any ("401", "authentication failure", "failed login")
    | summarize AuthFailCount = count() by SourceIP, DestinationHostName, bin(TimeGenerated, 15m)
    | where AuthFailCount > 20;
let RequestFlood =
    Syslog
    | where TimeGenerated > ago(Lookback)
    | where SyslogMessage has_any ("/studies", "/patients", "/tools/", "/instances") or ProcessName has "orthanc"
    | summarize RequestCount = count() by SourceIP = tostring(extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)), HostName, bin(TimeGenerated, 15m)
    | where RequestCount > 500;
let ServiceRestarts =
    Syslog
    | where TimeGenerated > ago(Lookback)
    | where SyslogMessage has_any ("orthanc.service", "Main process exited", "segmentation fault", "core dumped", "orthanc") 
    | where SyslogMessage has_any ("exited", "failed", "dumped", "killed", "restart")
    | project TimeGenerated, HostName, SyslogMessage, SeverityLevel;
union AuthFailures, RequestFlood
| project TimeGenerated, SourceIP, HostName = coalesce(DestinationHostName, HostName), AuthFailCount, RequestCount
| join kind=leftouter (ServiceRestarts) on HostName
| order by TimeGenerated desc

For Defender for Endpoint visibility on Windows-hosted Orthanc instances, this complementary query watches for the Orthanc process spawning shells or scripting engines — a post-crash or post-exploitation red flag:

// Orthanc process spawning unexpected child processes (Windows hosts)
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where InitiatingProcessFileName =~ "orthanc.exe"
   or InitiatingProcessCommandLine has "orthanc"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "curl.exe")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine, InitiatingProcessCommandLine, AccountName
| order by TimeGenerated desc

Velociraptor VQL

Use this artifact to hunt Orthanc hosts for evidence of service instability (repeated process starts), unexpected network listeners, and child process anomalies following a suspected DoS event.

-- Hunt: Orthanc service anomalies - process restarts, unexpected children, network listeners
SELECT Pid,
       Ppid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime,
       count(group_by=Exe) AS StartCount
FROM pslist()
WHERE Name =~ '(?i)orthanc'
   OR Exe =~ '(?i)orthanc'
   OR CommandLine =~ '(?i)orthanc'
GROUP BY Exe

-- Hunt: Network connections associated with the Orthanc process - identify unexpected clients
SELECT Pid,
       Name,
       Status,
       Laddr.IP AS LocalIP,
       Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP,
       Raddr.Port AS RemotePort
FROM netstat()
WHERE Name =~ '(?i)orthanc'
   AND (LocalPort = 8042 OR LocalPort = 4242)
   AND Status = 'ESTABLISHED'

Cross-reference RemoteIP results against your approved inventory of modalities, PACS peers, and integration servers. Any ESTABLISHED session from an unknown or user-subnet address to port 8042 warrants immediate investigation.

Remediation Script

This Bash script inventories your Orthanc deployment, checks version and exposure, enforces authentication, and applies immediate hardening while you schedule the vendor update. Run it on the Orthanc host (Debian/Ubuntu assumed; adapt package paths for RHEL or Docker).

#!/usr/bin/env bash
# Orthanc DoS Vulnerability - Verification and Hardening Script
# Security Arsenal - run as root on the Orthanc host
set -euo pipefail

echo "=== [1] Identify Orthanc version ==="
if command -v orthanc &>/dev/null; then
    orthanc --version || true
elif docker ps --format '{{.Image}}' | grep -qi orthanc; then
    echo "Docker deployment detected:"
    docker ps --format '{{.Names}} {{.Image}}' | grep -i orthanc
    docker exec "$(docker ps --format '{{.Names}}' | grep -i orthanc | head -1)" \
        sh -c 'Orthanc --version 2>/dev/null || orthanc --version' || true
else
    echo "WARNING: Orthanc binary not found in PATH. Verify installation manually."
fi

echo "=== [2] Check listening exposure on 8042/4242 ==="
ss -tlnp | grep -E ':(8042|4242)' || echo "Orthanc ports not listening (verify service state)."

echo "=== [3] Locate and back up configuration ==="
CONF=$(find /etc/orthanc /opt /srv -name 'orthanc.json' 2>/dev/null | head -1 || true)
if [ -n "${CONF}" ]; then
    cp -a "${CONF}" "${CONF}.bak.$(date +%F)"
    echo "Config backed up: ${CONF}.bak.$(date +%F)"

echo "=== [4] Audit authentication settings ==="
    grep -E '"AuthenticationEnabled"|"RegisteredUsers"|"RemoteAccessAllowed"' "${CONF}" || \
        echo "WARNING: No auth keys found - review full config manually."
    if grep -q '"AuthenticationEnabled"[[:space:]]*:[[:space:]]*false' "${CONF}" || \
       ! grep -q '"AuthenticationEnabled"' "${CONF}"; then
        echo "CRITICAL: REST API authentication is disabled or unset. Enable it before continuing."
    fi
else
    echo "orthanc.json not found in standard paths - check Docker volume mounts."
fi

echo "=== [5] Check for credential rotation need ==="
echo "ACTION REQUIRED: Rotate ALL RegisteredUsers passwords in orthanc.json."
echo "Use unique, high-entropy credentials per integration account. Do NOT reuse service passwords."

echo "=== [6] Bind REST API to localhost where feasible ==="
echo "RECOMMENDED: Set \"HttpServerEnabled\" behind a reverse proxy and restrict 8042 to trusted subnets via firewall:"
echo "  ufw allow from <PACS_SUBNET> to any port 8042 proto tcp"
echo "  ufw allow from <MODALITY_SUBNET> to any port 4242 proto tcp"
echo "  ufw deny 8042 && ufw deny 4242"

echo "=== [7] Enable systemd auto-restart as DoS resilience stopgap ==="
if systemctl list-unit-files | grep -q orthanc; then
    mkdir -p /etc/systemd/system/orthanc.service.d
    cat > /etc/systemd/system/orthanc.service.d/restart.conf <<'EOF'
[Service]
Restart=always
RestartSec=5
StartLimitIntervalSec=300
StartLimitBurst=10
EOF
    systemctl daemon-reload
    systemctl restart orthanc
    echo "systemd auto-restart hardening applied."
fi

echo "=== [8] Apply vendor update ==="
echo "Now update Orthanc to the latest patched release:"
echo "  apt update && apt install --only-upgrade orthanc"
echo "  # or pull the latest image: docker pull orthancteam/orthanc:latest"
echo "Verify version after update and re-run step 1."

echo "=== Done. Review all warnings above before closing this ticket. ==="

Remediation

1. Update Orthanc immediately. Upgrade all Orthanc instances — bare-metal, package-managed, and Docker — to the latest release published by the Orthanc project. Monitor the official channels for the patched version and advisory details:

   • Orthanc official site and release notes: https://www.orthanc-server.com/
   • Orthanc source and issue tracker: https://hg.orthanc-server.com/ and https://discourse.orthanc-server.org/
   • The HIPAA Journal coverage: https://www.hipaajournal.com/orthanc-dicom-server-vulnerability-denial-of-service/

2. Rotate all REST API credentials. Because exploitation requires authentication, treat every credential in RegisteredUsers as potentially exposed. Rotate passwords now, enforce unique credentials per integration account, and audit for shared or script-embedded secrets. Remove any accounts no longer in active use.

3. Enforce authentication everywhere. Verify "AuthenticationEnabled": true in orthanc.json on every instance. An unauthenticated Orthanc API converts this authenticated-only DoS into a zero-click problem. If you find any instance with authentication disabled, treat it as an incident, not a misconfiguration.

4. Segment and restrict network exposure. The Orthanc REST API (TCP 8042) should never be reachable from general user subnets, guest networks, or the internet. Restrict access to known PACS peers, VNA systems, and integration servers via firewall rules or a reverse proxy with allowlisting. The DICOM port (TCP 4242) should be reachable only from authorized modalities and routing peers.

5. Put the REST API behind a reverse proxy. Front Orthanc with nginx or Apache terminating TLS, enforcing rate limiting, and logging requests centrally. This gives you both a mitigation layer against request-flood-style DoS and the telemetry your detections depend on.

6. Add service resilience as a stopgap. Configure systemd Restart=always (or Docker restart: unless-stopped) so a crash-triggered DoS self-recovers while you patch. This is not a fix — it reduces clinical impact duration.

7. Audit for internet exposure. Query Shodan/Censys for your organization's IP space on ports 8042 and 4242. Exposed DICOM infrastructure is a well-documented healthcare attack surface and has been targeted in prior data-theft and extortion campaigns. Pull anything exposed behind a VPN or private connectivity immediately.

8. Review HIPAA Security Rule alignment. Availability of ePHI systems is a compliance obligation (45 CFR §164.306, §164.308(a)(7) contingency planning). Document this remediation in your risk register and verify your contingency plan covers imaging-system downtime procedures.

Closing Assessment

An authenticated DoS in a DICOM server is exactly the kind of vulnerability that separates reactive healthcare security programs from resilient ones. The patch is straightforward; the harder work is the credential hygiene, network segmentation, and monitoring that determine whether an attacker ever gets to the authentication step in the first place. Use this disclosure as the forcing function: patch Orthanc, rotate the credentials, lock down port 8042, and get your imaging infrastructure telemetry into the SIEM. If a radiologist can't pull priors because your DICOM server is down, the clinical impact clock is already running.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub