CVE-2026-87020: Orthanc DICOM Server Heap Overflow DoS — Healthcare Detection and Remediation Guide

CISA ICS Medical Advisory ICSMA-26-253-02 flags a high-severity flaw in Orthanc DICOM Server < 1.13.0, tracked as CVE-2026-87020, CVSS v3 8.1. The weakness is an integer overflow or wraparound in a pitch/buffer-size computation used while decoding attacker-supplied PNG or JPEG image data. A successful exploit can drive a heap out-of-bounds write past the end of an allocation and crash the Orthanc process, creating a denial-of-service condition.

This is not an abstract image-parser bug. Orthanc is widely deployed as a lightweight PACS/DICOM server and edge modality gateway in hospitals, imaging centers, teleradiology pipelines, research archives, and vendor-integrated clinical workflows. If Orthanc is unavailable, modalities may queue studies, radiology worklists may stall, prefetch/cache jobs can fail, and downstream viewers or AI inference services may stop receiving studies. The advisory explicitly places deployment in the Healthcare and Public Health critical infrastructure sector and worldwide scope.

The exploitation requirement matters: CISA describes an authenticated remote attacker. That reduces opportunistic internet exploitation, but it does not eliminate risk. Many Orthanc instances are deployed with weak local credentials, anonymous access enabled by accident, flat network trust inside clinical VLANs, vendor service accounts, reverse proxies that pass through application authentication, or exposed REST endpoints used by integration engines. In incident response, “authenticated” often means “any process or compromised workstation that can reach port 8042 and knows or guesses a service credential.”

Affected products, severity, and exploitation status

The defect class is important for defenders. Integer overflows in image decoding are frequently reachable through metadata or dimensions, not merely through malformed pixel bytes. In DICOM workflows, image payloads can arrive through multiple paths: DICOM C-STORE with encapsulated transfer syntaxes, REST uploads to Orthanc endpoints, import from folders, plugin-driven ingestion, modality worklist/PACS bridge synchronization, or automated de-identification/conversion jobs that materialize PNG/JPEG previews.

CISA’s summary does not state confirmed in-the-wild exploitation, public proof-of-concept code, or CISA Known Exploited Vulnerabilities inclusion for CVE-2026-87020. Treat it as high priority but not known-exploited as of the advisory. The healthcare impact profile and CVSS 8.1 score justify accelerated patching even without active exploitation, especially where Orthanc is reachable from clinical workstations, vendor support networks, cloud imaging pipelines, or less-trusted research networks.

Defender’s view of the attack chain

A realistic attack chain looks like this:

1. Reach Orthanc. The attacker needs network access to Orthanc’s REST/API surface, commonly TCP 8042, or to an integration path that ultimately submits images to Orthanc. DICOM C-STORE commonly uses TCP 4242, but the advisory specifically describes decoding attacker-supplied PNG or JPEG, so the highest-fidelity hunting surface is Orthanc’s HTTP/REST ingestion and any conversion/import pipeline that feeds image files into Orthanc.
2. Authenticate. The attacker uses valid local credentials, a compromised integration account, an exposed reverse proxy session, a stolen token from a modality gateway, or an instance misconfigured with remote access allowed and weak/no authentication.
3. Submit crafted image content. The attacker supplies a PNG/JPEG directly or embeds image data in a workflow that causes Orthanc to decode it. Examples include REST upload paths, generated DICOM objects with image payloads, preview generation, plugin conversions, or inbound synchronization from a compromised peer.
4. Trigger size computation overflow. During decode, Orthanc computes a pitch and buffer size from attacker-controlled values. If width/height/stride arithmetic wraps, the allocated buffer is smaller than the amount written.
5. Crash the process. The heap out-of-bounds write corrupts memory and terminates or destabilizes Orthanc. Repeated submissions can keep the service in a crash loop, interrupting imaging availability.

The public summary does not claim code execution. Do not overstate RCE in client communications. The operational risk is availability and integrity of imaging workflows, plus the fact that a memory-corruption primitive in an internet- or intranet-reachable medical service deserves treating as a serious engineering failure even when the demonstrated outcome is a crash.

Immediate triage questions for the SOC and clinical engineering

Ask these questions today:

• Where are all Orthanc servers, including Docker containers, research PACS, vendor appliances, test instances, DICOM routers, and temporary de-identification nodes?
• What version is running on each node, and who owns patching: IT, clinical engineering, vendor, or research team?
• Is TCP 8042 reachable beyond a dedicated PACS VLAN? Is TCP 4242 exposed to modalities only, or broadly routable?
• Is RemoteAccessAllowed disabled unless truly required? Is AuthenticationEnabled true? Are registered users minimal and unique?
• Are reverse proxies terminating TLS and enforcing SSO/MFA, or are they merely forwarding unauthenticated traffic to Orthanc’s native authentication?
• Which plugins are installed? Image conversion, DICOM web, PostgreSQL/MySQL index, cloud storage, or custom import plugins can expand the image-decode attack surface.
• Are crash dumps, service restarts, container restarts, and Orthanc logs centrally collected? Can you correlate a REST upload with a crash within seconds?

Detection strategy

The most reliable signal is temporal correlation: an authenticated image upload or import followed closely by Orthanc process termination, container restart, systemd restart, Windows service stop, core dump creation, or application error logs. Network-only detection for PNG/JPEG payloads is noisy because hospitals move massive volumes of images. Process-crash and crash-loop telemetry is lower-noise and directly maps to the impact.

Prioritize these data sources:

• Orthanc logs: HTTP requests, errors during decode, DICOM association drops, plugin errors.
• Linux: syslog/journald, systemd unit restart counters, systemd-coredump, auditd, Docker/containerd events, orchestrator restart events.
• Windows: Service Control Manager operational events for Orthanc service stop/start, Windows Error Reporting artifacts, process termination events, application crash dumps.
• Reverse proxy/load balancer logs: POSTs to Orthanc upload or instance endpoints, client identity, request size, status codes, and upstream resets.
• EDR: process lifetime for Orthanc, child processes, service recovery actions, abnormal exits.

---
title: Orthanc DICOM Server Crash Artifact Creation
id: 7d4f1a2e-4b0c-4f53-9d1a-2c7b8a9f0011
status: experimental
description: Detects creation of crash dump or Windows Error Reporting artifacts associated with the Orthanc DICOM server process, which may indicate exploitation of CVE-2026-87020 or another memory-corruption failure.
references:
  - https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-253-02
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.impact
  - attack.t1499
logsource:
  category: file_event
  product: windows
detection:
  selection_wer:
    TargetFilename|contains:
      - '\Windows Error Reporting\'
      - '\WER\'
    TargetFilename|contains: 'Orthanc'
  selection_dumps:
    TargetFilename|endswith:
      - '.dmp'
      - '.hdmp'
      - '.mdmp'
    TargetFilename|contains: 'Orthanc'
  condition: selection_wer or selection_dumps
falsepositives:
  - Legitimate Orthanc instability during upgrades, plugin faults, or storage exhaustion
  - Manual dump collection by administrators
level: high
---
title: Orthanc Service Stop or Unexpected Termination on Windows
id: 1bb5c9d7-83f5-4ec9-9c47-0f5c6a21e2aa
status: experimental
description: Detects stop, disable, or recovery-control actions targeting the Orthanc Windows service. Use with process and proxy telemetry to identify crash loops consistent with image-decode denial of service.
references:
  - https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-253-02
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.impact
  - attack.t1499
logsource:
  category: process_creation
  product: windows
detection:
  selection_sc:
    Image|endswith: '\sc.exe'
    CommandLine|contains:
      - ' stop '
      - ' config '
      - ' failure '
    CommandLine|contains: 'Orthanc'
  selection_net:
    Image|endswith: '\net.exe'
    CommandLine|contains:
      - ' stop '
      - ' start '
    CommandLine|contains: 'Orthanc'
  selection_powershell:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - 'Stop-Service'
      - 'Restart-Service'
      - 'Set-Service'
    CommandLine|contains: 'Orthanc'
  condition: 1 of selection_*
falsepositives:
  - Maintenance windows and patching
  - Legitimate service recovery scripts
level: medium
---
title: Linux Core Dump Handler Invoked for Orthanc Process
id: 4e70d0d9-4f89-46c2-9aa7-b2e11d0d90c3
status: experimental
description: Detects systemd-coredump or crash handler activity referencing Orthanc on Linux hosts. A core dump shortly after an authenticated image upload is a strong indicator of CVE-2026-87020-style denial of service.
references:
  - https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-253-02
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.impact
  - attack.t1499
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|endswith:
      - '/systemd-coredump'
      - '/coredumpctl'
      - '/abrt-hook-ccpp'
      - '/apport'
    CommandLine|contains:
      - 'orthanc'
      - 'Orthanc'
falsepositives:
  - Deliberate debugging or dump collection
  - Orthanc crashes caused by storage, database, or plugin defects
level: high

// Microsoft Sentinel / Defender hunt: Orthanc crash, restart, and suspicious upload correlation
// Tune orthanc host names, service names, ports, and proxy log fields to your environment.
let lookback = 7d;
let OrthancHosts = dynamic(["orthanc", "pacs", "dicom"]);
let ProcSignals =
    union isfuzzy=true
    (Syslog
    | where TimeGenerated > ago(lookback)
    | where ProcessName has_any (OrthancHosts) or SyslogMessage has_any ("Orthanc", "orthanc", "systemd-coredump", "Segmentation fault", "core dumped", "Aborted")
    | where SyslogMessage has_any ("Orthanc", "orthanc", "Segmentation fault", "core dumped", "Aborted", "exit-code", "Main process exited", "Failed", "PNG", "JPEG", "DICOM")
    | project TimeGenerated, Computer, ProcessName, SyslogMessage, HostIP, Source="Syslog"),
    (CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where DeviceProduct has_any ("nginx", "apache", "haproxy", "proxy", "firewall") or DeviceCustomString1 has_any ("orthanc", "pacs", "dicom")
    | where RequestURL has_any ("/instances", "/tools", "/patients", "/studies", "/series") or RequestMethod == "POST"
    | where DestinationPort in (8042, 4242) or DeviceCustomString1 has "8042"
    | project TimeGenerated, Computer=SourceHostName, ProcessName="", SyslogMessage=strcat(RequestMethod, " ", RequestURL, " status=", tostring(AdditionalExtensions)), HostIP=SourceIP, Source="CEF"),
    (DeviceProcessEvents
    | where TimeGenerated > ago(lookback)
    | where FileName =~ "Orthanc.exe" or FileName =~ "orthanc" or ProcessCommandLine has "Orthanc"
    | project TimeGenerated, Computer=DeviceName, ProcessName=FileName, SyslogMessage=ProcessCommandLine, HostIP="", Source="DefenderProcess");
ProcSignals
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Count=count(), Sources=make_set(Source), SampleMessages=make_set(SyslogMessage, 8) by Computer, ProcessName
| where Count > 5 or Sources has_any ("Syslog", "CEF")
| sort by LastSeen desc;

-- Velociraptor artifact: Orthanc process, listener, and crash-artifact hunt
-- Scope to clinical engineering, PACS, DICOM router, research imaging, and vendor-managed subnets first.
SELECT Pid,
       Ppid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime
FROM pslist()
WHERE Name =~ '(?i)orthanc'
   OR Exe =~ '(?i)orthanc'
   OR CommandLine =~ '(?i)orthanc'
UNION ALL
SELECT NULL AS Pid,
       NULL AS Ppid,
       'LISTENER:' + Protocol AS Name,
       Laddr AS Exe,
       Raddr AS CommandLine,
       Name AS Username,
       NULL AS CreateTime
FROM netstat()
WHERE Laddr =~ ':(8042|4242)$'
UNION ALL
SELECT NULL AS Pid,
       NULL AS Ppid,
       'CRASH_ARTIFACT' AS Name,
       FullPath AS Exe,
       Size AS CommandLine,
       Mtime.String AS Username,
       Mtime AS CreateTime
FROM glob(globs=[
  '/var/lib/systemd/coredump/*orthanc*',
  '/var/lib/systemd/coredump/*Orthanc*',
  '/var/crash/*orthanc*',
  'C:/ProgramData/Microsoft/Windows/WER/**/*Orthanc*',
  'C:/ProgramData/Microsoft/Windows/WER/**/*orthanc*',
  'C:/**/*.dmp'
], accessor='file')
WHERE FullPath =~ '(?i)(orthanc|wer|dump|dmp)'

Tune aggressively. The Sigma rules are intentionally impact-oriented: dumps, service manipulation, and core-dump handlers. Do not deploy a broad “any JPEG upload” rule in a hospital network; it will drown the SOC and train analysts to ignore the alert. Instead, alert on Orthanc termination within a short window after authenticated POST/upload activity, repeated container restarts, or crash artifacts on PACS infrastructure.

Bash audit and hardening script

Run this on Linux Orthanc hosts to identify vulnerable versions, exposed listeners, weak authentication posture, recent restarts, and crash artifacts. It is intentionally audit-first; it does not blindly upgrade a clinical system during imaging hours.

#!/usr/bin/env bash
set -euo pipefail

echo "[+] Orthanc CVE-2026-87020 audit - $(date -Is)"

echo "[+] Installed Orthanc binaries/packages"
command -v orthanc || true
command -v Orthanc || true
( orthanc --version 2>/dev/null || Orthanc --version 2>/dev/null || true )
if command -v dpkg >/dev/null 2>&1; then dpkg -l 2>/dev/null | grep -i orthanc || true; fi
if command -v rpm >/dev/null 2>&1; then rpm -qa 2>/dev/null | grep -i orthanc || true; fi

echo "[+] Containers/images that may contain Orthanc"
if command -v docker >/dev/null 2>&1; then docker ps --format '{{.Names}} {{.Image}} {{.Ports}}' 2>/dev/null | grep -Ei 'orthanc|8042|4242' || true; docker images --format '{{.Repository}}:{{.Tag}}' 2>/dev/null | grep -i orthanc || true; fi
if command -v podman >/dev/null 2>&1; then podman ps --format '{{.Names}} {{.Image}} {{.Ports}}' 2>/dev/null | grep -Ei 'orthanc|8042|4242' || true; podman images --format '{{.Repository}}:{{.Tag}}' 2>/dev/null | grep -i orthanc || true; fi

echo "[+] Listening sockets for Orthanc defaults"
(ss -lntup 2>/dev/null || netstat -lntup 2>/dev/null || true) | grep -E ':(8042|4242)\b|orthanc' || true

echo "[+] Candidate configuration files"
for f in /etc/orthanc/*.json /etc/orthanc/orthanc.json /opt/orthanc/*.json /usr/local/etc/orthanc/*.json; do
  [ -f "$f" ] || continue
  echo "--- $f"
  grep -Ei 'RemoteAccessAllowed|AuthenticationEnabled|RegisteredUsers|DicomPort|HttpPort|SslEnabled|Plugins|StorageDirectory|IndexDirectory' "$f" 2>/dev/null || true
done

echo "[+] Risky configuration flags"
grep -RniE '"RemoteAccessAllowed"[[:space:]]*:[[:space:]]*true|"AuthenticationEnabled"[[:space:]]*:[[:space:]]*false|"RegisteredUsers"[[:space:]]*:[[:space:]]*\{' /etc/orthanc /opt/orthanc /usr/local/etc/orthanc 2>/dev/null || true

echo "[+] Recent Orthanc service/container restarts"
( journalctl -u 'orthanc*' --since '14 days ago' --no-pager 2>/dev/null | grep -Ei 'start|stop|exit|failed|core|segfault|aborted|orthanc' | tail -n 80 ) || true
if command -v docker >/dev/null 2>&1; then docker events --since '336h' --format '{{.Time}} {{.Type}} {{.Action}} {{.Actor.Attributes.name}} {{.Actor.Attributes.image}}' 2>/dev/null | grep -Ei 'orthanc|die|restart|kill|oom' || true; fi

echo "[+] Core dumps and crash artifacts"
( coredumpctl list --no-pager 2>/dev/null | grep -i orthanc || true )
ls -lh /var/lib/systemd/coredump/*orthanc* /var/crash/*orthanc* 2>/dev/null || true

echo "[+] Exposure checks - run from a scanner, not only locally"
cat <<'CHECKS'
1. Confirm TCP 8042 is not reachable from user VLANs, guest Wi-Fi, VPN pools, vendor remote access, or the internet unless explicitly required and proxied with SSO/MFA.
2. Confirm TCP 4242 is restricted to authorized modalities/PACS peers by AE title where possible and by source IP at the firewall.
3. If internet exposure exists for DICOMweb/REST, place Orthanc behind a hardened reverse proxy/WAF with TLS, request-size limits, authentication, rate limiting, and upload logging.
CHECKS

echo "[+] Version gate"
VER="$( (orthanc --version 2>/dev/null || Orthanc --version 2>/dev/null || true) | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1 )"
if [ -n "${VER:-}" ]; then
  python3 - "$VER" <<'PY'
import sys
def parts(v): return tuple(int(x) for x in v.split('.'))
if parts(sys.argv[1]) < (1,13,0):
    print('VULNERABLE: Orthanc', sys.argv[1], '< 1.13.0. Plan upgrade now.')
else:
    print('OK: Orthanc', sys.argv[1], 'is 1.13.0 or later by version string; still verify build provenance and plugins.')
PY
else
  echo "VERSION UNKNOWN: validate package/container tag manually; absence of a local binary does not prove absence of a container or appliance."
fi

echo "[+] Reminder: test upgrade in staging, snapshot/backup StorageDirectory and database, then schedule clinical change control."

Remediation and risk reduction

Primary fix: upgrade Orthanc DICOM Server to 1.13.0 or later. Treat this as the only complete remediation for CVE-2026-87020. Follow the CISA advisory at https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-253-02 and the Orthanc project release artifacts for your platform, package, container, or plugin compatibility matrix. For Docker/Podman deployments, update the image tag, rebuild any derived images, and rotate cached base layers so an older vulnerable layer is not redeployed by orchestration.

Before production change, create a recovery plan for imaging operations:

• Snapshot/backup StorageDirectory, the index database, configuration JSON, certificates, plugin configuration, and any cloud sync state.
• Verify study counts and recent-modality ingest before and after upgrade.
• Test DICOM C-STORE/C-FIND/C-MOVE, REST upload/download, DICOMweb if enabled, viewer launch, worklist, de-identification jobs, and plugin behavior.
• Stage during a low-imaging window with radiology/clinical engineering on call and a rollback path.

If patching cannot happen immediately, reduce exploitability and blast radius:

• Enforce AuthenticationEnabled: true and unique strong credentials. Remove anonymous/shared accounts and rotate any credential stored in scripts, integration engines, vendor documentation, or orchestration secrets.
• Set RemoteAccessAllowed: false unless remote HTTP access is strictly required. Where required, front Orthanc with a reverse proxy enforcing TLS, SSO/MFA, IP allowlists, request-size limits, and explicit method/path restrictions for upload endpoints.
• Restrict TCP 8042 to PACS application servers, integration engines, and approved admin jump hosts. Do not expose it to broad clinical user VLANs, guest networks, research DMZs, vendor VPNs, or the internet.
• Restrict TCP 4242 to authorized modalities and PACS peers using source-IP rules and AE title validation where supported. Segment DICOM from general user traffic.
• Disable unused plugins and image conversion/import features. Review any plugin that accepts files from users, scanners, cloud buckets, or external partners and routes them into Orthanc decoding.
• Add service supervision with sane restart limits and paging on repeated restarts. A crash loop should page the SOC and clinical engineering, not silently restart forever.
• Capture and retain Orthanc HTTP/REST logs, reverse proxy logs, DICOM association logs, systemd/container restart events, and crash dumps for at least the IR window required by policy and regulatory obligations.
• For PHI environments, preserve crash dumps cautiously. They may contain fragments of imaging data or identifiers. Store them in access-controlled locations and include privacy/compliance in handling decisions.

Patching priority guidance

Prioritize in this order:

1. Internet-reachable or partner-reachable Orthanc nodes.
2. Orthanc servers reachable from large user VLANs, research networks, vendor support VPNs, or flat clinical segments.
3. Nodes that accept uploads from modalities, third-party AI/inference pipelines, de-identification services, or cloud ingestion.
4. Highly available PACS components where a crash would interrupt urgent care, surgery, stroke, trauma, oncology, or cardiology imaging.
5. Test/development instances with production data or production network reachability.

Do not let “authenticated” lull the team into a normal quarterly cycle. In healthcare environments, authentication is often a thin control over a broad internal attack surface. A CVSS 8.1 memory-corruption crash in a DICOM server that can interrupt imaging availability belongs on the accelerated patch list.

Validation after remediation

• Confirm version strings and package/container digests across every node.
• Run an authenticated negative test in staging with malformed PNG/JPEG samples from your security test corpus; verify Orthanc rejects input without process termination. Do not run crash-inducing tests against production imaging.
• Verify logs show clean application errors rather than service exits, core dumps, container restarts, or upstream resets.
• Review firewall/proxy rules after maintenance to ensure temporary “open it up for the vendor” access was removed.
• Add a regression alert: any Orthanc process crash artifact, repeated service restart, or authenticated upload followed by termination should create a high-priority case.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub