40% of Exposed Medical Image Consoles Answer without a Password

By Adrian Cheek, Senior Cybercrime Researcher

To reach a hospital’s medical images the hard way, you need a DICOM (Digital Imaging and Communications in Medicine) client and some knowledge of a protocol designed in the 1980s for machines that were never supposed to face the internet. To reach a growing number of them the easy way, you can open a web browser and type an address. The image server that stores a patient’s scans no longer just speaks the old wire protocol on an obscure port. It increasingly runs a web console for administration and a browser-based viewer for the images themselves, and those two web interfaces sit on the public internet far more often, and far more openly, than they should.

In May 2026, Trend Micro’s TrendAI team published a careful census of internet-exposed DICOM servers measured at the protocol layer, finding thousands worldwide with almost no encryption or caller validation and a large share running identical configurations. It is the definitive account of that exposure, and nothing here disputes it. But a DICOM server is two things at once, and a protocol scan sees only one. The same system that answers radiology workstations on port 104 increasingly runs a web console for administration and a browser-based viewer for clinicians, and those web interfaces sit on the public internet far more often, and far more openly, than they should. We went looking for the other: the web interfaces of the same systems, reachable with a browser and nothing else. They constitute a distinct exposure surface that protocol-layer surveys overlook, and one frequently reachable without authentication. What we found: 40% of US Orthanc (free, open-source DICOM) admin consoles answer a browser with no authentication challenge at all.

We collected this entirely from passive open source data already in open circulation. The result is a view of two open-source components a protocol scan never sees, and a measurement of how many answer a browser with no password at all.

Key Findings About Exposed Medical Image Findings

• The exposure has a second layer that protocol scans miss. The systems here answer on web ports (80, 443, 8042, 3000), not the DICOM protocol ports (104, 4242, 11112). Closing the DICOM port does not close the web console, and the web console opens in a browser, no specialist software required.
• 40% of exposed Orthanc admin consoles answered with no authentication at all. Of 91 Orthanc Explorer consoles geolocated to the United States, 36 returned their management interface with no authentication challenge and no login gate; another 12 were ambiguous and 43 were protected. The pattern held abroad, with 105 of 314 confirmed open in the rest of the world.
• OHIF viewers are an exposure category no DICOM census counts, because the viewer speaks HTTP, not DICOM. We observed 700 globally, 138 in the US. Viewer presence is not itself a data leak, but a small number expose backend endpoints in client-side configuration.
• The exposure rides a copy-paste deployment recipe. Among OHIF viewers that exposed a favicon, 96% carried one of just two identical hashes, the fingerprint of the canonical OHIF-Orthanc Docker recipe deployed verbatim. The same shared-recipe pattern that creates the exposure also makes it uniform, so one misconfiguration repeats across hundreds of unrelated deployments.
• This is a small-operator problem, not a hospital-IT problem. The systems concentrate on hosting-provider networks and small-practice deployments, not enterprise hospital estates. That fits radiology and pathology shops self-hosting a free imaging stack without the security review a hospital would apply.

Two Doors, Not One

The distinction matters because the two layers fail independently. The protocol layer is the DICOM wire service a radiology workstation talks to, reachable on ports 104, 4242, and 11112 with a DICOM client. The web layer is what a browser sees: Orthanc’s Explorer console and the OHIF viewer. An organization can firewall the DICOM port and leave the Orthanc console answering on port 8042, and from the data, many have. These are different entrances to the same building, and the web entrance needs no special tools to walk through.

Every system here was found on a web port; none overlaps the protocol-port population a DICOM scan enumerates. That is the basis for treating it as a separate exposure, not a re-run of prior work.

What is on the Web Layer

Two open-source components carry this: Orthanc, the Picture Archiving and Communication System (PACS) that stores and serves images, with its browser-based Explorer console; and OHIF, a browser-based viewer that renders studies from a backend like Orthanc. Neither is visible to a DICOM-protocol scan. Globally we observed 414 Orthanc consoles and 700 OHIF viewers.

The two raise different questions. Orthanc holds data, so whether its console is locked is the exposure that matters. OHIF is a viewer, so its presence alone is not a leak, and the interesting question is what it reveals about the backend behind it. The published protocol-layer work flattens both into a port number. Here they are measured as what they are: web applications.

The Orthanc Console: Open More Often Than Not

Orthanc’s Explorer is the administrative front end of the image store, and whether it is locked is the exposure that counts. Read passively, the classification is three-way:

• Protected: a 401 or auth header
• Open: a 200 serving the interface with no login gate
• Ambiguous: a 200 serving the interface but also carrying login markup, which may gate client-side

Held to that standard, the US breaks down as 36 of 91 confirmed open (40%), 43 protected (47%), and 12 ambiguous (13%). Even setting every ambiguous host aside, a confirmed-open console is routine, not an outlier.

On method: the open count is deliberately conservative. Every host classified as open returned a 200, served the Orthanc Explorer interface, and carried no authentication header and no login-gate markup in the stored response. Hosts that returned the interface alongside any login or password markup were set aside as ambiguous, not counted as open. No host was contacted to make this determination; the classification was tightened against the responses already collected.

On cause: This is the measured result of a known cause. CVE-2025-0896 records that Orthanc does not enable authentication by default when remote access is turned on. The advisory tells an operator the default is unsafe. What it does not tell anyone is how much of the live population still reflects that default, and the answer, on the web layer, is most of it.

The OHIF Viewer: A Surface No Protocol Scan Sees

OHIF appears in no DICOM-protocol census because it does not speak DICOM. It is a static browser app that talks to a backend over web APIs, so a wire-protocol scan looks straight past it. Finding a viewer is not a breach, but it is an information surface. The viewer ships a client-side configuration object, and 674 of the instances we observed expose it in the page; in 7, it references the DICOMweb backend endpoints directly, a pointer to the data source served to any browser. We report OHIF as application-present, 138 in the US, and treat backend exposure as a separate, graded question. The point is narrower and still useful: an exposure category the protocol-layer view cannot register.

One Recipe, Repeated

Trend Micro found that a large share of exposed servers cluster into identical configurations at the protocol level. The web layer shows the same monoculture from the other side, and our data reproduces it independently, most clearly for OHIF.

Of 700 viewers, 658 exposed a favicon. Of those, 632 carried just two identical hashes. Over 90% of viewers concentrate on two assets, the signature of hundreds of operators deploying the same Docker recipe without changing anything.

Orthanc shows the same shape on thinner evidence. Only 168 of 414 consoles exposed a favicon at all, and among those, 149 shared a single hash. That is a strong cluster among consoles that report a favicon, but it says nothing about the 60% that do not, so the Orthanc monoculture is suggestive rather than population-wide. The OHIF signal is the firm one. In both cases the cause is the same: the canonical OHIF-Orthanc Docker compose file, copied verbatim, carrying its defaults (including authentication left off) into every deployment that uses it. The protocol-layer and web-layer monocultures are two views of one root cause.

A shared deployment recipe means a single insecure default can affect hundreds of independent deployments at once. A default-off authentication setting stops being one clinic’s mistake and becomes a population-scale condition.

Who is Exposed

Attribution from the data is best-effort. The systems concentrate on hosting-provider networks, not hospital enterprise ranges, and the geography spreads across India, the US, Brazil, Germany, and a long tail of others, tracking the global install base of a free imaging stack rather than any one health system. The shape fits small radiology and pathology practices self-hosting Orthanc and OHIF, not hospital IT departments that would put an image store behind authentication and off the public internet as a matter of course. The organizations least equipped to review their own exposure are the ones most likely to be carrying it.

Key Judgments

High Confidence

• We assess with high confidence that self-hosted medical imaging is exposed at the web-interface layer, independently of the DICOM protocol layer. Every system here was found on a web port distinct from the DICOM protocol ports, and the populations do not overlap.
• We assess with high confidence that a large share of exposed Orthanc admin consoles are reachable without authentication. On a conservative passive classification, 36 of 91 US consoles (40%) are confirmed open with no authentication, 47% are protected, and 13% are ambiguous; the pattern is consistent across regions and consistent with the default-off behavior recorded in CVE-2025-0896. The confirmed-open figure is a floor, since the ambiguous hosts may also be open.
• We assess with high confidence that the OHIF viewer constitutes an exposure category absent from protocol-layer censuses. It speaks HTTP rather than DICOM and therefore cannot appear in a wire-protocol scan, yet 700 instances are reachable and most expose client-side configuration.

Moderate Confidence

• We assess with moderate confidence that the exposure is driven by a shared deployment recipe rather than independent misconfiguration. The OHIF favicon concentration is strong evidence; the Orthanc favicon evidence is partial because most consoles do not report one, so the recipe conclusion is firm for the viewer and suggestive for the server.
• We assess with moderate confidence that the affected population is concentrated among small practices and self-hosting operators rather than hospital enterprise IT, based on hosting-network concentration and deployment pattern. Attribution from autonomous-system and DNS data is indicative, not definitive.

What Security Teams Can Do This Week

For any organization running, or contracting out, a self-hosted imaging stack:

• Check the web interface, not just the DICOM port. Closing ports 104, 4242, and 11112 does nothing for port 8042. Confirm the Orthanc console requires authentication when reached from outside your network, and assume it does not until you have checked.
• Treat the viewer’s client configuration as public. Anything in OHIF’s app-config is readable by any browser that loads the viewer. It must not contain backend endpoints, internal hostnames, or anything you consider private.
• Pull the image store off the public internet. The viewer can be public; the PACS backend should sit behind authentication and ideally not be internet-reachable at all.
• Fix it at the recipe, not just the instance. Because the exposure rides a shared Docker recipe, the durable fix is a deployment that ships with authentication enabled. For the open-source projects, a recipe that refuses to start while exposed and unauthenticated would close most of this at the source.

The DICOM protocol exposure that Trend Micro documented and the web-interface exposure documented here are two views of one systemic problem: a free, powerful imaging stack deployed by operators who never changed its defaults. The difference is that the web doors require no special tools to find or to open. For the small practices and imaging shops carrying this exposure, the fix is not complex, but it does require knowing the door exists. Most do not. Until the upstream recipes ship secure by default, this will remain a population-scale condition hiding in plain sight on ports that every browser already knows how to reach.

Methodology and Limitations

This analysis was produced entirely from passive sources and from data already in open circulation. No active scanning, probing, authentication, or DICOM operation of any kind was performed against any host referenced here. The work is scoped to the HTTP web-interface layer, on ports including 80, 443, 8042, and 3000, and does not cover the DICOM protocol layer on ports 104, 4242, and 11112, which is the subject of Trend Micro’s May 2026 TrendAI census and is cited here as prior work rather than reproduced. Collection date June 29, 2026. Hosts are de-duplicated by IP address. Web-interface authentication state is inferred from the stored HTTP status and banner content using a conservative three-way scheme. A 401 or authentication header is counted as protected. A 200 that serves the console interface with no login-gate markup is counted as open. A 200 that serves the interface alongside login or password markup is set aside as ambiguous, because passive data cannot distinguish an open console from one that gates client-side. The open counts are therefore a floor. No host was contacted to refine this classification; it was derived entirely from responses already collected. An open classification is a strong signal but not confirmation of reachable patient data, and the text says reachable without an authentication challenge, never breached or accessed. OHIF viewer presence is reported separately from backend data exposure, because a static viewer being reachable is not itself a leak. The monoculture finding is evidenced by shared favicon hashes across unrelated hosts, and is firm for OHIF and partial for Orthanc, where most consoles do not report a favicon. Organizational attribution is best-effort from autonomous-system registration, reverse DNS, and certificate metadata, which can be stale or inaccurate, and is graded accordingly. Counts are independently derived; figures attributed to Trend Micro are theirs. Organizations are not named, a deliberate editorial choice that keeps a published analysis from doubling as a target list while the same systems sit in the same circulating data.