An open-source DICOM server that shipped with auth off by default

MedDevice Cyber Staff · Feb 6 · 3 min read · Via CISA

The default was the vulnerability. Orthanc Server, the widely embedded open-source DICOM server, drew ICSMA-25-037-02 for versions before 1.5.8. CVE-2025-0896, missing authentication for a critical function, base score 9.8.

Insecure defaults are a design decision more than a coding mistake. Software often ships with the gentlest possible initial setup, permissions relaxed so a new user reaches a working system without a fight, the tightening left to whoever deploys it. Yet a default is the configuration the overwhelming majority of installations run unchanged, and when the component is meant to be embedded, that setting travels downstream into every integration that never thought to override it.

Expose the remote HTTP interface without explicitly setting AuthenticationEnabled to true, and an unauthenticated attacker could read or modify imaging records or knock the service over. The people who integrate Orthanc into a product inherit that default unless they know to change it, and most integration guides never mention it.

For a server whose whole purpose is to hold medical imaging, authentication left off separates a private archive from an open, readable service. An interface reachable on a network with no login in front of it can be found by routine scanning and then read from or written to at will, which here means studies, patient identifiers and the ability to alter or delete them. Nothing has to be broken into; the door was never fitted with a lock.

The deeper issue is where this software lives. It is not a finished product a hospital configures but a building block folded into larger systems, often several layers removed from the clinician who depends on it. That distance lets a permissive default persist, because each party assumes another dealt with it. Open-source components at the base of the imaging stack have become a recurring source of exposure for this reason.

This is separate from the nine-CVE Orthanc note that came a year later. Same server, two advisories, one lesson: ship secure by default, because the default is what most deployments run forever.

Remediation Desk

For ProvidersOperators, hospitals, and clinical engineering

Orthanc Server before 1.5.8 did not enable authentication by default when the HTTP interface was exposed (ICSMA-25-037-02), leaving imaging records reachable to any unauthenticated attacker. Update past 1.5.8, turn authentication on, and confirm no instance is exposed without it.

Update past 1.5.8. Move to the Orthanc release that closes the default-no-auth behavior.
Require authentication. Enable authentication on the HTTP interface and verify it is enforced, not just configured.
Ship secure by default. An exposed interface should require authentication out of the box, never rely on an operator knowing to switch it on.

For Device ManufacturersAm I affected, and how to fix the class

Am I affected?

This class applies to devices with the properties below. Check them against your product to gauge exposure.

Required

data_phi

Contributing

net_wired net_remote_access app_user_accounts net_wireless net_cloud app_database parse_image sys_ots_software use_hospital_net

EMB3D

PID-331 PID-332 PID-41

Fix the class in your product

The product exposes an interface with authentication off out of the box. As the maker, make the default configuration the secure configuration: require an admin credential before any interface serves data, and refuse to expose anything until setup is complete.

Default to authenticated. Block every data path until an admin credential is set on first boot.
Make insecure mode explicit. If an open mode must exist, it is a loud, logged, opt-in choice, never the starting state.
Test the out-of-box state. Treat the shipped default as its own threat model.

Mapped EMB3D mitigations

Questions & Answers

What is CVE-2025-0896 in Orthanc Server?

Missing authentication for a critical function, base score 9.8, in versions before 1.5.8. With the remote HTTP interface exposed and AuthenticationEnabled not explicitly set to true, an unauthenticated attacker could read or modify imaging records or take the service down.

Who is affected by the Orthanc default?

Any deployment that exposed the HTTP interface without turning authentication on, including commercial products that embed Orthanc. Integrators inherit the default unless they know to change it.

← Back to Vulnerabilities